При работе с Git-репозиториями часто нужно выполнять множество одинаковых действий: фиксировать изменения, переключать ветки, синхронизировать репозитории. Всё это требует ввода соответствующих команд в терминале. Когда частота ввода повышается до утомительной, на помощь могут прийти различные GUI-инструменты. В статье расскажу об одном из них — Lazygit, легковесном консольном клиенте для Git, который облегчает и упрощает работу с репозиториями.
Об инструменте
Автор проекта — Jesse Duffield, разработчик из Мельбурна. Начиналось всё как хобби: по словам Jesse, он хотел чтобы и другие разработчики могли быть такими же ленивыми, как он сам. На текущий момент вокруг утилиты собралось довольно большое сообщество. В разработке поучаствовало уже 178 контрибьюторов. У проекта 32 тыс. звезд на GitHub.
Lazygit написан на Go, распространяется под лицензией MIT и работает под всеми доступными операционными системами.
GUI сделан на основе библиотеки gocui, с помощью которой можно реализовать полноценные окна и взаимодействие с ними в терминале.
Установка утилиты
Разработчики подготовили сборки для всех существующих ОС, даже для FreeBSD (!).
Стоит отметить, что я сам активно пользуюсь этой программой на протяжении последних двух–трех лет. Поэтому успел протестировать ее на множестве ОС, начиная с различных Linux и macOS и заканчивая той самой FreeBSD.
В нашем случае тесты проводятся на macOS, поэтому для установки воспользуемся Homebrew:
brew install lazygitПосле установки запустить программу можно командой lazygit. Если в каталоге, в котором вы находитесь, уже инициализирован Git-репозиторий, он сразу же будет подхвачен, и можно начинать работать. Если репозитория нет, программа спросит, нужно ли его там создать, предоставив на выбор два варианта: создать или отказаться (во втором случае программа не запустится).
Обзор интерфейса
Для примера рассмотрим репозиторий werf. Склонируем его, перейдем в каталог и запустим утилиту:
$ git clone git@github.com:werf/werf.git
Cloning into 'werf'...
remote: Enumerating objects: 119179, done.
remote: Counting objects: 100% (66/66), done.
remote: Compressing objects: 100% (58/58), done.
remote: Total 119179 (delta 34), reused 13 (delta 8), pack-reused 119113
Receiving objects: 100% (119179/119179), 47.85 MiB | 4.24 MiB/s, done.
Resolving deltas: 100% (78239/78239), done.
$ lazygit
Главный интерфейс программы разделен на несколько окон:
Files — здесь отображаются измененные файлы, если они есть.
Local branches — локальные ветки в склонированном репозитории.
Commits — все последние коммиты.
Diff — дифф изменений.
Command log — лог работы.
Рассмотрим подробнее основные возможности программы.
Работа с ветками
Переключение на удаленную ветку
В некоторых окнах можно переключиться на другой режим. Например, в окне с ветками можно просмотреть не только локальные, но и все ветки в удаленном репозитории, переключившись на режим Remotes. Для этого выбираем нужный репозиторий и нажимаем клавишу Enter.
Если ваш терминал поддерживает работу с мышью — как, например, iTerm2 в macOS, — можно просто нажать на нужную строку.
После выбора репозитория появится список всех доступных удаленных веток. В окне Diff при этом отобразится структура коммитов в соответствии с этими ветками:
Чтобы начать работать с веткой, на нее нужно переключиться — например, с помощью Space. При этом название локальной ветки, если необходимо, можно изменить:
После этого она станет доступна в разделе Local Branches.
Обновление веток
Если состояние текущей ветки актуально, она помечается зеленой галочкой.
Если локальная ветка «отстала» от мейнстрима, вместо галочки будет отображена стрелка, соответствующая состоянию отличий:
стрелка вниз — требуется скачать новые коммиты из удаленного репозитория;
стрелка вверх — нужно отправить изменения.
На примере выше отображены две ветки: fix-in-usage-style в актуальном состоянии, и main, отставшая от мейнстрима на 14 коммитов.
Любую ветку можно обновить, выполнив fetch или pull. Программа позволяет сделать это с помощью горячих клавиш: переходим на нужную ветку и нажимаем клавишу f или p в зависимости от команды, которую нужно выполнить.
Горячая клавиша может не сработать, если включена русская раскладка. Регистр также имеет значение — в этом конкретном случае нужно нажимать на маленькую f или p.
Создание новой ветки
Создать новую ветку можно с помощью клавиши n, выбрав ту ветку, от которой нужно ветвиться. Программа предложит ввести название новой ветки. После ввода будет создана новая, готовая к работе локальная ветка; она сразу появится в окне Local Branches.
Обратите внимание, что программа автоматически ничего никуда не отправляет, и созданная ветка будет только на вашей машине. Для отправки ее в удаленный репозиторий нужно, как обычно, сделать commit и push.
Merge веток
Выполнить merge веток можно горячей клавишей M. Для этого сначала нужно переключиться на целевую ветку, затем выбрать ту, из которой будут вноситься изменения, и нажать M.
Внесение изменений, commit и push
Commit изменений
После того, как новая ветка создана, можно вносить изменения в код. По завершении в левом верхнем окне программы (Files) появится список изменившихся файлов, которые можно закоммитить в репозиторий:
В правом окне Diff будут отображаться все изменения, внесенные в конкретный файл.
Чтобы зафиксировать изменения, нажимаем клавишу a (git add). Все измененные файлы позеленеют, то есть будут готовы к коммиту.
Чтобы закоммитить изменения, нажимаем клавишу c и в открывшемся окне вводим описание коммита.
Новый коммит появится в нижнем левом окне Commits.
Изменение описания коммита
Чтобы исправить описание коммита, переходим в окно Commits и выбираем нужный коммит. Нажимаем клавишу r (rename) — после этого возвращаемся в то же самое окно, в котором можно изменить текст.
Push в удаленный репозиторий
Для отправки зафиксированных изменений в удаленный репозиторий используется сочетание клавиш Shift + P.
Если вы делаете это впервые, программа спросит, с каким удаленным репозиторием предстоит работать и в какую ветку отправлять изменения.
Здесь лучше оставить всё как есть: локальный репозиторий и удаленный должны быть одинаковыми во избежание неприятных казусов в будущем.
Если именовать ветки по-разному, в будущем можно запутаться в том, что и куда должно отправляться. Это может привести к неприятным ситуациям, когда изменения будут отправлены не в ту ветку, а также к потраченному впустую времени на поиск правильного пути.
Перейдем к более сложным задачам.
Squah, rebase и force-push коммитов
Squash и force-push
Часто требуется делать промежуточные коммиты, чтобы не потерять наработки или зафиксировать важную часть прогресса по задаче. При этом коммиты нужно отправить в свою ветку с изменениями в удаленном репозитории.
Например, мы создали промежуточный комментарий, назвав его просто +++.
Отправим изменения в репозиторий (Shift + P).
Теперь продолжим работу до момента, когда понадобится закончить текущую правку и объединить предыдущий коммит с последним. Как обычно, закоммитим изменения:
Далее необходимо «слить» последний коммит с предыдущим. Сделать это можно горячей клавишей s. Программа, запросив подтверждение, сделает squash коммита со следующим, расположенным ниже по списку.
Теперь два последних коммита объединены в один. Осталось их переименовать (по умолчанию имя общего коммита содержит описания обоих коммитов). Нажимаем r и удаляем лишнее (+++):
Отправим изменения в удаленный репозиторий. Так как локальная ветка отличается от удаленной, необходимо не просто выполнить push изменений, а сделать это в режиме –force, чтобы изменения перезаписались.
Обратите внимание, что push с force нужно выполнять только тогда, когда есть четкое понимание, для чего это делается. Операция перезаписывает содержимое всей удаленной ветки, что может привести к потере данных. Например, два человека одновременно работают с одной веткой над какой-то небольшой правкой, и оба по очереди перезаписали удаленную ветку своими изменениями. Если не уследить за своевременной синхронизацией, вероятность потери данных сильно возрастает. Также нужно помнить, что ни в коем случае не следует выполнять такой push к главной ветке репозитория (master или main).
Для отправки изменений снова нажимаем Shift + P. Программа определит, что удаленная ветка отличается от локальной и сама предложит сделать push с force.
Rebase ветки
Рассмотрим еще один частый случай. Например, во время работы текущая ветка отстала от мейнстрима, и необходимо актуализировать состояние с помощью rebase.
Для этого нужно:
переключиться на ветку, rebase которой будем выполнять;
выбрать ветку, на которую будет производиться rebase.
На скриншоте показан пример rebase ветки fix-in-usage-style на ветку main:
В случае успешного завершения процесса в дереве коммитов появятся все «новые» коммиты, соответствующие актуальному состоянию ветки main. Последние коммиты, внесенные в ветку fix-in-usage-style, будут всё так же сверху.
Чтобы зафиксировать изменения в удаленном репозитории, необходимо выполнить push (Shift + P).
Вызов справки
В любом из окон можно вызвать справку с перечнем всех доступных горячих клавиш, нажав x.
Конфигурация
Программу можно гибко настраивать под себя, начиная с цветовой гаммы и заканчивая добавлением новых команд или горячих клавиш. Все настройки лежат в файле config.yml, который размещается в разных каталогах в зависимости ОС:
Linux:
~/.config/lazygit/config.ymlMacOS:
~/Library/Application Support/lazygit/config.ymlWindows:
%APPDATA%\lazygit\config.yml
Более подробно о всех доступных настройках написано в официальной документации.
Завершение работы
Для выхода из программы необходимо нажать горячую клавишу q.
Итог
Lazygit — полезная программа, которая упрощает работу с Git. Она не занимает много места, не требует дополнительных знаний и умений помимо тех, которые требует сам Git. Программа предоставляет очень удобный интерфейс для привычных каждодневных операций, таких как управление ветками в репозитории и их rebase, squash коммитов и push ветки в удаленный репозиторий с force.
Мне кажется, автору Lazygit удалось реализовать задуманное — облегчить работу с Git простым, понятным и «ленивым» средством.
P.S.
Читайте также в нашем блоге:
Комментарии (30)
constb
26.01.2023 11:48+3что-то мне показалось, что это не только не упрощает, а пожалуй даже и как-то усложняет работу с гитом. :) учить кучу хоткеев вместо нескольких команд – ну такое себе… лучше уж и правда гуй взять – бесплатный типа gitahead или платный типа git tower.
если уж говорить об инструментах которые экономят время – тут лучше про git town написать было бы – он реально неплохо автоматизирует большинство типовых задач…
domix32
26.01.2023 12:18+3А зачем учить, там же либо буквально кнопка с подсказкой рисуется, либо жмется кнопочка H и открывается cheatsheet c хоткеями.
petuhov_k
27.01.2023 13:00Там подсказки просто "гениальные". Push и Pull висят на кнопке 'p' и 'P' или 'P' и 'p'. 50/50 шансы угадать с первого раза какая p является заглавной, а какая нет. По крайней мере с тем терминальным шрифтом, что был у меня в убунте.
Zhbert Автор
27.01.2023 16:51+1Это запоминается с первых двух тыков на самом деле. Как и тот факт, что надо сначала выбрать что-то, а потом на чем-то другом что-то нажать, как, например, в случае с ребейзом веток.
Тут вопрос в том, насколько инструмент интересен и хочется в нем работать. У меня лично года три назад не возникло желания его бросить, а наоборот хотелось изучить и пользоваться. Наверное, потому что он очень хорошо вписался в мой повседневный кейс работы.
А вот гит в той же GoLand мне неудобен, хотя там и «наглядно» все. Как и в VSCode.
Free_ze
26.01.2023 12:13+1Еще не гуй, но уже и не куй. Целевой аудиторией скорее всего будут пользователи vim, но для них явно был бы удобнее плагин с таким функционалом, вместо отдельной софтины.
nightvich
26.01.2023 12:52+3Обычно значительно проще использовать команды CLI для работы с GIT, за исключением моментов, когда надо полазить по истории. Для этого есть утилита TIG.
Эта утилита достаточно забавная, но на мой взгляд, избыточная.
nronnie
28.01.2023 00:11когда надо полазить по истории
Ну так ведь
git log --graph:) А вообще, фейпалм и слёзы каждый раз когда вижу людей что дажеgit commitне могут сделать без полусотни гуйных утилит :)
fishHook
26.01.2023 15:09+2Уставил как написано
>brew install lazygitзапустил, потыкал, смотрю - внизу написано
H/L to scrollокей, нажал L, программа зависла навсегда. Знакомство было недолгим
Helltraitor
26.01.2023 18:32-6Жаль автора программы, который потратил на нее время.
Я использую GitHub Desktop и в git лезу только когда тег не на тот комит прицепил
evg_krsk
26.01.2023 20:21+1Откройте для себя magit :-)
Даже под vscode есть версия, вполне сносно работает.
stanlyzoolo
27.01.2023 16:48+1Для любителей консольных утилит. В коем числе и я.
Но, откровенно говоря, практически ничего стороннего для гита не использую, всё могу сделать просто из терминала без гуёв и утилит. Что неудобно (или не наловчился), так это разрешать конфликты при ребейзе. Всё остальное делается руками и быстро. Если надо полазить по содержимому в истории коммитов, то в VSCode всё минимальное есть.
Разработчику безусловно респект, потрудился, а труд в целом нельзя обесценивать, нравится он тебе или нет)
sergey-kuznetsov
28.01.2023 21:22+1Отличный консольный GUI-клиент! Спасибо за наводку, но есть пара замечаний к терминологии.
Remote в отношении репозиториев и веток не очень адекватно переводить как «удалённая». Это порождает странные понятия типа «удалить удалённую». Лучше говорить «внешняя ветка», «вышестоящий репозиторий».
Commit Message это явно не название коммита, это именно «сообщение коммита». Многострочный текст из нескольких абзацев это не название. Заголовок сообщения коммита разве можно обозвать названием? Когда мы поправляем сообщение склеенных коммитов после squash, это не переименование коммита, а редактирование сообщения.
Ну и если вы технический писатель, то должны знать, что в английском языке нет наших падежей и нелепо выглядит попытка прикрутить изменённые окончания к словам написанным английскими буквами — «Vim’ом редактирую». В тексте такие места выглядят скорее как обозначение икоты. Либо пишите русскими буквами «Вимом редактирую», либо оставляйте названия как есть «в Vim редактирую»
MonkAlex
Почитал статью по диагонали - по моему любой гуй будет понятнее и удобнее.
Лет пять пользуюсь gitextension (под windows, впрочем) - он скрывает за собой почти все необходимые мне фичи. Пулл-пуш, коммит, редкий ребейз\черипик и разрешение конфликтов. Знаний консольных команд при этом не нужно, всё в кнопках, местами есть картинки для подсказок. Местами "главные" кнопки отдельно подсвечивают. Местами есть доп диалоги типа "а хотите ещё вот это сделать?" с возможностью запомнить поведение.
Zhbert Автор
Ага, гуевых клиентов много. Здесь вопрос удобства лично для тебя и привычек.
У меня часто работа идет именно в терминале (да да, я еще и файлики Vim'ом редактирую!), поэтому тыркаться куда-то в сторонний гуй будет просто неудобно — быстрее и комфортнее запустить терминальную же утилиту и парой быстрый хоткеев без движений мышкой по кнопкам сделать нужные действия с гитом.
Apollon_Diamed
На мой взгляд даже из терминала удобнее просто набрать `code .`, сделать нужные вещи и закрыть vscode. Но это если нужно что-то сложнее просто коммита или простой работы с ветками
domix32
Гуй конечно хорошо, но когда у тебя сборочник на удаленке - проще и полезнее поставить терминаьлный гуй. Ну и плюс хороших и бесплатных гуёв всё ещё нет -
Tortoise Git,Git 4 Windows,Source Tree,git cola- крайне неповоротливые, часто неоправданно большие, а иногда ещё и крашатся, плюс интеграция с другими инструментами крайне скудная (kdiff3 например), либо откровенно кривая, и это в довесок к интеграциям, о которых никто не просил. Поведение опять же отличается от консольного гита - конфиги и ssh ключи через одно место и поди найди ещё это самое место. А уж если коммиты подписывать надо, то тут ещё одна свистопляска.Из хороших и платных знаю только Sublime Merge, но его на кучу машин не наставишься, плюс некоторые сборочники шарятся между разрабами и это фактически запрещает его использование на них. Всякие свистелко-пердельные клиенты типа
Git Krakenрассматривать даже смысла особо нет.Как у них с подписью коммитов правда не в курсе.
lazygitв этом плане неплох, но на определённых данных и просто неудобно пользоваться - слияние длинных строк, работа с длинными путями и кажется он не слишком хорошо работает с большими репозиториями - чуть веток за десяток перевалило и дерево начинает ползти и коммиты крайне неспешно отображаются, плюс всё это жрёт память довольно ощутимо - спасибо go рантайму. Поэтому последней инстанцией сталgitui. Выглядит практически также, только по набору фич переплевывает плюс по скорости и потреблению памяти переигрывает. Однако коммитить с подписью и работать с bare репами тоже не умеет, но клиент продолжает развиваться - недавно вертикальную прокрутку добавили, например. И да есть даже под FreeBSD.MonkAlex
А что такое "сборочник на удаленке"?
Ну потому что у меня гит на моей локальной машине, я на ней работаю и выполняю все гитовые операции. Всё остальное работает другими способами - хуками, к примеру.
ПС: с моей точки зрения gitextension очень даже бесплатный и хороший.
Source Treeвроде тоже бесплатный для личного использования, не помню деталей.domix32
Удалённая машина, на которой собирается код. В моём случае - C/C++ на виртуалке с FreeBSD, например.
Source Tree - бесплатен для всех, однако у него есть куча интеграций, которые нужны далеко не всем, плюс оно крайне плохо работает с git lfs. Если атлассиановский аккаунт не используется, то он миллион попапов высветит. Деталей не помню, но была какая-то проблема с поиском/хранением ssh ключей на Windows, которую так и не обошли. В итоге некоторые вещи приходилось ручками из консоли делать, благо под это есть кнопка в интерфейсе. Переключение веток непропопорционально тормознуто, в сравнении с обычным git checkout branchname, поиск хотя бы по заголовкам коммитов - тормознуто, просмотр коммитов, особенно с разных веток - тормоза. Встроенный diff - довольно кривой. Удаление/добавление hunkов с изменениями - тормоза по несколько секунд. Иногда оно может покрашиться, под виндой со всеми интеграциями может просто повиснуть на каком-то дедлоке во время синхронизации чего-то куда-то о чем никто не может рассказать.
GitExtensions сам не пользовал, но там вроде были проблемы с отсутвием встроенного резолва мержей или что-то в этом роде. Насколько оно тормознуто тоже не могу сказать. Знаю что винда не в восторге от кучи пунктов контекстного меню, которые оно добавляет.
Если очень хочется gui то лучшими кандидатами (ИМХО) на Windows были TortoiseGit и git-cola. Основная претензия к ним, что они довольно тормозные. У черепашки - просмотр истории был медленный и работа с конфликтами была кривоватой, а кола так и вовсе с питоном под капотом.
MonkAlex
Так а зачем там то гит клиент нужен?
Там должен быть "агент" ci\cd, который триггерится на настроенные события и билдит. В билде делаем очевидные clone && checkout и всё.
Встроенного нет, я пользуюсь тем что идёт с VisualStudio. Только он вполне корректно вызывается из GitExtension, а это всё что надо от хорошего инструмента.
domix32
Это не CI, это именно то что собирает продукт для того чтобы я мог это отлаживать тут же локально. При необходимости сделать какие-то быстрые изменения не отходя от кассы и не парился с миллионом мелких пушей в своей ветке. Почему так рассказывать не стану, но вполне себе кейс. В конце концов удалёнка же - в офисе стоит мощная сборочная рабочая машина - сиди из дома эсэсаш её - терминал становится лучшим другом.
Zhbert Автор
С подписями да, есть особенности.
В принципе, если нужно просто подписать GPG-подписью коммит, то он это делает: сам лейзигит сворачивается, вылезает окно ввода пароля GPG (как обычно), потом все подписывается и снова разворачивается лейзигит. По времени вообще не ощущается как что-то затратное.
Если при этом надо еще и
Sign-off-запись получить в комменте, тот тут немного сложнее. Я пробовал повесить выполнение коммита с--signoffна новый хоткей (в конфиге можно как угодно настраивать все), но на моменте ввода ключа GPG почему-то его начинает дико колбасить — и лейзигит не свернут, и пароль вводится, и все мерцает. Возможно, я сделал что-то не так, и надо было в конфиг прописать сворачивание его как при обычном коммите, но, если честно, мне стало лень разбираться.В итоге я просто накидал скриптик с
git commit --amend --no-edit --signoff%и теперь процесс выглядит так: коммит, пароль, q, скрипт, снова лейзигит и пуш. Занимает этот аккорд буквально секунд 5 на самом деле, но зато все подписывается.mayorovp
Что значит "всё ещё нет"? Прямо в комментарии на который вы отвечали упоминается Git extensions — хороший и бесплатный гуй для винды.
UMenyaNeudobnieVoprosiki
Когда сборка на удалёнке, у вас будет не более чем git clone в нём и уж точно речь не про kdiff3. При этом если даже удалённо прям разрабатывать нужно, всякие VSCode и JetBrains умеют в ремоутный сервер
domix32
Ах, жить бы в этом замечательном мире где всё работает.
kdiff3 конечно же не на удаленке, хотя можно и через иксы прокинуть.
UMenyaNeudobnieVoprosiki
Пока что Git и тулы вокруг него работают куда более надёжно и предсказуемо, чем всё остальное, особенно всякие Jira и интеграции в них. Поэтому не понимаю вашей боли
domix32
странно, что вы называете JetBrains и VsCode тулами вокруг гита. Суть в том что несмотря на наличие таких фич как удаленный сервер разработки они работают либо плохо либо вообще не работают на FreeBSD. То бишь нельзя просто сделать pkg install blabla && blablabla serve и оно автомагически заводится. Оно требует дополнительно красноглазить и допиливать напильником, что мне персонально делать очень не хочется. Плюс сборка кода происходит не слишком стандартным образом, так что тут ещё некоторая кучка нюансов, которые могут всплыть, до которых я просто ещё не добрался. Так что живём с болью от турбоподогрева кресла.
olku
Пару лет попробовал все, остановился на SmartGit, бесплатен для оперсорса.
Mitai
+1 за gitui тоже остановился на нем
UMenyaNeudobnieVoprosiki
Пользую GitExtensions, с интеграцией в тикеты GitLab и Meld. Неплохо, но прямо в нём есть консоль, которой тоже активно пользуюсь (в т.ч. glab, tig который на винде ставится прямо с гитом), которая bash (т.е. по дефолту всё тот же vim для нюансиков, если не переконфигурить, но мне норм).
Почитайте на досуге https://git-scm.com/book/ru/v2 и жить станет сильно интереснее
MonkAlex
Я умею пользоваться консольным гитом, но смысла не вижу, кроме редких исключений.
Да, понимать что внутри происходит помогает в случае проблем или сложных кейсов. Да, возможность без гуя быстро разобраться вне своего рабочего места - тоже иногда надо. Но в обычной ежедневной работе - гуй закрывает все 146% моих задач и это хорошо.