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

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

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

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

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

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

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

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

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

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

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

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

Все зависит от того, как вы собираетесь использовать GIT для управления своим кодом, планом выпуска и версией. Лучше всего иметь ветвь master для хранения кода производственного уровня, ветвь develop для разработки, ветвь release, ответвляющуюся от develop, для обработки будущих выпусков, и ветвь hotfix, ответвляющуюся от master, для обработки срочных исправлений производственного кода. Таким образом, ветки release и hotfix, наконец, будут объединены обратно в ОБЕИХ master и develop, чтобы убедиться, что обе ветки внесли изменения, а позже, когда develop разветвится на новую release, этот новый выпуск без проблем объединится в master. И пометка всегда будет на master.

При таком подходе ветки release и hotfix будут объединены дважды, и иногда возникает конфликт при слиянии с develop, что неизбежно, если в develop идет много активностей по разработке. Сократите жизненный цикл ветки release или hotfix, чтобы смягчить эту проблему. Если возникает конфликт, решите его любыми методами и убедитесь, что не изменяете завершенный и протестированный код release или hotfix.