В этой статье мы сравним функциональность Git в IDE Visual Studio 2022 и в других клиентах Git с GUI. Git внутри VS2022 имеет упрощённый интерфейс по сравнению с некоторыми другими GUI-клиентами наподобие MeGit/EGit и SourceTree. Это привлекает многих разработчиков к платформе VS2022/Git, однако опытным пользователям дополнительно потребуются и другие инструменты.

1. Введение

Git интегрирован в IDE Visual Studio, начиная с версии 2019, а в версии 2022 он получил ещё больше возможностей и постепенно становится любимым инструментом для контроля версий в Visual Studio/Microsoft. В этой статье мы планируем рассмотреть базовые функции GUI-инструментов Git в VS2022.

▍ 1.1. GUI-клиент Git MeGit/EGit для сравнения

Я считаю, что автономный GUI-клиент Git MeGit/EGit ^[1] — это «правильный Git». Это GUI-инструмент Git, но из всех виденных мной GUI-инструментов Git он ближе всего к «философии и терминологии Git», а ещё мне нравится его поведение и внешний вид. Поэтому я буду использовать его как пример, чтобы лучше показать, как могут выглядеть GUI-опции по сравнению с GUI VS2022. Разумеется, настоящим примером должен быть интерфейс командной строки Git, но мне кажется, что в рамках этой статьи сравнивать с ним было бы слишком сложно. Правда в том, что ни один GUI-инструмент Git не может предоставить всех опций, имеющихся у интерфейса командной строки Git. Но справедливо и то, что пользователю, вероятно не потребуются все эти опции для повседневной работы. Например, я уже много лет работаю с TFS и делаю всё из GUI; при этом мне ни разу не приходилось использовать командную строку TFS ^[2].

▍ 1.2. Философия Git в VS2022

Изучив GUI-интерфейс Git в VS2022, я пришёл к выводу, что его разработчики имели собственное мнение о том, как должен выглядеть Git. Похоже, они не хотели следовать философии Git во всех подробностях как, например, разработчики MeGit/EGit. Кажется, они думали, что все грязные подробности Git следует максимально скрыть от разработчиков; интерфейс пользователя упростился настолько, чтобы разработчики без знаний Git, имеющие лишь базовые знания концепции контроля версий, могли пользоваться им и коммитить свою работу локально и на сервер контроля версий. Возможно, это был умный подход, благодаря простоте изучения быстро привлёкший к платформе VS2022/Git множество пользователей/разработчиков. Однако некоторым опытным пользователям Git может не хватать некоторых инструментов/опций или может показаться, что Git реализован неправильно.

▍ 1.3 GUI-клиент Git SourceTree для сравнения

Приложение Atlassian SourceTree ^[3] — это ещё один популярный GUI-клиент Git. Мы покажем, как его панели выглядят по сравнению с VS2022 в одних и тех же операциях. Мы считаем, что MeGit/EGit чуть более мощен и больше соответствует «философии работы Git». Разработчики SourceTree, аналогично разработчикам VS2022, решили сокрыть часть «внутренностей Git», например, информацию HEAD и Refs. Тем не менее, приложение отображает больше информации, чем VS2022.

▍ 1.4 Git не интуитивен для обучения

Я уверен, что многие разработчики попробуют «проложить себе дорогу к Git», просто осваивая GUI-опции Git в VS2022, особенно те, кто пришли с других систем контроля версий, например TFS. И до определённого уровня это сработает, поскольку VS2022 намеренно скрывает некоторые концепции Git, например, staging файлов (обычно пользователи TFS задаются вопросом: что такое staging и зачем он нужен?). Но я считаю, что рано или поздно вам придётся прочитать какую-нибудь книгу по Git, потому что он имеет собственную терминологию и философию, и если у вас когда-нибудь возникнет нерешаемая проблема с Git, то вам нужно будет точно знать, что делать и как правильно решить её. Если вы учитесь при помощи освоения GUI-инструментов, то для изучения Git я рекомендую поэкспериментировать с MeGit/EGit, поскольку так вы увидите больше подробностей, которые намеренно скрывает от вас VS2022.

