Git - podejście do problemu

Question

Witam

Załóżmy, że mamy jakiś projekt w którym używamy jakiegoś DVCS'a - np git'a i znajdujemy się w następującej sytuacji. Otrzymaliśmy jakieś zadanie, więc tworzymy sobie branch'a, przechodzimy na niego, pracujemy sobie nad rozwiązaniem naszego zadania i nagle odkrywamy jakiegoś bug'a, jest to błąd który sprawia, że np aplikacja pod wpływem jakiś zachowań użytkownika przestaje działać(aplikacja uruchamia się bez błędów, ale pod wpływem niektórych zachowań potocznie mówiąc "wywala się"), teoretycznie coś takiego nie powinno mieć miejsca, bo programista odpowiedzialny za ten kawałek kodu powinien go przetestować i wykryć ewentualne błędy, no ale okey, błądzić jest rzeczą ludzką. Jednak ten błąd przeszkadza nam w pracy, tzn przez niego nie możemy swobodnie pracować, ponieważ feature nad którym pracujemy wymaga, aby ten błąd został poprawiony. I jak w takiej sytuacji należy się zachować?(nie możemy pracować przez nie nasz błąd). Zgłosić "issue" i zaprzestać pracy? Czy może próbować samemu rozwiązać ten problem, jeżeli tak to w jaki sposób*?

Z racji na to, że to pytania wydaje mi się trochę zagmatwane pozwoliłem sobie na próbkę moich artystycznych umiejętności i zobrazowanie problemu;) 

 

* W jaki sposób od strony git'a. Ja myślałem o takim podejściu, skoro błąd ten jest na masterze, czyli de facto na produkcji, więc trzeba by było go jak najszybciej tam zażegnać, czyli powrót do mastera, z "wysokości" mastera tworzymy brancha na którym naprawiamy problem, mergujemy, no i na pierwszy rzut oka wszystko ok, mamy na masterze stabilną, działającą wersje, ale kiedy wrócimy na naszego brancha to na nim nadal nie będziemy mieć naprawionego tego problemu, więc to chyba nie jest rozwiązanie.

Zaznaczam, że nie mam żadnego większego doświadczenia z git'em, i problem z którym tu wychodzę, jest moim luźnym przemyśleniem, na które nie mogłem sobie odpowiedzieć.

Pozdrawiam   

Answer 1

Trochę uprościłeś te naprawianie buga. Potrzebny będzie jeszcze pull request i teoretycznie rewiew.

Ale załóżmy, że jest jak napisałeś. Zaczynasz prace na feauture banrch, wykrywasz buga - zapisujesz zmiany na FB (feature branch), przełączasz sie na mastera i go naprawaisza. Nowe zmiany sa juz w masterze, wracasz do FB. Twój problem polega na tym że masz teraz nieaktualny jakiś plik (w którym wcześniej był bug). Możesz spokojnie zaciągnąć tylko ten jeden plik z aktualnego mastera, nie tracąc zmian w innych plikach z Twojego FB. Oczywiście może być sytuacja, że naprawiany plik z mastera będzie jednocześnie plikiem w którym ty w ramach FB poczyniłeś najwięcej zmian - rozwijając funkcjonalność. Wtedy robisz merga z mastera tego pliku ale przy okazji dostajesz komunikat o konfliktach, które musisz rozwiązać.

Comments

Nie polecam mergować mastera do swojego brancha - brzydko to wygląda w historii i ciężko później ogarnąć, do którego commita się zresetować.

Zamiast tego, polecam rebase Twojego brancha na mastera.