Не знаю, на каком языке программирования вы пишете, но уверен, что используете Гит при разработке. Инструментов для сопровождения разработки становится всё больше, но даже самый маленький тестовый проект, я неизменно начинаю с команды git init. А в т��чение рабочего дня набираю в среднем ещё 80 команд, обращаясь к этой системе контроля версий.


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


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


Кому будет полезна эта статья?


Вы уже освоили джентльменский набор Гита и готовы двигаться дальше? Существует 2 пути:


  1. Освоить сокращённые команды – алиасы. Они почти всегда составлены мнемонически и легко запоминаются. Забыть оригиналы команд проблематично, я легко их набираю, когда это требуется. Плюс не сбиваюсь с мысли, проверяя что-то в Гите в процессе написания кода.
  2. Узнать о дополнительных флагах к командам, а также их объединении между собой. Я понимаю, что кто-то ненавидит сокращения. Для вас тоже есть интересный материал в статье – как повысить полезность и удобство вывода команд, а также как решать не самые тривиальные, но часто встречающиеся на практике задачи.

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


Добро пожаловать под кат!


Подготовка


Среди разработчиков стандартом альтернативы Bash является Zsh – продвинутая программная оболочка, поддерживающая тонкую настройку. А среди пользователей Zsh стандартом является использование Oh My Zsh – набора готовых настроек для Zsh. Таким образом, установив этот комплект, мы из коробки получим набор хаков, которые годами собирало и нарабатывало для нас сообщество.


Очень важно отметить, что Zsh есть и для Linux, и для Mac, и даже для Windows.


Установка Zsh и Oh My Zsh


Устанавливаем Zsh и Oh My Zsh по инструкции одной командой:


# macOS
brew install zsh zsh-completions && sh -c "$(curl -fsSL https://raw.githubusercontent.com/robbyrussell/oh-my-zsh/master/tools/install.sh)"

# Ubuntu, Debian, ...
apt install zsh && sh -c "$(curl -fsSL https://raw.githubusercontent.com/robbyrussell/oh-my-zsh/master/tools/install.sh)"

Поскольку задача – оптимизировать взаимодействие с Гитом, добавим к Zsh пару плагинов. Откройте файл ~/.zshrc и добавьте к списку plugins:


plugins=(git gitfast)

Итого:


  • git – набор алиасов и вспомогательных функций;
  • gitfast – улучшенное автодополнение для Гита.

Установка tig


И последний штрих – установка консольной утилиты tig:


# macOS
brew install tig

# Ubuntu, Debian, ...
# https://jonas.github.io/tig/INSTALL.html

О ней поговорим дальше.


Гит на практике


Разбираться с Гитом лучше всего на примерах решения конкретных задач. Далее рассмотрим задачи из ежедневной практики и варианты их удобного решения. Для этого рассмотрим некий репозиторий с текстовыми файлами.


В жёлтых блоках указан основной алиас для решения задачи из раздела. Выучите только его, а всё остальное оставьте для общего развития.

Проверяем состояние рабочей директории


Начнём с самой базовой вещи. Мы немного поработали и теперь давайте посмотрим, что происходит в рабочей директории:


$ git status

On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   e.md

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   b.md

Untracked files:
  (use "git add <file>..." to include in what will be committed)

    d.md

Текущее состояние всех файлов описано очень подробно, даны дополнительные руководства к действию. Очень полезно на первых порах использования Гита, но для ежедневной работы очень много лишнего. Давайте понизим уровень шума дополнительными ключами:


$ git status -sb

## master
 M b.md
A  e.md
?? d.md

Ага, мы находимся в ветке master, изменили файл b.md (M-odified) и создали два файла, добавив первый в индекс Гита (A-dded), а второй оставив вне индекса (??). Коротко и ясно.


Осталось оптимизировать бесконечный ввод этой команды алиасом «git status with branch»:


Показать сокращённый статус рабочей директории
 
$ gsb # git status -sb


Создаём коммит


Продолжаем.


Конечно, вы умеете создавать коммиты. Но давайте попробуем оптимизировать решение и этой простой задачи. Добавляем все изменения в индекс алиасом «git add all»:


$ gaa # git add --all

Проверяем, что в индекс попало именно то, что нам нужно с помощью алиаса «git diff cached»:


$ gdca # git diff --cached

diff --git a/b.md b/b.md
index 698d533..cf20072 100644
--- a/b.md
+++ b/b.md
@@ -1,3 +1,3 @@
 # Beta

-Next step.
+Next step really hard.
diff --git a/d.md b/d.md
new file mode 100644
index 0000000..9e3752e
--- /dev/null
+++ b/d.md
@@ -0,0 +1,3 @@
+# Delta
+
+Body of article.