Это не туториал по Git
Статья не задумывалась как туториал по Git. Она предназначена для разработчиков, имеющих некоторые познания в Git и желающих увидеть, как Git выглядит сегодня в IDE VS2022.

2. VS2022 против MeGit

▍ 2.1. Методология тестирования

Мы рассмотрим один и тот же репозиторий Git из четырёх инструментов: VS2022, MeGIt, SourceTree и GitBash.

Мы локально создали проект простого приложения на C# и выбрали в качестве удалённого репозитория GitHub.


Тестирование выполнялось со следующей версией Visual Studio:

▍ 2.2. Просмотр истории коммитов в репозиторий

Одна из базовых и важных функций: просмотр пользователями содержимого их репозитория.

❒ 2.2.1. История из GitBash

Команда Git git log отображает лог всех коммитов.

Вот все коммиты текущей ветки master.


Вот коммиты всех веток с текущей веткой master.


Вот «граф», который может создавать GitBash — все коммиты всех веток с текущей веткой master.

❒ 2.2.2. История из MeGit

Вот соответствующий граф, создаваемый MeGit. Это красивая графическая визуализация.


Она выглядит аналогично «графу», создаваемому GitBash. Обратите внимание, что в графе GitBash содержалась дополнительная информация — местоположение создания «хранилища» (stash), коммит ac95254. MeGit может показать это местоположение, но только по запросу (при нажатии на конкретный stash).

❒ 2.2.3. История из VS2022

Я нашёл в VS2022 три графа истории, и все они были хуже, чем даже граф Git командной строки. Похоже, разработчики не особо беспокоились о его реализации. Панель History VS2022 фильтрует и отображает коммиты, только относящиеся к текущей выбранной ветке.

Первый граф для той же структуры репозитория с текущей веткой master выглядит так:


Есть и ещё более простая версия, без других веток:


Также существует ещё одна версия, с показанными ссылками на ветки:


Я считаю, что графы истории VS2022 хуже, чем граф истории MeGit, но опытному пользователю они могут оказаться полезными. В них можно удобно просмотреть изменения в репозитории.

Часто люди в Интернете задают вопрос: зачем вообще нужен красивый граф? Для меня ответ прост: интерфейс пользователя называется графическим, поэтому здорово иметь качественный граф, сравнимый, например, с графом истории MeGit.

К сожалению, стоит заметить, что VS2022 не показывает в графе местоположение ссылки HEAD, хотя и GitBash, и MeGit чётко отображают ссылку HEAD. Похоже, разработчики VS решили, что терминология Git наподобие ссылок HEAD должна быть скрыта от пользователей. Не уверен, что на самом деле возможно компетентно использовать Git в течение длительного времени, не зная, что такое ссылка HEAD.

❒ 2.2.2. История из SourceTree

Вот соответствующий граф, создаваемый SourceTree. Он имеет красивый графический вид.


Но разработчики SourceTree тоже решили скрыть от пользователя концепции наподобие HEAD и ссылок.

▍ 2.3. Просмотр веток, тегов, ссылок

❒ 2.3.1. Ветки, теги, ссылки в MeGit

Ветки, теги и ссылки в проекте/репозитории заметить очень легко:


Обратите внимание, что помечена текущая checkout-ветка master. Также вы видите, что ссылка HEAD ref указывает на последний локальный коммит ec56b90 ветки master.

Чтобы выполнить checkout ветки Feature1, нужно нажать на нужную ветку правой клавишей мыши и выбрать в контекстном меню опцию.

❒ 2.3.2. Ветки, теги, ссылки в VS2022

В VS2022 отображается более скромная информация:


Насколько я понимаю, список тегов недоступен сам по себе, а применённые теги видны только в графе истории. Список ссылок также недоступен, разработчики решили, что он слишком низкоуровневый и не нужен, поэтому скрыли эту информацию.

