[Перевод] 8 советов для более эффективной работы с Git10.08.2016 20:18

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



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-сервера.

Комментарии (7)

  • 10 августа 2016 в 16:23

    0

    ↑

    ↓

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

    А разве после пуша пачки коммитов, они каким то магическим образом будут сгруппированы?

    • 10 августа 2016 в 16:25

      +1

      ↑

      ↓

      Наверное, имеется в виду локальный rebase со squash коммитов в один.

      • 10 августа 2016 в 16:26

        0

        ↑

        ↓

        Возможно, только вот коммиты все равно должны быть пачкой. Лучше уж сразу применять модель: функция = ветка.

  • 10 августа 2016 в 17:09

    0

    ↑

    ↓

    С одной стороны всё это можно узнав, прочитав официальную документацию.
    С другой стороны, каждый раз лезть в документацию неохота.

    Мне кажется лучшим решением было бы дополнительно к статье создать cheat sheet (на cheatography по git уже есть, но того, что описано в статье, там нет).

    • 10 августа 2016 в 18:26

      +1

      ↑

      ↓

      Практически все 8 советов можно прочитать чуть ли не на первой страничке официальной документации по GIT.
      https://git-scm.com/doc

      Например Git cheat sheet: https://services.github.com/kit/downloads/github-git-cheat-sheet.pdf

  • 10 августа 2016 в 17:28

    0

    ↑

    ↓

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

    Рекомендую использовать для этих целей worktree. Это куда удобнее бесконечных stash → checkout → checkout → stash pop. Единственное что GUI клиенты ещё не научились с этим корректно работать. SmartGit и gitg по крайней мере.

    • 10 августа 2016 в 18:49

      0

      ↑

      ↓

      IDEA относительно недавно умеет worktree, и очень давно — «smart checkout» (stash → checkout → stash pop)

© Habrahabr.ru