Может ли слияние мастера с разработчиком в GitFlow когда-нибудь вызвать конфликт?

Question

Мне интересно, не вызовет ли когда-нибудь использование gitflow и слияние master с development. Я намерен превратить этого "мастера git merge" в команду разработки в автоматический неинтерактивный процесс, поэтому в случае конфликта он завершится неудачей, так как потребует взаимодействия с человеком.

Я использую GitFlow, и изменения, которые применяются непосредственно к мастеру, представляют собой версию, которая изменяет версию, фиксирует, а затем изменяет версию на версию моментального снимка. Например, мастер может иметь версию 1.0.1-SNAPSHOT. Если мы вернем версию, версия изменится на 1.0.2, а затем мы сделаем коммит git. Затем мы меняем версию на 1.0.2-SNAPSHOT и затем фиксируем это. Таким образом, каждый удар по версии вызывает два коммита (см. Обновление версии mvn).

Периодически я хочу объединить последнюю версию из master в development, вызвав git merge. Это займет изменение версии, но также и любые другие изменения, найденные в master, а не в development. Я считаю, что это не должно вызывать никаких конфликтов, так как все, что есть у мастера, должно происходить и в развитии, потому что мы объединяем развитие в мастера.

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

Есть ли способ здесь конфликтовать? Будет ли какая-либо проблема, пытаясь автоматизировать процесс слияния мастер-в-разработке? Благодарю.

Answer 1

TL;DR Да!

Я вижу здесь несколько вопросов / проблем, о которых нам нужно поговорить:

(1) В git-flow создан и задокументирован nvie, нет слияния из master в develop а скорее слияние из (давайте просто воспользуемся версией 1.0.2 в этом примере) release/1.0.2 разветвляться в master и develop.

(2) Это release/1.0.2ветка предназначена для того, чтобы быть местом, где вы можете изменить свою версию. Затем он автоматически появится на develop с тех пор как вы сливаетесь release/1.0.2 в developв любом случае после каждого релиза. Нет необходимости периодически обновлять с master тогда.

(3) masterветка содержит только коммиты слияния, больше ничего. Это просто упорядоченный список всех выпусков.

(4) Вы можете столкнуться с конфликтами слияния в обоих случаях, поскольку develop постоянно работает (при условии, что вы не один работаете над всем проектом), пока вы работаете над release/1.0.2. Если в одни и те же строки вносятся изменения, могут возникнуть (но не обязательно) конфликты слияния.