[fataler]

Pytanie bo się uczę w git'a. Co zrobić w takim przypadku. Mam sobie działający branch master opublikowany na produkcji. Podczas używania okazuje się że jest tam bug, który jest pierdołą ale trzeba go szybko naprawić. Co robić w takiej sytuacji? Zrobic nowy branch, poprawić bug, zmergować z masterem i opublikować na produkcji czy mogę od razu w masterze poprawić i opublikować na produkcji?

#git #github #programowanie

[baidu]

@fataler: bardziej eleganckim wyjsciem stworzenie nowego brancha, poprawienie buga, w nim i merge z master.

[quickplay-pl]

Możesz poprawiać od razu na masterze.

[S.....s]

@fataler: możesz zrobić i tak i tak, pierwszy sposób będzie porządniejszy, drugi trochę mniej

[kto3]

@fataler nowy branch zdecydowanie, zresztą jak pójdziesz do dobrej firmy to dostaniesz skrót dobrych praktyk jakie u nich obowiązują.

[cxnmlhuipwetr]

@fataler: nie widzę powodu dla którego hotfixy powinny być traktowane jakkolwiek inaczej.

[Kizio]

@fataler zależy od przyjętego flow. U mnie robimy to tak: nowy branch fix/{nazwa} w forku, pull request na upstreama, wciagamy pull request i tyle. Jeśli fix wymaga zaangażowania więcej niż jednej osoby to branch fix/ #!$%@? tez na upstreama i stamtad leci pull request.

[fataler]

@baidu: i po prostu po wszystkim usuwam branch'a z fixem?

@kto3: w tym sęk, że nigdy nie pójdę do żadnej firmy. Ale może gdzieś znajdę taki skrót dobrych praktyk (ale taki realny, używany w SH, a nie opublikowany przez rozmarzonych blogerów)?

@cxnmlhuipwetr: nie wiem, bo to pierdoła a ścieżka naprawy dłuższa ( ͡° ͜ʖ ͡°)?

@Kizio: czekaj czekaj, napisz to po ludzku bo ciekawie

[a231]

i po prostu po wszystkim usuwam branch'a z fixem?

@fataler: jak zmegujesz to branch z fixem sam się zamyka.

[fataler]

@a231: a to się jakoś inaczej oznacza takowy?

[cxnmlhuipwetr]

@fataler: W niektórych modelach pracy (np przy projektach open-source) masz małą grupę ludzi/automatów które mogą wprowadzać zmiany w głównym repozytorium. Żeby wystawić pull request robisz fork (kopię) repozytorium u siebie na koncie, tam wprowadzasz zmiany i wystawiasz pull request z forka do upstreamu (w pewnym uproszczeniu - oryginalnego repozytorium). Regularnie synchronizujesz sobie fork ze zmianami z upstreamu i kontynuujesz pracę na kolejnych branchach.

W prywatnych firmach raczej daje się developerom ograniczony

[Kizio]

@fataler: Jest repozytorium z kodem, nazwijmy je upstream. Każdy z członków zespołu ma własnego forka tego repozytorium. Za każdym razem gdy ktoś chce wrzucić coś na upstream to robi pull request z własnego forka. Pull request jest sprawdzany i wciągany na odpowiedni branch. Każdy ma obowiązek zadbać o to, by jego fork miał aktualne zmiany z upstreama tak, żeby pull requesty mógły być mergowane bez konfliktów. To jak ktoś sobie prowadzi

[fataler]

@cxnmlhuipwetr: ok, teraz kumam co miał kolega na myśli.

[fataler]

@Kizio: zakumałem, dzięki.

Jednak zakładając, że jestem jedynym programistą, który może wprowadzać zmiany w masterze bezpośrednio, a do pomocy 2-3 programistów (mały zespół). To i tak niechlujnie jest robić małe fixy bezpośrednio w masterze i lepiej zrobić jednak branch w tym celu?