Блог

Интересно, не совершаю ли я ошибку, сначала объединив мастер с другой веткой, а затем объединив его обратно с мастером.

Предположим, я создаю следующие ветки, каждая с отдельной фиксацией:

             mkdir git_merging
            cd git_merging/
            git init
            touch on_master
            git add .
            git commit -m "Initial commit on master"

            git checkout -b x
            touch on_branch_x
            git add .
            git commit -m "Initial commit on branch x"

            git checkout master
            touch on_master_again
            git add .
            git commit -m "Commit on master after branching"
  

Теперь я хочу объединить. Обычно я предпочитаю сначала объединить master в x, а затем объединить x в master:

             git checkout x
            git merge -m "Merge master into x" master 
            echo "test results"
            git checkout master 
            git merge x
  

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

             git merge -m "Merge x into master" x
            git checkout x 
            git merge master 
  

На практике я часто сталкиваюсь с репозиториями, которые, похоже, объединяются исключительно с мастером. Есть ли какие-либо недостатки в моем подходе? Есть причины, по которым я не должен этого делать?

Это довольно субъективный вопрос, но я дам ему пропуск, потому что я думаю, что могу придумать довольно объективный ответ.

Отличная практика — объединить мастер обратно в свою ветку перед ее объединением. Что, если кто-то другой совершил что-то, что нарушило функцию, которую вы только что реализовали (как вы указали)? Или что, если кто-то изменил тот же код, что и вы, и вызвал возможные конфликты слияния? На самом деле я очень часто предлагаю объединить мастер обратно в вашу ветку. Это не только избавит вас от необходимости тратить полтора дня на разрешение конфликтов слияния (хотя это может быть признаком того, что ваши ветки слишком большие, но это уже другая история), но и позволит вам следить за изменениями и развитием проекта.

Некоторые могут сказать, что вам следует перебазировать свои коммиты поверх master. Моя короткая версия такова: я призываю людей открывать запросы на извлечение очень рано в процессе разработки, даже если функция не выполнена. Это означает, что вы, скорее всего, отправляете свой код на удаленный сервер (например, на GitHub). Чтобы перебазировать ваши коммиты, вам нужно будет нажать с переписанной историей git и принудительно нажать. Принудительное нажатие — плохое решение для рабочего процесса, и его следует избегать, так как это может нанести (почти) непоправимый ущерб вашей истории коммитов.

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