На сервере TFS, использующем git, как эффективно объединить изменения между филиалами?

Question

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

У нас есть сервер TFS, который использует git в качестве основного источника контроля.У нас есть ветка разработки, в которую люди проверяют код для текущей итерации.Затем, когда мы собираемся выпустить релиз, мы начинаем разработку.С этого момента, когда люди проверяют ветку релиза, они выбирают ее для ветки разработки ... иногда в любом случае.

Проблема в том, что когда я делаю окончательное слияние сотпустите для разработки, он по-прежнему показывает все изменения, которые уже были выбраны, потому что, очевидно, TFS слишком тупой, чтобы на самом деле смотреть на различия между ветками git.Вместо этого он просто показывает историю изменений на основе каждого рабочего элемента.Даже если ветви в git идентичны, потому что каждое изменение уже выбрано, оно все равно показывает их как новые изменения в TFS.

Это означает, что для каждого выпуска мне нужно выполнить слияние git локально, чтобыпосмотрите, есть ли какие-либо различия (всегда есть, потому что кто-то всегда забывает что-то выбрать).Затем я должен пройти их все и убедиться, что они в порядке, прежде чем делать запрос на извлечение в TFS, что является огромной болью.Кроме того, я также должен отключить политику ветвления принудительного слияния.В противном случае он объединяет все воедино, и история изменений по-прежнему не объединяется.Это становится еще более сложным, если существует более одной ветки релиза одновременно.

Есть ли лучший процесс, в котором TFS распознает, что изменения из вишневого пика в основном совпадают с изменениями из оригиналапроверить и обновить историю таким образом?

Или что-то совершенно другое.Я открыт для предложений.

Answer 1

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

Короче говоря, способ избежать этого - не выбирать вишню, а объединять - тогда один и тот же идентификатор фиксации находится в обеих ветвях, и git распознает внесенные изменения.

---

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

Итак, ваша команда будет:

1. Сделать коммит в release
2. Переместить изменение обратно, чтобы развить с помощью git merge
3. Повторите

Поскольку идентификатор фиксации между ветвями будет одинаковым, каждая операция слияния будет применять только те изменения, которые еще не были применены к develop. Таким образом, даже если что-то было изменено в develop, вы получите конфликт только в том случае, если оно также было недавно изменено в release.

---

Поскольку вы упоминаете, что людям неудобно (потенциально) объединять коммиты других людей при синхронизации выпуска для разработки, следующий процесс позволит избежать этой проблемы:

1. Обрабатывать release как master и develop - т.е. прямые коммиты не допускаются
2. Когда разработчику нужно начать работу, сделайте ветку «Feature» из release
3. После завершения разработки (и просмотра, если применимо), объедините изменение из «функции» в release
4. Затем сделайте второе слияние с «фичей» в develop

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

ПРИМЕЧАНИЕ: это приводит ко многим дополнительным коммитам слияния, и они появятся при слиянии release в develop. Однако поскольку коммиты слияния из release должны быть пустыми изменениями, я ожидаю, что конфликты почти не будут существовать. Кроме того, история Git станет очень запутанным. Лично я не считаю, что проблема и процесс ребазирования, которые вам нужно использовать, чтобы избежать ее, имеют свою собственную кривую обучения.