Управление исправлениями при разработке ветки сильно отличается от master?

Question

Я использую модель ветвления "Git Flow", с основной ветвью и ветвью разработки.Я работаю над новым выпуском, поэтому моя ветка разработки сильно отличается от моей основной ветки.Это создает проблему в любое время, когда мне нужно сделать исправление в основной ветке и объединить его с разработкой.Почти всегда возникают конфликты, и это становится настоящей болью.

Каков наилучший способ справиться с этим?Мне было бы легче внести небольшие изменения в исправления при разработке вручную, а затем объединить все в мастер, когда я буду готов, без объединения мастера в разработку.Это возможно?

Answer 1

Самый простой способ получить некоторые коммиты из одной ветви в другую - это cherry-picking .

Предполагая, что ваше исправление в 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.

Answer 2

Мой общий рабочий процесс для этой ситуации - создать bug-fix ветвь master, которая устранит проблему. Когда все будет готово, объедините это обратно в master, затем объедините master в develop.

Предполагается, что исправление вашей ошибки почти один к одному между кодом, который необходимо изменить в обеих ветвях. Если это так, вы всегда можете попробовать git merge -s ours master (см. man-page ) в develop, поэтому ветвь develop имеет приоритет.

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

Надеюсь, это поможет.

Answer 3

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

Если вы могли бы работать с feature ветвями и объединять их в development только до создания release ветки (то есть вы на самом деле готовите релиз) ... этот метод должен избегать большинства конфликтов слияния, которые вы опыт.

Поскольку в ветви feature-breaking могут произойти критические изменения, вы МОЖЕТЕ иметь конфликты только один раз, когда эта ветка feature-breaking будет включена в разработку. Также вы можете в любое время слить development в ветку release, чтобы обновлять ее.

Вы также будете спокойны с объединением в development всех ваших hotfix-branch с минимальным или вообще без конфликтов.

В руководстве, которым я ранее поделился по ссылке, делается большой акцент на том, чтобы никогда не сливаться с development до master или наоборот. Всегда обрабатывайте ваши релизы через release ветку.