Jak zapanować nad rozwijaniem kilku funkcjonalności za pomocą GITa?

Jak uzywac gita przy rozwijaniu kilku różnych funkjonalności aplikacji przez różnych programistów.
Mamy główną gałąź master i pojawiają się następujące sytuacje

• programista 1 tworzy sobie branch A w którym będzie rozwijał jakąś funkcjonalność
• programista 2 tworzy sobie branch B w którym będzie rozwijał jakąś funkcjonalność
• trochę później programista 3 tworzy sobie branch C w którym będzie dodawał swoją funkcjonalność

Tak to ma wyglądać? Po prsotu tworzyć sobie branche dla różnych funkcjonalności?
Co w przypadku, gdy np programista 3 zmerguje swój kod do mastera a następnie programist a1 będzie też chciał zmergować swoją pracę. Czy wtedy to co napisał programista 3 nie zostanie nadpisane tym co miał u siebie w branchu programista 1 (czyli zostaną cofnięte zmiany wprowadzone przez 3 bo programista 1 ma wcześniejszą wersję kodu)?

Po prsotu tworzyć sobie branche dla różnych funkcjonalności?

Tak - nazywa się to fachowo feature branch.

Czy wtedy to co napisał programista 3 nie zostanie nadpisane tym co miał u siebie w branchu programista 1

Nie - zmiany zostaną "inteligentnie" połączone ze sobą.

czyli zostaną cofnięte zmiany wprowadzone przez 3 bo programista 1 ma wcześniejszą wersję kodu

Nie, nic nie zostanie cofnięte.

Poczytaj sobie o git flow, jeśli chcesz się dowiedzieć, jak powinno to wyglądać i działać The Right Way (TM).

Już gdzieś to kiedyś pisałem. Tak jak kolega wyżej napisał jest to feature branch. Ja jestem zwolennikiem następującego podejścia. Tworzymy branch do pracy z głównego brancha (np. master), dokonujemy zmian i robimy commity. Następnie przełączamy się na master, ściągamy najnowsza wersje i znów przełączamy się na feature branch. Robimy rebase z mastera i przy okazji robimy squash commitow, następnie przełączamy się na master i robimy merge. Dzięki temu mamy prosta, liniową historię commitow. Polecenia Git będą więc wyglądać tak:

Git pull master
Git checkout -b feature
{tutaj dokonujemy zmian}
Git commit -a -m "My changes"
Git rebase -i master (tutaj w trakcie dokonujemy squash commitow i naprawiamy merge conflicts)
Git checkout master
Git merge -ff-only feature
Git push