Обратите внимание, что текущая checkout-ветка master выделена жирным шрифтом. Кроме того, текущую checkout-ветку можно увидеть в правом нижнем углу.


Чтобы выполнить checkout ветки Feature1, нужно нажать на нужной ветке правую клавишу мыши и выбрать в контекстном меню опцию.


Кроме того, вы можете выполнить checkout ветки во всплывающем меню в правом нижнем углу:

❒ 2.3.3. Ветки, теги, ссылки в SourceTree

Ветки и теги проекта/репозитория легко заметны, однако ссылки в GUI не отображаются. Разработчики тоже решили скрыть подробности Git от пользователя.


Обратите внимание, что текущая checkout-ветка master выделена жирным шрифтом.

Чтобы выполнить checkout ветки Feature1, нужно нажать на нужную ветку правой клавишей мыши и выбрать в контекстном меню опцию.

▍ 2.4. Просмотр состояния Detached HEAD

Просмотреть состояние «Detached HEAD» легко. Достаточно выполнить checkout коммита, не находящегося на конце ветки, а затем закоммитить новые изменения. Давайте посмотрим, как отображается такое состояние.

❒ 2.4.1. Detached HEAD в MeGit

Вот как выглядит состояние Detached HEAD в панели History:


Как видите, HEAD указывает на коммит 40c21ff, а не на конец какой-то ветки. В терминологии Git этот коммит находится в состоянии Detached HEAD. В панели просмотра веток это представлено в следующем виде:


Обратите внимание, что ни одна ветка не отмечена как выбранная, а ссылка HEAD содержит значение id этого коммита 40c21ff.

❒ 2.4.2. Detached HEAD в VS2022

Теперь взглянем на ту же ситуацию с репозиторием в VS2022. Вот как она выглядит в панели Branches:


Обратите внимание, что ни одна ветка не выделена жирным шрифтом. то есть ни одна не является checkout-веткой.

Кроме того, состояние Detached HEAD отмечено в правом нижнем углу:


Как мы видим, все упоминания ссылки HEAD в VS2022 избегаются, хотя интуитивно непонятно, что происходит с репозиторием и как устранить состояние Detached HEAD. Именно поэтому я считаю, что пользователь должен обладать реальными познаниями Git, а инструменты, скрывая от него концепции Git, не помогают ему в этом.

❒ 2.4.3. Detached HEAD в SourceTree

Вот как выглядит состояние Detached HEAD в панели History:


Как видите, HEAD указывает на последний коммит, а не на конец какой-то ветки. Хэш коммита можно увидеть в нижней панели, он равен 40c21ff. В терминологии Git этот коммит находится в состоянии Detached HEAD. Любопытно, что разработчики внезапно отображают нечто под названием HEAD, хотя до этого скрывали эту концепцию в приложении.

В панели просмотра веток это представлено в следующем виде:


Обратите внимание, что ни одна ветка не помечена как выбранная.

❒ 2.4.4. Намеренное создание «висячего коммита»

Допустим, мы решили устранить состояние Detached HEAD, выполнив checkout ветки master и оставив новый коммит 40c21ff висячим. Доступ к такому коммиту невозможно получить ни по какой из ссылок и он не будет больше отображаться в History.

❒ 2.4.5. Восстановление висячего коммита/Detached HEAD в MeGit

Теперь в истории и ветках отображается checkout-ветка master, а упоминания коммита 40c21ff отсутствуют.



Что, если мы совершили ошибку и теперь хотим восстановить висячий коммит 40c21ff? Это возможно, мы можем найти его в панели Reflog:


Можно нажать на него правой клавишей мыши и выбрать опции меню для его восстановления:


И мы снова оказались в ситуации, когда этот коммит 40c21ff является checkout и мы можем делать всё, что угодно.

❒ 2.4.6. Восстановление висячего коммита/Detached HEAD в VS2022

Вот как та же ситуация выглядит в VS2022:


