"Эта ветка - 1 фиксация вперед, 1 фиксация за мастером" в Github при использовании "Успешная Git ветвящаяся модель"

Я работаю в чистом репо только с одним файлом. Я единственный разработчик.

Я хочу сделать рабочий процесс разработки-release-мастера в успешной модели ветвления git, поэтому я сделал:

Примечание. Пожалуйста, имейте в виду, что у меня есть перемотка вперед по умолчанию, поэтому рассмотрите все команды merge как merge --no-ff.

Мое происхождение - Github.

В ветке мастер:

git add .
git commit -m "Initial commit"
git push origin master
git checkout -b develop

В ветке Развить. Я делаю изменения в файле, а затем:

git add .
git commit -m "work in the file"

Я готов выпустить это как версию 0.0

git checkout -b release-0.0 develop

В ветке release-0.0. Я добавляю номер версии в файл.

git add .    
git commit -m "Bumped version 0.0"

Я готов объединить этот выпуск в мастер.

git checkout master
git merge release-0.0 -m "Releasing v0.0"
git tag -a 0.0 -m "Version 0.0"

... и развиваться.

git checkout develop
git merge release-0.0 -m "Merge release 0.0 into develop"

Затем я нажимаю на мастер и развить в Github

git push origin master
git push origin develop

Когда я проверяю ветку развить в Github, он говорит:

Эта ветвь - 1 фиксация вперед, 1 фиксация за мастером.

В ветке master нет такого сообщения.

Что я могу сделать, чтобы исправить это? И Мастер и Развить должны быть равны на этом этапе, поскольку они были объединены как с release-0.0.

Ответ 1

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

Что касается сообщения, которое не присутствует в главном, это потому, что сообщение приходит, когда ветвь сравнивается с мастером. Поэтому, если вы сравниваете master с master, сообщение не требуется.

Одно из решений заключается в том, чтобы включить ускоренную перемотку вперед и явно создать комманды слияния в release и master, а затем продолжить ускоренную пересылку. Другой вариант заключается в том, чтобы rebase развиваться после каждого слияния для освоения. Как вы хотите заниматься этим, это ваш личный выбор в зависимости от вашего рабочего процесса и кода.

Также сообщение о том, что вы не должны беспокоиться о том, что код в ветвях точно так же, как вы хотите.

Ответ 2

Просто чтобы добавить к другим ответам:

Оригинальный git-flow не разрабатывался с 2012 года, и во многих местах его заменил выпуск AVH git-flow (включая репозитории Ubuntu и Git для Windows).

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

Это делает master прямым родителем развития и должно исключить одну часть сообщения, которое вы видите; должен остаться только "1 коммит вперед". Это также немного облегчает проверку того, что мастер и разработка не разошлись случайно.

* Точнее, это новый тег (на мастере), который объединяется с разработчиком.

Ответ 3

Поскольку вы используете --no-ff каждое слияние будет другим коммитом. Когда вы объединяете release-0.0 с development и master, коммит слияния будет другим. Вот как это выглядит:

Как вы можете видеть, ветвь разработки имеет один коммит (объединить выпуск 0.0 с разработчиком), которого нет в (недоступном для) главном и ветвь мастера имеет один коммит (Releasing v0.0), которого нет в ветке разработки. И это то, что GitHub говорит с этим сообщением, и это совершенно нормально (содержимое одно и то же, но коммиты разные).

Если вы хотите использовать Git Flow, вы должны взглянуть на https://github.com/nvie/gitflow, который вам очень поможет.