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
Или, для одного конкретного файла:
$ git checkout HEAD -- path/to/file
Далее, если ненужные изменения уже были закоммичены, для их отката нужно ввести:
$ git reset Более эффективное использование Git blame
Git blame используется для того, чтобы узнать, кто внес изменения в определенную строку файла. Существует набор флагов, которые можно передавать данной команде, в зависимости от того, что вы хотите вывести:
$ git blame -w
$ git blame -M
$ git blame -C
Помимо описанных выше советов по работе с командами, существует несколько общих советов по работе с Git.
Делайте пулл часто
Если вы используете GitLab Workflow, значит вы работаете в ветках для выделенной функциональности (feature branches). Пока вы работаете над фичей в отдельной ветке, в мастер-ветке может произойти множество изменений, некоторые из которых могут конфликтовать с добавленными фичами.
Для того, чтобы избежать подобных конфликтов, нужно как можно чаще пуллить изменения из мастер-ветки в вашу. Это позволит разрешать возможные конфликты по мере их появления и сделает последующий мерж вашей ветки гораздо более легким.
Частые коммиты, редкие пуши
Частые коммиты логически разделяют добавленную функциональность и позволяют откатывать отдельные ее части при необходимости. Однако нет никакой необходимости пушить каждый коммит на сервер: единственное, к чему это приведет – засорение истории изменений. Пушьте только тогда, когда ваша фича готова.
Пуш только после тестирования изменений
Хорошим знаком того, что изменения готовы к пушу, является успешное прохождение тестов. Также это как правило значит, что данный блок реализуемой функциональности завершен, и можно переключить свои усилия на следующий. Делайте пуш изменений только после прохождения всех тестов, с последующим повторным их прохождением на стороне CI-сервера.
Источник: https://habrahabr.ru/company/softmart/blog/307526/?utm_source=habrahabr&utm_medium=rss&utm_campaign=interesting
Комментариев нет:
Отправить комментарий