Po co tworzyć nowe gałęzie w Git Opcje

[pabito]

Witam
Wiem jak tworzyć nowe gałęzie i jak je mergować, ale nie widzę praktycznego ich zastosowania.
Czy mógłby ktoś podać przykładowe zastosowanie gałęzi abym mógł lepiej zrozumieć cel ich stosowania ?

[Crozin]

1. Powiedzmy, że masz już jakieś działające oprogramowanie. Jego źródła będą znajdować się w domyślnej gałęzi master.
2. Pojawia się potrzeba na dodanie dwóch nowych funkcji do systemu oraz poprawienia błędu. Wszystkie trzy zmiany mogą wymagać edycji pokrywających się plików.
3. Dla każdego z zadań tworzysz sobie nową gałąź, np. feature-257, feature-258, bug-1114.
4. Po tygodniu pracy okazuje się, że nowa funkcjonalność nie będzie jednak potrzebna, także możesz spokojnie przerwać pracę przy gałęzi feature-258.
5. Po kilku dniach możesz na spokojnie połączyć gałęzie feature-257 i bug-1114 z gałęzią master.

Przy prowadzeniu jednoosobowego projektu możesz nie uzyskać wielu zalet ze stosowania gałęzi (czy w ogóle połowy funkcji Gita), jednak pracując już chociażby w dwuosobowym zespole unikniesz problemów ze wchodzeniem sobie nawzajem w drogę czy wymuszaniu na kimś pracy z kodem, który jedynie częściowo rozwiązuje np. buga-1114 (co z reguły oznacza, że sam generuje drugie tyle błędów).

[PrinceOfPersia]

6. debugowanie: coś ci się sypie w programie i chcesz coś testowo sprawdzić, np. wyłączyć zabezpieczenia, albo dodać masę var_dumpów, testowo wyłączyć pewne funkcje itp.. Żeby tego nie robić na masterze, możesz zrobić nową gałąź, eksperymentować do woli, a potem, po zlokalizowaniu źródła buga, usunąć testową gałąź.

[pabito]

czyli jeżeli chcę wprowadzić jakąś zmianę w kodzie/coś dodać to muszę tworzyć nową gałąź ?

[Crozin]

Nie, nie musisz. Nie mniej jednak jest dobra praktyka, powody masz wypisane powyżej.

[lukasz1985]

Ja znam jedną taką sytuację, kiedy to ma zastosowanie:
Kiedy dochodzisz do pewnego punktu w swoim projekcie i stwierdzasz, że połowa z tego, co zrobiłeś jest źle, natomiast chcesz sobie zostawić to co miałeś (z jakiegokolwiek względu), a nie chcesz kopiować swojego całego projektu robiąc backup. Wtedy najlepiej po prostu uworzyć nową gałąź i po prostu pozmieniać co trzeba. Stary kod pozostaje gdzie był, a Ty pracujesz na zupełnie nowej gałęzi.
Co prawda nie jest to do czego git w istocie służy bo głównym jego zastosowaniem jest umożliwienie pracy grupowej, tak jak to opisali inni powyżej ale mi bardzo ułatwia takie podejście pracę z "niepewnym" kodem.

[pabito]

a dlaczego nie lepiej od razu zacomitować to do głównej gałęzi.

[redeemer]

http://nvie.com/posts/a-successful-git-branching-model/

[lukasz1985]

Jak zapiszesz wszystkie zmiany w głównej gałęzi to jak potem chcesz wrócić do punktu w którym jeszcze nie wszystko było źle?

[Pyton_000]

W prawdzie redeemer wyczerpał temat podając link który powinien znać każdy GIT-owiec to dodam od siebie małe wyjaśnienie.

1. Utrzymanie gałęzi master w procesie programowania w najczystszej postaci jest niezwykle cenne. Każdy release lub hotfix który jest włączany do Master jest kolejnym krokiem milowym w aplikacji. Oznaczenie Tagiem tego miejsca pozwala błyskawicznie cofać się do poprzednich wersji w których wszystko działało i mieć czas na sprawdzenie gdzie się pojawił błąd.
2. Rozwój aplikacji na Dev pozwala kontrolować przebieg prac. Testujesz bez obaw że kod rozsypie Ci produkcyjną wersję. Wyobraź sobie że robisz nowy feature i co? Chcesz od razu na master? Proszę. Okazuje się że nie działa i produkcja leży. Robisz śmietnik w gałęzi master niepotrzebnymi commitami które napawią problem.
3. Możesz pracować na wielu nowych funkcjonalnościach. Nowe funkcjonalności możesz rozpocząć w dowolnym momencie i nawet od dowolnego miejsca w drzewie commitów.
4. Utrzymujesz logiczny porządek nad swoją pracą. Każdy feature ma swój branch. Dzięki temu połapiesz się nad czym pracujesz i jakie zmiany wprowadziłeś już od początku prac.
5. Podczas pracy w grupie pk. 4 ma niezwykłe zastosowanie. Ponieważ pracując w grupie zawsze czerpiesz aktualny kod z gałęzi Dev jako rozwojowej. Dzięki temu, że każdy feature jest oddzielnym branchem ktoś kto zaczyna pracę z Dev nie klnie na innych że coś nie zdziała bo ktoś nie skończył swojego featurea. Dopiero po skończeniu feature włączasz go do dev jako kompletny i działający kod (to nie oznacza że nie wolny od błędów, ale nie wysypujący aplikacji przy pierwszym wejściu)
6 ...

