[eloar]

@ArturEsportivo:
- jest od jakiegoś czasu filozofia, gdzie się praktycznie nie tworzy gałęzi i jest powiązana z rapid development,
- kijowo się robi review jak jest milion commitów napierdzielone,

15 min, które dałoby się ująć w 3.

[l.....x]

jest od jakiegoś czasu filozofia, gdzie się praktycznie nie tworzy gałęzi i jest powiązana z rapid development,

I jakie są zalety takiego podejścia? W jaki sposób 2 zespoły mają niezależnie pracować nad różnymi feature'ami jednej aplikacji?

@eloar:

[eloar]

@Hauleth: też po raz pierwszy spotkałem się z podejściem bez branchy dopiero na konferencji parę miesięcy temu. A co do tego, że masz niby 2 branche to nie do końca, chyba, że nie masz śledzenia remote. Masz ten sam branch na wielu repozytoriach. Możesz mieć ile chcesz remote.

No i jak ma się squash commitów do tego co było w filmiku o zbyt dużych i ogólnych commitach? Jeśli praca zostanie

[Hauleth]

A co do tego, że masz niby 2 branche to nie do końca, chyba, że nie masz śledzenia remote. Masz ten sam branch na wielu repozytoriach.

@eloar: z punktu widzenia Gita to są osobne gałęzie i nic z tym nie zrobisz. Nie ważne jaki abstrakcyjny koncept i wytłumaczenie sobie znajdziesz - są one osobne i de facto mogą być niezależne. Tak to działa, czy chcesz czy nie.

[eloar]

@ArturEsportivo:
1. Trunk Based Development
2. duża liczba utrudnia przeglądanie historii. Zawsze jak się zastanawiasz czemu jakiś fragment kodu się tam znalazł u przeglądasz historię i widzisz jak się w commitach o takim samym refs zmienia 10x o 180st.

@Hauleth: no super, to są osobne i co to zmienia jak są ze sobą dość ściśle powiązane? Osobiście jestem zwolennikiem korzystania z podstawowego GitFlow, ale TBD brzmi dość ciekawie.

[Hauleth]

@eloar: ja osobiście nie lubię GitFlow bo IMHO bez sensu wprowadza sztuczny podział na master i development.