[ArturEsportivo]

#naukaprogramowania #programowanie #frontend #backend

Dzień dobry Mireczki, przychodzę do Was z szybkim filmikiem o często popełnianych błędach przy korzystaniu z systemu kontroli wersji GIT. Materiał bardziej skierowany do początkujących. #programista15k raczej zbyt wiele z niego nie wyciągnie ( ͡° ͜ʖ ͡°)

[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]

@ldefix: wg ludzi, którzy to stosują zaletą jest łatwiejsza integracja i mniej porzuconego kodu. Odnośnie pracy nad różnymi feature'ami w jednej aplikacji to akurat łatwizna, bo przecież różne to niezależne. kilka osób pracujących nad tym samym fragmentem kodu to jest kłopot, ale na etapie podziału pracy, a nie jej realizacji

[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

[ArturEsportivo]

@eloar
1. Nie znam tej filozofii więc trudno mi się do niej odnieść. Jestem w branży ~9 lat i nie korzystałem z takiego podejścia na żadnym projekcie. Jestem ostrożny względem takich nowinek.
2. Mógłbyś rozwinąć dlaczego? W mojej ocenie wiele commitów to plus dla raportowania i historii projektu. Gdy robię code review i tak sobie przeglądam wszystkie zmiany w danym pull requestcie (github lub gitlab) i liczba commitów nie ma znaczenia

[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.