Теперь в истории и ветках отображается checkout-ветка master, а упоминания коммита 40c21ff отсутствуют. Можем ли мы выполнить восстановление коммита 40c21ff? Проблема в том, что в VS2022 нет панели Reflog.

Этот коммит 40c21ff по-прежнему находится в репозитории, однако через GUI VS2022 доступ к нему получить невозможно.

Для опытного пользователя это может быть проблемой и ему может понадобиться использовать другой инструмент для выполнения нужных действий. Разработчики VS2022 посчитали, что такие ситуации настолько редки, что среднестатистическому пользователю никогда не доведётся с ними сталкиваться.

❒ 2.4.7 Восстановление висячего коммита/Detached HEAD в SourceTree

А вот как выглядит теперь ситуация в SourceTree. Теперь в истории и ветках отображается checkout-ветка master, а упоминания коммита 40c21ff отсутствуют.


Как нам восстановить коммит 40c21ff? Проблема в том, что в SourceTree нет панели Reflog. Но в нём есть значок для запуска GitBash, поэтому из командной строки мы можем получить нужную нам информацию, а именно хэш коммита:


Итак, мы можем выполнить в командной строке git reflog и получить нужный хэш:


Получив хэш висячего коммита, мы обходными путями можем восстановить этот коммит. Мы создадим новую ветку, содержащую этот коммит.




После выполнения checkout этого коммита 40c21ff, на этот раз как части новой ветки, мы можем делать всё, что угодно.

▍ 2.5. Просмотр панели Unstaged-файлов/Staged-файлов/коммитов

Одна из основных функций GUI Git — выполнение коммитов работы в репозиторий.

❒ 2.5.1. Панель Unstaged-файлов/Staged-файлов/коммитов в MeGit

MeGit, в соответствии с философией Git, имеет отдельные формы Unstaged- и Staged-файлов.

Здесь вы видите, что были внесены изменения в файл ClassA.cs, а Git указывает изменения в форме Unstaged-файлов («Working directory changes»):


Но чтобы выполнить коммит (обратите внимание, что кнопка Commit недоступна), необходимо использовать значок «плюс» и добавить изменения в форму Staged-файлов, после чего можно будет выполнить коммит изменений в репозиторий.

❒ 2.5.2. Панель Unstaged-/Staged-файлов/коммитов в VS2022

VS2022 в качестве диалогового окна коммитов по умолчанию отображает опцию выполнения коммитов файлов непосредственно из «Working directory changes» (Unstaged-файлов):


На самом деле, это соответствует правилам Git, поскольку такая команда существует в командной строке Git. Это схоже с выполнением git commit -am "<commit message>.

Если вы хотите просмотреть форму «Staged files» и выбрать, для каких файлов нужно выполнить stage и коммит, нужно использовать значок «плюс» и добавить в Staged те файлы, коммит которых нужно выполнить:


Теперь диалоговое окно коммитов выглядит как диалоговое окно MeGit.

Разработчики VS2022 решили «срезать углы», отображая непосредственный коммит в форме «Working directory changes».

Обычно пользователи задаются таким вопросом: зачем мне нужно сначала выполнять Stage файлов? Ответ прост: это необязательно, это только опция для ситуаций, когда, например, вы изменили пять файлов, а хотите закоммитить только три из них. Такую ситуацию можно разрешить, выполнив Staging этих трёх файлов и закоммитив только staged-файлы.

❒ 2.5.3. Панель Unstaged-файлов/Staged-файлов/коммитов в SourceTree

SourceTree, в соответствии с философией Git, имеет отдельные формы для Unstaged- и Staged-файлов.

Здесь вы видите, что были внесены изменения в файл ClassA.cs, а Git указывает изменения в форме Unstaged-файлов («Working directory changes»):


Однако для выполнения коммита (обратите внимание, что кнопка Commit недоступна) нужно использовать кнопку Stage Selected и добавить изменения в форму Staged-файлов, после чего можно будет закоммитить изменения в репозиторий.

