Как улучшить свой опыт работы с Git

Я сделал ошибку в своем коммите, как это исправить?

Моя история коммитов это полный бардак, как сделать ее аккуратнее?

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

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

Я сделал ошибку в своем коммите. Что делать?

Сценарий 1

Например, вы сделали коммит нескольких файлов и поняли, что введенное вами сообщение коммита не слишком понятное. Вы хотите его изменить. Чтобы это сделать, вам нужно использовать команду git commit —amend

git commit --amend -m “Новое сообщение коммита”

Сценарий 2

Скажем, вы хотели сделать коммит 6 файлов, но по ошибке внесли только 5. Можно, конечно, создать новый коммит и добавить 6-й файл.

В этом подходе нет ничего плохого. Но чтобы ваша история коммитов была аккуратнее, будет лучше каким-то образом добавить этот файл к предыдущему коммиту. Это также можно сделать с помощью команды git commit —amend:

git add file6git

commit --amend --no-edit

—no-edit означает, что сообщение коммита не меняется.

Сценарий 3

Когда бы вы ни сделали коммит в Git, к нему будет привязано имя автора и email. Вообще, эти данные указываются при первоначальной настройке Git. Об этих деталях не стоит волноваться при каждом коммите.

Но может так случиться, что в конкретном проекте вы захотите использовать другой email ID. Сконфигурировать email id для этого проекта можно следующей командой:

git config user.email “ваш email id”

Памятка

Используйте команду amend только в своем локальном репозитории. Использование amend для удаленного репозитория может создать много путаницы.

Моя история коммитов беспорядочна. Как с этим справиться?

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

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

Каждый раз, когда вы забираете код из удаленного репозитория в локальный, в вашем локальном репозитории создается новый merge-коммит. Это означает, что в вашей локальной истории будет много merge-коммитов, а это может сбивать с толку того, кто затем будет ее просматривать.

Как сделать историю коммитов аккуратнее? В этом вам поможет rebase.

Что такое rebasing?

Объясню на примере.

• В Release branch есть три коммита: Rcommit1, Rcommit2 и Rcommit3.
• Вы создали ваш Feature branch из Release branch, когда в нем был только один коммит – Rcommit1.
• Вы добавили два коммита в Feature branch. Это Fcommit1 и Fcommit2.
• Ваша цель – получить коммиты из Release branch в ваш Feature branch.
• Для этого вы собираетесь использовать rebase.
• Давайте назовем Release branch словом release, а Feature branch – словом feature.
• Rebasing можно сделать с помощью следующих команд:

git checkout featuregit rebase release

Rebasing

При выполнении rebasing ваша цель – обеспечить получение Feature branch последнего кода из Release branch.

Rebasing пытается добавить все коммиты один за другим и проверяет, нет ли конфликтов. Звучит запутанно?

Я поясню с помощью диаграммы. Здесь показано, что на самом деле осуществляет rebasing.

Шаг 1

• При запуске команды Feature branch направлен к head Release branch.
• Теперь Feature branch содержит три коммита: Rcommit1, Rcommit2 и Rcommit3.
• Вероятно, вам интересно, что случилось с Fcommit1 и Fcommit2.
• Эти коммиты по-прежнему здесь; они будут использоваться в следующих шагах.

Шаг 2

• Теперь Git пытается добавить Fcommit1 в Feature branch.
• Если конфликтов нет, Fcommit1 добавляется после Rcommit3.
• Если есть конфликт, Git уведомит вас об этом и вам придется разрешить этот конфликт вручную.

Шаг 3

• Когда Fcommit1 будет добавлен, Git попытается добавить Fcommit2.
• Опять же, если конфликтов не будет, Fcommit2 добавится после Fcommit1 и rebase пройдет успешно.
• Если будет конфликт, Git уведомит вас об этом и вам придется разрешить этот конфликт вручную.
• После полного окончания rebase вы заметите, что Feature branch содержит Rcommit1, Rcommit2, Rcommit3 , Fcommit1 и Fcommit2.

Что стоит запомнить

• В Git полезен и Rebase, и Merge. Один ничем не лучше другого.
• В случае с merge у вас будет merge-коммит. В случае с rebase таких дополнительных коммитов не будет.
• Самый лучший подход – использовать эти команды с различными целями. Выбирайте rebase для обновления своего локального репозитория в соответствии с последними изменениями на удаленном репозитории. Используйте merge при пул-реквестах, чтобы слить Feature branch обратно в Release или Master branch.

Поздравляю. Теперь вы Git-эксперт

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

Ставьте лайки, подписывайтесь на канал и группу ВКонтакте -https://vk.com/mrsisadm там еще больше интересного!