Комментарии 40
Бред.
А чего не хватает в TortoiseGit?
Согласно небольшой статистике, собранной по коллегам, которые начинали работать с гит-ом после svn (а перед этим был tean coherence), среди тех, кто знакомился с гитом посредством черепашки, в среднем, понимание гита было гораздо хуже, чем среди тех, кто использовал gui-клиенты, у которых в центре внимания стоит дерево коммитов. Большинство пользователей черепашки вообще не понимали, что происходит, повторяли заученные действия и любое отклонение приводило в ступор. Чтобы использовать черепашку, надо очень хорошо знать сам гит и хорошо знать, куда в черепашке засунули нужное действие (местами, они там в меню расположены контринтуитивно для человека, знающего гит).
Для себя нашел идеал — GitExtensions (ддо этого пробовал sourcetree, интерфейс не понравился, хотя он на голову выше черепашки в плане понимания того, что происходит). В нём commit-диалог не идеален, но достаточен для большинства применений (не удобен только если требуется сделать очень большой коммит после массивного рефакторинга).
Отдельно прокомментирую идею автора статьи запихнуть команды гита в меню вокруг мышки. По моему, это вкусовщина, сформированная вокруг увлечений автора. Напоминает приблуды, которые шли в комплекте с драйверами некоторых мышек. Я их сразу выключал, т.к. больше мешали чем помогали.
не удобен только если требуется сделать очень большой коммит после массивного рефакторинга
А что именно неудобно и как это могло бы выглядеть?
Ну например если файл больше 5 метров — приходится нажимать на кнопку "показать изменения" после добавления в индекс каждой строчки. А также после любого переключения на другой файл.
Если измененных файлов дофига — то команда Stage All может повиснуть ничего не сделав (я так понимаю, там каждый файл передаётся отдельным параметром в git add, и зависает сам процесс формирования этой команды). В таких случаях приходится добавлять файлы группами.
Наконец, функциональность добавления отдельных строк конфликтует с отображением изменений без учёта форматирования. Иногда сформировать нужный патч для частичного коммита становится очень сложно.
Но это всё редкие ситуации, для большинства применений GitExtensions идеальны.
Не знаю, на вкус и цвет. Пользовалься черепахой с svn, сейчас с гитом. Если запускаю Линукс, то очень страдаю без черепахи. Наверное, просто привычка.
Ща крамолу скажу, но мне кажется Gui для scm — это зло. Постоянно сталкиваюсь с тем, что джуны не умеют работать с git, не понимают как он устроен, каким образом на основе него можно решать ежедневные насущные задачи (ревью, изоляция дефектов, управление релизами и т.д.). Я заметил, что ситуация сильно улучшается за пару недель, если настаивать на использовании консоли. Мне кажется, люди просто начинают думать о scm как о базе данных и меньше как о файловом сервере. Конечно всегда будет ниша, но… Что касается Gui, мне кажется сейчас огромная дыра с точки зрения usability в области review. У Github, Gitlab и Atlassian интерфейс заточен под маленькие ревью — 5 строчек и три файла, из-за чего приходится резать изменения на маленькие коммиты, чтобы хоть как-то протащить их через ревью. В Gerrit процесс был более годный, подразумевающий колаборацию через код. Если посмотрите в open source проекты на github, там редко идут дебаты в ревью, большей частью люди общаются в issues. Мы вот недавно переехали с Gerrit/Jenkins на Gitlab и ревью доставляют страдания. Одно время даже думали в обратную сторону мигрировать…
Пользовали коробочный гитлаб на крупном проекте, в котором реквесты были по 100 изменнных файлов. Полет нормальный, особенно на последних версиях. На битбакете (тоже коробочный) тоже неплохо, но сам процесс дискуссии изменений хромает в отличии от гитлаба. Но и мы не на последней версии конечно (
Все правильно говорите. Насчёт геррита и прочего.
А гитлаб — он заблудился. В поиске себя и в пилении новых фич (но никак не закрытии старых бесящих всех багов или вылизывание уже существующих фич). К сожалению, чем больше я на это гляжу, тем меньше я могу порекомендовать гитлаб для разработки в промышленных масштабах
Это помогает, согласен.
Использовать же консоль при работе на большом проекте, с нормальным уровнем версионного менеджмента, и со сложной версионной политикой. Это себя не любить, банально не удобно и черевато ошибками
А уже разбор полетов…
Тут порекомендовали гит кракен, примкну к рекомендации, годная вещь, в сложных вещах не заменима.
Насчет пул реквеста не понял в чем проблема, у атласиона он нормальный, размер ревью не шибко на что влияет
согласен полностью с тем, что обучение гита лучше начинать с консоли. Фишка консоли именно в том, что там ты должен использовать оригинальные команды гита как они есть, а не кнопки, которые не всегда делают очевидные вещи. Идея колеса с командами в данной статье как раз пришла именно оттуда — суть колеса в том, что оно отображает команды один в один без искажений.
но мне кажется Gui для scm — это зло
GUI, как ни странно, позволяет некоторые задачи решать удобнее и быстрее, чем консоль.
Вот и в случае git иногда таки запускаю в консоли команду git gui.
Кстати, для меня это почему-то оказалось лучшим gui клиентом для git. Оно не идеально, да и ошибок хватает, но лучше пока не нашел. Другие клиенты вроде и возможностей больше дают, и удобств всяких, но почему-то что-то все время мешает более-менее комфортно ими пользоваться.
Очень давно юзаю гит экстеншен. Все очень даже неплохо и удобно
git консольный + gitk для графического дерева коммитов (но можно и в консоли тоже) + meld для диффов/мерджей.
https://git-scm.com/download/gui/linux
Прямо все плохи, даже коммерческие?
Эмоджировать хеши, это плюс! А так, похоже gitlens по vscode очень неплох.
В IntelliJ IDEA отличный gui для гита. А недостающие индивидуальные фичи можно реализовать в виде плагина.
По своему опыту скажу что для Windows лучший вариент — TortoiseGIT
Для Linux — SmartGIT (он вообще на java, по идее кроссплатформенный).
Пол года назад открыл для себя Fork — теперь работа с репозиторием приносит огромное удовольствие, при каждом использовании. Уже через несколько дней использования, понял, что за такое ПО хочется автора отблагодарить финансово (правда через месяц он стал платным). P.s. Слышал, что на винде есть какая-то проблема со скролом
Скачал пока попробовать, пока принципиальной разницы не увидел, попробую попользоваться может чего прояснится.
Да, с первого взгляда похож, но нет. Я бы посоветовал немного полистать блог форка, чтобы понять как с ним удобно можно взаимодействовать (помимо очевидного): https://git-fork.com/blog/. Особенно хочу выделить Quick Launch, Drag&Drop и Interactive rebase
А чем плох GitKraken? На мой взгляд лучший GUI.
Ниже я опишу это в формате ТЗ (технического задания) в максимально понятной форме.
Вот из-за таких ТЗ я ненавижу всяких продактов, наполняющих бэклог.
А еще в нем поддерживаются фичи, которых больше нигде нет (по крайней мере я не нашел). Worktree например.
Git GUI моей мечты