2.6. Просмотр Stash

В обоих инструментах есть удобные панели для просмотра «хранилищ» (stash).

❒ 2.6.1. Stash в MeGit

Список всех stash в репозитории:


Выберем один stash, Stash с индексом [0]. Тогда мы сможем просмотреть подробности об этом stash:

Местоположение в истории, когда был сделан stash:


Подробная информация об этом stash:


Разница в файлах, демонстрирующая изменения по stash:

❒ 2.6.2. Stash в VS2022

Список всех stash в репозитории:


Выберем один stash, Stash с индексом [0]. Тогда мы сможем просмотреть подробности об этом stash:

Подробная информация об этом stash:


Разница в файлах, демонстрирующая изменения по stash:


VS2022 не содержит опции отображения позиции в графе истории, где был сделан stash. Похоже, кто-то из разработчиков VS2022 ненавидит графы истории Git.

Вы можете задаться вопросом: зачем вообще нужно видеть эту информацию в графе? Для меня ответ прост: он называется графическим интерфейсом пользователя, поэтому было бы здорово видеть эту информацию в графе.

❒ 2.6.3. Stash в SourceTree

Список всех stash в репозитории:


Выберем один stash, Stash с индексом [0].

Разница в файлах, демонстрирующая изменения по stash:

2.7. Просмотр Blame

▍ 2.7.1. Blame в MeGit

Найти функциональность Blame немного сложно, потому что на этот раз MeGit использует не термин Git «Blame», а «Revision information». Всё выглядит хорошо:


Как вы видите, мы смотрим на файл Program.cs и на строку 12. Последний раз её изменял автор MarkPelf в коммите cef7440, а ниже показана подробная информация об этом коммите, в том числе и граф истории.

Также мы видим diff файла для этого коммита cef7440.

▍ 2.7.2. Blame в VS2022

Для того же сценария (файл Program.cs и строка 12) VS2022 изначально показывает меньше информации, но можно нажать правой клавишей мыши, чтобы получить больше информации о том, кто и в каком коммите в последний раз менял эту строку:

Экран Blame:


Нажмём правой клавишей мыши на интересующей нас строке кода:


Подробности коммита cef7440:


Граф истории для коммита cef7440:

▍ 2.7.3 Blame в SourceTree

Для того же сценария (файл Program.cs и строка 12), SourceTree изначально показывает меньше информации, но можно нажать правой клавишей мыши, чтобы получить больше информации.


Нажмём правой клавишей мыши на интересующей нас строке кода:


Подробности коммита cef7440:

3. Заключение

В этой статье я привёл краткий обзор GUI-интеграции Git в IDE VS2022 и сравнил её с GUI-клиентами Git MeGit/EGit и SourceTree. Мы показали, что UI клиента MeGit более подробен и ближе соответствует «философии и терминологии Git». Мы показали, что разработчики VS2022 решили пойти по пути упрощения UI Git для пользователя и что многие внутренности Git спрятаны от пользователя.

Это хорошо тем, что привлекает к платформе Git множество новых разработчиков и стимулирует их переходить на Git благодаря простоте UI и удобству обучения. Плохо это тем, что некоторые важные концепции Git наподобие ссылок HEAD скрыты от пользователя, а некоторые опции Git намеренно ограничены. Опытным пользователям Git могут понадобиться другие инструменты Git, например, GitBash или какой-то другой GUI-клиент Git (MeGit/EGit ^[1], Sourcetree ^[3]), чтобы лучше понимать свои репозитории и выполнять сложные операции, не поддерживаемые GUI Git в VS2022.

Ясно одно — интеграция Git в IDE VS2022 определённо повысит популярность системы контроля версий Git.

4. Ссылки

• [1] https://github.com/eclipsesource/megit
• [2] https://docs.microsoft.com/en-us/azure/devops/repos/tfvc/use-team-foundation-version-control-commands?view=azure-devops
• [3] https://sourcetreeapp.com/