Предотвратить мастер ветвь от опережения

Question

мы получили довольно стандартный рабочий процесс git, но меня раздражает одна вещь: мастер опережает разработку, потому что при каждом развертывании мы создаем коммит-слияние от dev до master.

Сначала наш рабочий процесс:

• master branch - всегда чистый и доступный для развертывания
• development branch - Собирает новые функции / исправления ошибок, если они рассмотрены и утверждены
• feature branch - новая ветвь, в которой необходимы только изменения для одной функции ( она разветвлена ​​development branch)

Каждый успешный запрос на извлечение (функция> разработка) создает merge-commit , это нормально.

Но каждое развертывание (разработка> master) также создает merge-commit , который существует только в master.Так что же происходит, что после 20 развертываний главная ветвь на 20 коммитов опережает ветку разработки.

Как вы справляетесь с таким поведением?Вы время от времени сливаете master> dev (который на самом деле ничего не делает, кроме создания бесполезного merge-commit)?

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

Answer 1

То, что вы просите, называется слиянием «ускоренной перемотки вперед». Поскольку вы упоминаете pull-запросы, я предполагаю, что вы используете что-то для управления своими ветками для вас (GitHub, BitBucket и т. Д.), Поэтому точные инструкции для выполнения того, что вы хотите, могут отличаться.

---

Учитывая это состояние:

master o-o-o-o
              \
development    o-o-o

Вероятно, ваше программное обеспечение применяет флаг --no-ff при объединении (это стандартное поведение, потому что вы хотите зафиксировать объединение при объединении функции в development). Из командной строки это эквивалентно:

git merge --no-ff development

master o-o-o-o-------o
              \     /
development    o-o-o

Однако, если вы хотите избежать коммита слияния, вы действительно хотите перемотать ветку вперед:

git merge --ff development (--ff должен быть ненужным, потому что это поведение по умолчанию)

master/development o-o-o-o-o-o-o

---

Примечания:

1. Если вы сделаете это, вы потеряете способность видеть, когда development был объединен с master. Это может не беспокоить (или вы, возможно, решаете эту проблему по-другому, например, с помощью тегов).
2. Если у вас есть уникальные коммиты на master и быстрая перемотка вперед невозможна, это все равно создаст коммит-слияние. Однако вы можете использовать флаг --ff-only, чтобы выдать ошибку, если быстрая перемотка вперед невозможна (либо уникальные коммиты в master, либо уже обновленные).

Answer 2

У нас есть 3 базовых филиала: разработка, постановка и мастер.Какую бы новую функцию мы не создавали, мы сохраняем ее в функции / ветви и вносим изменения в разработку.Поскольку эта функция нуждается в тестировании, она будет снова загружена в промежуточную ветку.Получив подтверждение от тестера, мы отправляем его в мастер ветку.По сравнению с вашим рабочим процессом у нас меньше фиксаций в основной ветке, но опять-таки конфликт слияния все равно будет существовать, если вы внесли какие-либо изменения в уже существующий код.

Answer 3

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

Почему тебя это раздражает? Если вы придерживаетесь потока, у вас будут эти коммиты, но зачем их вообще волновать? Они никак не влияют на рабочий процесс.

Answer 4

Вот как мы это делаем: ветвь release ветвь от development, когда вы думаете, что ваши функции готовы («отбрасывание кода»).Запустите дорогостоящие тесты и исправьте ошибки, затем объедините release в master и объедините master в development.Снова запустите новую ветку release.

Вы можете объединить master обратно в development и после каждого развертывания, но без каких-либо реальных изменений в ветке release, что не так уж и многочувство.