Git merge против rebase

Избегайте коммитов слияния, которые образуются при выполнении git pull

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

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

Вам следует всегда вытягивать изменения через git pull --rebase. В git это можно сделать поведением по умолчанию:

git config --global --bool pull.rebase true

Перед отправкой в главный репозиторй выполняйте интерактивное перемещение локальных коммитов

Выполняйте эту команду каждый раз перед отправкой набора коммитов:

git rebase -i @{u}

Здесь "u" обозначает "upstream" (добавлено в git v1.7.0) и определяется как последний коммит текущей ветки удаленного репозитория. Проще говоря, эта команда переписывают историю только локальных коммитов, которые вы собираетесь отправить. Начиная с git v.1.7.6, @{upstream} используется по умолчанию, если не указаны другие аргументы.

Это дает возможность подчистить изменения, которыми вы собираетесь поделиться. Например, провести объединение связанных между собой коммитов и отредактировать сообщения коммитов, если они слишком длинные или недостаточно описательны.

Идея достаточно проста: не делайте ошибки или опечатки частью истории проекта, если еще не отправили их в главный репозиторий.

Объединяйте изменения из master-ветки в feature-ветку через слияние

Если вы длительное время работаете над feature-веткой, иногда приходится проводить слияние с master-веткой (под "master" подразумевается главная ветка для разработки), чтобы убедиться, что они совместимы и получены самые свежие исправления ошибок.

Вы также можете перебазировать текущую ветку на master-ветку, но перебазирование имеет свои недостатки: * Если над функциональностью работает множество людей, то переписывание истории усложняет их рабочий процесс. * Разрешить конфликты слияния может быть проще во время слияния, чем разрешать более многочисленные конфликты поменьше при перебазировании.

Записывайте коммит слияния, когда новая функциональность попадает в master-ветку

После работы над feature-веткой, делайте слияние в master-ветку таким образом:

git merge --no-ff feature

Флаг --no-ff прогарантирует, что коммит слияния всегда будет создан, даже когда в этом нет технической необходимости. Коммиты слияния полезны, потому что содержат следующую информацию:

  • откуда пришли изменения (в данном случае: из feature-ветки);
  • когда и кем было произведено слияние, по возможности обозначая рецензирование кода (если это часть ваше процесса разработки);
  • хранит коммиты, относящиеся к этой функциональности, в сгруппированном виде.

Иногда ветка состоит из одного единственного коммита, особенно в случаях исправления ошибок. При их слиянии запись в коммите слияния об этом коммите менее информативна для команды, так как фактически дублирует его описание.

Такой коммит вы можете втянуть в master-ветку так:

git cherry-pick feature

Оригинал: http://mislav.net/2013/02/merge-vs-rebase/

Статьи и заметки
ЛИЧНЫЙ КАБИНЕТ
На вашу почту отправлено сообщение с кодом подтверждения. Введите его для завершения регистрации.
ВЫПОЛНИТЬ