Перевод статьи Адити Сридхара «How to become a Git expert».
Я сделал ошибку в своем коммите, как это исправить?
Моя история коммитов это полный бардак, как сделать ее аккуратнее?
Если вы когда-либо задавались подобными вопросами, этот пост для вас. В нем освещается список тем, знание которых позволит вам улучшить свой опыт работы с Git.
Помните: чтобы получить наибольшую пользу от этой статьи, для начала вам нужно освоить основы Git.
Я сделал ошибку в своем коммите. Что делать?
Сценарий 1
Например, вы сделали коммит нескольких файлов и поняли, что введенное вами сообщение коммита не слишком понятное. Вы хотите его изменить. Чтобы это сделать, вам нужно использовать команду git commit —amend
[code]git commit —amend -m “Новое сообщение коммита”[/code]
Сценарий 2
Скажем, вы хотели сделать коммит 6 файлов, но по ошибке внесли только 5. Можно, конечно, создать новый коммит и добавить 6-й файл.
В этом подходе нет ничего плохого. Но чтобы ваша история коммитов была аккуратнее, будет лучше каким-то образом добавить этот файл к предыдущему коммиту. Это также можно сделать с помощью команды git commit —amend:
[code]git add file6
git commit —amend —no-edit[/code]
—no-edit означает, что сообщение коммита не меняется.
Сценарий 3
Когда бы вы ни сделали коммит в Git, к нему будет привязано имя автора и email. Вообще, эти данные указываются при первоначальной настройке Git. Об этих деталях не стоит волноваться при каждом коммите.
Но может так случиться, что в конкретном проекте вы захотите использовать другой email ID. Сконфигурировать email id для этого проекта можно следующей командой:
[code]git config user.email “ваш email id”[/code]
Памятка
Используйте команду 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 можно сделать с помощью следующих команд:
[code]git checkout feature
git rebase release[/code]
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. Это очень важные темы, которые вам обязательно пригодятся.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]