Takich przykładów można pisać mnogo i wielko. Każdy ma swoje zastosowanie. Ale jako że praca z branch-ami w GIT jest chyba najprzyjemniejsza na świecie to powinno się z tego korzystać ile się da. Bo to po prostu porządkuje naszą pracę.

[f4ll3ns3raf1n]

Podczepiając się pod temat: gałęzie są pewnie i wygodne i pomocne, ale ja potrzebuję stworzyć dla przykładu 3 środowiska:
LIVE, DEV i FEATURE.

schemat na obrazku poniżej:


nie chcę bawić się w skakanie po gałęziach, chcę niezależnie na serwerze mieć możliwość uruchomienia każdej ze stron.
nie do końca potrafię ogarnąc jak się tym posługiwać. Proszę o pomoc w takich sytuacjach jak:

1) Załóżmy, że zmieniam coś w LIVE, uploaduję to i działa (fixy, poprawki). tutaj tylko drobne zmiany, ale są.
Wtedy na DEV i FEATURE chciałbym pobrać zmienione pliki z LIVE. Rozumiem, że jeśli DEV i FEATURE to klony LIVE, to wystarczy użyć polecenia "git fetch origin" ?


2) Wprowadzam coś ważnego w DEV, sprawdzam, działa? Działa. Chcę całość projektu DEV wrzucić do LIVE, po czym za pomocą netbeansa uploadować tylko te pliki, które się zmieniły.
Czy w LIVE mam dodać repozytorium zdalne do DEV (git remote add...), po czym za pomocą komendy "git fetch dev" pobrać zawartość zmienionych plików w DEV ?
Po tym, chciałbym aby FEATURE też było aktualne względem DEV, podobnie: "git fetch dev" ?


3) Zrobiłem coś fajnego w FEATURE, znów sprawdzam, działa. Z poziomu LIVE pobieram FEATURE: "git fetch feature", po czym w DEV: "git fetch LIVE" ?


czy komendy są prawidłowe? Raczkuję w GIT, a mam projekt z którym już siedzę od jakiegoś czasu i po1. nie chcę co rewizja uploadować 35tys plików na nowo (skoro większość się powtarza, tylko różne daty między plikami lokalnymi a serwerem) ważących ok 150mb. Netbeans dla mnie jest wygodny, bo po synchronizacji widzę dokładnie jakie zmiany na serwerze względem lokalnych plików będą przeprowadzone.

[Pyton_000]

3 repozytoria są ihmo bardzo niewygodne zakładając taki przebieg jaki Ty proponujesz.

Mając 1 scentralizowane masz pełną kontrolę, szybkość i wiele innych zalet.
Flow polega na tym że:
- Masz gałąź Master w które trzymasz wersję produkcyjną. Jeżeli będziesz tagował każdy ważny merge do tej gałęzi to jednym poleceniem możesz uzyskać listę plików które się zmieniły pomiędzy jakimiś ważnymi pkt. np;

Kod

git diff --name-only 1.4..1.5 | xargs -I {} -0 rsync -R -0 {} ./patch/

Tym poleceniem skopiujesz sobie wszystkie pliki które zostały zmienione pomiędzy tagami 1.4 a 1.5 do katalogu patch z zachowniem struktury katalogów.

- Mając gałąź Dev Możesz sobie realizować rozwijanie kodu. A jak skończysz robisz po prostu:

Kod

git co master
git merge --no-ff dev
git tag -a 1.x -m 'Wersja 1.xx'

i masz już wszystkie zmiany w gałęzi produkcyjnej.

- Tworząc kolejne gałęzie typy feature/nowyBajer poprzez:

Kod

git co -b feature/nowyBajer master

tworzysz branch na podstawie gałęzi master. Robisz sobie coś fajnego. Jak stwierdzisz że jest ok to robisz merge do dev:

Kod

git co dev
git merge --no-ff feature/nowyBajer

i testujesz sobie rozwiązanie czy działa z obecną gałęzią dev.
PS. Możesz podczas tworzenia gałęzi feature/ zamiast master dać dev, wtedy nie będziesz musiał dodatkowo testować tego na dev.

To tak ogólnie. Jak jakieś pytania to pisz