Git: Naprawienie błędu dotyczącego dwóch gałęzi


16

Opieram moje repozytorium Git na udanym modelu rozgałęziania Git i zastanawiałem się, co się stanie, jeśli masz taką sytuację:

wprowadź opis zdjęcia tutaj

Powiedzmy, że rozwijam dwie gałęzie funkcji A i B, a B wymaga kodu z A. Węzeł X wprowadza błąd w funkcji A, który wpływa na gałąź B, ale nie jest to wykrywane w węźle Y, gdzie funkcje A i B zostały połączone i testy przeprowadzono przed ponownym rozgałęzieniem i pracą nad następną iteracją.

W rezultacie błąd znajduje się w węźle Z przez osoby pracujące nad funkcją B. Na tym etapie zdecydowano, że potrzebna jest poprawka. Ta poprawka powinna być zastosowana do obu funkcji, ponieważ osoby pracujące nad funkcją A również potrzebują naprawy błędu, ponieważ jest to część ich funkcji.

Czy gałąź błędu powinna zostać utworzona z najnowszego węzła funkcji A (tej rozgałęzionej z węzła Y), a następnie połączona z funkcją A? Po czym obie funkcje zostaną ponownie opracowane i przetestowane przed rozgałęzieniem?

Problem polega na tym, że wymaga to połączenia obu gałęzi w celu rozwiązania problemu. Ponieważ funkcja B nie dotyka kodu w funkcji A, czy istnieje sposób na zmianę historii w węźle Y poprzez wdrożenie poprawki i nadal pozwalanie, aby gałąź funkcji B pozostała nie połączona, a mimo to ma stały kod z funkcji A?

Łagodnie powiązane: Konwencja rozgałęziania błędów Git


6
Czy nie możesz po prostu naprawić błędu w gałęzi „rozwijania”, a następnie scalić go zarówno z funkcją A, jak i funkcją B?
tdammers

Hmm, wydaje się, że tak byłoby najlepiej. W funkcji A mogą występować konflikty scalania, ale myślę, że jest to nieuniknione.
Aram Kocharyan

Jeśli nie dokonałeś żadnego dalszego rozwoju w gałęzi „programowanie”, a poprawka błędu nie nakłada się na żadne zmiany w gałęzi „funkcja A”, nie wystąpią żadne konflikty.
tdammers

Odpowiedzi:



5

Prawdopodobnie nie ma błędu w A lub X. Napraw błąd w gałęzi B, w której został znaleziony. Poprawka zostanie propagowana do X i A w normalnym toku zdarzeń.


Dzięki, jest to również wykonalne, o ile błąd nie wpływa na funkcję A.
Aram Kocharyan

0

Chociaż nie jest to popularny przepływ pracy git, przepływ pracy, który jest popularny w Mercurial, polegałby na aktualizacji do wersji X, naprawieniu błędu (jako X2 ), a następnie ponownym scaleniu Y(co byłoby parą scaleń w Mercurial).

W rzeczywistości, to pracy jest łatwiejsze git, ponieważ każdy ma po włączeniu od Ydo Y2 wtedy sędziowie z oryginałem Yzostaną utracone, a to w końcu będą zbierane śmieci. W hgtym przypadku musiałbyś ręcznie usunąć te zobowiązania, aby uporządkować swoje repozytorium.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.