Хм, в один коммит должны попадать изменения, решающие единственную задачу. Здесь же изменения обоих файлов никак не связаны между собой. Давайте пока исключим файл d.md из индекса алиасом «git reset undo»:


$ gru d.md # git reset -- d.md

И создадим коммит алиасом «git commit»:


$ gc # git commit

Пишем название коммита и сохраняем. А следом создаём ещё один коммит для файла d.md более привычной командой с помощью алиаса «git commit message»:


$ gaa # Уже знакомый алиас
$ gcmsg "Add new file" # git commit -m "Add new file"

А ещё мы можем...


… коммитить изменённые файлы из индекса одной командой:


$ gcam "Add changes" # git commit -a -m "Add changes"

… смотреть изменения по словам вместо строк (очень полезно при работе с текстом):


$ gdw # git diff --word-diff

… добавлять файлы по частям (очень полезно, когда нужно добавить в коммит только часть изменений из файла):


$ gapa # git add --patch

… добавлять в индекс только файлы, уже находящиеся под наблюдением Гита:


$ gau # git add --update

Итого:


Добавить в индекс / Создать коммит
 
$ ga # git add
$ gc # git commit


Исправляем коммит


Название последнего коммита не объясняет сделанных нами изменений. Давайте переформулируем:


$ gc! # git commit -v --amend

И в открывшемся текстовом редакторе назовём его более понятно: "Add Delta article". Уверен, вы никогда не используете ключ -v, хотя при редактировании описания коммита он показывает все сделанные изменения, что помогает лучше сориентироваться.


А ещё мы можем...


… внести в коммит изменения файлов, но не трогать описание:


$ gcn! # git commit -v --no-edit --amend

… внести все изменения файлов сразу в коммит, без предварительного добавления в индекс:


$ gca! # git commit -v -a --amend

… скомбинировать две предыдущие команды:


$ gcan! # git commit -v -a --no-edit --amend

Ну и важно ещё раз отметить, что вместо набора полной регулярно используемой команды git commit -v --amend, мы пишем всего три символа:


Изменить последний коммит
 
$ gc! # git commit -v --amend


Начинаем работать над новой фичей


Создаём новую ветку от текущей алиасом «git checkout branch»:


$ gcb erlang # git checkout --branch erlang

Хотя нет, лучше напишем статью про более современный язык Эликсир алиасом «git branch с ключом move» (переименовывание в Гите делается через move):


$ gb -m elixir # git branch -m elixir

Здесь логично было бы использовать алиас gbmv, но его, к сожалению, ещё не придумали. Хороший вариант для контрибьюта.


Вносим изменения в репозиторий и создаём коммит, как уже умеем:


$ echo "# Эликсир — мощь Эрланга с изяществом Руби." > e.md
$ gaa && gcmsg "Add article about Elixir"

И запоминаем:


Создать новую ветку
 
$ gcb # git checkout --branch


Сливаем изменения


Теперь добавляем нашу новую статью об Эликсире в master. Сначала переключимся на основную ветку алиасом «git checkout master»:


$ gcm # git checkout master

Нет, серьёзно. Одна из самых часто используемых команд в три легко запоминающихся символа. Теперь мерджим изменения алиасом «git merge»:


$ gm elixir # git merge elixir

Упс, а в master кто-то уже успел внести свои изменения. И вместо красивой линейной истории, которая принята у нас в проекте, создался ненавистный мердж-коммит.


Слить ветки
 
$ gm # git merge


Удаляем последний коммит


Ничего страшного! Нужно просто удалить последний коммит и попробовать слить изменения ещё раз «git reset hhard»:


Удалить последний коммит
 
$ grhh HEAD~ # git reset --hard HEAD~


Решаем конфликты


Стандартная последовательность действий checkout – rebase – merge для подготовки линейной истории изменений выполняется следующей последовательностью алиасов:


gco elixir # git checkout elixir
grbm # git rebase master
gcm # git checkout master
gm elixir # git merge elixir

Все они так часто используются что уже отлетают от пальцев, и проделывая подобные операции, нет необходимости задумываться о том, какой набор букв нужно набирать. И не забывайте, что в Zsh можно дополнять названия веток клавишей Tab.


Сделать ребейз
 
$ grb # git rebase


Отправка изменений на сервер


Сначала добавляем origin алиасом «git remote add»:


$ gra origin git@github.com/... # git remote add origin git@github.com/...

А затем отправляем изменения напрямую в текущую ветку репозитория («gg» – удвоенное g в начале команды указывает на выполнение действия в текущую ветку):


$ ggpush # git push origin git_current_branch

Вы также можете...


… отправить изменения на сервер с установкой upstream алиасом «git push set upstream»:


