Примечание: это мое мнение , здесь может быть несколько мнений, но, по крайней мере, поймите мою точку зрения здесь и решите, что вы хотите, чтобы это было иначе.
Прежде всего, есть что-тоотсутствует здесь, и я думаю, что в долгосрочной перспективе это создаст вам проблемы с рабочим процессом.
Объединение - это не то, что должно быть пропущено или делегировано другим людям, разработчики, работающие в этих ветвях, должны объединиться сами.Они и, вероятно, только они, будут знать, что они сделали и как разрешить конфликты слияния.
В любом случае, делать это полностью автоматически, это не сработает.
Вот рабочий процесс, который разработчики должны использовать (на мой взгляд.)
Периодически, например, каждое утро разработчики в ветке должны проверять сервер сборки, чтобы убедиться, что ветка по умолчанию строится.Если это так (и должно!), Они объединяют из ветви по умолчанию в свои собственные.
Это имеет три основных преимущества:
- Они всегдаиметь последний код в своей собственной ветке и не увязать в работе с известными ошибками, которые уже были исправлены в другой ветке
- Они постоянно имеют дело с конфликтами слияния из других веток, в то время как конфликты небольшие,и изменения все еще свежи в умах разработчиков, которые их сделали.
- Поскольку вы сталкиваетесь с конфликтами слияния каждый день (если они есть), когда вы подходите к концу жизни этой ветвив любом случае, он почти полностью объединен с веткой по умолчанию, поэтому работа по слиянию его с версией по умолчанию теперь должна быть дешевой, если не бесплатной.
В какой-то момент их читают, чтобы интегрировать ихвернитесь в ветку по умолчанию (либо периодически, т. е. частичные выпуски новых функций, либо, в конце концов, все сделано), а затем они все еще работаютЗатем объедините из default в свою собственную ветку.Это гарантирует, что любые затянувшиеся конфликты слияния обрабатываются этой командой в их ветви, прежде чем они передадут ее остальным разработчикам.
Когда они имеют дело с любыми конфликтами слияния из-за этого слияния, они могут слитьсядругое направление, от их ответвления до дефолта.На этом этапе, если кому-то пока не удалось объединить / перенести какие-либо конфликтующие изменения в дефолт по умолчанию, конфликтов слияния не будет вообще.
Выполнение этого способа гарантирует, что:
- Разработчики, которые выполняют слияния, обучаются слиянию
- Разработчики, которые внесли изменения, все еще имеют эти изменения свежими в памяти
- Вы амортизируете работу, связанную с конфликтами слияний, делая их часто,и делать их небольшими порциями.
- Вы не получите большую «неделю» слияния в конце проекта, когда все забыли все изменения, почему они были сделаны и кто их сделал
Если что-то из этого было неясно, пожалуйста, оставьте комментарий, и я обновлю / отредактирую соответственно.