Чи порушує запит на витягування алгоритм злиття git?

Зараз я працюю в компанії, яка використовує VSTS для управління git-кодом. "Рекомендований" спосіб об'єднання гілки Майкрософт - це зробити "злиття сквош", це означає, що всі зобов'язання для цієї гілки стискаються в один новий документ, який включає всі зміни.

Проблема полягає в тому, що, якщо я вношу деякі зміни в одній гілці для одного елемента відставання, то негайно хочу розпочати зміни в іншій гілці для іншого елемента відставання, і ці зміни залежать від набору змін першої гілки?

Я можу створити гілку для цього елемента відставання та базувати її на першій гілці. Все йде нормально. Однак, коли настає час створити запит на тягу для мене другої гілки, перша гілка вже була об'єднана в головний і тому, що це було зроблено як злиття сквош, git розгортає купу конфліктів. Це тому, що git не бачить оригінальних комісій, на яких була заснована друга гілка, вона просто бачить одну велику сквош-злиття, і тому для того, щоб злити другу гілку в майстер, вона намагається відтворити всі зобов'язання першої гілки верх сквош зливається, викликаючи безліч конфліктів.

Отже, моє питання полягає в тому, чи є спосіб обійти це (окрім того, що ніколи не засновувати одну гілку функції на іншій, що обмежує мій робочий процес) або злиття сквош просто порушує алгоритм злиття git?

З Git, чинить

• незмінні,
• і формують спрямований ациклічний графік.

Кабачки не поєднують комітів. Натомість він записує нове зобов’язання зі змінами з кількох інших комітетів. Випуск схожий, але не поєднує коміти. Запис нового комітету з тими ж змінами, що і існуючий комітет, називається переписуванням історії . Але оскільки існуючі комісії незмінні, це слід розуміти як "написання альтернативної історії".

Об’єднання намагається поєднати зміни двох історій (гілок) комірок, починаючи від спільного вчинку предків.

Тож давайте розглянемо вашу історію:

                                 F  feature2
                                /
               1---2---3---4---5    feature1 (old)
              /
-o---o---o---A---o---o---S          master

A - це загальний пращур, 1-5 - початкова гілка функції, F - нова гілка функції та S - стискається комірка, яка містить ті самі зміни, що й 1–5. Як бачимо, загальним предком F і S є А. Що стосується git, то між S та 1-5 немає зв’язку. Тож злиття майстра з S на одній стороні та функція2 з 1–5 з іншого буде суперечити. Вирішити ці конфлікти не складно, але це зайва, копітка робота.

Через ці обмеження існує два підходи для боротьби зі злиттям / розчавленням:

• Або ви використовуєте переписування історії, і в цьому випадку ви отримаєте декілька комітетів, які представляють однакові зміни. Потім ви будете перезавантажувати другу гілку функції на стиснуту комітку:

                                   F  feature2 (old)
                                  /
                 1---2---3---4---5    feature1 (old)
                /
  -o---o---o---A---o---o---S          master
                            \
                             F'       feature2
  

• Або ви не використовуєте переписування історії, і в цьому випадку ви можете отримати додаткові об'єднання:

                                   F  feature2
                                  /
                 1---2---3---4---5    feature1 (old)
                /                 \
  -o---o---o---A---o---o-----------M  master
  

  Коли об'єднати element2 та master, спільним предком буде 5.

В обох випадках ви докладете певних зусиль для об'єднання. Ці зусилля не сильно залежать від обраної із двох вищеописаних стратегій. Але переконайтесь у цьому

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

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

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

Ось чому наше неписане правило тут - це добре гасити, доки ніхто більше ніколи не залежав від вашої гілки, але це може бути 90% часу. Інакше пряме злиття допомагає всім уникати проблем.