Представьте на секунду, что одна постоянная ветвь «новее», чем другая, как ветвь с новыми функциями F против ветвь с исправлением ошибок B . (Если одна из ваших ветвей имеет больше уникального кода, чем другая, для этого назовите его F , чтобы минимизировать необходимость объединения в обоих направлениях.) Затем, если изменение применяется к обоим , это по определению будет исправлением ошибки, поэтому вы примените его к B и позже объедините B в F , разрешив любые конфликты, возникшие из-за новые функции изменили соответствующий код.
Эта модель также работает и здесь (особенно если почти все новые изменения применяются к обеим версиям и могут быть внесены сначала в B ), но есть проблема: в первый раз, когда вы объединитесь, вы попытаетесь внести все нежелательные различия между F и B в F . Поэтому сделайте сначала подделку : объедините B в F , но на самом деле не измените F . Тогда только new работают над B ( т.е. , те самые «новые функции», о которых вы спрашивали) имеют право на объединение, что вам и нужно.
Поддельное слияние может быть создано следующим образом (с использованием только кроссплатформенных функций оболочки):
# create cmt with a message for the fake merge
git commit-tree F: -p F -p B <cmt
# use the hash it prints below
git checkout F
git merge $HASH
Слияние будет ускоренным, поскольку commit-tree основывалось на F .