Да и да.
Вы можете объединяться любым способом в git. Слияние просто означает «объединить эти истории». Когда git не может, его режим по умолчанию просто сбрасывает изменения на вас, «конфликт слияния», но вы также можете изменить это поведение, чтобы склониться к «нашим» или «их». Взгляните на git-merge документы для полного объяснения сотен вариантов ...
Итак, из вашего объяснения, диаграмма историй может выглядеть так:
*-------*-------*------* master
|
*----*-----* A
|
*-------* B
|
*----* C
Где * - это просто некоторый коммит в этой ветви, за исключением точки, в которой они все созданы. Итак, как вы решаете эту проблему? Ну, я бы:
git checkout A
Находясь на А, в основном мы собираемся объединить А в мастеринг следующим образом:
git merge master
есть веская причина для этого - когда представляем другому разработчику, предполагая, что слияние является точным, это представляет собой прямое слияние для быстрой перемотки вперед. Другими словами, объединить А с фактическим мастером в чужом хранилище становится проще. Теперь следующий шаг, который вы или другой разработчик могли бы сделать:
git checkout master && git merge A
Это тянет за собой А. В принципе, вообще не должно быть конфликтов слияния, поскольку процесс слияния мастера с А разрешил их, и разработчик, ответственный за интеграцию А, обработал его.
Итак,
git checkout B && git merge master
снова, разрешите проблемы слияния, затем git checkout master && git merge B
Наконец, вы говорите, можно ли слить master в C? Абсолютно. Мы только что проделали этот процесс дважды.
Мы используем этот особый способ ведения дел на работе. По сути, я заставляю других разработчиков сообщать мне, когда их ветки готовы, затем я объединяю их, затем все сливают мастера в свои ветви, и процесс повторяется. Вы даже можете сделать это с удаленными хранилищами. Если у вас есть отслеживание веток на пульте, git pull внесет ваши изменения. На самом деле это git fetch, за которым следует git merge, поэтому, если вы не отслеживаете чью-либо ветку, вы все равно можете применить объединение следующим образом:
Они могут сделать git merge leaddeveloper/master, где leaddeveloper - удаленное имя. Затем они могут исправить любые конфликты, отправив электронное письмо ведущему разработчику с просьбой «потяните», и ведущий разработчик может набрать git fetch && git merge juniordeveloper1/somebranch или, более вероятно, git fetch && git diff master..juniordeveloper1/somebranch, чтобы выяснить, что они сделали в первую очередь.
Короче говоря, это действительно хороший способ управления проектом. Он держит всех в курсе событий и гарантирует, что парень, работающий с главным мастером, также не выполняет интеграцию кода.
Что касается git rebase, этот вопрос решает его очень аккуратно.