"Эта ветвь-1 commit ahead, 1 commit behind master" в Github при использовании " успешной модели ветвления Git"
Я работаю в чистом РЕПО только с одним файлом. Я единственный разработчик.
Я хочу сделать рабочий процесс разработки-выпуска-master в успешная модель ветвления git так я и сделал:
Примечание: пожалуйста, имейте в виду, что у меня есть быстрая перемотка вперед по умолчанию, поэтому рассмотрите все merge
команды merge --no-ff
.
мое происхождение-Github.
на мастер отрасли:
git add .
git commit -m "Initial commit"
git push origin master
git checkout -b develop
In разработки филиала. Я делаю изменение в файле, затем:
git add .
git commit -m "work in the file"
Я готов выпустить это как версию 0.0
git checkout -b release-0.0 develop
на релиз-0.0 филиала. Я добавляю номер версии в файл.
git add .
git commit -m "Bumped version 0.0"
Я готов объединить этот выпуск в master.
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 фиксация за мастером.
на мастер у филиала нет такого сообщения.
что я могу сделать, чтобы это исправить? Оба!--20-->мастер и разработки должны быть равны в этот момент, так как они были объединены с релиз-0.0.
3 ответов
нет, это не будет равно, так как вы по умолчанию отключили перемотку вперед. Каждое слияние создает новую фиксацию, а фиксация слияния имеет другой идентификатор. Поэтому фиксацию в мастер не фиксацию в разработке. И, следовательно, развиваются и коммит не в мастер, а мастер фиксации не развиваются. Отсюда и послание в разработке.
Что касается сообщения, не находящегося в master, то это потому, что сообщение приходит, когда ветвь сравнивается с master. Поэтому, если вы сравните master с master, сообщение не является необходимым.
одним из решений является включение быстрой перемотки вперед и явное создание коммитов слияния в release и master, а затем быстрая перемотка вперед. Другой вариант-перебазировать develop после каждого слияния в master. Как вы хотите это сделать, это ваш личный выбор в зависимости от вашего рабочего процесса и кода.
также сообщение о том, что нет чего-то, о чем вы должны беспокоиться, пока код в ветвях точно такой же вы хотите.
просто добавить к другим ответам:
оригинал git-flow не находится в разработке с 2012 года, и он был заменен git-flow AVH edition во многих местах (в том числе репозитории Ubuntu и Git для Windows).
одно из различий, введенных изданием AVH, заключается в том, что окончательное слияние-это мастер* в разработки а не релиз на разработки.
Это делает мастер прямой родитель разработки и должен исключить одну часть сообщения, которое вы видите; должно остаться только "1 commit ahead". Это также немного облегчает проверку того, что master и developm не разошлись случайно.
* точнее, это новый тег (на master), который объединяется в develop.
потому что вы используете --no-ff
каждый простой будет другой фиксацией. При слиянии relese-0.0
в develop и в master коммиты слияния будут разными. Вот как это выглядит:
Как вы можете видеть, ветвь разработки имеет одну фиксацию (слияние выпуска 0.0 в develop), которая не находится в (недоступна) master и master ветвь имеет одну фиксацию (освобождение v0.0) который не находится в ветви разработки. И вот что gihub говорит с этим сообщением, и это совершенно нормально (содержимое то же самое, но коммиты разные).
Если вы хотите использовать git flow, вы должны взглянуть наhttps://github.com/nvie/gitflow, который поможет вам много.