Открыли для себя 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.

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

git config user.email “your email id”

А что если вы забыли настроить эти данные и уже отправили коммит? Amend может быть использован и для изменения данных автора. Вот так:

git commit --amend --author "Author Name <Author Email>"

Внимание!

Используйте команду amend только в локальном, а не удаленном репозитории.

В истории коммитов бардак. Как это исправить?

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

Это полезно, потому что позволяет синхронизировать код локального и удалённого репозиториев. Как следствие, количество проблем при отправке изменений на проверку минимизируется.

Каждый раз, когда вы перемещаете код из удаленного репозитория в локальный, создается merge commit. Если коммитов станет слишком много, то программист, изучающий внесённые изменения, может запутаться.

Тогда как привести это всё в нормальное состояние?

Здесь на помощь приходит rebase. Как это работает:

1. В ветви Release есть три объекта: Rcommit1, Rcommit2 и Rcommit3.
2. Вы создали ветвь Feature из ветви Release, когда там была единственная запись − Rcommit1.
3. Затем в ветку Feature добавили ещё два коммита − Fcommit1 и Fcommit2
4. Нужно перевести их из одной ветки в другую. Для этого применяем rebase.
5. Теперь пришло время rebase. Вот так:

git checkout feature
git rebase release

Цель − обеспечить, чтобы ветвь Feature получила последний код из ветви Release.

Rebase по очереди добавляет коммиты и проверяет их на несоответствия. Кажется странным? Вот что происходит внутри функции:

Шаг №1

1. При запуске команды ветвь Feature укажет на начало ветви Release.
2. Теперь ветвь Feature имеет три коммита: Rcommit1, Rcommit2 и Rcommit3.
3. Что случилось с Fcommit1 и Fcommit2? Нет, они не исчезли и встретятся далее.

Шаг №2

1. Теперь Git пытается добавить Fcommit1 в ветвь Feature.
2. Если всё в порядке, Fcommit1 добавляется после Rcommit3.
3. Если есть проблемы, Git уведомит вас, решать их придется вручную. Для продолжения, используйте следующие команды:

git add fixedfile
git rebase --continue

Шаг №3

1. После добавления Fcommit1 Git попытается добавить Fcommit2.
2. Опять же, если всё в порядке, Fcommit2 добавится после Fcommit1.
3. Если нет, то изучать проблему придётся самостоятельно, после чего переходите к командам из пункта выше.
4. Когда процесс закончится, вы заметите, что ветвь Feature имеет Rcommit1, Rcommit2, Rcommit3, Fcommit1 и Fcommit2.

Полезно знать

• Rebase и Merge одинаково полезны в Git.
• Обе команды помогают в объединении, но rebase не делает лишних записей.
• Лучше всего использовать команды в разных ситуациях. Например, rebase, когда вы синхронизируете код локального репозитория с кодом из удалённого, а merge − при объединении веток.
• Запомните, rebase − только для локального репозитория, иначе возникнет путаница с коммитами других программистов.

Возможно, вас заинтересуют следующие материалы

• 11 концепций и команд git, которые заставят вас плакать
• Как использовать Git эффективно: налаживаем работу Git workflow
• Git-мастер: 3 простых шага для достижения цели

Источник: Советы для Git-разработчиков on freeCodeCamp