Praca w GIT tylko na Masterze

Z tego co wywnioskowałem to git branchless charakteryzuje się następującymi cechami:

1. Każdy commit powinien reprezentować jakąś logiczną jednostkę kodu,
2. Commity lokalnie składają się z mniejszych lokalnych commitów, które można dowolnie sobie modyfikować i zmieniać kolejność,
3. Po spushowaniu na mastera tworzony jest pull request na mastera przy pomocy takich narzędzi jak Gerrit gdzie można sobie robić code review zanim commit finalnie trafi na mastera,
4. Całe flow jest uproszczonym gitlab/github flow gdzie kroki, które można zrobić za pomocą amend lub stash oraz przy użyciu feature branchy są tak naprawdę robione pod spodem,
5. Jest jeszcze mało tooli dla gita, które to wspierają taki workflow lub nie są one jeszcze zbyt popularne.

Czy dobrze to rozumiem?

Obstawiam, że w fangach ktoś pomyślał sobie, że każdy programista na gita zużywa np. 2 godziny dziennie i dzięki temu, że uproszczą te komendy to zaoszczędzą ten czas razy 20000 programistów, ale osobiście ciężko mi uwierzyć w ten zysk. U mnie flow wygląda z reguły tak, że robię sobie feature brancha i pierwszego commita, później z 10 razy git commit --amend --no-edit. A później jak dostanę approve w moim PR to zaznaczam squash i wychodzi mi na to samo.

Charles_Ray napisał(a):

Jeżeli ten brancheless https://github.com/arxanas/git-branchless

odzwierciedla to co jest w Googlu, to code review jest robione na poziomie commita, który trafia bezpośrednio do mastera - pisałem o tym podejściu w innym wątku. Oczywiście pod spodem tworzy się kopia robocza plików, które się modyfikuje - bez tego nie dałoby się pracować :) Zakładam, że w Insta może być podobnie.

Dobrze, ale tak właściwie, to po co?
Czemu odbierać ludziom wolność twórczą, którą daje git? Czemu odbierana jest lokalna historia, jaki jest zysk z cofnięcia się o blisko 20 lat w rozwoju?
Skoro nakładka niszczy bazową koncepcję jakiegoś narzędzia, to czemu po prostu nie napisać swojego narzędzia dostosowanego do potrzeb?

Na pewno radziłbym zachować otwartą głowę, bo większość wypowiadających się tutaj prezentuje tzw. fixed mindset - ja wiem najlepiej, a OP to tam pewnie zmywał w tym Instagramie i w ogóle nie wie jak działa git. Wstydźcie się :)

Więcej powodów do wstydu powinni mieć raczej ci, którzy twierdzą, że "wszyscy pracują na jednej gałęzi". Bo jakby to dosłownie interpretować, to znaczy, że cała firma ma jeden komputer z jedną instancją repozytorium. Bida w tych faangach. ;)

Gerrit daje swobodę. To jest narzędzie głównie do CodeReview gdzie postawili na poprawę pojedyńczego commita, zamiast dodawanie kolejnych commitów w procesie CR kończąc na końcu dużym squashem. Można tu mieć i git flow, oraz takiego trunka.

Co do trunka, imo najlepszy system jaki istnieje, jeżeli:

• ma się możliwość bardzo szybkiego deploymentu, z tym jest związany też szybki proces QA
• można wypuszczać aplikację do procenta użytkowników i nie informować ich o zmianach
• ma się możliwość back rolloutu
• ma się zaawansowane systemy raportujące błędy
• błąd na produkcji nie niesie poważnych konsekwencji dla firmy, bo wtedy QA nie musi byc mega dokladne i mozna testowac na % użytkowników
• dużo łatwiej wprowadzić to w działającej aplikacji od dłuższego czasu, niż w takiej tworzonej od zera

@anonimowy z ciekawości, jak sobie radzicie z podbiciem zależności. Często jest tak, że jakaś zewnętrzna biblioteka nawala i wychodzi to dopiero na jakiś specyficznych urządzeniach. Robicie rollback wtedy i czekacie, aż naprawi owner biblioteki? A co z podbiciem Android 12 np i gdy okazuje się, że jest problem i trzeba jednak poczekać z tym, utrzymujecie feature branche na jakieś specjalne okazje (gdy was przyciśnie potrzeba?)

@anonimowy Lokalnie też miałbym nie mieć żadnych branchy? Tylko master i origin/master? Czy widziałbyś to tak że mogę mieć wiele lokalnych branczy, ale tylko jeden remote branch?

Ja znam takie podejście, wiem jak nawet się nazywa pier***nik :D

troche mnie zdziwilo, jak napisales (OP) ze konfilktow nie macie :D
ja to miewalem konfilkty miedzy dwoma branchami na ktorych tylko ja cokolwiek robiłem i się głowiłem z 15 minut :D

anonimowy napisał(a):

Idea polega na tym, że nie masz długich gałęzi, które na wiele dni/tygodni są tworzone równolegle.

Pozwala to uniknąć:

• dużych mergy
• nagłego dostarczenie całej funkonalności do mastera, która nie była testowana na serwerach produkyjnch
• rozjazdu modułu, który byl np. modyfikowany na różne sposoby w dwóch dużych feature branach. Ale to można podpiać pod problem z mergami bardziej ogólnie

Gościu, strzeliłeś sobie w stopę.

To o czym mówisz istnieje, i nazywa się Continuous Integration z Extreme Programming. Większość ludzi osiąga to robiąc częste rebase'y swojego feature brancha na mastera, inni robiąc częste merge.

Wiadomo że każdy chce mieć mały rozjazd feature brancha z masterem, i dla małych feature'ów które można zmieścić w jednym comicie, faktycznie feature branch jest niepotrzebny, ale jak masz ilość commitow większą niż jeden to nie ominiesz feature branchy. I oczywiście nie chodzi o to żeby squashować cały feature, tylko że jeśli masz duży feature to siłą rzeczy musisz go developować chwilę osobno.

Jestem autorem tego urządzenia git-branchless. Możesz mnie pytać szczególne pytania. Przepraszam za niedobry polski.

Polecam, żeby ktoś chcąc więcej się uczyć czytał więcej na tej stronie: trunkbaseddevelopment.com. Moim zdaniem, najważniejszy jest nie utrzymywanie długożyjących gałęzi.

A jak ktoś sam chce używać tego workflow, można używać tego urządzenia: graphite.dev . (Bardzo lubię, ale niestety jeszcze jest w beta...) Ma też tę dokumentację na stacked changes, który jest ważną częścią dania sobie radę tego workflow: docs.graphite.dev/getting-started/why-use-stacked-changes

Oczywiście, jeśli nie wykorzystasz* tego workflow, to nie używaj. Nie jest dla każdego.

Na temat konfliktów, często po prostu się nie dzieje, bo duża jest baza kodu, i większość osób nie pracuje nad tym samym rzeczą. W takim przypadku, nie pojawi się konfliktu. Jednak, deweloper nadal powinien często rebase nad master gałęzią i naprawić wtedy swoje konflikty, aby zmniejszyć ich ciężkość (wspomniano poprzednio w tym wątek jako Continuous Integration).

* znaczy "benefit from"?

Ja tak tylko dodam, że po sprawdzeniu kolegi @Waleed Khan wygląda na to, że to naprawdę on, a nie jakiś troll podszywający się pod kogoś i robiący zamieszanie ;)