Branche z mastera? nie polecam, conajmniej z mastera trzeba zrobić developa i do mastera umożliwić merga tylko z developa, to po pierwsze. Z developa programiści robią branche na swoje funkcjonalności na których pracują i robią pr tylko do developa, nigdy w życiu do mastera. Jeśli w każdym z tych PR`ów co zrobili programiści nie było zmian dokładnie tego samego kodu wszystko pójdzie ok. Jesli natomiast edytowali ten sam fragment otrzyma się tzw konflikt który programista musi rozwiązać lokalnie, poprzez lokalny merge developa do swojego brancha i poprawiania tego co zaznaczył git w informacjach o konflikcie. Przykładowy konflikt znaleziony w googlu

Trzeźwy Pomidor napisał(a):

Jak uzywac gita przy rozwijaniu kilku różnych funkjonalności aplikacji przez różnych programistów.
Mamy główną gałąź master i pojawiają się następujące sytuacje

• programista 1 tworzy sobie branch A w którym będzie rozwijał jakąś funkcjonalność
• programista 2 tworzy sobie branch B w którym będzie rozwijał jakąś funkcjonalność
• trochę później programista 3 tworzy sobie branch C w którym będzie dodawał swoją funkcjonalność

Tak to ma wyglądać? Po prsotu tworzyć sobie branche dla różnych funkcjonalności?
Co w przypadku, gdy np programista 3 zmerguje swój kod do mastera a następnie programist a1 będzie też chciał zmergować swoją pracę. Czy wtedy to co napisał programista 3 nie zostanie nadpisane tym co miał u siebie w branchu programista 1 (czyli zostaną cofnięte zmiany wprowadzone przez 3 bo programista 1 ma wcześniejszą wersję kodu)?

Wszystko rozchodzi się o to, do której gałęzi będą się łączyć feature branche tych 3 programistów.

Załóżmy hipotetyczny, prosty przypadek, trzech pisarzy (programistów), pisze inwokacje.

Pisarz 1 ma treść:
Litwo Ojczyzno moja.

Pisarz 2 ma treść:
Polsko Ojczyzno moja.

Pisarz 3 ma treść:
Litwo Ojczyzno moja.
Ty jesteś jak zdrowie.

Na potrzeby tego prostego przykładu zakładamy, że są na swoich własnych branchach, ale finalnie chcą zrobić "dołączenie" - merge, do głównego - mastera. Zasadniczo Pisarz 1 i Pisarz 3 będą mieć najprościej, gdyż git za pomocą swoich algorytmów, z łatwością rozpozna, że jeśli Pisarz 3 zmergował pierwszy, a więc jego wersja jest tą "referencyjną" na masterze, to Pisarz 1 nie musi się fatygować, bo jego zmiana już jest na masterze - nie ma problemu.
Gdyby to Pisarz 1 był "pierwszy", wówczas, git dla tak prostego przypadku będzie potrafił "pogodzić" ze sobą te zmiany, bo polegają one tylko na dopisaniu dodatkowej linijki pod spodem. Celowo dałem ten przykład taki prosty.

Problem zacznie się dopiero, gdy Pisarz 2 zechce mergować, albo będzie pierwszy na masterze. Wtedy git już nie będzie tak łatwo mógł ocenić, jak taką zmianę "połączyć" i dojdzie do merge conflict - wówczas na użytkownika, który konflikt spowodował, zostanie zrzucona konieczność rozwiązania tego konfliktu.

To jest bardzo uproszczony przykład tego, o co pytasz, możliwych flow, jak i wad i zalet z nimi związanych jest trochę i nie sposób tutaj ich wszystkich wymienić.

Już kilka osób poleciło git flow. A dla mnie to git flow może umrzeć. Niech żyje Trunk Based Development.

PS Dzięki niemieckim architektom w pracy używam git flow i płaczę każdego dnia. Za to jest bardzo profesjonalnie.

To już nie wiem jak i co stosować :)
Z waszych wpisów wychodzi żeby nie pchać się w Git Flow. Jak wiec rozplanować sobie to inaczej?

Ja polecam Trunk Based Development bez branchy releasowych, jeżeli nie ma potrzeby wspierać np. dwóch głównych wersji aplikacji jednocześnie. Przede wszystkim uczy to wprowadzać małe zmiany do kodu, które go nie psują. Po drugie, drzewo gita jest dużo bardziej przejrzyste.

Ale szczerze, to po prostu używaj gita. W momencie pojawienia się konfliktów, przejrzyj dokumentację i internety, żeby zobaczyć jak je rozwiązać. Bez sensu jest na starcie inwestować wysiłek we wzorce itd. Po prostu poznaj narzędzie.

Po prostu jak zaczynasz pracę nad jakimś taskiem, to robisz branch z mastera, a jak skończysz to mergujesz zmiany z mastera do tego brancha, a potem masz dwa wyjścia:

1. mergujesz brancha do mastera - wtedy zachowujesz historię pracy nad taskiem.
2. mergujesz brancha do mastera z opcją squashowania commitów - wtedy do mastera idzie jeden commit, i masz ładną historię głównej gałęzi. (Ja preferuję takie podejście, bo historia pracy nad taskiem i tak jest bezużyteczna.)

I nie trzeba do tego żadnej marketingowej nazwy w stylu "cośtamflow".

Dosyć wiele IDE obsługuje gita i pozwala w bardzo prosty sposób rozwiązywać konflikty, wystarczy się dosłownie przeklikać :)

Do rozwiązywania konfliktów używam TortoiseGita. I to jest aktualnie jedyne zadanie do którego na co dzień używam Tortoise'a, do reszty używam konsoli.
Nie dlatego że wygodniej (wolałbym Tortoise'a), ale jest po prostu szybciej (Tortoise przy tak dużym repo niestety muli).

Pytanie do tych, co krytykują istnienie brancha develop - to z którego brancha generujecie wersję do testów?
U mnie nader często zdarza się, że jakaś paczka zadań wymaga pilnego pchnięcia na produkcję, a inna paczka czeka wciąż na przetestowanie. To co do testów trzymam na devie, to co gotowe do wydania wrzucam na master. Jedyna alternatywa, jaką widzę, to żeby testować każdego brancha osobno, ale to przecież bez sensu.... Po pierwsze kupa konfiguracji w TC (witki mi opadają na samą myśl), a po drugie - branche mogą wpływać na siebie i po merge'u może się okazać, że to co było OK na jednym branchu i OK na drugim, razem już nie jest OK.

aurel napisał(a):

Pytanie do tych, co krytykują istnienie brancha develop - to z którego brancha generujecie wersję do testów?

Z głównego brancha.

aurel napisał(a):

U mnie nader często zdarza się, że jakaś paczka zadań wymaga pilnego pchnięcia na produkcję, a inna paczka czeka wciąż na przetestowanie.

Czyli rozumiem, że niektóre rzeczy idą na produkcję nieprzetestowane? Czemu w takim razie nie można po prostu wypuścić aplikacji z miejsca, gdzie zmiany zostały wprowadzone do kodu?

aurel napisał(a):

Pytanie do tych, co krytykują istnienie brancha develop - to z którego brancha generujecie wersję do testów?

Co to jest "wersja do testów"? Jakich testów?

TeamCity wspiera przecież branche w Gicie, więc testy będące częścią builda uruchamiają się automatycznie. Po merdżu do mastera, jeśli build przejdzie, to się automatycznie wdraża na środowisko testowe i odpalane są na nim testy integracyjne. Wtedy testerzy mogą sobie potesować manualnie czy jak tam chcą.

Czyli rozumiem, że niektóre rzeczy idą na produkcję nieprzetestowane?

Nie, część rzeczy mogła zostać przetestowana wcześniej, ale nie była jeszcze planowana do wydania, a tu nagle zmiany w planach co do tego co pójdzie. Ewentualnie jakieś drobne zmiany, które testów nie wymagają. Poza tym, część funkcjonalności może przejść testy, a część nie, i wtedy może paść decyzja, że tylko niektóre branche mogą faktycznie iść do wydania, a pozostałe są przesuwane na następne wydanie.

Czemu w takim razie nie można po prostu wypuścić aplikacji z miejsca, gdzie zmiany zostały wprowadzone do kodu?

Chyba nie rozumiem - czy "miejsce, gdzie zmiany zostały wprowadzone", to komputer dewelopera?

@somekind, chodziło mi o testy manualne. I ok, twoja wersja brzmi całkiem spoko - ale co w sytuacji, gdy testy manulane nie przejdą? Nie zrobisz żadnego wydania, póki wszystko nie będzie na 100% tip top? Nawet jeśli część zadań można by już pchnąć, a jedno ma babola zmergowanego do mastera? Czy cofasz wtedy tego merge'a i wydajesz, czy blokujesz wydanie?

@aurel: ale wiesz, że taga można umieścić w na dowolnym commicie? Np. tak git tag v3.0 12345abcdef. Nie musisz nic revertować. A co do testów manualnych to można tak skofigurować CI by mieć release apps.

@hauleth, ooo dzięki :) Wiedziałam, że można ustawić tag dowolnie, ale nie wiedziałam, że mogę się do niego podpiąć w TC ;) Teraz podpinam się do brancha.
Link sobie poczytam później, ale już widzę, że się przyda :D Właśnie dlatego dopytuję, bo coś czuję, że można by usprawnić nasze CI.

aurel napisał(a):

Nie, część rzeczy mogła zostać przetestowana wcześniej, ale nie była jeszcze planowana do wydania, a tu nagle zmiany w planach co do tego co pójdzie. Ewentualnie jakieś drobne zmiany, które testów nie wymagają. Poza tym, część funkcjonalności może przejść testy, a część nie, i wtedy może paść decyzja, że tylko niektóre branche mogą faktycznie iść do wydania, a pozostałe są przesuwane na następne wydanie.

No to nie rozumiem w takim razie. Manualne testy robione przez QA są wykonywane tylko na głównym branchu, Jeżeli coś nie przeszło testów manualnych to możemy korzystać z "feature flag" i ją wyłączyć na produkcji, jeśli nie ma czasu naprawić bugów przed releasem. Jeżeli nie korzystamy z flag, to pozostaje cofnąć zmiany. Nie widzę jak pośredni branch między featurem a głównym branchem w jakiś sposób ułatwia organizację tego.

aurel napisał(a):

Chyba nie rozumiem - czy "miejsce, gdzie zmiany zostały wprowadzone", to komputer dewelopera?

Miejsce w sensie commit w historii gita, a nie fizyczne miejsce.

aurel napisał(a):

@somekind, chodziło mi o testy manualne. I ok, twoja wersja brzmi całkiem spoko - ale co w sytuacji, gdy testy manulane nie przejdą? Nie zrobisz żadnego wydania, póki wszystko nie będzie na 100% tip top? Nawet jeśli część zadań można by już pchnąć, a jedno ma babola zmergowanego do mastera? Czy cofasz wtedy tego merge'a i wydajesz, czy blokujesz wydanie?

Dlatego właśnie warto mieć continous deployment i wdrażać jedną rzecz na raz.Taki problem wtedy w ogóle nie występuje.

aurel napisał(a):

Pytanie do tych, co krytykują istnienie brancha develop - to z którego brancha generujecie wersję do testów?
U mnie nader często zdarza się, że jakaś paczka zadań wymaga pilnego pchnięcia na produkcję, a inna paczka czeka wciąż na przetestowanie. To co do testów trzymam na devie, to co gotowe do wydania wrzucam na master. Jedyna alternatywa, jaką widzę, to żeby testować każdego brancha osobno, ale to przecież bez sensu.... Po pierwsze kupa konfiguracji w TC (witki mi opadają na samą myśl), a po drugie - branche mogą wpływać na siebie i po merge'u może się okazać, że to co było OK na jednym branchu i OK na drugim, razem już nie jest OK.

Można puścić jeszcze tzw. hotfix, jak mamy CI/CD, który obsługuje taki "feature", czyli przyspieszony wjazd na prod (zazwyczaj jest to do tego celu). Pewnie każdy ma na swój sposób to implementowane, ale generalnie chodzi o to, że hotfix powinien mieć "ułatwione" wejście na docelowe środowisko, poza "standardowym" flow, czyli jakieś minimum testów (czy się kompiluje, czy cała apka wstaje).

U mnie w korpo porzuciliśmy SVN na rzecz GITa i 4/6 osób z zespołu używa VS, SourceTree lub TortoiseGit. Dwie osoby używają dodatkowo konsoli.

Za schemat obraliśmy git flow.
W skrócie.

Mamy branch:

1. master - wersja produkcyjna leży na prd i pre prd.
2. releases - przyszłe wersje, które idą na preprd -> prd. Release to środowisko UAT.
3. develop - branch dla developerów. Z develop robimy feature branch lub bugfix branch.

Flow:
feature branch - testy na maszynie developera ->
develop - wdrożenie na INT - testy developerów ->
release-x - wdrożenie na UAT testy testerów ->
master - wdrożenie na pre prd - testy testerów i biznesu ->
wdrożenie na prd.

Widzicie jaki natłok pracy?

Zmodyfikowaliśmy trochę ten flow podany w linku ponieważ nie kasujemy branchu release-x od razu po wgraniu. Czasami stąd czasami z master robimy hotfix/.
Oczywiście mamy TeamCity i 3 buildy odpowiedzialne za publikowanie innych branchy na inne środowiska :)

Nadziany Szczur napisał(a):

Flow:
feature branch - testy na maszynie developera ->
develop - wdrożenie na INT - testy developerów ->
release-x - wdrożenie na UAT testy testerów ->
master - wdrożenie na pre prd - testy testerów i biznesu ->
wdrożenie na prd.

Widzicie jaki natłok pracy?

No jak w osiemnastowiecznej szwalni przed upowszechnieniem maszyn parowych. Ale grunt to mieć dużo procedur. :)