$ gpsup # git push --set-upstream origin $(git_current_branch)

Отправить изменения на сервер
 
$ gp # git push


Получаем изменения с сервера


Работа кипит. Мы успели добавить новую статью f.md в master, а наши коллеги изменить статью a.md и отправить это изменение на сервер. Эта ситуация тоже решается очень просто:


$ gup # git pull --rebase

После чего можно спокойно отправлять изменения на сервер. Конфликт исчерпан.


Получить изменения с сервера
 
$ gl # git pull


Удаляем слитые ветки


Итак, мы успешно влили в master несколько веток, в том числе и ветку elixir из предшествующего примера. Они нам больше не нужны. Можно удалять алиасом «git branch delete another»:


$ gbda # git branch --no-color --merged | command grep -vE "^(\*|\s*(master|develop|dev)\s*$)" | command xargs -n 1 git branch -d

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


Создаём временный коммит


Работа над новой статьёй h.md про Haskell идёт полным ходом. Написана половина и нужно получить отзыв от коллеги. Недолго думая, набираем алиас «git work in progress»:


$ gwip # git add -A; git rm $(git ls-files --deleted) 2> /dev/null; git commit --no-verify -m "--wip-- [skip ci]"

И тут же создаётся коммит с названием Work in Progress, пропускающим CI и удаляющим «лишние» файлы. Отправляем ветку на сервер, говорим об этом коллеге и ждём ревью.


Затем этот коммит можно отменить и вернуть файлы в исходное состояние:


$ gunwip # git log -n 1 | grep -q -c "\-\-wip\-\-" && git reset HEAD~1

А проверить, есть ли в вашей ветке WIP-коммиты можно командой:


$ work_in_progress

Команда gwip – довольно надёжный аналог stash, когда нужно переключиться на соседнюю ветку. Но в Zsh есть много алиасов и для самого stash.


Добавить временный коммит / Сбросить временный коммит
 
$ gwip
$ gunwip


Прячем изменения


С этой командой нужно быть осторожным. Файлы можно спрятать, а затем неаккуратным действием удалить насовсем, благо есть reflog, в котором можно попытаться найти потерянные наработки.


Давайте спрячем файлы, над которыми работаем, алиасом «git stash all»: 


$ gsta # git stash save

А затем вернём их обратно алиасом «git stash pop»:


$ gstp # git stash pop

Или более безопасным методом «git stash all apply»:


$ gstaa # git stash apply

Вы также можете ...


… посмотреть, что конкретно мы припрятали:


gsts # git stash show --text

… воспользоваться сокращениями для связанных команд:


gstc # git stash clear
gstd # git stash drop
gstl # git stash list

Спрятать изменения / Достать изменения
 
$ gsta
$ gstaa


Ищем баг


Инструмент git-bisect, который неоднократно спасал мне жизнь, тоже имеет свои алиасы. Начинаем с запуска процедуры «двоичного поиска ошибки» алиасом «git bisect start»:


$ gbss # git bisect start

Отмечаем, что текущий, последний в ветке, коммит содержит ошибку, алиасом «git bisect bad»:


$ gbsb # git bisect bad

Теперь помечаем коммит, гарантирующий нам рабочее состояние приложения «git bisect good»:


$ gbsg HEAD~20 # git bisect good HEAD~20

А теперь остаётся продолжать отвечать на вопросы Гита фразами gbsb или gbsg, а после нахождения виновника сбросить процедуру:


$ gbsr # git bisect reset

И я действительно пишу эти сокращения при использовании этого инструмента.


Поиск коммита с ошибкой
 
$ gbss # git bisect start
$ gbsb # git bisect bad
$ gbsg # git bisect good
$ gbsr # git bisect reset


Ищем зачинщика беспредела


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


$ gbl a.md -L 2 # git blame -b -w a.md -L 2

Видите, контрибьютеры Oh My Zsh сделали алиас не просто на команду git blame, а добавили в него ключи, которые упрощают поиск непосредственно зачинщика.


Bonus


Просмотр списка коммитов


Для просмотра списка коммитов используется команда git log с дополнительными ключами форматирования вывода. Обычно эту команду вместе с ключами заносят в кастомные алиасы Гита. Нам с вами повезло больше, у нас уже есть готовый алиас из коробки: glog. А если вы установили утилиту tig по совету из начала статьи, то вы абсолютный чемпион.


Теперь, чтобы поизучать историю коммитов в консоли в очень удобном виде, нужно набрать слово git наоборот:


$ tig

Утилита также даёт пару полезных дополнений, которых нет в Гите из коробки.


Во-первых, команда для поиска по содержимому истории:


$ tig grep

Во-вторых, просмотр списка всех источников, веток, тегов вместе с их историей:


$ tig refs

