Чи краще використовувати злиття чи переробку, коли два люди знаходяться в одній і тій самій гілці віддаленої функції та мають конфлікти, які будуть пов'язані з svn-gіt, gіt-svn, git-rebase, git-merge

Ми з колегою енергійно обговорюємо стратегії злиття, і я сподіваюся, що ми зможемо отримати якусь інформацію, яка допоможе її вирішити.

Tl: dr is: Чи слід нам використовувати злиття або перебазування під час витягування змін із віддаленої гілки, щоб ми не постійно повторювали вирішення конфліктів.

• svn: наш головний золотий сховище
• trunk: відстеження віддаленого відділення git svn. Використовується для індексування зміни git перед dcommitting до диверсії.
• feature-branch: віддалена гілка git, де поєднується робота 2+ колег над однією функцією
• колега1: Місцеве відділення першого колеги
• colle2: Місцеве відділення другого колеги.

Ми використовуємо чудовий робочий процес Себастьяна Варетта від Чи є git-svn dcommit після злиття в git небезпечним?.

Проблема, яку ми отримуємо, полягає в тому, що кожного разуколега1 перебазує з svn (шляхом перебазування до магістралі, а потім перебазування до колеги1 перед натисканням на функцію-гілка, коли закінчено), а потім фіксує функцію-гілка, конфлікт один з одним повинен бути повторно зроблений. Те саме вирішення конфліктів потрібно робити раз за разом - кожного разу, коли виконується робочий процес 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

Тепер колега1 хоче внести зміни зі 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 цикл трапляється, всі способи вирішення конфліктів повинні виконуватися знову і знову.

Питання

1. якщо ви перебазуєте зі svn, натисніть на пультгілка, попросіть колега2 надсилати деякі фіксації до віддаленої гілки, а згодом колега1 виконує злиття з віддаленої гілки, щоб отриманий коміт злиття згадував коміти svn (і, отже, спричиняв проблему при наступних перебазуваннях).
2. Що краще у сценарії вище: перебазувати чи об’єднати?
3. Чи буде функція повторного використання більше корисна?

Дуже дякую!

Відповіді:

0 для відповіді № 1

По-перше, я опущу однакові вузли та реорганізую вузли так, щоб кожна гілка мала головку як самий правий вузол, щоб краще представляти дерево. (виправте мене, якщо дерево помиляється). Мої коментарі жирним шрифтом.

Держава 1

svn-trunk:     A

git-trunk:       A"

c1/remote-feature: ----C



c2-feature:            --D

Потім D було перебазовано як D "на C. Це легка частина (зрозуміти). Це могло б бути вишневим (або" звичайним "D), якби не було конфлікту.

Держава 2

C конфліктує з D у файлі 1 (F1). F1 вирішив конфлікт, тому D стає D ".

svn-trunk:     A-----B
     (svn rebase)
git-trunk:       A"----B"


c1-feature:         C

c2/remote feature:    D"

Тепер ми переходимо до складної частини.

Держава 3

Тепер колега1 хоче внести зміни зі svn-trunk:

git checkout trunk
git svn rebase

а потім перебазувати їх на c2-функцію

git checkout feature-branch
git rebase trunk

Перебаза ставить B1 на функцію c2, а потім C, а потім захоплює D "і змушує те саме вирішення конфлікту стати D" "

Графік коміту:

svn-trunk:     A

git-trunk:       A"----B"
     
     
c1-feature:         C     
     
remote feature:       D"    

c2-feature:                   C----D""

Мені складно зрозумітиперехід із стану 2 у стан 3, оскільки ваші коментарі, здається, не збігаються із станом графіка (що виглядає скоріше як спроба перебазувати c2 / віддалену функцію на стовбур (у B "), а c2-функцію як Результат. Я вважаю, що ви насправді хотіли ось що:

Бажаний стан 3

svn-trunk:     A-----B
     (svn rebase)
git-trunk:       A"----B"


c1-feature:               C

c2/remote feature:          D"

це означає, що ви не змогли перебазувати A "-C-D"на "-B" без подальшої необхідності вирішення конфліктів щодо D ", що дивно, оскільки цього не повинно статися (я намагався відтворити це на репозиторії git-svn, і це працює за призначенням). Строго кажучи, це не" t навіть проблема git-svn, оскільки ви просто перебазуєте одну гілку git проти іншої. Насправді схоже, що ви робите спробу перебазувати належним чином, тому я можу лише припустити, що якась інформація відсутня, тобто те, що я описав, не означає, що це насправді сталося.

---

0 для відповіді № 2

Я колега2.

Моя позиція полягає в тому, що це часті перебазуванняSVN до нашої спеціальної гілки, яка заподіює біль. Кожного разу, коли ми перебазуємо, набір змін відтворюється поверх змін SVN. Фактичні конфлікти містяться в нашому відтвореному наборі змін.

В ідеалі ми "розкладемо наш набір змін на єдиний коміт, щоб конфлікти, що виникли в наборі змін, були вирішені, і не повинні були вирішуватися знову після чергового перебазування.

Крім того, ми могли б почекати перебазування з SVN, поки гілка об’єктів не буде завершена і готова до фіксації.

Я не впевнений, що перехід від перебазуванняколи ми перейдемо до об’єднання, це взагалі покращить наш процес. Проблемою є часті перебазування даних з SVN, і я не вірю, що злиття між гілкою функцій та нашими локальними гілками покращить базу даних SVN.

---