Obecnie uczę się korzystać z Git, czytając Pro Git . Teraz uczę się o rozgałęzianiu i tagach. Moje pytanie brzmi: kiedy powinienem użyć gałęzi, a kiedy tag?

Załóżmy na przykład, że tworzę gałąź dla wersji 1.1 projektu. Czy po zakończeniu i wydaniu tej wersji muszę opuścić oddział, aby oznaczyć wersję? Czy powinienem dodać tag? Jeśli dodam tag, czy powinienem usunąć gałąź wersji (zakładając, że jest ona scalona w master lub innej gałęzi)?

W skrócie: najlepsze praktyki to rozgałęzienie, łączenie często i zawsze zsynchronizowane .

Istnieją dość jasne konwencje dotyczące trzymania kodu w oddzielnych gałęziach od gałęzi master:

1. Za chwilę wprowadzisz poważną lub zakłócającą zmianę
2. Za chwilę wprowadzisz zmiany, które mogą nie zostać użyte
3. Chcesz eksperymentować z czymś, co do którego nie masz pewności, że to zadziała
4. Kiedy każą ci się rozgałęziać, inni mogą mieć coś, co powinni zrobić w mistrzu

Ogólna zasada jest po rozgałęzieniu, powinieneś być zsynchronizowany z gałęzią master. Ponieważ w końcu musisz połączyć go z powrotem w master. Aby uniknąć ogromnego skomplikowanego bałaganu konfliktów przy ponownym łączeniu, powinieneś często popełniać, często scalać.

Dobre praktyki do naśladowania

Udany model rozgałęziania Git autorstwa Vincenta Driessena ma dobre sugestie. Jeśli ten model rozgałęzień przemawia do ciebie, rozważ rozszerzenie przepływu do git . Inni komentowali przepływ .

Praktyki znakowania

Jak już wiesz, Git daje ci identyfikatory takie jak 1.0-2-g1ab3183, ale to nie są tagi! Tagowanie odbywa się za pomocą znacznika git, a znaczniki tworzone za pomocą znacznika git są podstawą identyfikatorów zatwierdzeń tworzonych przez git opisz. Innymi słowy, w Git nie tagujesz gałęzi. Tagujesz zatwierdzenia. Prawidłowe jest stwierdzenie, że znacznik jest tylko wskaźnikiem z komentarzem do zatwierdzenia.

Spójrzmy na praktyczny przykład, który to pokazał,

                        / - [v1.0]
                       v
---. ---. --- .--- S ---.--- A <- master
                         \ 
                           \ -.--- B <- test

Dokonajmy zatwierdzenia „S”, zatwierdzonego przez znacznik „v1.0”. Zatwierdzenie to dotyczy zarówno gałęzi „master”, jak i gałęzi „test”. Jeśli uruchomisz polecenie „ git opisz ” na górze zatwierdzenia „A” (na szczycie gałęzi „master”), otrzymasz coś takiego v1.0-2-g9c116e9. Jeśli uruchomisz polecenie „git opisz” na górze zatwierdzenia „A” (inaczej gałęzi „test”), otrzymasz coś takiego v1.0-2-g3f55e41, jak w przypadku domyślnej konfiguracji git-description. Zauważ, że ten wynik jest nieco inny. v1.0-2-g9c116e9oznacza, że ​​jesteśmy w trakcie zatwierdzania z posortowanym identyfikatorem SHA-1 wynoszącym 9c116e9, 2 zatwierdzenia po tagu v1.0. Nie ma tagu v1.0-2!

Jeśli chcesz, aby twój tag pojawiał się tylko w gałęzi „master”, możesz utworzyć nowe zatwierdzenie (np. Aktualizować tylko informacje o domyślnej / zastępczej wersji w GIT-VERSION-FILE) po punkcie rozgałęzienia gałęzi „test”. Jeśli zatwierdzisz zatwierdzenia w gałęzi „test” za pomocą np. „V1.0.3”, będzie to widoczne tylko z „testu”.

Bibliografia

Znalazłem wiele, wiele przydatnych blogów i postów do nauki. Jednak te, które są profesjonalnie zilustrowane, są rzadkie. Dlatego chciałbym polecić post - Skuteczny model rozgałęziania Git autorstwa @nvie. Pożyczyłem jego ilustrację :)

Oddział jest używany, jeśli masz jednocześnie dwie różne wersje repozytorium. Tag jest sposobem na oznaczenie punktu w twoim repozytorium.

Powinieneś dodać tag, aby zaznaczyć wydaną wersję. Jeśli musisz wprowadzić poprawki do tego wydania, utworzyłbyś gałąź przy tagu.

Chcesz tylko usunąć gałęzie, które zostały scalone z powrotem do HEAD [lub innej gałęzi].