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 ( ͡°͜ʖ͡°)
@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,
@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
jest od jakiegoś czasu filozofia, gdzie się praktycznie nie tworzy gałęzi i jest powiązana z rapid development
@eloar: raczej nie spotkałem się z czymś takim. Dodatkowo de facto takie coś jest niemożliwe, bo zawsze masz przynajmniej 2 gałęzie - local i remote. To, że obie nazywają się master to nie zmienia faktu, że są to osobne gałęzie.
kijowo się robi review jak jest milion commitów napierdzielone
@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 odpowiednio
@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 w
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.
@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.
Ale wiecie, że samo dolewanie paliwa do konfliktu się skończy albo katastrofą demograficzną na Ukrainie albo włączeniem wojsk NATO do konfliktu? #wojna #ukraina
Będzie:
Walka do ostatniego Ukraińca, utracone pokolenia41.4% (155)
Jeden bankrut pożycza drugiemu bankrutowi. 400 mld euro poszło na odbicie malutkiej wsi robotajne a na tagu radość bo 61 mld dolarów przegłosowali xD Starczy na 2 miesiące po czym znów będzie objazd po wszystkich krajach prosząc o pieniądze bo za mało było xD #ukraina #rosja
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 ( ͡° ͜ʖ ͡°)
- 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.
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: raczej nie spotkałem się z czymś takim. Dodatkowo de facto takie coś jest niemożliwe, bo zawsze masz przynajmniej 2 gałęzie - local i remote. To, że obie nazywają się
masterto nie zmienia faktu, że są to osobne gałęzie.Dla tego masz
git commitNo 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 odpowiednio
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 w
@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.
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.
masteridevelopment.