Мой коллега и я ведем активную дискуссию о стратегиях слияния, и я надеюсь, что мы сможем получить некоторую информацию, чтобы помочь решить ее.
Tl: dr: Должны ли мы использовать слияние или ребазирование при вытягиванииизменения из удаленной ветви, так что мы не постоянно переделываем разрешение конфликта.
- svn: наш главный золотой репозиторий
- trunk: git: отслеживание удаленной ветви svn.Используется для создания git-изменения перед передачей в subversion.
- feature-branch: git remote branch, где объединяется работа 2+ коллег по одной функции
- colleague1: локальная ветвь первого коллеги
- colleague2: местное отделение второго коллеги.
Мы используем отличный рабочий процесс Себастьяна Варетта из Опасно ли использование git-svn dcommit после слияния с git? .
Проблема, с которой мы сталкиваемся, состоит в том, что каждый раз, когда colleague1 переходит из svn (переходит в транк, а затем переходит в коллегу 1, прежде чем нажать на feature-ветвь, когда это сделано), затем фиксирует ветвь Feature, конфликт которой друг с другом должен быть повторен.-сделанный.Одно и то же разрешение конфликтов нужно делать снова и снова - каждый раз, когда выполняется рабочий процесс svn rebase.
Обратите внимание, что мы используем git rebase mirror un-3451 для этой перебазировки.
Мой аргумент заключается в том, чтомы должны использовать git merge mirror un-3451.Насколько я понимаю, это даст коммит, который помечен как слияние двух предыдущих коммитов.Поэтому git будет знать, что не следует использовать предыдущие коммиты, а вместо этого использовать коммит слияния.
Мой коллега, с другой стороны, утверждает, что использование слияния значительно усложнит возможное слияние с svn и намного предпочтет использовать rebase,Ему это легко - к сожалению, он не тот, кто разрешает все конфликты.Он утверждает, что использование коммита сквоша даст тот же эффект.
Мой аргумент заключается в том, что слияние имеет тот же эффект, что и сквош, но включает в себя маркировку коммитов, которые были включены.
Состояние 1
svn-trunk: A
\
git-trunk: A'
\
remote-feature: A'-----C
\ /
c1-feature: A'--C
\
c2-feature: A'--D
Состояние 2
C конфликтует с D в файле 1 (F1).F1 разрешил конфликт, поэтому D становится D '.
git pull --rebase remote feature
git add F1
git rebase --continue
git push
График фиксации:
svn-trunk: A-----B
\ \(svn rebase)
git-trunk: A'----B'
\
remote-feature: A'-----C---------D'
\ / \ /
c1-feature: A'--C \ / (git push)
\ \ /
c2-feature: A'-------C--D'
Состояние 3
Теперь colleague1 хочет получить изменения из svn-trunk:
git checkout trunk
git svn rebase
, а затем переназначить их на функцию c2
git checkout feature-branch
git rebase trunk
Повторная установка помещает B1 в функцию c2 и затем C, а затем захватывает D 'и заставляет то же разрешение конфликта стать D' '
График коммитов:
svn-trunk: A--------B
\ \(svn rebase)
git-trunk: A'--------B'
\ \
remote-feature: A'-----C--\-----D'
\ / \--\--\ \
c1-feature: A'--C \ \ \
\ \ \ \
c2-feature: A'----------B'-C--D''
Каждый раз, когда происходит цикл git checkout trunk; git svn rebase; git checkout feature-branch; git rebase trunk; git push remote, все разрешения конфликтов необходимо выполнять снова и снова.
Вопросы
- если вы перебазируете svn, нажмите на удаленную ветвь, коллега2 передаст некоторые коммиты в удаленную ветвь, а затем, коллега1 выполнит извлечение слияния из удаленной ветки, будет ли в результате коммита слияния упомянуть коммиты svn (и, следовательно, возникнет проблемапри последующих перебазировках).
- Что лучше в приведенном выше сценарии: перебазировка или слияние?
- Будет ли полезна функция переобучения?
Большое спасибо!