Если вы хотите отправить свои изменения в ветку, а кто-то уже сделал это до вас, то сначала вы должны вытянуть эти изменения. Обычно 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} используется по умолчанию, если не указаны другие аргументы.
Это дает возможность подчистить изменения, которыми вы собираетесь поделиться. Например, провести объединение связанных между собой коммитов и отредактировать сообщения коммитов, если они слишком длинные или недостаточно описательны.
Идея достаточно проста: не делайте ошибки или опечатки частью истории проекта, если еще не отправили их в главный репозиторий.
Если вы длительное время работаете над feature-веткой, иногда приходится проводить слияние с master-веткой (под "master" подразумевается главная ветка для разработки), чтобы убедиться, что они совместимы и получены самые свежие исправления ошибок.
Вы также можете перебазировать текущую ветку на master-ветку, но перебазирование имеет свои недостатки: * Если над функциональностью работает множество людей, то переписывание истории усложняет их рабочий процесс. * Разрешить конфликты слияния может быть проще во время слияния, чем разрешать более многочисленные конфликты поменьше при перебазировании.
После работы над feature-веткой, делайте слияние в master-ветку таким образом:
git merge --no-ff feature
Флаг --no-ff прогарантирует, что коммит слияния всегда будет создан, даже когда в этом нет технической необходимости. Коммиты слияния полезны, потому что содержат следующую информацию:
Иногда ветка состоит из одного единственного коммита, особенно в случаях исправления ошибок. При их слиянии запись в коммите слияния об этом коммите менее информативна для команды, так как фактически дублирует его описание.
Такой коммит вы можете втянуть в master-ветку так:
git cherry-pick feature