В-третьих, может быть найдёте что-то интересное для себя сами:


$ tig --help

Случайно сделал git reset --hard


Вы работали над веткой elixir весь день:


$ glog

* 17cb385 (HEAD -> elixir) Refine Elixir article
* c14b4dc Add article about Elixir
* db84d54 (master) Initial commit

И под конец случайно всё удалили:


$ grhh HEAD~2
HEAD is now at db84d54 Initial commit

Не нужно паниковать. Самое главное правило – перестаньте выполнять какие-либо команды в Гите и выдохните. Все действия с локальным репозиторием записываются в специальный журнал – reflog. Из него можно достать хеш нужного коммита и восстановить его в рабочем дереве.


Давайте заглянем в рефлог, но не обычным способом через git reflog, а более интересным с подробной расшифровкой записей:


$ glg -g

Находим хеш нужного коммита 17cb385 и восстанавливаем его:


# Создаём новую ветку с нашим коммитом и переключаемся на неё
$ gcb elixir-recover 17cb385

# Удаляем старую ветку 
$ gbd elixir

# Переименовываем восстановленную ветку обратно
$ gb -m elixir

Случайно вместо создания нового коммита внёс изменения в предыдущий


Здесь нам снова на помощь приходит рефлог. Находим хеш оригинального коммита 17cb385, если мы производим ��тмену коммита сразу же, то вместо поиска хеша можем воспользоваться быстрой ссылкой на него HEAD@{1}. Следом делаем мягкий сброс, индекс при этом не сбрасывается:


# Мягкий сброс на оригинальный коммит
$ grh --soft HEAD@{1} # git reset -soft

# Коммитим правильно
$ gcmsg "Commit description"

Ветка слишком сильно устарела


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


Давайте рассмотрим на примере ветки с фичей под названием elixir:


# Переключаемся на master
$ gcm # git checkout master

# Создаём новую актуальную ветку для оригинальной фичи
$ gcb elixir-new # git checkout --branch elixir-new

# Переносим единственный коммит с фичей из устаревшей ветки в новую
$ gcp elixir@{0} # git cherry-pick elixir@{0}

Вот так, вместо попытки обновления ветки, мы берём и без проблем переносим один единственный коммит.


Удаление важных данных из репозитория


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


$ git filter-branch --force --index-filter 'git rm --cached --ignore-unmatch <path-to-your-file>' --prune-empty --tag-name-filter cat -- --all && git push origin --force --all

Выполнение этой команды поломает ваш stash. Перед её исполнением рекомендуется достать все спрятанные изменения. Подробнее об этом приёме по ссылке.


Обращение к предыдущей ветке


При выполнении некоторых команд, которые ожидают на вход название ветки, мы можем передать дефис - в качестве ссылки на ветку, с которой мы пришли. Особенно хорошо использовать этот трюк для чекаута: 


$ gco - # git checkout -
$ gm - # git merge -
$ grb - # git rebase -

Удаление всех файлов, отмеченных в .gitignore


Ещё одна нередкая неудача – слишком поздно добавить в .gitignore какие-то нежелательные файлы или директории. Для того, чтобы вычистить их из репозитория (и удалить с диска) уже есть готовые ключи для команды git clean:


$ gclean -X # git clean -Xfd

Будьте осторожны!


Как правильно перебдеть читайте дальше.


Зачем многим командам нужен ключ --dry-run?


Ключ --dry-run нужен как раз в качестве осторожности при задачах удаления и обновления. Например, в предыдущем разделе описан способ удаления всего, что указано в файле .gitignore. Лучше проявиться осторожность и воспользоваться ключом --dry-run, отсмотреть список всех файлов к удалению, и только затем выполнить команду без --dry-run.


Заключение


В статье показывается точка для оптимизации трудовой деятельности программиста. Запомнить 10-20 мнемонических сокращений не составляет труда, забыть оригинальные команды практически невозможно. Алиасы стандартизированы, так что при переходе всей команды на Zsh + Oh My Zsh, вы сможете работать с теми же скоростью и комфортом, даже при парном программировании.


Куда двигаться дальше?


Предлагаю следующие варианты:


  1. Наконец-то разберитесь, как Гит устроен внутри. Очень помогает понимать, что ты делаешь и почему то, что ты хочешь сделать не получается.
  2. Не ленитесь лишний раз заглянуть в документацию к командам: git --help или ghh.
  3. Посмотрите полный список алиасов по ссылке. Пытаться запомнить их все – безумие, но использовать список в качестве сборника набора интересных команд и ключей к ним – хорошая идея.

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


Надеюсь, материал оказался полезным, и вы смогли узнать для себя что-то новое. А может быть уже начали активно внедрять новый подход. Удачи!