Изменение поведения git merge в релизе 1.7.10 перевод

В соответствии с календарем релизов осталось всего несколько недель до заморозки списка фич следующего релиза git (1.7.10), в который войдет улучшение работы git merge, нарушающее обратную совместимость и ставящее «под удар» тех, кто использует merge в своих скриптах.
Мы решили последовать совету Джейка Эджа (Jake Edge): «Большинство свободных проектов обсуждают планируемые изменения до их реализации и дают пользователям возможности протестировать новые фичи задолго до релиза. Лучшая помощь проекту на этом этапе — четко обоснованные, конкретные описания существующих проблем, отсутствующей функциональности и т.д., а не бесконечный поток сообщений „Project XYZ ОТСТОЙ!!!11“ в списках рассылки или комментариях»

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


Когда git merge пытается выполнить слияние двух или более веток, генерируется описание — какие ветки участвовали в слиянии и, если автоматическое слияние успешно, — эта заготовка записывается как описание коммита без всякого вмешательства со стороны пользователя. Если же автоматическое слияние провалилось — мы даем пользователю шанс все исправить самостоятельно и использовать git commit для записи результата.

Большинство слияний проходит без всяких проблем, и именно это поведение привело к тому, что люди делают merge не задумываясь, даже в тех ситуациях когда необходимо объяснить причину этого действия. Никто не затрудняет себя вызовом git commit --amend для заполнения описания о причинах слияния после успешного merge.

Недавно в списке рассылки Git Линус заметил (и я согласен с ним) что такое поведение — ошибка дизайна системы, сделанная на самой заре существования Git. И теперь, начиная с 1.7.10, при запуске git merge в консоли (стандартный ввод и вывод присоединены к терминалу) открывается редактор для создания описания коммита, давая шанс пользователю объяснить причины своего поступка.

Мы бы хотели дать парочку рекомендаций, которые могут помочь нашим пользователям привыкнуть к этому изменению:

(1) Когда git merge запускается из командной строки возможны два варианта:
— вы вливаете обновленный upstream в ветку, в которой вы работаете над новым функционалом (topic branch). Подобное слияние без реальных на то причин — дурная практика. Подобное слияние в «неправильном» направлении должно производиться только в случае крайней необходимости, к примеру если ваша новая функциональность зависит от улучшений, недавно принятых в upstream. В противном случае, ваша ветка прекращает содержать в себе коммиты, относящиеся к одной единице функциональности, и, вместо этого становится свалкой коммитов из разных источников. В этом случае новое поведение git merge вам на руку, т.к. больше не прийдется вызывать amend для выяснения причин.
— при вливании ветки с новой функциональностью в интеграционную ветку (или ветку тестирования) причина слияния обычно понятна из контекста — вы вливаете готовую функциональность в проект. В таком случае вы можете передать параметр --no-edit в вызов git-merge и согласиться с подготовленным сообщением без редактирования

(2) У вас есть скрипт, выполняющий git merge и вы оставили стандартный поток ввода и вывода привязанными к терминалу, скрипт спросит у пользователя о причинах merge. Это может быть нежелательно. К примеру, часто подобные скрипты используются для массового слияния большого количества веток в тестовую ветку и должны оставаться неинтерактивными до тех пор, пока подобное автоматическое слияние возможно. Очевидно, что в таком случае вам желательно сохранить старое поведение команды. Совершенно необязательно добавлять --no-edit к каждому вызову git merge. Вместо этого вы можете определить переменную окружения MERGE_AUTOEDIT=no в начале своего скрипта и git merge будет молча делать коммиты до первого конфликта

Попробуйте 1.7.10 до релиза и адаптируйте свои скрипты и привычки :)
Если у вас есть пожелания касательно:
— документации
— ошибок, рекомендаций и прочих сообщений
— логики определения интерактивного запуска
мы всегда рады вас выслушать в списке рассылки git@vger.kernel.org

Сам факт запуска редактора при интерактивном слиянии — не обсуждается. Как сказал Линус — the default matters — и то как вел себя merge раньше было действительно плохим «умолчанием»

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