Хабрахабр

[Перевод] Git: исправление ошибок и наведение порядка в коммитах

Ошибка в коммите… Как её исправить? Беспорядок в истории коммитов… Как привести всё в пристойный вид? Автор статьи, перевод которой мы публикуем сегодня, говорит, что она написана специально для тех, кто задавался такими вопросами. По его словам, изучив методики работы с 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, может, выполняя каждый коммит, не заботиться о сведениях об его авторе.

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

git config user.email "your email id"

Предположим, вы забыли выполнить такую настройку и уже сделали первый коммит. Исправить положение может уже знакомая нам команда amend. С её помощью можно изменить сведения об авторе предыдущего коммита:

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

▍Примечание

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

Наведение порядка в истории коммитов

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

Это позволяет избежать множества конфликтов, связанных со слиянием, возникающих при слишком редкой синхронизации репозиториев. Рекомендуется поддерживать синхронизацию между локальным и удалённым репозиториями. Следуя этой практике, вы решаете загружать изменения из удалённого репозитория каждые два дня.

Это означает, что в вашей локальной истории коммитов будет много таких коммитов, которые могут запутать того, кто будет просматривать ваш код. Каждый раз, когда вы загружаете код из удалённого в локальный репозиторий, в локальном репозитории создаётся новый коммит-слияние (Merge Commit).


История коммитов в локальном репозитории

Для решения этой задачи можно воспользоваться командой git rebase. Как привести в порядок историю коммитов?

▍Команда git rebase

Рассмотрим команду git rebase на примере.


Коммиты в ветке Release и в ветке Feature

Вы создали свою ветку Feature из ветки Release, когда в ней был всего один коммит — Rcommit1. В ветке Release есть три коммита: Rcommit1, Rcommit2, и Rcommit3. Это — Fcommit1 и Fcommit2. После этого вы добавили два коммита в ветку Feature. Для того чтобы это сделать, вы собираетесь воспользоваться командой rebase. Ваша цель заключается в том, чтобы загрузить коммиты из ветки Release в свою ветку Feature.

Будем использовать для двух рассматриваемых веток имена release и feature.

В результате применение команды rebase будет выглядеть так:

git checkout feature
git rebase release

▍Особенности команды rebase

Команда rebase используется для того, чтобы обеспечить наличие в ветке Feature свежего кода из ветки Release.

Если звучит это сложно — давайте рассмотрим следующий рисунок. При применении этой команды система пытается добавить в ветку Feature каждый коммит, по одному, и осуществить проверку на наличие конфликтов. Тут показаны внутренние механизмы команды rebase.


Ветка Feature и три шага работы команды rebase

Шаг 1

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

Шаг 2

Теперь Git пытается добавить коммит Fcommit1 в ветку Feature. При отсутствии конфликта Fcommit1 добавляется после Rcommit3. При обнаружении конфликта Git сообщит об этом и вам придётся разрешить этот конфликт вручную.

Шаг 3

После того, как в ветку Feature добавлен коммит Fcommit1, Git пытается добавить туда же Fcommit2. Тут, опять же, если конфликтов нет, то Fcommit2 добавляется после Fcommit1 и операция оказывается успешно завершённой. Если обнаружен конфликт, то Git, как и прежде, сообщит об этом и предложит с ним разобраться.

После завершения работы команды rebase можно будет увидеть, что в ветке Feature имеются коммиты Rcommit1, Rcommit2, Rcommit3, Fcommit1, и Fcommit2.

▍Примечание

При работе с Git находят применение и команда merge, и команда rebase. Нельзя сказать, что одна из них предпочтительнее другой.

В случае использования rebase никаких дополнительных коммитов у вас не будет. В случае использования команды merge вы получите коммит-слияние.

Так, rebase подходит для обновления кода локального репозитория на основе свежего кода из удалённого репозитория. Рекомендуется использовать эти команды в различных ситуациях. Используйте команду merge, выполняя пулл-запросы, направленные на слияние ветки Feature с веткой Release или Master.

Итоги

Изучив представленные в этом материале концепции, вы улучшили свои навыки владения Git и приблизились к уровню Git-эксперта. Надеемся, то, что вы тут узнали, вам пригодится. Но мир Git огромен, поэтому, освоив что-то новое, не останавливайтесь на достигнутом и двигайтесь дальше.

Уважаемые читатели! Сталкивались ли вы с беспорядком в Git-коммитах?

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть