Алиасы

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

Например, алиасы для команд checkout, commit и branch можно создать следующим образом:

git config --global alias.co checkout
git config --global alias.ci commit
git config --global alias.br branch

Теперь вместо git checkout master достаточно ввести git co master.

Также можно изменять и добавлять алиасы напрямую редактируя файл ~/.gitconfig:

[alias]
	co = checkout
	ci = commit
	br = branch

Скрытие (stashing) изменений до коммита

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

При помощи команды git stash можно временно отменить внесенные изменения, не удалив их окончательно:

$ git stash

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

Чтобы вернуть скрытую функциональность, достаточно ввести:

$ git stash pop

Если же скрытая функциональность больше не нужна, ее можно удалить с помощью:

$ git stash drop

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

Быстрым и легким способом сравнения изменений между коммитами или версиями одного и того же файла является использование команды git diff.

Для сравнения состояний одного и того же файла между коммитами нужно ввести:

$ git diff $start_commit..$end_commit -- path/to/file

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

$ git diff $start_commit..$end_commit

Эти команды выведут результат в текстовом виде прямо в окно терминала. Для более наглядного результата можно использовать git difftool. Данная команда запускает специальную программу для сравнения изменений. Одной из таких программ является Meld.

Для настройки Meld введите:

$ git config --global diff.tool git-meld

Теперь ее можно использовать:

$ git difftool $start_commit..$end_commit -- path/to/file
# или
$ git difftool $start_commit..$end_commit

Откат изменений

Иногда при работе над кодом становится понятно, что внесенные изменения оказались ненужными/неверными и их необходимо откатить. Вместо того, чтобы делать undo по каждому изменению, достаточно сделать reset файлов на HEAD-коммит ветки:

$ git reset --hard HEAD

Или, для одного конкретного файла:

$ git checkout HEAD -- path/to/file

Далее, если ненужные изменения уже были закоммичены, для их отката нужно ввести:

$ git reset --soft HEAD~1

Более эффективное использование Git blame

Git blame используется для того, чтобы узнать, кто внес изменения в определенную строку файла. Существует набор флагов, которые можно передавать данной команде, в зависимости от того, что вы хотите вывести:

$ git blame -w  # игнорировать знаки табуляции
$ git blame -M  # игнорировать перемещения текста
$ git blame -C  # игнорировать перемещения текста в другие файлы

Помимо описанных выше советов по работе с командами, существует несколько общих советов по работе с Git.

Делайте пулл часто

Если вы используете GitLab Workflow, значит вы работаете в ветках для выделенной функциональности (feature branches). Пока вы работаете над фичей в отдельной ветке, в мастер-ветке может произойти множество изменений, некоторые из которых могут конфликтовать с добавленными фичами.

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

Частые коммиты, редкие пуши

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

Пуш только после тестирования изменений

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