Управление исправлениями при разработке ветки сильно отличается от мастера?
Я использую модель ветвления "Git Flow", с ветвью мастера и ветвью разработки. Я работаю над крупным новым выпуском, поэтому моя ветка разработки сильно отличается от моей основной ветки. Это создает проблему в любое время, когда мне нужно сделать исправление на главной ветке и объединить его обратно в разработку. Почти всегда есть конфликты, и это становится настоящей болью.
Каков наилучший способ управления этим? Мне было бы легче внести небольшие исправления в разработку вручную, а затем объединить все в master, когда я буду готов, не объединяя мастера в разработку. Возможно ли это?
Ответы
Ответ 1
Самый простой способ получить некоторые коммиты от одной ветки к другой - вишневый выбор.
Предполагая, что ваше исправление в master имеет хеш фиксации HASH, и вы хотите принять это исправление в ветвь devel, выполните git checkout devel, а затем git cherry-pick HASH. Что это.
Если вы хотите сделать все изменения с master на devel, вы можете добиться этого с помощью
git checkout devel
git rebase master
Если у вас есть противоположный сценарий (вы делаете исправление во время разработки в ветке devel и хотите принять это исправление в master до того, как devel полностью интегрируется в master), рабочий процесс очень похож, Предполагая, что исправление имеет хэш HOTFIX_HASH, выполните следующее:
git checkout master
git cherry-pick HOTFIX_HASH
Теперь коммит присутствует в master и devel. Чтобы обойти это, введите
git checkout devel
git rebase master
и фиксация исчезнет с devel, поскольку она уже присутствует в master.
Ответ 2
Моим общим рабочим процессом для этой ситуации является создание ветки bug-fix master, которая устраняет проблему. Как только он будет готов, объедините его обратно в master, затем слейте master в develop.
Это предполагает, что исправление ошибки почти взаимно однозначно между кодом, который необходимо изменить в обеих ветвях. Если это так, вы всегда можете попробовать git merge -s ours master (см. man-страница) в develop, поэтому ветвь develop имеет приоритет.
Я использую аналогичный процесс для управления выпуском исправления ошибок в проекте с открытым исходным кодом, над которым я работаю. master всегда впереди, где нужно исправить ошибку, поэтому я создаю ветку из тега, которая нуждается в исправлении, применяет исправление и освобождение, затем переназначает и объединяет новый тег в master. Это вызывает конфликт из-за номеров версий, но его можно избежать с помощью команды выше.
Надеюсь, что это поможет.
Ответ 3
Я обычно следую этому руководству, который в большинстве случаев хорошо подходит и позволяет избежать мэра проблем с конфликтами и большой изменения.
Если вы могли бы работать с ветвями feature и объединять их в development только до создания ветки release (что означает, что вы действительно готовите выпуск)... этот метод должен избегать большинства конфликтов слияния, которые вы опыт.
Так как в ветки feature-breaking произойдут нарушения, вы можете иметь только конфликты один раз в то время, когда ветвь feature-breaking объединяется в процесс разработки. И вы могли бы также объединить development в ветвь release в любое время, чтобы обновить ее.
Вы также будете здоровы слиянием в development всех hotfix-branch es с минимальными или неконфликтными.
Руководство, которое я поделил по ссылке, делает большой упор на том, чтобы никогда не сливаться с development на master или назад. Всегда обрабатывайте свои релизы через ветвь release.
