Привет, мне показалось хорошей идеей начать переводить не только релизные посты из блога ГитЛаба. Для разминки я взял этот пост почти наугад, так что не судите строго. Буду рад, если поможете определиться с выбором статьи для перевода, выбрав один из вариантов в опроснике
Git – это система контроля версий с огромным количеством возможностей. Пытаться изучить их все довольно утомительно, поэтому большинство пользователей ограничивается использованием лишь базового набора команд. В этой статье представлены несколько советов по работе с Git, о которых вы, возможно, не знали. Эти советы помогут вам оптимизировать ваш процесс разработки.
Алиасы
Одним из лучших способов упрощения работы с 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-сервера.
Автор: Softmart