Как обрабатывать зависимости при использовании рабочего процесса ветки git theme?

Question

В нашем проекте мы стараемся держаться поближе к «официальному» рабочему процессу git, как это предлагается здесь: http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html

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

Теперь иногда случается, что на topic-X происходит какая-то разработка.Разработчик создает somefile.c и добавляет туда код, который ему нужен для его темы.Через некоторое время другой разработчик работает над topic-Y и узнает, что ему также необходимо создать somefile.c и даже потребуется некоторые части этого файла из topic-X - но не полный файл, поскольку он также содержит код, которыйотносится только к topic-X.Возможно, ему также придется добавить другой код в этот файл.

Если бы topic-X был бы завершен и объединен в master, это было бы легко: мы могли бы изменить topic-Y на master, чтобы сделать этокод доступен.Но что, если обе темы все еще не завершены?

Поскольку topic-X и topic-Y действительно не связаны, за исключением этого второстепенного общего кода в somefile.c, как мы можем избежать объединения их друг с другом ивсе же предоставим обоим разработчикам общие части из somefile.c?

Если мы создадим свежую копию somefile.c в topic-Y только с соответствующими частями, мы обнаружили, что позже мы получим конфликты слияния, когда мысделать интеграцию теста в next.Есть ли альтернатива?

Answer 1

Лучше всего консолидировать общую базу для X и Y в ветви, и основывать как topic-x, так и topic-y на этой ветви. Тогда оптимально обе ветви больше не будут касаться somefile.c, а скажут только somefile-x.c и somefile-y.c.

В качестве альтернативы вам может помочь более продвинутый инструмент, такой как topgit (или нет: -))

Answer 2

При слиянии git обнаружит, были ли уже применены изменения в коммите.

Поэтому, когда у вас есть коммит в topic-x, который меняет somefile.c, что вы также хотите в topic-y,Вы можете выбрать этот коммит в topic-y.(Облегчите себе и оставьте этот коммит ограниченным только теми вещами, которыми вы хотите поделиться.)

git checkout topic-y
git cherry-pick topic-x

Позже, когда вы объедините topic-x и topic-y, git увидит, что патч ужебыл применен и изящно пропущен.

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