Разработчикам несомненно надо уметь работать с Git и делать это через командную строку. Иногда бывают ситуации, когда просто нет возможности установить на машину альтернативный инструмент с графическим интерфейсом. При этом некоторые задачи удобнее выполнять в специализированных приложениях, и никто не запрещает использовать GUI в собственных проектах.
В этой статье собраны самые популярные графические интерфейсы Git. Есть как бесплатные инструменты с открытым исходным кодом, так и проприетарные решения с дорогими лицензиями. Некоторыми клиентами из статьи я пользовался сам, чтобы в итоге выбрать удобный вариант для своих задач.
GitHub Desktop
Официальный клиент GitHub от разработчиков сервиса. С его помощью можно создавать репозитории, управлять запросами на включение кода, редактировать файлы и сравнивать изменения во встроенном редакторе кода. Для более удобного и быстрого изменения предусмотрена функция быстрого перехода в редактор по умолчанию, который можно выбрать в настройках. Также можно выбрать предпочитаемый терминал из установленных на машине.
Файлы автоматически подтягиваются из директории репозитория, но работает и перетаскивание. В остальном GitHub Desktop довольно минималистичный и предоставляет только базовый набор инструментов для работы с удалёнными репозиториями. В нём нет подробных графиков и визуального отображения истории веток. Также клиент работает только с GitHub, что заметно ограничивает сценарии его использования.
GitHub Desktop разработан на языке TypeScript, с использованием фреймворков React и Electron. Код проекта открыт, поэтому желающие могут дорабатывать его и подстраивать под собственные задачи.
???? Цена: бесплатно
???? Платформы: Windows, macOS и неофициальные сборки под Linux
Sourcetree
Sourcetree — ещё один бесплатный Git-клиент, только в этом случае разработан компанией Atlassian, которая также поддерживает проекты Jira, Confluence и Bitbucket. У инструмента всё такой же простой интерфейс, как у GitHub Desktop, но уже с подробной визуализацией истории веток. Поддерживаются все привычные функции работ с Git.
Sourcetree можно использовать с репозиториями Git и Mercurial, что расширяет круг потенциальных пользователей. Также разработчики из Atlassian добавили интеграции с экосистемой Bitbucket и Jira. Поэтому, если в компании используют именно этот стек для планирования и разработки, то пользователям будет удобнее работать сразу с настроенными интеграциями.
Из минусов можно отметить, что Sourcetree достаточно простой и может показаться бесполезным для продвинутых пользователей, привыкших к специализированным инструментам с расширенными возможностями. Также важно отметить, что Sourcetree — проприетарный инструмент, поэтому в Сети нет сборок от сторонних разработчиков. По этой же причине код проекта нельзя модифицировать и дорабатывать. В остальном решение от Atlassian схоже с GitHub Desktop.
???? Цена: бесплатно
???? Платформы: Windows и macOS
GitKraken
Один из самых функциональных и продвинутых Git-клиентов от разработчиков популярного расширения GitLence для Visual Studio Code. В Gitkraken большое внимание уделяется дизайну и визуализации. Таким образом, пользователи могут видеть подробную историю коммитов в виде графика, на котором действия каждого участника проекта подсвечиваются своим цветом. Предусмотрены информативные оповещения о конфликтах слияния и интерфейс для их устранения.
Разработчики проекта уверяют, что интерфейс спроектирован таким образом, чтобы в нём могли разобраться даже новички. После опыта использования можно отметить, что в некоторых местах GitKraken может быть нелогичным и нагруженным. Для этих случаев компания предусмотрела утилиту GitKraken CLI, но тогда можно пользоваться и стандартным CLI.
GitKraken поддерживает работу с репозиториями GitHub, GitLab и Bitbucket. Вместе с этим предусмотрена возможность интегрировать популярные CI/CD и трекеры задач, к примеру, Jira или Trello. Также в GitKraken есть возможность создать несколько профилей и переключаться между ними, если с одной машины приходится работать над рабочими и собственными проектами.
Большое внимание в клиенте уделяется совместной работе. К примеру, участников проекта можно разделить на команды: разработчики, тестировщики, дизайнеры, поддержка и так далее. Каждая команда будет видеть важные для себя изменения в репозиториях. Также предусмотрена функция для быстрого онбординга новых членов команды.
GitKraken входит в GitHub Student Developer Pack, что позволяет технических специальностей бесплатно пользоваться полной версией клиента до тех пор, пока они продолжают учёбу.
???? Цена:
Free — бесплатный тариф с ограниченными возможностями;
Pro — полный тариф за 5 долларов в месяц при оплате сразу за год;
Teams — тариф для команд за 9 долларов в месяц с каждого члена команды;
Enterprise — тариф для очень больших команд за 19 долларов.
???? Платформы: Windows, macOS и Linux.
Tower
Tower — ещё один клиент с платной подпиской, разработанный компанией Fournova. Если сравнивать субъективно, то у Tower более приятный и лёгкий интерфейс, поэтому с ним легче работать. К тому же на macOS инструмент выполнен в стандартном для операционной системы дизайне. Это делает взаимодействие с Tower более интуитивным и понятным. В GitKraken, к примеру, некоторое время уходит на изучение кнопок и переключателей в окне инструмента.
В Tower также есть детализированная визуализация истории коммитов для каждой отдельной ветки. Можно просматривать все данные коммита, включая профиль пользователя, который его выполнил. Кроме этого предусмотрен детализированный режим решения конфликтов слияния. Благодаря ему разработчик может быстрее оценить ситуацию и принять решение.
Fournova большое внимание уделяет образовательной части. Поэтому на сайте можно найти много обучающих материалов по изучению Git, веб-разработки и самого Tower. Все уроки полностью бесплатные и доступны как в виде онлайн-книг, так и в виде коротких роликов. При необходимости можно скачать с сайта шпаргалки по работе с VS Code, Xcode, Tower, Git, командной строкой и другими инструментами.
Tower также входит в программу GitHub Student Developer Pack, что позволяет студентам технических направлений пользоваться премиальной версией клиента до тех пор, пока они продолжают обучение. Сборки для Linux нет, а код инструмента закрыт.
???? Цена:
Basic — 69 долларов в год;
Pro — 99 долларов в год;
Enterprise — тариф для компаний, цена обговаривается в частном порядке.
???? Платформы: Windows и macOS.
Working Copy
Полноценный и рабочий Git-клиент для мобильных устройств под управлением iOS и iPadOS. Поддерживается работа с удалёнными репозиториями на базе GitHub, GitLab, BitBucket и Gitea. Сами репозитории можно клонировать на мобильное устройство, изменять в Working Copy или сторонних редакторах кода. Клонированные репозитории доступны для редактирования без Интернета, поэтому над проектами можно работать в дороге.
Working Copy поддерживает нативные функции экосистемы Apple. К примеру, можно создавать и использовать сценарии автоматизации с помощью приложения Shortcuts. Если к коммиту сложно придумать описание, то это может сделать нейросеть.
В остальном Working Copy поддерживает основные функции Git, включая интерфейс решения конфликтов слияний. Расширенных функций в виде визуализации и аналитики нет, но само наличие Git-клиента на iOS можно считать небольшим чудом.
Учитывая все возможности Working Copy, инструмент всё равно сложно использовать для полноценной разработки и поддержки больших проектов. Для этих целей удобно использовать привычные машины, а не планшет или, тем более, смартфон. При этом инструмент может быть полезен для быстрого редактирования или исправления ошибок. Для случаев, когда не надо переписывать большие фрагменты кода.
Студенты могут бесплатно пользоваться полной версией Working Copy бесплатно, благодаря программе GitHub Student Developer Pack. В российском AppStore приложение сейчас недоступно, для установки необходима смена региона.
???? Цена: 7 долларов в месяц;
???? Платформы: iOS и iPadOS.
Fork
Fork — ещё один минималистичный Git-клиент с пользовательским интерфейсом, сочетающий в себе скорость работы и минималистичный дизайн. В macOS элементы интерфейса пытаются быть похожими на нативные, но немного отличаются. Это всё равно не должно помешать быстро разобраться и начать работать.
Важно отметить, что проект Fork развивается силой семьи разработчиков, которые вкладывают в него своё свободное время. По этой причине новые функции могут появляться не так часто. Тем не менее, заявлена полная поддержка всех основных возможностей Git. Разработчики начали проект, желая создать простой и удобный клиент для ежедневного использования. После Fork начали использовать друзья разработчиков и советовать своим друзьям.
Из дополнительных можно отметить функцию Image Diffs, которая показывает историю изменений изображений, чтобы наглядно было видно, что именно поменялось с последнего коммита. Режим будет полезен в тех случаях, когда репозиторий адаптировали и используют для работы дизайнеров.
Также есть поддержка системных уведомлений, которые сообщают об изменениях в репозиториях. Можно открывать несколько репозиториев в разных вкладках и переключаться между ними, что позволяет работать над несколькими проектами в одном окне клиента.
Fork активно обновляется, несмотря на небольшую команду проекта. Обновления исправно выходят каждый месяц. Также на сайте Fork есть блог с обучающими статьями, посвящёнными работе с клиентом, но статьи не публиковались с августа 2020 года. Вероятно, сил маленькой команды не хватает на всё сразу.
Из минусов можно отметить, что у Fork нет интеграций с популярными сервисами для отслеживания задач, а также нет привычных инструментов из более продвинутых клиентов.
???? Цена: 50 долларов единовременно;
???? Платформы: Windows и macOS.
SmartGit
SmarGit на профильных веб-сайтах называют самым популярным кроссплатформенным Git-клиентом. Инструмент доступен по подписке для Windows, macOS и Linux. Отчасти популярность SmartGit обусловлена тем, что инструмент поддерживает работу не только с Git, но и со SVN.
Пользователям доступны функции управления репозиториями, редактирования кода, разрешения конфликтов слияния и работа через SSH. В SmartGit, как и во многих других клиентах, доступно перетаскивание файлов и веток, что ускоряет работу и делает её более интуитивной.
Из минусов пользователи отмечают отсутствие интеграций с популярными трекерами задач и поддержки привычных функций из других клиентов. Также имеющиеся функции не всегда интуитивны и для их понимания надо обращаться к документации. Вместе с этим обращают внимание на сравнительно высокий порог входа, не такой высокий, как в CLI-клиентах, но выше, чем в более красивых. Новичкам это может создавать дополнительные трудности при освоении.
???? Цена: 182 доллара при единовременной оплате лицензии с трёхлетней поддержкой или 59 долларов ежегодно при выборе подписки;
???? Платформы: Windows, macOS и Linux.
Gitnuro
Gitnuro — бесплатный и кроссплатформенный Git-клиент с графическим интерфейсом. Авторы проекта отмечают в репозитории, что хотели разработать открытый инструмент, который был бы полностью бесплатным, а отсутствие подписки не ограничивало бы пользователей в возможностях.
Клиент пока ещё находится на стадии разработки, но уже сейчас поддерживает все основные инструменты для работы с Git-репозиториями. Также в Githuro нет многих модных фич из больших платных клиентов. Есть поддержка визуализации истории веток, но не более этого. Интеграции со сторонними сервисами не поддерживаются и маловероятно, что когда-нибудь будут.
Главный плюс Gitnuro заключается в его открытости. Клиентом можно пользоваться бесплатно, а открытый исходный код позволяет изменять и подстраивать Githuro под собственные задачи, решая проблемы, которые оставили разработчики проекта. Открытый код есть, к примеру, и у GitHub Desktop, но у него изначально меньше возможностей, чем у Gitnuro.
???? Цена: бесплатно;
???? Платформы: Windows, macOS и Linux.
Комментарии (116)
mayorovp
09.06.2023 15:16+22А где Git Extensions?
dekeyro
09.06.2023 15:16-3Возможно не попал в список из-за нестабильной работы. Во всяком случае у меня он регулярно валится.
mayorovp
09.06.2023 15:16Чего-о-о? Это ж что вы с ним делаете-то...
Консольный гит у меня регулярно валился в прошлом, ибо cygwin и его приколы с разделяемой памятью. А вот падение Git Extensions я наблюдал всего пару раз, и уже не помню как оно выглядело.
DreamChild
09.06.2023 15:16Регулярно пользуюсь GitExtensions. Инструмент очень хороший, но месяца три назад вышло обновление, после которого перестал работать встроенный в него терминал.
daniilshat Автор
09.06.2023 15:16-1К сожалению, не пользовался и не пробовал Git Extensions. Своё знакомство с Git-клиентами начал с GitKraken и Tower. По большей части из-за того, что они входили в студенческий пакет ПО от GitHub. В итоге понял, что мне хватает возможностей работы с Git, доступных из IDE. Иногда пользуюсь Lazy Git, но его сложно назвать инструментом с полноценным GUI
mayorovp
09.06.2023 15:16+8А я своё знакомство с Git-клиентами начал с Git Extensions, и у меня так и не возникло повода попробовать ни одного другого клиента. Слишком уж он удобный.
Так что всё-таки лучше бы его добавить в список...
daniilshat Автор
09.06.2023 15:16+1Да, обязательно добавлю Git Extensions и выше ещё обратили внимание на Sublime Merge
SpiderEkb
09.06.2023 15:16+1На рабочем компе стгит тортуаза + git extensions. Некоторые вещи в тортуазе проще делаются - два коммита объдинить, тег перенести... А что посложнее - тут уже extensions. Пробовал что-то ещё - не зашло.
RSATom
09.06.2023 15:16+15Другой вариант использовать `git gui` и `gitk --all` - чье основное преимущество в том, что, независимо от платформы, UI почти идентичен, что несколько облегчает жизнь если приходится скакать между разными ОС.
vassabi
09.06.2023 15:16+4вот да - я попробовал и тортойз и сорстри, и встроенные гуи, и все равно `git gui` и `gitk --all` удобнее и переносимее всего этого зоопарка
LeshaRB
09.06.2023 15:16+3А та же Idea тоже позволяет работать
Мне во многих программах, не нравиться, что нельзя отображать изменения ввиду дерева, только списком
GitHub Desktop долго страдал этим
https://github.com/desktop/desktop/issues/2417Но походу исправили, я уже не смотрел
daniilshat Автор
09.06.2023 15:16+2Да, сейчас в основном пользуюсь только встроенными инструментами в WebStorm
ssv32
09.06.2023 15:16-4gui и git = плохо, только если дерево красивое посмотреть полистать, и то это можно делать в удалённом репозитории. Если начинающий изучать git человек лучше начинать с консоли.
Просто по работе (из жизни) пару раз точно видел как люди путаются (вроде стоял у них Fork), т.е. в какой то момент человек перестаёт из за gui понимать текущее состояние, gui рисует что то выдаёт ошибки и надо понимать как с ним взаимодействовать. Я к тому что человек пользующийся этим запутывается иногда при сложностях если всё идёт не просто.
А в консоли всегда всё понятно, всегда понятно текущее состояние репы и что происходит в данный момент.
И gui скорее всего внутри выполняет обычные команды git, т.е. многовесящая надстройка.
И по итогу при сложностях придётся искать именно варианты решения проблемы как в gui выкрутиться или обойти ошибку, а не работать с git (например блочится кнопка выкидывает сообщение и т.д.).
(зависит от работы, но если выкатывается на сервер то там ничего кроме консоли нет, т.е. лучше сразу изучать и пользоваться чисто консолью)
mayorovp
09.06.2023 15:16+10А вот и нет.
Когда у вас в проекте 200 добавленных файлов — очень сложно понять по одному только git status что из них 100 файлов — лишние и должны быть заигнорены. Или вот изменено 10 файлов, и тяжело вспомнить что два из них содержат временные изменения, которые не должны попасть в коммит. В Git Extensions такое видно сразу же, а вот от тех кто пользуется консолью я постоянно вижу мусорные изменения.
ssv32
09.06.2023 15:16+2"мусорные изменения" - зависят от человека, врятли тут важно консоль или gui
(какие именно изменения смотрятся как в консоли так и в gui глазами).
(у нас видимо разные сферы деятельности т.к. у меня и бинарников то нет)), а выкатываются именно исходники (php) )
Как и 100-200 файлов не появляются просто так из вакуума (так что бы вы не знали нужны они или нет) (может в начале проекта). Если не создаются лично вами, возможно скачено/добавлено готовое решение, или как то нагенерировано но причастны именно вы к этому и должны знать откуда они.
Т.е. даже в gui вы глазами наверно смотрите что надо или не надо (игнорите или делаете правила), и в консоли вы можете игнорить определённые форматы файлов или разделы, и добавлять разделы разом или файлы по маске.
(gui в моём понимание просто надстройка это чуть больше чем консоль в плане графики просто в плане визуала, и чисто лично у вас на вашем ПК делает красивости )
---
Просто сталкивался с 2мя случаями на практике, 2ва разных человека одна и та же программа Fork вроде (в разное время и разные проекты), люди не могли понять в каком состояние у них репа находится, чисто из за gui (может конечно из за недостатка знаний в Fork). Gui их запутал тем что рисовал именно он.
mayorovp
09.06.2023 15:16+5GUI — это не просто красивость, это ещё и плотность информации.
Взгляните что одновременно показывает знакомый вам Fork в окне создания коммита, и сравните что показывает git add -i
Просто сталкивался с 2мя случаями на практике, 2ва разных человека одна и та же программа Fork вроде (в разное время и разные проекты), люди не могли понять в каком состояние у них репа находится, чисто из за gui
Это очень странно. Возможно, недоработка Fork. Тот же Git Extensions прекрасно уведомляет о странных состояниях (скажем, что репозиторий посреди операции rebase)
Кстати, если уж мы начали обсуждать невнимательных коллег — я видел кучу вопросов на ruSO из разряда "ничего не работает, помогите прочитать что мне пишет git status"
nronnie
09.06.2023 15:16Если в проекте накапливается по 200 добавленных или измененных файлов, то это либо какая-то нестандартная ситуация (например, эти файлы автогенеренные), либо сам процесс работы с контролем версий (будь то git, или что-то другое) поставлен не так. Обычно коммитят гораздо раньше.
mayorovp
09.06.2023 15:16-1Это вполне себе стандартная ситуация в начале разработки.
И да, там половина файлов совершенно точно автогенерённые — а именно, результаты сборки. И если человек работает в консоли, он в такой ситуации делает
git add .и здравствуй 100 изменённых файлов в каждом коммите пока кто-нибудь с GUI их из репы не почистит.
haxecoder
09.06.2023 15:16+3логичный вопрос - нужны ли автосгенерированные файлы в репозитории?
обычно такие директории сразу уходят в gitignore
aamonster
09.06.2023 15:16+2Вот гуй и удобен для его организации. Не критично, просто чтобы сразу окидывать взглядом список и кидать что-то в индекс, а что-то в игнор. Не что-то, без чего никак – просто как сесть в удобное кресло вместо стула и сделать ту же работу, что в консоли.
mayorovp
09.06.2023 15:16Так они и не нужны. Только у пишущего
git add .не будет ни шанса вовремя заметить что он делает.С gitignore можно работать двумя способами — или докидывать в него паттерны по мере необходимости (и тогда интерактивный режим добавления файлов обязателен), либо можно взять готовый и пользоваться им, а потом внезапно обнаружить что нужный файл за каким-то фигом оказался проигнорирован. Если на проекте один разработчик — он это обычно видит когда файл уже потерян.
KvanTTT
09.06.2023 15:16+4Это нормальная ситуация - рефакторинг, переименование глобальной сущности, которая используется почти везде.
zloddey
09.06.2023 15:16+1Сударь, Вы же в консоли! Весь спектр утилит приходит на помощь:
less,grepи далее по списку. Да и команды самогоgitна банальномstatusне заканчиваются, а только начинаются. Освойте хотя быdiff,log,show, и поймёте, что без гуя можно вполне неплохо жить.Зачем, к примеру, "вспоминать", какие изменения были сделаны в том или ином файле? Смотрим через
diffи понимаем.
geher
09.06.2023 15:16+4без гуя можно вполне неплохо жить.
Можно, но с ним удобнее. Особенно если нужно, например, быстро пробежаться по истории изменений или еще что подобное.
Консольные инструменты вполне удобны, когда четко знаешь, что ищешь. А при необходимости выполнить заранее неопределенную цепочку действий, каждый шаг которой порождается из результатов предыдущего (например, найти в истории коммитов и откатить или скорректировать некоторое изменение, которое могло привести к замеченным сильно позже спецэффектам в работе пиограммы), хорошо сделанный gui все же удобнее.
Сам пользуюсь в основном консолью, но в некоторых случаях пользую "родной" клиент git gui (есть в поставке git для windows, есть, наверное, в репозитории любого дистрибутива линукса) и другие графические средства, из него вызывающиеся. Их возможности не слишком впечатляющи, но мне пока хватает.
aamonster
09.06.2023 15:16Мне казалось ровно наоборот – цепочки удобнее в консоли (автоматизация), а в гуе отдельные действия, где нет команды на кончиках пальцев и надо повтыкать в экран.
Или я неправильно понял смысл слова "цепочка"?
mayorovp
09.06.2023 15:16Речь шла об интерактивной цепочке действий, на каждом шаге которой требуется решение пользователя.
mayorovp
09.06.2023 15:16+3Вот у вас в консоли git status показывает 100 изменений. Теперь вы будете git diff каждому прописывать или что?
В GUI же я вижу результат git status и git diff одновременно в одном окне, и git log с git show в другом.
zloddey
09.06.2023 15:16В обычной ситуации я буду делать либо `git diff` без аргументов (показывает все изменения, кроме новых файлов), либо `git add -p` (смотреть изменения по кускам и сразу решать, что добавлять в индекс, а что нет).
В сложной ситуации я тоже вызову гуй (обычно это
gitk, который есть везде) и попытаюсь разобраться в картине в целом.Ваш вопрос очень хорош тем, что он подсказывает, где именно могут лежать источники расхождений между любителями cli и любителями gui. Возможно, что дело в частоте, объёме и сложности просматриваемых изменений. Я давно привык уже делать собственные коммиты максимально часто (даже после самых простых изменений). Подавляющую часть времени я сижу с "чистым статусом", а когда ситуация меняется, то новые изменения либо добавляются в коммит, либо целиком отбрасываются. Последствия этой тактики такие:
Вызывать какой-либо gui на такое частое действие (временами вплоть до нескольких раз в минуту) начинает быстро надоедать. Пока программа запустится, пока отрисует ситуацию, пока голова разбертёся в этой картине, пройдёт заметно много времени.
С другой стороны, команды в cli можно набивать молниеносно быстро (привычки пальцев + алиасы по вкусу), а отсмотреть и отрешать сравнительно небольшой объём достаточно однородных изменений нетрудно.
Частые повторы позволяют закрепить привычку работать через cli. Формируется мышечная память и укрепляются маршруты в голове ("в такой-то ситуации используем такую команду").
-
Со временем это приводит к тому, что даже большие коммиты (например, чужие) становится удобнее изучать через cli (на деле, часто через cli и редактор одновременно). Гуёвые программы почти перестают использоваться.
Итого: суть удобной и эффективной работы с
gitв консоли состоит в том, чтобы стараться не доходить до ситуации, когда надо отсмотреть и порешать сотню изменений.
mayorovp
09.06.2023 15:16Вызывать какой-либо gui на такое частое действие (временами вплоть до нескольких раз в минуту) начинает быстро надоедать. Пока программа запустится, пока отрисует ситуацию, пока голова разбертёся в этой картине, пройдёт заметно много времени.
А зачем вы его закрываете? Терминал-то небось у вас открыт постоянно...
С другой стороны, команды в cli можно набивать молниеносно быстро (привычки пальцев + алиасы по вкусу), а отсмотреть и отрешать сравнительно небольшой объём достаточно однородных изменений нетрудно.
Ну да, ну да. Посмотрю я как вы молниеносно быстро
git add projects/backend/Some.Project.Name/Some/Namespace/FooCommandHandler.csнаберёте...А что до мышечной памяти — она и в gui неплохо так формируется.
nronnie
09.06.2023 15:16Да легко:
$ git add **/FooCommandHandler.csучитывая, что в реальности ситуация, что где-то еще лежит файл с таким же названием, да еще при этом и измененный крайне маловероятна. Потом, ведь, всегда можно проверить по
$ git statusчто у тебя по wildcards добавилось.
ilitaiksperta
09.06.2023 15:16+2где именно могут лежать источники расхождений между любителями cli и любителями gui.
Они лежат в религиозной плоскости. Gui - это инструмент, а консоль - религия.
Те, кто использую гуй - используют его для своих задач и все. Консольщикам же необходимо бегать всем и доказывать что консоль лучше.
geher
09.06.2023 15:16+2Они лежат в религиозной плоскости. Gui - это инструмент, а консоль - религия.
И то, и другое - инструменты, пока конкретным человеком используется то, что удобнее именно ему, или что принято использовать в конкретном проекте. А вот когда упираются в один инструмент, и настаивают на его применении всеми вокруг, а все остальное считают ересью, это уже религия. Консольщики на этом поприще более заметны только потому, что их религия древнее (консоль появилась намного раньше графического интерфейса).
ilitaiksperta
09.06.2023 15:16А вот когда упираются в один инструмент, и настаивают на его применении всеми вокруг, а все остальное считают ересью, это уже религия
Именно про это я и пишу. Только консолью такое почему-то бывает в десятки раз чаще чем с гуем. Примеров в одних только коментах тут можно насобирать.
Консольщики на этом поприще более заметны только потому, что их религия
Это мягко говоря не правда, примеров религиозного отношения к gui, я например сходу вспомнить не могу
geher
09.06.2023 15:16Только консолью такое почему-то бывает в десятки раз чаще чем с гуем.
Так их религия более древняя, более укоренившаяся. Причем современное поколение с точки зрения этой религии по большей части состоит из еретиков, что дополнительно распаляет их религиозное рвение.
Это мягко говоря не правда, примеров религиозного отношения к gui, я например сходу вспомнить не могу
А как же постоянное запугивание адом командной строки по разгым поводам?
ilitaiksperta
09.06.2023 15:16А как же постоянное запугивание адом командной строки по разгым поводам?
Ну cli действительно куда менее понятный интерфейс для людей далеких от ойти
mayorovp
09.06.2023 15:16+2Да, ещё момент.
но если выкатывается на сервер то там ничего кроме консоли нет, т.е. лучше сразу изучать и пользоваться чисто консолью
На сервер надо выкатывать артефакты после сборки, а не исходники. Даже в мире Javascript давным-давно победили транспайлеры и бандлеры.
git на сервере не нужен.
nronnie
09.06.2023 15:16git на сервере не нужен.
Например, если это сервер для CI/CD, или чтобы хранить в git конфиги (я давно так и делаю, я не админ серверов, но у меня всегда для разработки cтоит несколько виртуалок под Линуксом без GUI).
aamonster
09.06.2023 15:16+2Для коммитов, просмотра дерева, переключения веток, diff/annotate удобен гуй. Что посложнее – да, в консоли, и разбираться обязательно (отсутствие гуя не должно сильно напрягать).
polearnik
09.06.2023 15:16я бы сказал наоборот. слияние веток, откат какого-то коммита , разбор ошибок при слиянии удобнее делать в гуи. а консоль она разве что на сервере нужна чтоб делать git pull git checkout
aamonster
09.06.2023 15:16+2Слияние веток – да, тоже предпочитаю в гуе, но "посложнее" бывает сильно сложнее – например, примерно всё, что связано с git reflog (и не говорите мне, что он не нужен: я был вынужден в него полезть примерно на третий день после перехода с hg на git, разломав свою локальную репу).
В общем, git – тот ещё конструктор, и предусмотреть gui для всего, что можно из него собрать – сложно и не нужно. Плюс когда у человека возникают вопросы по git – проще ему сказать командную строку, в gui пусть сам переводит, если ему надо.
Ну и для пользования гуём крайне полезно знать, как его действия переводятся на cli. Чтобы было меньше магии в происходящем.
shaggyone
09.06.2023 15:16Плохо, если человек не имеет навыка исключительно в cli. Если навык есть, то хорошо когда есть инструменты упрощающие жизнь. Сам gui не люблю, пользовались cli, если не считать ревью на гитхабе и аннотаций в vscode.
polearnik
09.06.2023 15:16при хорошем гуи кли не нужно.
shaggyone
09.06.2023 15:16+1Вот как вы будете GUI в скриптах использовать? Или при работе по ssh или просто без X сервера? Потом, я с вами соглашусь, если вы cli все же освоили, а то видел уже людей, кто зависает на банальном рибейзе, так как в любимой гуишке этой кнопка запрятана и неудобно сделана.
AlexGluck
09.06.2023 15:16Я в вскоде пробовал ребейз через гуй сделать, всё сломалось) Пришлось в консоли.
mayorovp
09.06.2023 15:16Ну да, ну да, уж запрятана так запрятана...
alhimik45
09.06.2023 15:16Интересно, а расширенные опции на скрине содержат
--rebase-merges? Из Jetbrains Rider не нашёл как запустить такую штуку, приходилось через консоль делатьmayorovp
09.06.2023 15:16Да, содержат. Хотя лично я никогда не понимал зачем она нужна — что с неё, что без неё rebase при наличии слияний работает хреново.
polearnik
09.06.2023 15:16при работе по ssh лично мне нужно 3 команды hg pull -u hg checkout branch_nme hg update. работать с репой на сервере плохая идея. обычно там токены только для чтения реп а не записи. но при необходимости нужные команды гуглятся. с гуи вход легче. новичку проще понять что надо делать когда перед глазами есть вся история. с командами это гораздо тружнее. Когда уже есть понимание работы то загуглить как в гите смерджить ветки например уже горахдо легче. особенно если догадатся предварительно поэксперементировать на копии репы и результат контролировать через тот же гуи.
ilitaiksperta
09.06.2023 15:16+3gui скорее всего внутри выполняет обычные команды git,
Аналитика которую мы заслужили
ssv32
09.06.2023 15:16Что внутри конкретно перечисленных в статье gui я не видел (есть там лог команд гита или нет) как и не пользовался. А вывод у меня такой т.к. давно когда то пользовался TortoiseHg это тоже gui но для hg, (сейчас специально запустил перепроверить, версия 5.0.2) в нём всё что делается графически и кнопочками, внизу в консоли дублируется консольными командами (+ можно выполнить команды прямо там, без нажатия кнопок), поэтому у меня сложилось такое мнение сразу о всех gui систем контроля версий. (на картинке нажатие кнопки в gui выполнило команду внизу + какие то данные для информации вывела)
KvanTTT
09.06.2023 15:16+2gui и git = плохо, только если дерево красивое посмотреть полистать, и то это можно делать в удалённом репозитории.
Субъективное мнение.
Просто по работе (из жизни) пару раз точно видел как люди путаются (вроде стоял у них Fork), т.е. в какой то момент человек перестаёт из за gui понимать текущее состояние, gui рисует что то выдаёт ошибки и надо понимать как с ним взаимодействовать.
А я видел, что люди путаются в командах git и без gui.
А в консоли всегда всё понятно, всегда понятно текущее состояние репы и что происходит в данный момент.
Кому как.
И gui скорее всего внутри выполняет обычные команды git, т.е. многовесящая надстройка.
Ну да, как и компиляторы, конвертеры и другие инструменты - это стандартная вещь.
dark_ruby
09.06.2023 15:16+6не популярное мнение - вам не нужен гуи для гита, вам нужна дисциплина (в том числе во всей команде) чтоб не доводить ветки до такого состояния что вам понадобится гуи чтоб разобраться. В целом запрет мерджей и регулярные ребейсы на ту ветку в которую потом будет открыт мердж/пулл реквест - и все, вы великолепны!
mayorovp
09.06.2023 15:16+2Один только git pull уже создаёт слияние по умолчанию.
И любая попытка исправить это через интерактивный rebase, скорее всего, приведёт к слиянию результата rebase с исходным состоянием. Кучу раз я это наблюдал: меня просят исправить в хлам запутанную историю, я исправляю, потом коллега делает git pull и всё по новой.
Без графических инструментов слишком тяжело заметить насколько ужасна история и как в ней будет тяжело разобраться в будущем.
VadimVP
09.06.2023 15:16+1Я в
git guiсмотрю и подчищаю диффы перед тем как коммитить, очень удобно, ну и сразу коммит месседжи пишу заодно. Остальное в командной строке.
Т.е. гуи нужен, но не для веток, мерджей и ребейзов.
AndronNSK
09.06.2023 15:16Дада. Особенно он не нужен, когда в проекте 4 уровня вложенности субмодулей.
ilitaiksperta
09.06.2023 15:16+2Ну да, вам не нужен комбайн чтобы убрать пшеницу с поля. Вам нужны коса и противогаз. Добавьте много усердия - и все, вы великолепны!
baitarakhov
09.06.2023 15:16+4Пробовал разные GUI и остановился на Git-клиенте, встроенный в IDE от JetBrains.
Например из бесплатных:
IntelliJ IDEA Community Edition (https://www.jetbrains.com/idea/download/)
Android Studio на базе IntelliJ IDEA (https://developer.android.com/studio)
Платформы: Windows, macOS, Linux
Цена: Бесплатная, на базе открытого исходного кода
tenzink
09.06.2023 15:16+5На мой взгляд достаточно поверхностный обзор, хотя, возможно, у меня высокие ожидания от подобной статьи. В разное время много работал с command line, git extensions, smartgit, tortoise git.
Лично мне было бы интересно прочитать про то, как инструменты работают с большими активно меняющимися репозиториями (длинная история, много веток, тегов и разработчиков). А то бывает, прекрасный инструмент, красивый, отлично работает на игрушечном примере, но безумно тормозит как только его нагружаешь.
Интересно насколько удобно заниматься археологией - искать кто, зачем и когда изменил строку кода, при том, что код мог мигрировать из файла в файл, которые ещё и переименовывались.Удобно ли смотреть историю файла/каталога и т.п.
P.S. если честно не понял про smartgit и трекеры. Вроде как с jira работает как ожидается
SnowBearRu
09.06.2023 15:16+19А как же черепашка, TortoiseGit. Черепашка, в виде отдельных клиентов, есть и по mercurial и под svn.
SpiderEkb
09.06.2023 15:16+2Причем, черепашка стоит немного особняком т.к. она идет от того, что ты хочешь сделать. Т.е. не дублирование команд гита, но целевые действия.
К примеру, объединение двух коммитов (когда последний коммит нужно подклеить к предпоследнему) - в черепашке это просто выделить два коммита и выбрать Combine to one commit и дальше поправить описание. А во что это выльется командами?
Аналогично - перенести тег. Просто Create tag on this commit и там открыжить forse.
dedmagic
09.06.2023 15:16-1А во что это выльется командами?
git commit --amendЯ обычно описание в таких случаях не правлю, поэтому
git commit --amend --no-editmayorovp
09.06.2023 15:16+1Это до того как коммит появился. А если коммит уже создан — это
git rebase -i хеш_коммита_который_ещё_надо_найтиdedmagic
09.06.2023 15:16Да, я неправильно понял задачу, наверное из-за того, что мне ни разу в жизни не приходилось объединять два последних коммита и даже сложно представить, зачем это может понадобиться. А вот
amend– регулярно =D.хеш_коммита_который_ещё_надо_найтиВроде речь идёт о двух последних коммитах и искать ничего не надо, не?
git log -2– или я опять что-то неправильно понял?
Mingun
09.06.2023 15:16-1А мне не сложно представить. Сначала в режиме потока накидиваешь коммиты, как придется (=добился более-менее правильной работы), затем ребейзишь все добро. И "последние два коммита" здесь только для примера. С тем же успехом это могут быть "последние 3", "от последнего 10-го до последнего 6-го", и куча других вариантов
mr_bag
09.06.2023 15:16+4Пробовал Sourcetree, SmartGit, GitKraken. Последний сразу удалил - при открытии одной репы сразу скушал 1G оперативы.
Потом наткнулся на Fork и успокоился :)
Иногда открываю SmartGit.
p.s. голосовалка напрашивается ;)
TheRaven
09.06.2023 15:16+6TortoiseGit. И SVN-новая и GIT-овая черепахи просты и удобны. Плюс встроеный git в Idea.
Sourcetree пробовал, но об больше путает, чем помогает
max_dark
09.06.2023 15:16Из GUI чаще всего пользуюсь GitExtentions, но больше предпочитаю консоль - нужные команды проще найти.
Sazonov
09.06.2023 15:16+4Увы, если вам нужен кросс-платформенный клиент (с нормальным линуксом) то единственным внятным решением остается ГитКракен. Пользовался практически всем из списка, но последние года 2 покупаю ГитКракен.
Главный недостаток ГитКракена - забагованный GUI. Это хорошо проявляется на больших резпозиториях или где много файлов под LFS. Иногда тупо фризится весь интерфейс и нет возможности ничего сделать кроме как прибить и запустить заново клиент. Плохо работает с приватными сабмодулями. Часто не может сделать update, приходится открывать вручную, делать fetch, и только после этого уже в основной ветке update. Или приходится pull+gc делать вручную через консоль, а потом уже пользоваться GUI. Так же очень много мест (те же логи) где текст выделяется но не копируется.
Из плюсов - хорошо из коробки работает интеграция с GitHub/GitLab.
QtRoS
09.06.2023 15:16+1Потому что он на Electron. Есть много отличных инструментов, созданных с его помощью, но большие деревья гита ему объективно тяжело рисовать.
Sazonov
09.06.2023 15:16+2Я думаю там дело не в больших деревьях, а в тормознутости внутреннего представления данных, полученных из гита. Анимации, скролл и тп работают без проблем, я немного неверно выразился. Стейтмашина у контролов скорее кривая.
Такое чувство что под капотом самописные алгоритмы и контейнеры на js.
lorc
09.06.2023 15:16+1Лучше чем Magit еще ничего не придумали, но у него слишком большой порог входа в виде Emacs :)
Зато редактировать комиты, рибейзить, делать blame - одно удовольствие.
nronnie
09.06.2023 15:16+2А где вариант в голосовании "не пользуюсь вообще"? Я лично не пользуюсь, только, если надо быстро открыть какую-то предыдущую версию файла (тогда делаю это просто в Visual Studio), или когда надо какую-нибудь нетривиальную историю посмотреть (редко нужно, а так, обычно самого банального
git logхватает). Стоит только модуль Posh-Git для PowerShell.
dizjis
09.06.2023 15:16Также клиент работает только с GitHub, что заметно ограничивает сценарии его использования.
GitHub Desktop прекрасно работает с любым репозиторием. В том числе - удаленным. Я в частности его совместно с gitea использую
tov_jukov
09.06.2023 15:16Не упомянут GitAhead, к которому вопросы есть, но он от этого хуже не работает.
crackedmind
09.06.2023 15:16Какие вопросы? Ну и кстати он заброшен, но есть форк под названием gittyup
Kiel
09.06.2023 15:16+1Я просто использую Git в Visual studio. Единственное для чего открываю bash это git clean -xfd и сделать очередной ssh. Установлен GitExtensions, но как то не требуется. Пару раз использовал чтобы удалить много веток одновременно.
Использовать какие то еще инструменты, да еще и платить за них кажется совсем излишеством. Да и Microsoft действительно постаралась, чтобы сделать мою жизнь в VS максимально комфортнойmayorovp
09.06.2023 15:16+1Когда я последний раз проверял Git в Visual studio — он не умел работать с worktree :-(
santjagocorkez
09.06.2023 15:16-5Вы — не
Googlekernel.org. Вам не нужно5 алгоритмических панелей на собеседованииничего из git, тем более, что Торвальдс сумел сделать его интерфейс полным гуано. Хватит любого DVCS, в котором интерфейс сделан от "что я хочу получить" вместо гитового "как будет выглядеть бинарный дифф состояния репы". Например, mercurial.Впрочем, неудивительно, что полную профнепригодность Торвальдса в разработке сложных пользовательских интерфейсов (даже текстовых) все, включая меня, вынуждены приводить к благопристойному виду с помощью оберток, например, GUI.
zloddey
09.06.2023 15:16Профнепригодность, скорее, у Вас, если Вы не можете пострянно обходиться без костылей.
git- это довольно простой инструмент, с компактной и логичной моделью работы. Благодаря его распределённости, все нюансы его работы можно освоить на практике (в дополнительных копиях своих репозиториев или вообще на фейковых данных). Простоту освоенияgit, среди прочего, подтверждает и тот факт, что за последние 10+ лет он стал практически доминирующим VCS, победив и былых гигантов вроде SVN, и всех компетиторов типа HG.Казалось бы, можно выделить себе время на освоение инструмента, почитать доки, поэкспериментировать, разобраться как что работает. Поднять собственную эффективность в работе с кодом, получать удовольствие от работы. Но нет! Мы вместо этого будем добровольно сидеть в яме страдания, мечтать о несбыточном и ругать Линуса.
santjagocorkez
09.06.2023 15:16-3Логичный интерфейс, говоришь? Работаю с историей. Хочу откусить и выкинуть два последних коммита в текущей ветке (благо, они только локальные). Может быть, команда будет из серии git log? Нет же, git reset. Очень логичный интерфейс, да. Рассказать, как называется команда для откатывания коммита в mercurial? rollback. Невероятно, тупые питонисты придумали название команды, точно отражающее суть того, что произойдёт с объектной моделью. Не суть бинарного диффа между состояниями репозитория до и после, как в git, а суть понятных человеку изменений.
Ладно, бранчи. Без них же никуда. Тонким слоем по всей системе команд. branch при этом самая малая часть. Что-то в rebase, что-то в pull, что-то в checkout.
Да и вообще, зачем мне эти ваши ребейзы, черрипики, сквоши, прочий хлам? Мне пять коммитов вместо одного глаз не режут. Черрипик я попробовал, спасибо, потом пришлось сносить ветку к чертям и запускать заново, ведь это в гите мерж по сути, взять потом что-то ещё из середины источника в ту же ветку уже не получится. Ребейзы "с красивой историей и подворотами" мне не упали, смержилось — и хорошо. Конечный результат один. А сотен тысяч коммитов, как у Торвальдса, у нас нет, как я уже говорил, вы — не kernel.org. git вам не нужен. Другое дело, что тот же меркуриал медленный, а потому гитхаб столько же одновременных операций с ним, сколько тащит с гитом, не вытянул бы. А у свн проблемы с конкуррентностью. Вот это настоящие причины того, что все сейчас на гите сидят, а не мифическая простота его освоения и использования. Но на селф-хостед гит — это из пушки по воробьям, да ещё и калечить себя его убогим интерфейсом.
Что же до документации. Вот только сегодня смотрел. Что означает git tag -a? Нет, я читал, что в документации написано, что означает "annotated"? И такой магии — полон гит.
Ах да, как в нём сделать шаблон сообщения для тэга? Для коммита есть. Для тэга нет. Л — логика. https://www.selenic.com/mercurial/hgrc.5.html#committemplate Вот, внизу перечень команд, на которые шаблон распространяется. Фактически, все.
В общем, верни собаку.
tenzink
09.06.2023 15:16+4Раз много коммитов вам не режут глаз, то для отката есть команда с очень говорящим названием git revert. Замечательная команда rollback в mercurial (переписывающая историю) уже давно deprecated, и, внезапно, рекомендованный способ похож на используемый в git
В самых частых сценариях, конечно, не нужны ни rebase, ни cherry-pick, ни squash (я так понял, что вы про interactive rebase). Вы можете их не знать и отлично работать, но я очень рад, что эти инструменты есть. Иногда очень помогают.
cherry-pick вы, похоже, не поняли. К merge он никакого отношения не имеет. В документации самой первой строчкой написано, что он используется для применения изменений из существующего коммита. Как говорится, RTFM
Ещё вы пишете, что документация git вас не устраивает. Но пример, который вы приводите вызывает вопросы. В документации к команде git tag (https://git-scm.com/docs/git-tag) очень понятно описано что такое "annotated" tag в секции Description. Раз вы не читаете документацию (как и в случае с cherry-pick), то никакая документация вам не поможет
KvanTTT
09.06.2023 15:16+2Хочу откусить и выкинуть два последних коммита в текущей ветке (благо, они только локальные). Может быть, команда будет из серии git log? Нет же, git reset.
Ну reset - это откат на какое-то прошлое состояние, тоже вполне логично. В любом случае, это запоминается за пару раз и больше такой вопрос не возникает.
Да и вообще, зачем мне эти ваши ребейзы, черрипики, сквоши, прочий хлам? Мне пять коммитов вместо одного глаз не режут.
Вас никто не заставляет их использовать. Но мне это часто нужно.
zloddey
09.06.2023 15:16Я прошу прощения за, возможно, излишне резкий тон своего предыдущего комментария. Хотел подколоть намёком, но вышло грубовато. Это не было целью. Попробую в этот раз обойтись без намёков.
В своей повседневной работе мы постоянно имеем дело с очень сложными системами: IDE, компиляторами, VCS, ОС, браузерами, сетями, своим собственным разрабатываемым кодом и т.п. (у каждого своё). Ни одну из них невозможно "поместить в голову" целиком, со всеми тонкостями и нюансами. Поэтому мы неосознанно и автоматически используем упрощённые представления об этих системах - их ментальные модели. Хорошая модель позволяет без напряга и с хорошей точностью предсказывать реакцию системы на то или иное внешнее воздействие.
Но если мы пытаемся применить модель одной системы к другой, она может не подойти. Это начнёт приводить к ошибкам ("что-то сделал, и всё сломалось"), а оттуда к раздражению. Иногда модель можно поправить под новую систему простыми "патчами", но это возможно не всегда.
В таких случаях нужно иметь смелость признать, что текущая модель не подходит, выкинуть её - и попытаться осознанно выстроить новую на другом основании. На мой взгляд, такой навык является одним из ключевых составляющих профессионализма (Ваш же термин).
Судя по тому, что Вы постоянно сравниваете "неправильный"
gitс "правильным"hg, мы имеем место именно с неподходящей моделью. Подумайте, оправданно ли держаться за неё в 2023 году? Войны DVCS отгремели годы назад, победитель определён, и альтернативные инструменты нужны, разве что, для каких-то узких, нишевых кейсов. Оптимизировать свои модели под широкую область или под нишевую - это и есть тот добровольный выбор, про который я писал выше.
IntActment
09.06.2023 15:16Для повседневных нужд использую встроенный в Visual Studio гит. Да, в нем многого нет, но мне нравится его киллер-фича - поддержка синтаксиса в диффе (а с решарпером можно смотреть локальное изменение, не отрываясь от строчки в исходнике). Для всего остального - гит через консоль.
lrrr11
09.06.2023 15:16+1тривиальные вещи делаю в sublime merge, это просто быстрее. Нетривиальные - через cli.
Еще пользуюсь lazygit, для случаев когда что-то делаю по ssh.
KvanTTT
09.06.2023 15:16А где-нибудь есть поддержка worktree, за исключением GitExtensions (хотя и там она ограниченная)?
Mingun
09.06.2023 15:16TortoiseGit не умеет их создавать, но отлично умеет работать с существующими, сам активно их пользую. Под msys2 может не видеть worktree, если путь в служебном файле в каталоге с worktree указан в стиле unix (через
/<диск>/<путь>, в таком виде он создаётся консольным git'ом из msys), тогда просто вручную меняем его на путь в стиле Windows (<диск>:\<путь>) и всё работает.KvanTTT
09.06.2023 15:16А, ну так IDEA тоже отлично с ними работает, но не умеет создавать. Интересует создание.
DrMefistO
09.06.2023 15:16Вообще-то SmartGit бесплатен для некоммерческого использования.
Пользуюсь им уже лет 6 и крайне доволен. Пробовал Кракен, Форк, и Саблайм Мерж, но что-то не прикалывают эти Электрон-based приложения своей хипстерностью (знаю, Merge не на Электроне)...
BeardedBeaver
09.06.2023 15:16+1Они недавно поменяли требования к некоммерческой лицензии, теперь надо "проводить большую часть времени, работая над опенсорсными проектами" и запрашивать некоммерческую лицензию, убеждая syntevo что тебе положено. Раньше была бесплатная версия для некоммерческого использования с обычной галкой. А так клиент реально лучший из тех гуев, что я пробовал.
andToxa
09.06.2023 15:16+1Электрон-based
Fork — это .NET-приложение.
ilitaiksperta
09.06.2023 15:16Это 2 отдельных приложения на самом деле. Под винду на .NET, под мак на свифте и cocoa.
Metotron0
09.06.2023 15:16+1Если нужно посмотреть коммиты, использую gitg. Чтобы быстро выбрать файлы для коммита, беру tig. Ещё ставил git cola, но запускал только пару раз.
rotlis
09.06.2023 15:16+1Я недавно искал GIT GUI который бы рисовал ветки так же как люди. Мне для археологии надо. Вот когда вы объясняете branching strategy проекта новичку, нарисуете вы такое же дерево как Fork или SourceTree? Пока что лучший граф я видел у https://github.com/mlange-42/git-igitt . Правда, кроме графа там всё, мягко говоря, скромно.
MeGaPk
09.06.2023 15:16пользуюсь гитом встроенный в JetBrains. В данный момент, пока еще живое, пользуюсь AppCode.
hedger
Столько всякого, а Sublime Merge не упомянули.
QtRoS
Согласен, Sublime Merge это лучшее, что появилось со времён поворота SourceTree куда-то не туда. Все самое базовое есть, в том числе удобная работа с hunk'ами для частичного коммита, основные понятия гита не переизобретает своими абстракциями, не упрощает и так простое. Дополнительно радует интеграция с Sublime Text, очень легко переходить туда-обратно.
ilitaiksperta
У Sublime Merge визуализация веток плохо сделана, на паре паралельных веток уже ничего не понятно. И лайаут неудачный, например чтобы посмотреть текущие staged\unstaged файлы, надо выделить в списке коммитов верхний пункт, изза чего постоянно путаешься, если ткнул на другой коммит в ветке.