Я сделал ошибку в коммите, как ее исправить? Моя история коммитов – хаос, как навести порядок? Если вы когда-либо задавались любым из представленных выше вопросов, то эта статья для вас. В этом посте описывается несколько тем, благодаря которым вы станете экспертом в GIT.
Чтобы данная статья пошла вам на пользу, вы должны знать основы GIT.
Я допустил в моих коммитах GIT, ошибки. Как их исправить?
Сценарий 1
Допустим, вы добавили в коммит кучу файлов и поняли, что введенное вами сообщение коммита на самом деле не является понятным. Теперь вы хотите изменить сообщение. Для этого вы можете использовать git commit --amend
git commit --amend -m "New commit message"
Сценарий 2
Допустим, вы хотели добавить в коммит 6 файлов, но по ошибке вы в итоге добавили только 5 файлов. Вы можете подумать, что можете создать новый коммит и добавить в нее 6-й файл.
В этом подходе нет ничего плохого. Но, чтобы поддерживать аккуратную историю коммитов, разве не лучше каким-то образом добавить этот файл в предыдущий коммит? Это можно сделать с помощью git commit --amend:
git add file6
git commit --amend --no-edit
--no-edit означает, что сообщение коммита не изменится.
Сценарий 3
Всякий раз, когда вы делаете коммит в GIT, он имеет имя автора и адрес электронной почты автора. Обычно, когда вы настраиваете GIT впервые, вы указываете имя автора и адрес электронной почты. Вам не нужно беспокоиться об авторах для каждого коммита.
Тем не менее, возможно, что для конкретного проекта вы хотите использовать другую почту. Вам необходимо настроить ее для этого проекта с помощью команды:
git config user.email "your email id"
Допустим, вы забыли настроить электронную почту и уже сделали свой первый коммит. Amend также может использоваться для изменения автора вашего предыдущего коммита. Автор коммита может быть изменен с помощью следующей команды:
git commit --amend --author "Author Name <Author Email>"
Используйте команду amend только в локальном хранилище. Использование amend для удаленного хранилища может повлечь много путаницы.
Моя история коммитов – хаос. Как навести порядок?
Допустим, вы работаете над кодом. Вы знаете, что для завершения работы потребуется около 10 дней. В течение этих 10 дней другие разработчики также будут добавлять код в удаленный репозиторий.
Рекомендуется регулярно обновлять код локального репозитория вместе с кодом в удаленном репозитории. Это позволяет избежать множества конфликтов слияния позже, когда вы будете создавать запрос на извлечение. Итак, вы решаете, что вы будете извлекать изменения из удаленного хранилища раз в 2 дня.
Каждый раз, когда вы извлекаете код из удаленного хранилища в локальное, в вашем локальном хранилище создается новая версия слияния. Это означает, что ваша локальная история коммитов будет иметь много версий слияния, которые могут запутать того, кто будет просматривать код.
Как сделать так, чтобы история коммитов смотрелась аккуратнее?
Здесь вам поможет rebase.
Что такое rebasing – перемещение?
Давайте объясню на примере.
- У ветки Release 3 коммита: Rcommit1, Rcommit2, Rcommit3;
- Вы создали ветку Feature из ветки Release, когда в ней был только один коммит – Rcommit1;
- Вы добавили 2 коммита в ветку Feature: Fcommit1 и Fcommit2;
- Ваша цель – переместить коммиты из Release в Feature;
- Для этого вы будете использовать rebase;
- Пусть название вашей ветки Release – release, а Feature – feature;
Перемещение можно сделать с помощью таких команд:
git checkout feature
git rebase release
Перемещение (Rebasing)
При перемещении ваша цель - обеспечить, чтобы ветвь Feature получала самый последний код из ветки Release.
Перемещение пытается добавить каждый коммит последовательно и проверяет наличие конфликтов. Звучит странно?
Позвольте объяснить с помощью диаграммы.
Это показывает, что фактически делает перемещение:
Шаг 1
- Когда вы запустите команду, ветка Feature будет находиться в начале Release;
- Теперь в ветке Feature 3 коммита: Rcommit1, Rcommit2, Rcommit3;
- Вам, возможно, интересно, что произошло с Fcommit1 и Fcommit2;
- Эти коммиты все еще остались на месте и будут использованы ниже.
Шаг 2
- Теперь GIT попытается добавить Fcommit1 в ветку Feature;
- Если не возникнет конфликта, Fcommit1 будет добавлена после Rcommit3;
- Если будут в GIT ошибки, вам придет уведомление. Вам придется решать конфликт вручную. После этого используйте следующие команды, чтобы продолжить перемещение.
git add fixedfile
git rebase --continue
Шаг 3
- После того как будет добавлена Fcommit1, GIT попытается добавить Fcommit2;
- Если не возникнет конфликта, Fcommit2 будет добавлена после Fcommit1, а перемещение пройдет успешно;
- Если будут в GIT ошибки, вам придет уведомление. Вам придется решать конфликт вручную. Используйте те же команды, что были в шаге 2;
- После того как будет завершено все перемещение, вы увидите, что в ветке Feature есть Rcommit1, Rcommit2, Rcommit3, Fcommit1 и Fcommit2.
Важно знать и помнить
- В GIT полезны и rebase, и merge;
- При использовании merge вы получите коммит слияния. В случае rebase не существует дополнительных коммитов;
- Один из лучших способов - использовать команды в разных местах. Используйте rebase, когда вы обновляете свой локальный каталог кода, используя последний код из удаленного каталога. Используйте merge, когда вы имеете дело с запросами на извлечение, чтобы объединить ветку Feature с веткой Release или Master;
- Использование Rebase изменяет историю коммитов (делает ее более аккуратной). Но изменение истории сопряжено с риском. Убедитесь, что вы никогда не используете rebase для кода, который находится в удаленном хранилище. Всегда используйте rebase только для изменения истории вашего локального кода;
- Если перемещение будет выполнено для удаленного каталога, это может создать большую путаницу, так как другие разработчики не будут понимать новую историю;
- Кроме того, если перемещение выполняется в удаленном хранилище, это может создать проблемы, когда другие разработчики попытаются извлечь последний код из удаленного хранилища. Всегда используйте rebase только для локального хранилища.
Поздравляю
Теперь вы эксперт в GIT.
Из этой статьи вы узнали о:
- Исправлении коммитов;
- Перемещении.
Это очень полезные концепции. Исследуйте мир GIT, чтобы узнать еще больше.