GitFlow объединяет нежелательные аспекты мастера в разработке по окончании исправления

Question

Мы используем GitFlow с довольно стандартной настройкой, где у нас есть:

• Мастер, представляющий новейшую продукцию
• разработка, представляющая текущее развитие
• количество исправлений в списке исправлений / x, представляющих исправления в полете
• несколько функций в элементах / x, представляющих более крупные функции в полете для следующей версии.

У нас есть несколько различий между разработчиком и мастером в том, что мы хотим, чтобы мастер указывал на определенные версии зависимостей NuGet, например, при разработке указывает на другие версии этих зависимостей.

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

Мой коллега утверждает, что этот сбой, скорее всего, является побочным эффектом того, что основная ветвь формируется путем ветвления от разработки, когда мы изначально перешли на GitFlow вместо того, чтобы использовать функцию GitFlow Releases.

Есть ли у кого-нибудь опыт работы с этим типом установки или симптома или есть какие-либо предложения, чтобы попытаться решить его? Мы рассматривали попытку воссоздать мастер с помощью функции GitFlow Release или с помощью атрибутов Git, чтобы игнорировать файлы для слияния, но кажется, что может быть более разумный способ решить эту проблему.

Answer 1

Говоря коротко, gitflow неявно объединяет целые master в develop, и когда вы объединяете его таким образом, возникает проблема, связанная с тем, чтобы некоторые изменения master были удалены от develop.(Что касается вашего «Мои коллеги утверждают ...», я не полностью понял это, но не имеет значения, как были запущены ветви. Если бы они были изначально не связаны, слияние все равно было бы стремиться сделать их такими же, как объясняет другой ответ)

Единственное, что я могу предложить по этому поводу, это вернуть эту конфигурацию в develop после слияния.В следующий раз, когда в master произойдет изменение, это вызовет конфликт слияния, который вы можете разрешить вручную желаемым способом.

Answer 2

Это связано с тем, что ваша конфигурация на master была изменена где-то с момента "объединения базы" между master и develop. («База слияния», грубо говоря, самая последняя фиксация в истории как master, так и develop.) Я бы сказал, это означает, что ваш коллега находится на правильном пути. Строго не имеет значения, используете ли вы конкретный инструментарий GitFlow, но develop должен был ветвиться с master (не наоборот), и (возможно, что еще более важно) изменения не должны применяться непосредственно к master .

Если эти утверждения кажутся вам необоснованными, то то, что у вас есть, не является, как вы предлагаете, «довольно стандартной установкой» для GitFlow.

В настройках GitFlow версии зависимостей не сильно отличаются от любых изменений кода. Обычно происходит лишь несколько вещей:

Наиболее распространенная вещь должна состоять в том, что для функции требуется зависимость (или новая версия зависимости), чтобы изменение входило в конфигурацию сборки в ветви компонента. Оттуда он в конечном итоге сливается до develop, затем переносится в ветку релиза, которая объединяется в master.

Другая возможность заключается в том, что номер версии изменяется в исправлении, потому что вам нужно исправление безопасности или что-то в зависимости. Конечно, это должно быть объединено с master и develop.

Наконец, вы можете изменить зависимости в ветке релиза; но опять-таки эти изменения должны объединиться как в master, так и в develop.

Общей темой является то, что все они обычно должны сходиться к общей конфигурации. Это не по ошибке; если вы заявляете, что хотите, чтобы версии в prod оставались разными, то вы говорите, что не хотите, чтобы ваши разработчики когда-либо могли проводить точное и эффективное тестирование.

Если вы следуете gitflow, то единственная причина, по которой develop будет иметь другую версию зависимости от master, заключается в том, что изменение еще не достигло master; и в этом случае слияние исправлений не будет думать, что версия master должна переопределять версию develop, потому что база слияния будет в версии master.

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