![]() |
![]() |
![]()
Post
#1
|
|
![]() Grupa: Zarejestrowani Postów: 952 Pomógł: 154 Dołączył: 20.01.2007 Skąd: /dev/oracle Ostrzeżenie: (0%) ![]() ![]() |
Skoro już powstał stosowny ku temu dział, warto poruszyć temat modeli pracy z Gitem. Wiadomo, w tym systemie kontroli wersji nacisk kładziony jest na tworzenie gigantycznej liczby gałęzi i ich scalanie. Gdy wiosną przerzuciłem się na Gita, wszystko było fajnie, z wyjątkiem tego, że nie miałem żadnego doświadczenia w tym, jak organizować te gałęzie, by się w nich nie pogubić.
Dopiero niedawno problem de facto się rozwiązał, gdy znajomy podesłał mi opis pewnego modelu pracy z Gitem: http://nvie.com/posts/a-successful-git-branching-model/ Czy ktoś z Was już go stosuje i mógłby podzielić się doświadczeniami? A może wykorzystujecie jakieś inne, własne i sprawdzone konwencje? Mi powyższy model wygląda na dobry do większych projektów, natomiast ostatnio Gita używam coraz częściej do różnych mniejszych prac, nawet na własne potrzeby, gdzie ciężko jest go zastosować choćby z tego powodu, że nie ma w nich "wydań" jako takich. Tu wciąż sprawa pozostaje otwarta. -------------------- Specjalista ds. głupich i beznadziejnych, Zyx
Nowości wydawnicze: Open Power Collector 3.0.1.0 | Open Power Autoloader 3.0.3.0 |
|
|
![]() |
![]()
Post
#2
|
|
![]() Grupa: Zarejestrowani Postów: 1 366 Pomógł: 261 Dołączył: 23.09.2008 Skąd: Bydgoszcz Ostrzeżenie: (0%) ![]() ![]() |
Jeżeli chodzi o mniejsze rzeczy gdzie bugfix'y/zmiany robi się real-time to moim zdaniem najlepiej rozbić to na dev / stable (lub nawet ominąć dev jeżeli korzystasz sam z tego repo) i tylko branchować jakieś większe rzeczy, lub rzeczy które mogą zająć więcej czasu / testów a w międzyczasie może dojść jakaś nowa poprawka, wtedy wystarczy przełączyć się na stable/dev i ją zrobić i wrócić do dalszej pracy nad gałęzią.
-------------------- |
|
|
![]() ![]() |
![]() |
Wersja Lo-Fi | Aktualny czas: 14.08.2025 - 15:31 |