Открыли для себя Git? Разобраться в этом не так просто, поэтому мы написали несколько советов для начинающих Git-разработчиков. Я кое-что неправильно закоммитил.
Как это исправить, если история изменений не позволяет разобраться, что происходило? Если у вас возникали подобные вопросы, продолжайте изучение статьи.
Объясняем ситуации, которые могут облегчить жизнь Git-разработчиков.
Сценарий №1
Предположим, что вы закоммитили слишком много файлов и поняли, что пометка к записи написана непонятно. Чтобы изменить это сообщение, можно использовать git commit —amend
git commit --amend -m “New commit message”Сценарий №2
Предположим, что вы хотели отправить шесть файлов, но случайно забыли про один из них. Первое, что приходит в голову − сделать новую правильную запись.
В этом подходе нет ничего плохого. Но чтобы поддерживать историю фиксации в удобном виде, было бы лучше изменить предыдущую запись. Это можно сделать, используя git commit —amend:
git add file6
git commit --amend --no-edit—no-edit делает так, чтобы запись не менялась.
Сценарий №3
Всякий раз, когда вы коммитите Git, в записи упоминается имя автора и адрес его электронной почты. Как правило, они указываются при первой настройке Git.
Допустим, для конкретного проекта вы хотите использовать другие данные электронной почты. Настроить их можно с помощью команды:
А что если вы забыли настроить эти данные и уже отправили коммит? Amend может быть использован и для изменения данных автора. Вот так:
Внимание!
Используйте команду amend только в локальном, а не удаленном репозитории.
В истории коммитов бардак. Как это исправить?
Например, происходит работа над фрагментом кода. Вы знаете, что процесс займет порядка десяти дней, и в течение этого времени другие разработчики также будут передавать код удаленному репозиторию.
Это полезно, потому что позволяет синхронизировать код локального и удалённого репозиториев. Как следствие, количество проблем при отправке изменений на проверку минимизируется.
Каждый раз, когда вы перемещаете код из удаленного репозитория в локальный, создается merge commit. Если коммитов станет слишком много, то программист, изучающий внесённые изменения, может запутаться
Тогда как привести это всё в нормальное состояние?
Здесь на помощь приходит rebase. Как это работает:
- В ветви Release есть три объекта: Rcommit1, Rcommit2 и Rcommit3.
- Вы создали ветвь Feature из ветви Release, когда там была единственная запись − Rcommit1.
- Затем в ветку Feature добавили ещё два коммита − Fcommit1 и Fcommit2
- Нужно перевести их из одной ветки в другую. Для этого применяем rebase.
- Теперь пришло время rebase. Вот так:
Цель − обеспечить, чтобы ветвь Feature получила последний код из ветви Release.
Rebase по очереди добавляет коммиты и проверяет их на несоответствия. Кажется странным? Вот что происходит внутри функции:
Шаг №1
- При запуске команды ветвь Feature укажет на начало ветви Release.
- Теперь ветвь Feature имеет три коммита: Rcommit1, Rcommit2 и Rcommit3.
- Что случилось с Fcommit1 и Fcommit2? Нет, они не исчезли и встретятся далее.
Шаг №2
- Теперь Git пытается добавить Fcommit1 в ветвь Feature.
- Если всё в порядке, Fcommit1 добавляется после Rcommit3.
- Если есть проблемы, Git уведомит вас, решать их придется вручную. Для продолжения, используйте следующие команды:
Шаг №3
- После добавления Fcommit1 Git попытается добавить Fcommit2.
- Опять же, если всё в порядке, Fcommit2 добавится после Fcommit1.
- Если нет, то изучать проблему придётся самостоятельно, после чего переходите к командам из пункта выше.
- Когда процесс закончится, вы заметите, что ветвь Feature имеет Rcommit1, Rcommit2, Rcommit3, Fcommit1 и Fcommit2.
Полезно знать
- Rebase и Merge одинаково полезны в Git.
- Обе команды помогают в объединении, но rebase не делает лишних записей.
- Лучше всего использовать команды в разных ситуациях. Например, rebase, когда вы синхронизируете код локального репозитория с кодом из удалённого, а merge − при объединении веток.
- Запомните, rebase − только для локального репозитория, иначе возникнет путаница с коммитами других программистов.