Полезные советы для начинающих Git-разработчиков

3
7050
Добавить в избранное

Открыли для себя Git? Разобраться в этом не так просто, поэтому мы написали несколько советов для начинающих Git-разработчиков.

Я кое-что неправильно закоммитил. Как это исправить, если история изменений не позволяет разобраться, что происходило?

Если у вас возникали подобные вопросы, продолжайте изучение статьи. Объясняем ситуации, которые могут облегчить жизнь Git-разработчиков.

Сценарий №1

Предположим, что вы закоммитили слишком много файлов и поняли, что пометка к записи написана непонятно. Чтобы изменить это сообщение, можно использовать git commit —amend:

Сценарий №2

Предположим, что вы хотели отправить шесть файлов, но случайно забыли про один из них. Первое, что приходит в голову − сделать новую правильную запись.

В этом подходе нет ничего плохого. Но чтобы поддерживать историю фиксации в удобном виде, было бы лучше изменить предыдущую запись. Это можно сделать, используя git commit —amend:

—no-edit делает так, чтобы запись не менялась.

Сценарий №3

Всякий раз, когда вы коммитите Git, в записи упоминается имя автора и адрес его электронной почты. Как правило, они указываются при первой настройке Git.

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

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

Внимание!

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

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

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

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

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

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

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

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

Цель − обеспечить, чтобы ветвь 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 уведомит вас, решать их придется вручную. Для продолжения, используйте следующие команды:

Шаг №3

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

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

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

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

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

Ищете с чего начать?

Подпишитесь на нашу рассылку, чтобы получать больше интересных материалов:

И не беспокойтесь, мы тоже не любим спам. Отписаться можно в любое время.




3 Комментарии

  1. Git-разработчик? Наверно можно было подобрать термин получше. Для меня Git-разработчик это тот, кто разрабатывает Git…

Оставьте комментарий