Git: виправлення помилки, що впливає на дві гілки


16

Я базую свою репортажу Git на успішній моделі розгалуження Git і цікавився, що станеться, якщо у вас така ситуація:

введіть тут опис зображення

Скажімо, я розвиваюсь на двох функціональних гілках A і B, а B вимагає код від A. Вузол X вводить помилку в особливості A, яка впливає на гілку B, але це не виявлено у вузлі Y, де об’єднання A і B були об'єднані, і тестування проводилося перед тим, як знову розгалужуватися та працювати над наступною ітерацією.

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

Чи слід створити гілку виправлення з останньої функції вузла A (той, що розгалужується від вузла Y), а потім об'єднати з функцією A? Після чого обидві ознаки об’єднуються в розробку знову і тестуються перед розгалуженням?

Проблема в цьому полягає в тому, що для вирішення проблеми потрібно об'єднати обидві гілки. Оскільки функція B не торкається коду у функції A, чи існує спосіб змінити історію на вузлі Y, застосувавши виправлення та все ж дозволяючи гілці функції B залишатися без навантаження, але фіксований код має від функції A?

Помірно пов'язані: Зміна розгалуження помилок Git


6
Ви не можете просто виправити помилку у гілці "розвивати", а потім об'єднати її як у функцію A, так і у функцію B?
tdammers

Гм, здається, так було б найкраще. У функції A можуть виникнути конфлікти злиття, але я думаю, що це неминуче.
Арам Кочарян

Якщо ви ще не зробили подальшої розробки для гілки "development", а помилка не перекриває жодних змін у гілці "особливості A", то конфліктів у вас не виникне.
tdammers

Відповіді:



5

Можливо, помилок у А чи X немає. Виправте помилку у гілці В, де її було знайдено. Виправлення пошириться на X і A у звичайному ході подій.


Дякую, це теж можливо, доки помилка не вплине на особливості А.
Арам Кочарян,

0

Хоча це не популярний робочий процес у git, робочий процес, який популярний у Mercurial, було б оновити до версії X, виправити помилку там (якX 2 ), а потім повторити об'єднання Y(що було б парою злиття в Mercurial).

Насправді цей робочий процес простіший, gitоскільки після того, як всі переключились Yна Y2, тоді посилання на оригінал Yбуде втрачено, і він згодом буде збирати сміття. У hgвас би довелося вручну знімати ці зобов’язання, щоб привести в порядок ваш сховище.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.