Мы нашли «проблему» ... Теперь история, прокрутите вниз для решения (вроде).
Итак, мы хотели иметь удобство линейной истории на master с сохранением истории коммитов на develop.
Это заставляет develop продвигать WRT master до бесконечности, так что master "никогда" догоняет develop (в смысле фиксации история). При открытии PR с develop вы получаете этот огромный список коммитов (опять же, количество измененных файлов правильное, поэтому никаких реальных проблем там нет). Это неудобство GUI.
Полученный график выглядит примерно так (в тестовом хранилище)
Зеленый строка, выходящая из master, является исправлением, которое объединяется обратно в develop до создания нового PR. Другие строки, вытекающие из develop, являются особенностями.
Рабочий процесс для заинтересованных сторон выглядит следующим образом:
Особенность:
$ git checkout -b new-feature develop
... work, commit, work, commit
$ git rebase develop
$ git checkout develop
$ git merge --no-ff new feature
$ git push develop
$ git branch -d new-feature
Выпуск (из кончика разработки или последний коммит, готовый к выпуску)
$ git checkout -b release/x.y.z (develop|045c89)
... work, commit, work, commit
$ git tag -a x.y.z -m "new release x.y.z"
$ git checkout develop
$ git merge release/x.y.z
$ git push --follow-tags develop
$ git branch -d release/x.y.z
, затем мы открываем PR на github из develop и получаем sh в master. Я думаю, что это может быть также release.
Возвращаясь к нашему локальному каталогу, мы извлекаем / извлекаем из источника и объединяем master в develop. Этот шаг необходим, иначе мы получим «неспособность автоматически слиться» в следующем PR.
Исправления такие же, как релизы, но происходят от мастера.
Конечно, есть возможность sh непосредственно к master после исправления / исправления, выполнив:
$ git checkout master
$ git merge --squash x.y.z
... commit with something like "version x.y.z"
$ git push
Чтобы защита ветвей для линейной истории на github не жаловалась.
Вот скриншот PR на GitHub ... Только 4 файла были фактически изменены. Фактические коммиты для этих изменений - последние 3 в огромном списке. Все остальные являются предыдущими: (
РЕШЕНИЕ (вроде):
после объединения PR, локально выполните:
$ git checkout master
$ git pull
$ git checkout -B develop
$ git push --force origin HEAD
Это сбросит develop, так что и master, и develop будут четными. Мы теряем историю на develop, но у нас нет огромного списка 'коммитов'. Это заставляет меня задуматься, зачем нам нужен develop, во-первых, мы могли бы перейти на рабочий процесс 'trunk' или на поток github.