GIT - jakie branche w wytwarzaniu oprogramowania Opcje

[wiciu010]

Cześć,

W zespole chcemy przesiąść się na GIT. Pomysł branchy jest następujący:

1. master -> czyli kod, który działa produkcyjnie
2. development -> czyli kod, który działa na środowisku testowym

W zespole jest trzech programistów. Załóżmy, że każdy pracuje nad inną funkcjonalnością, więc tworzy sobie nowy branch (np feature-1).

Pytania:

1. Branche feature powinny bc tworzone na podstawie master czy development? Wydaje mi się, że master

2. Jeśli na test czyli branch development wejdzie kilka zmian (kilka branchy feature), ale na produkcję będziemy chcieli wrzucić tylko wybrane to powinniśmy mergować feature bezpośrednio do master?

[nospor]

Aktualne branche na features, bugs maja isc z develop.
Master jest updatowany z develop.
Tylko hotfix maja isc z master i po naprawie maja isc spowrotem do master i do develop.

To jedna ze szkol. Kombinacji jest znacznie wiecej ale ta tutaj wydaje sie najbardziej powszechna.

https://danielkummer.github.io/git-flow-cheatsheet/

[wiciu010]

Master jest updatowany z develop.

No ok, ale co jeśli na develop weszły trzy zmiany (każda jako inny features), ale tylko dwie albo jedna powinna trafić do master? Można je wydzielić z develop? Bo jeśli pójdzie cały develop do master to trafią tam wszystkie trzy zmiany

[nospor]

Zgodnie z linkiem co ci wyslalem, gdy zamierzasz puszczac cos do live, to masz z develop tworzyc branch RELEASE, tam zakonczyc sprawy i jak jest ok to mergowac do MASTER. W takim wypadku w RELEASE masz to co chcesz miec.

Zas jesli zmiany, ktore maja znalezc sie w master sa krytyczne, sa to wowczas tzw hotfix i sposob postepowania tez masz opisany.

ps: oczywiscie to tylko ogolne sugestie. Czasami postepuje sie w razie koniecznosci inaczej. Dobrze wypracowac sobie schemat, ktorego bedzie sie trzymac

[Pyton_000]

My robimy teraz tak że feature robimy z Develop, Hotfix z Master. I teraz tak. Robimy feature, jak skończony to siup do develop. Testujemy, jak jest ok i klepnięte to siup do mastera.
Na produkcji mamy podłączonego GITa do repo z kodem i poprzez cherry-pick wyciągamy konkretne tickety które trafiają do publiki.

Trochę zamotane ale działa Do każdego takiego cherry dodajey commit z hash oryginalnego commita + nr. ticketów.
Ostatnio w pythonie wyskrobałem skrypt do automatyzacji tego

Ten post edytował Pyton_000 14.06.2017, 11:18:38

[nospor]

@Pyton a czemu master traktujecie jako jedynie wiadro z ktorego sie wyciaga raz na jakis czas? Troche to dziwne, bo moze sie okazac w pewnym momencie ze w master sa rzeczy, ktorych zapomnieliscie wrzucic do public

[Pyton_000]

Ano może tak być Ale to jednostkowe przypadki.

A dlaczego tak? Bo tak