Problem ze zrozumieniem branchy

0

Hej,
Stosunkowo od niedawna zacząłem używać gita i oprócz commitowania chciałbym zrozumieć koncepcję branchy, co przychodzi mi z trudem. Chciałbym użyć branchy we własnym, 1-osobowym projekcie, dla samej nauki. Mam kilka głupich pytań, bo najwyraźniej kompletnie nie rozumiem jak to działa, mimo że trochę czytałem na ten temat.

Załóżmy, że mam plik na lokalnym repozytorium:

  1. Czy przed stworzeniem nowego brancha lokalnie, powinienem utworzyć kopię pliku, który chcę zmodyfikować i zacommitować do niego? Tzn. powiedzmy że zmieniam plik i co zrobić, aby nie utracić jego pierwotnej wersji? Tzn. chciałbym mieć wgląd w obie wersje pliku, tę nową i tą pierwotną.
  2. Czy tworzenie branchy w jednoosobowym projekcie to stosowana praktyka? Czy ma sens?

Będę wdzięczny za wszelkie tłumaczenie, wydaje mi się że te gałęzie to bardzo abstrakcyjne pojęcie.

5

najwyraźniej kompletnie nie rozumiem jak to działa, mimo że trochę czytałem na ten temat.

A czy stosowałeś to w praktyce? Najlepiej to rób na jakimś nowym folderze. Zrób sobie folder z głupotami napisz bla, bla czy coś i zacommituj do mastera, potem zrób np. git checkout -b nowa-galaz i ogólnie baw się tym. Sprawdzaj stan folderu i zawartość plików, zmieniaj je, commituj, przełączaj się między gałęziami. Tylko rób to na jakichś nowych repozytoriach (tak, że nawet jak coś zepsujesz, to nie będzie szkoda, więc do woli będziesz mógł eksperymentować)

(Nawiasem mówiąc jeśli tak ci się zdarzy, że zepsujesz w Git coś na prawdziwym repo, to też często da się to uratować - stack overflow przychodzi z pomocą)

Czy tworzenie branchy w jednoosobowym projekcie to stosowana praktyka?

Niektórzy powiedzą, że tak, ale obecnie rzadko robię branche w jednoosobowych projektach. Kiedyś mi się zdarzało częściej. Chociaż niedawno się zdarzyło, jak sobie "zabrudziłem" projekt eksperymentami i nie chciałem tego commitować do mastera, ale nie chciałem wyrzucać tego kodu. To jest sobie na pobocznej gałęzi.

powinienem utworzyć kopię pliku

Jeśli zacommitowałeś coś w Git, to już Git ci zrobił kopię pliku. Chyba, że masz na myśli niezacommitowane zmiany, wtedy trzeba uważać, bo niektóre komendy Gita mogą ci je skasować (albo w ogóle się nie uruchomić krzycząc, że masz niezacommitowane zmiany). Wtedy należy je zacommitować albo użyć komendy git stash, żeby tymczasowo przechować.

Jak coś jest w Gicie, to spoko, ale jak nie zacommitowałeś, to trzeba uważać.

Czy ma sens?

Używanie gałęzi ma zalety i wady. Wadą jest to, że potrzebujesz ogarniać, co jest w której gałęzi. Masz nagle ileś wersji projektu. I są to wersje, o których sam musisz myśleć. Możesz mieć tysiąc commitów w masterze i nie musisz o nich myśleć, bo od tego jest Git. Ale jak narobisz ileś gałęzi, to potrzebujesz dbać o to, żeby się nadawały do łatwego zmerdżowania, bo inaczej te gałęzie będą się tak różnić od mastera, że już ich łatwo nie zmerdżujesz, bo będą konflikty albo sobie rozwalisz coś w projekcie. Natomiast gałęzie mają też zalety (w przypadku 1 osobowego programowania np. można łatwo eksperymenty robić)

Czy przed stworzeniem nowego brancha lokalnie, powinienem utworzyć kopię pliku, który chcę zmodyfikować i zacommitować do niego?

Jeśli mówisz o git checkout -b nowa-galaz to tworzy ci nową gałąź, ale nie kasuje ci zmian. Więc robisz coś, jesteś na masterze i masz niezacommitowane zmiany, tworzysz sobie nową gałąź i cię przełącza na nową gałąź i możesz commitować już do nowej gałęzi.

4

Coś, co może pomóc Ci w nauce korzystania z gałęzi to: https://learngitbranching.js.org/. Jest to interaktywny tutorial - może dzięki niemu zabawa z gałęziami będzie dla Ciebie mniej abstrakcyjna.

3
Excelowiec napisał(a):
  1. Czy przed stworzeniem nowego brancha lokalnie, powinienem utworzyć kopię pliku, który chcę zmodyfikować i zacommitować do niego? Tzn. powiedzmy że zmieniam plik i co zrobić, aby nie utracić jego pierwotnej wersji? Tzn. chciałbym mieć wgląd w obie wersje pliku, tę nową i tą pierwotną.

W tym celu właśnie używa się systemów kontroli wersji, takich jak Git. Ich celem jest trzymanie historii zmian, żeby nie trzeba było samemu kopiować plików.

  1. Czy tworzenie branchy w jednoosobowym projekcie to stosowana praktyka? Czy ma sens?

A czy w jednoosobowym mieszkaniu trzeba się myć?
Ja tworzę gałęzie na potrzeby konkretnego zadania (nieważne, czy to refaktoryzacja, nowy ficzer czy bug do naprawienia), albo na potrzeby zrobienia jakichś swoich eksperymentów. Nie widzę związku z liczbą osób w projekcie. Higiena to podstawa.

1
somekind napisał(a):

A czy w jednoosobowym mieszkaniu trzeba się myć?
Ja tworzę gałęzie na potrzeby konkretnego zadania (nieważne, czy to refaktoryzacja, nowy ficzer czy bug do naprawienia), albo na potrzeby zrobienia jakichś swoich eksperymentów. Nie widzę związku z liczbą osób w projekcie. Higiena to podstawa.

YAGNI.

Istnieje coś takiego jak overkill.

Tego rodzaju praca z gałęziami, jaką opisałeś, w większości sprowadza się do czegoś takiego:

  1. Tworzysz gałąź
  2. Wprowadzasz poprawki
  3. Merge'ujesz gałąź

...i już.
Gdzie jest wartość dodana wynikła z używania galęzi??

Równie dobrze można usunąć punkty 1. i 3. i nic nie stracimy.

IMO w 1-os projekcie gałęzie mają sens tylko wtedy, jeśli naprawdę chcemy / potrzebujemy równolegle rozwijać 2 wersje projektu. Może tak być, ale raczej rzadziej niż częściej.

"Higiena to podstawa" - wyłuszcz, jakie korzyści to daje, albo jest to dogmatyzm & cargo cult.

1
YetAnohterone napisał(a):

Gdzie jest wartość dodana wynikła z używania galęzi??

Porządek w historii, zawsze stabilna wersja kodu póki kolejny ficzer nie zostanie ukończony.

"Higiena to podstawa" - wyłuszcz, jakie korzyści to daje, albo jest to dogmatyzm & cargo cult.

Używanie zwrotu cargo cult chyba samo w sobie stało się już cargo cultem.

0

Pomysl tak:

  1. Wyobraz sobie ze pracujesz nad dokumentem w wordzie. Commit, to zapisanie pliku pod unikalna nazwa.
  2. Branch to tak jakbys wzial katalog w ktorym masz swoj dokument i zrobil sobie kopie katalogu. Teraz jak jestes na glownym branchu to jestes w pierwotnym katalogu, jesli na ktoryms pobocznym otwierasz inny katalog i w nim pracujesz.
  3. Czy robic branche we walsnym projekcie? Zalezy od projektu, wielksoci zmiany i np.. od tego czy masz wpiete jakies testy/CI/CD i jak skonfigurowane. Ja czesto robie tak, ze male rzeczy zmeiniam bezposrednio na glownym branchu, ale jak chce zrobic cos wiekszego co moze np. stabilnosc zepsuc, albo pisze gre i chce sprawdzic kilka koncepcji to sobie robie kilka branchy. W pracy poza bardzo rzadkimi przypadkami i ew. repo gdzie jest Gerrit zawsze robie brancha, nawet na poprawe literowki (zreszta proces to wymusza).
0
somekind napisał(a):

Używanie zwrotu cargo cult chyba samo w sobie stało się już cargo cultem.

Obalić taki zarzut jest bardzo łatwo, wystarczy wykazać korzyści wypływające z danej praktyki.

Porządek w historii, zawsze stabilna wersja kodu póki kolejny ficzer nie zostanie ukończony.

Ale z punktu widzenia historii jest zawsze tak samo: po zmerge'owaniu masz jedną gałąź, na której liniowo pojawiają się kolejne commity.

"zawsze stabilna wersja kodu" - owszem, ale do pilnowania takowej wystarczy commit.

1

@Excelowiec: Podchodzisz do tego od bardzo złej strony - to spowoduje wiele miskoncepcji i utrwalisz w ten sposób błędy.

Ponieważ jeszcze nie umiesz używać branchy, to jest dla mnie sygnał że tak na prawdę jeszcze ich nie potrzebujesz. Ale słyszałeś że są używane więc chcesz je dodać. To jest bardzo zła motywacja żeby się czegoś nauczyć: tzn. coś jest popularne, więc wcisnę to do swojego projektu.

Moim zdaniem powinieneś na razie olać całkowicie naukę branchy, i pracować dalej tak jak pracowałeś, do momentu w którym poczujesz że ich potrzebujesz.

Excelowiec napisał(a):
  1. Czy przed stworzeniem nowego brancha lokalnie, powinienem utworzyć kopię pliku, który chcę zmodyfikować i zacommitować do niego? Tzn. powiedzmy że zmieniam plik i co zrobić, aby nie utracić jego pierwotnej wersji? Tzn. chciałbym mieć wgląd w obie wersje pliku, tę nową i tą pierwotną.

Wgląd w dwie wersje pliku możesz załatwić commitami.

To że tego do końca nie rozumiesz, to jest kolejny sygnał że nie potrzebujesz jeszcze używać branchy. Moim zdaniem powinieneś nadal poużywać gita i zobaczyć jak będzie.

  1. Czy tworzenie branchy w jednoosobowym projekcie to stosowana praktyka? Czy ma sens?

Tak - pod warunkiem że wiesz co robisz i wiesz po co one Ci są potrzebne. Tworzenie ich, tylko po to żeby były, jest dość bezsensowne. Sam mam jednoosobowe projekty w których mam wiele branchy, ale mam też takie w którym mam tylko master i wystarczy.

Off-topic

W wielu dziedzinach programowania taka "motywacja" prowadzi do okropnych wyników:

  • Ktoś nie potrzebuje wzorców, ale słyszy że są fajne, więć dodaje je tam gdzie nie pasują, i ma spaghetti w kodzie
  • Ktoś nie potrzebuje dockerować aplikacji, ale wie że to jest cool, więc dodaje dockera i potem mamy fizzbuzz enterprise
  • Ktoś nie potrzebuje pisać testów, ale wie że są modne, więc dodaje je - mamy rigid, fragile testy które nic nie testują
  • Ktoś nie potrzebuje interfejsów i abstrakcji, ale wie że są spoko więc dodaje je, i potem mamy 100 interfejsów które nic nie wnoszą
  • Ktoś nie potrzebuje reduxa w SPA, ale go dodaje i potem ma pomieszane zależności zamiast state.

Motywacja do nauki czegoś powinna wyglądać: "Potrzebuję czegoś" -> "a więc go dodam". Nie powinno być "słyszałem że jest coś takiego jak branche", "więc ja też chcę to mieć".

O poprzednich odpowiedziach

Odpowiedzi wcześniej się wypowiadających, np @LukeJL są bardzo dobrze i wartościowe - ja tylko odradziłbym stosowanie ich w "normalnych" projektach na początku; tylko raczej zacząłbym od śmieciowego projektu gdzie możesz sobie to przetrenować, i ewentualnie dopiero później je dodać, jak już będziesz wiedział do czego się mogą przydać.

O branchach

Branche są na tyle ciężkie do wytłumaczenia, że na różnym poziomie zaawansowania branche są używane w rózny sposób. Ty, jako początkująca osoba, pewnie najlepiej by je zrozumiała w taki sposób, że chcemy móc we w miare jednoczesnym momencie chcemy rozwijać dwie funkcjonalności w projekcie na raz. Tzn dodajesz do aplikacji jakąś funkcjonalność która zajmie Ci tydzień żeby ją napisać, ale w połowie stwierdzasz że chcesz dodać coś do "normalnej wersji" coś szybkiego, więc przełączasz się na nowy branch od zwykłej wersji (tygodniowy feature zostaje na poprzednim), dodajesz szybką funkcję, i potem wracasz na ten tygodniowy branch.

Skąd mam wiedzieć, kiedy będę ich potrzebował?

@Excelowiec: Jeśli będziesz programował sobie aplikacje, i w pewnym momencie uznasz "kurcze, mam zmiany w tym pliku, ale chciałbym zrobić coś innego bez tych zmian które mam teraz" - to wtedy zrób branch. Jeśli tak nie pomyślisz, to raczej nie potrzebujesz ich jeszcze.

4

To jest bardzo zła motywacja żeby się czegoś nauczyć: tzn. coś jest popularne, więc wcisnę to do swojego projektu.

Może inaczej - ja to widzę tak, że słyszał o jakimś narzędziu, ale go nie zna. I ten wątek nie tyle dotyczy pchania czegokolwiek na siłę, co raczej dowiedzenia się jak to działa, co się z tym robi i jeśli uzna, że będzie to przydatne - rozpoczęcie użytkowania. Raczej koledze się należy pochwała że chce się rozwijać, a nie krytyka jego motywacji.

1
Riddle napisał(a):

Ponieważ jeszcze nie umiesz używać branchy, to jest dla mnie sygnał że tak na prawdę jeszcze ich nie potrzebujesz. Ale słyszałeś że są używane więc chcesz je dodać. To jest bardzo zła motywacja żeby się czegoś nauczyć: tzn. coś jest popularne, więc wcisnę to do swojego projektu.

A tu się nie do końca zgodzę.

Celem stosowania praktyki / umiejętności / techniki / whatever X może być, tylko i wyłącznie, nauka X. Mało tego, czasem jest to wręcz konieczne: by umieć coś stosować wtedy, gdy jest to naprawdę potrzebne i przydatne, trzeba najpierw nauczyć się tego na przykładzie czysto ćwiczebnym.

Zresztą tak samo jest z TDD, które promujesz. Sami piewcy TDD twierdzą często, że by móc stosować to w produkcji trzeba najpierw się tego nauczyć na toy examples. Oczywiście do zrobienia kalkulatora zabawki TDD, jak i w ogóle testy są zbędne; ale nie temu to służy.

Albo z innej dziedziny. Czmu uczniowie w szkole rozwiązują zadania, że pociąg ze stacji A do stacji B wyjechał o godzinie 12:30 i jechał z prędkością 60km/h, zaś pociąg ze stacji B do stacji A wyjechał o godzinie 13:00 i jechał z prędkością 45 km/h; odległość międzi stacjami A i B wynosi 100km, o której godzinie spotkają się oba pociągi i gdzie? No przeciez to nie rozwązuje żadnego praktycznego problemu; ma tylko nauczyć umiejętności, które PÓŹNIEJ będa potrzebne do praktycznych problemów.

Motywacja do nauki czegoś powinna wyglądać: "Potrzebuję czegoś" -> "a więc go dodam". Nie powinno być "słyszałem że jest coś takiego jak branche", "więc ja też chcę to mieć".

Często najpierw musisz posiąść daną umiejętność, by zrozumieć, że w danym punkcie jej potrzebujesz.

Cargo cult, moim zdaniem, jest nieuniknionym etapem nauki.

1

Może źle się wyraziłem, bo widzę już shitstorm jadący w moją stronę.

Oczywiście pytający może zacząć się uczyć czegokolwiek chce kiedy chce, i popieram taką decyzję - do nauki czegokolwiek tylko po to żeby się nauczyć.

Ale nie znaczy to, że powinieneś to od razu dodawać do swoich projektów. Pytający moim zdaniem powinien stworzyć nowy projekt "taki do wyrzucenia", i na nim się uczyć. Bo pytający mówi że ma jednosobowy projekt i chce do niego dodać branche - przy czym nie jest powiedziane że one są tam potrzebne.

@cerato: @YetAnohterone @loza_prowizoryczna Zauważcie, że ja odradzałem dodawanie do projektu czegoś, czegoś czego się nie rozumie, i czegoś co nie koniecznie jest potrzebne.

Riddle napisał(a):

"Potrzebuję czegoś" -> "a więc go dodam". Nie powinno być "słyszałem że jest coś takiego jak branche", "więc ja też chcę to mieć".

Riddle napisał(a):

Ponieważ jeszcze nie umiesz używać branchy, to jest dla mnie sygnał że tak na prawdę jeszcze ich nie potrzebujesz. Ale słyszałeś że są używane więc chcesz je dodać

Ale uczyć się tego może do woli.

Nauka jest dobra. Niech sobie zrobi śmieciowy projekt, i na nich się uczy branchy, a potem zdecyduje czy chce dodać je do swojego głównego projektu czy nie. Podejście "dodam branche do swojego projektu i zobacze jak będzie" jest średnie, i przed tym chciałem przestrzec.

3
YetAnohterone napisał(a):

Ale z punktu widzenia historii jest zawsze tak samo: po zmerge'owaniu masz jedną gałąź, na której liniowo pojawiają się kolejne commity.

No nie jeśli nawalisz do niej pośrednich commitów.
Ja wiem, można to potem wszystko zrebase'ować, ale to strata czasu, no i przepisywanie historii mastera. W imię czego? Nieużywania właściwie głównego ficzera Gita?

"zawsze stabilna wersja kodu" - owszem, ale do pilnowania takowej wystarczy commit.

Nie bardzo. Jeden task to często dziesiątki commitów.
No chyba, że robisz jeden commit per zadanie, na jego koniec. W takim razie faktycznie nie potrzebujesz branchy. Systemu kontroli wersji też nie, zwłaszcza Gita.

1
somekind napisał(a):

Nie bardzo. Jeden task to często dziesiątki commitów.

Jeśli już jakaś higiena ma sens, to release early, release often.

Nawet, jeśli nie ukończyłeś taska, to staraj się, by kod kompilował się i działał. (Nie koniecznie twierdzę, że trzeba go od razu deploy'ować, ale chociaż teoretycznie powinien być deploywable)

Jeśli masz dziesiątki commitów na task, a jeszcze próbujesz miesz branch na task i być może robić kilka tasków jednocześnie, to zaczynasz ponosić koszta związane z branchowaniem: merge'y zaczynają być coraz bardziej uciążliwe, gdyż poszczególne wesje projektu rozjeżdżają się coraz bardziej. Ale rozwiązaniem tego problemu nie sa branche, tylko uniknanie pojawienia się tego problemu. W jednoosobowym projekcie bez deadline'ow i konieczności nagłego przerzucania się na inny task bo manager na cb wrzeszczy w większości przypadków jest to jak najbardziej wykonalne.

Jeśli już naprawdę musisz mieć kilkadziesiąt commitów na task, po pośrednich commitach projekt nawet teoretycznie nie jest deployable ORAZ jesteś zmuszony pracować równolegle nad wieloma taskami (np. wrzucić hotfixa do wersji stabilnej przed ukończeniem tego olbrzymiego taska, bo np. robisz hobbystyczną grę, zdobyłeś jakies gronko fanów, którzy wrzeszczą, że grać się nie da bo jest gamebreaking bug), no to wtedy rzeczywiście branche mają sens. Taka sytuacja może nastąpić. Raczej rzadko, ale tak, możesz być do niej kiedyś zmuszonym. Ale możesz zrobić tego brancha dopiero w tym momencie, w którym zaczynasz go naprawdę potrzebować, a nie od razu by default.

W takim razie faktycznie nie potrzebujesz branchy. Systemu kontroli wersji też nie, zwłaszcza Gita.

No nie. System kontroli wersji przydaje się do:

  • Trzymania historii;
  • Jest wymagany, jeśli np publikujesz własną libkę na githubie by społeczność z niej korzystała (albo korzystasz z jakiś narzędzi automatyzujących deployment)
    • W takim wypadku rzeczywiście można by default mieć dwie branche ma(ster|in)] + dev; ale to wciąż nie uzasadnia brancha na task
  • Wreszcie możliwość rozbranchowania zawsze będzie przydatna NA WYPADEK, gdy akurat zaczniesz jej potrzebować.
1

@somekind: @YetAnohterone Bardzo ciekawa rozmowa się z tego wyciągnęła, i obie strony mają merit (bo widzę skąd wychodzi zarówno jeden jak i drugi z was), ale ta rozmowa w żaden sposób nie pomoże pytającemu, więc może wartoby przenieść tą rozmowę do innego wątku?

0
Riddle napisał(a):

Nauka jest dobra. Niech sobie zrobi śmieciowy projekt, i na nich się uczy branchy, a potem zdecyduje czy chce dodać je do swojego głównego projektu czy nie. Podejście "dodam branche do swojego projektu i zobacze jak będzie" jest średnie, i przed tym chciałem przestrzec.

Nauka jest dobra ale czy wyniki uzyskane w wyniku sterylnego izolowanego eksperymentu są tak samo użyteczne w warunkach gdzie takie założenia nie mogą być spełnione? Odważne, nie powiem.

0
loza_prowizoryczna napisał(a):
Riddle napisał(a):

Nauka jest dobra. Niech sobie zrobi śmieciowy projekt, i na nich się uczy branchy, a potem zdecyduje czy chce dodać je do swojego głównego projektu czy nie. Podejście "dodam branche do swojego projektu i zobacze jak będzie" jest średnie, i przed tym chciałem przestrzec.

Nauka jest dobra ale czy wyniki uzyskane w wyniku sterylnego izolowanego eksperymentu są tak samo użyteczne w warunkach gdzie takie założenia nie mogą być spełnione? Odważne, nie powiem.

Dla początkującego na pewno tak, a nawet bardziej; bo skupia się na istotnych rzeczach, a nie na rzeczach specyficznych dla "niesterylnego projektu".

0

Ale czy brancze w gicie nie powstały właśnie w celu umożliwienia bezproblemowej współpracy na zdecentralizowanym repo zespołom ludzi? W takim razie jedna osoba w w jednym projekcie nigdzie nie złapie tych cech istotnych, czyż nie?

0
loza_prowizoryczna napisał(a):

Ale czy brancze w gicie nie powstały właśnie w celu umożliwienia bezproblemowej współpracy na zdecentralizowanym repo zespołom ludzi?

Nie.

Po to powstały commity i w zasadzie cały git.

loza_prowizoryczna napisał(a):

W takim razie jedna osoba w w jednym projekcie nigdzie nie złapie tych cech istotnych, czyż nie?

Gadasz głupoty.

1

Po prostu zacznij działać. Powiedzmy, że masz do napisania jakąś funkcjonalność i potem musisz ją sobie przetestować ręcznie.
Masz więc coś takiego
Repo:
--main
--branchX

Odgałęziając się od tego głównego brancha main masz kopię plików w branchX powiedzmy, że musisz sobie pracować nad funkcjonalnością tydzień. Codziennie po skończeniu jakiejść części kodu może sobie go zacommitować. Stabilna wersja bez zmian jest ciągle dostępna w main i w razie co możesz przerwać pracę nad tym swoim branchem lub w ogóle go porzucić.
Zaleta następna możesz sobie po takich commitach wypchnąć zmiany do repo zdalnego i nie ma zaskoczenia, że w połowie pracy dysk padanie i cały misterny plan...
Na koniec robisz sobie np. merge ze squash, opisując taki commit jednym ładnym i historia w głównym branchu jest klarowna, łatwo się cofnąć przed te zmiany itd.
Jak już się przyzwyczaisz to się okaże, że jest to wygodne, praktyczne a wręcz niezbędne.

Co do ogólnego zrozumienia, poglądaj kursy na YT. Zobaczysz tam grafy z commitami i opisy jak to wygląda przy mergu czy rebase.
Ekstra profit, jak na rozmowie o pracę zapytają merge vs rebase będziesz wiedział co odpowiedzieć.

0
jurek1980 napisał(a):

Po prostu zacznij działać. Powiedzmy, że masz do napisania jakąś funkcjonalność i potem musisz ją sobie przetestować ręcznie.
Masz więc coś takiego
Repo:
--main
--branchX

Odgałęziając się od tego głównego brancha main masz kopię plików w branchX powiedzmy, że musisz sobie pracować nad funkcjonalnością tydzień. Codziennie po skończeniu jakiejść części kodu może sobie go zacommitować. Stabilna wersja bez zmian jest ciągle dostępna w main i w razie co możesz przerwać pracę nad tym swoim branchem lub w ogóle go porzucić.

To nie jest cecha branchy w gicie, bo to samo możesz zrobić bez rozgałęzienia się - po prostu checkout na poprzednią wersję. Jeśli chcesz "oznaczać" stabilne wersje, to do tego lepiej nadają się tagi.

jurek1980 napisał(a):

Zaleta następna możesz sobie po takich commitach wypchnąć zmiany do repo zdalnego i nie ma zaskoczenia, że w połowie pracy dysk padanie i cały misterny plan...
Na koniec robisz sobie np. merge ze squash, opisując taki commit jednym ładnym i historia w głównym branchu jest klarowna, łatwo się cofnąć przed te zmiany itd.

Bez rozgałęziania się też możesz zrobić squash, i to całkiem łatwo.

@jurek1980: Nie myśl że się nie zgadzam z tym co powiedziełeś: opisałeś bardzo ładnie jak można pracować z gitem.

Ale nic z tego co opisałeś nie dotyczy branchy tak na prawdę, opisałeś gita po prostu.

4

@Riddle:

Nie myśl że się nie zgadzam z tym co powiedziełeś: opisałeś bardzo ładnie jak można pracować z gitem.

Podałem hasła do szukania w YT, opisałem dlaczego warto. Opisałem w skrócie bardzo że branch to kopia kodu z jakiegoś punktu. Na tym etapie chyba wystarczy do szukania w necie?
Oczywiście w git można robić różne cuda o jakich pewnie obaj nawet nie wiemy. Chciałem tochę ukrucić komentarze typu "nie warto, nie rób", " w domu to nie masz co tego stosować" które jakoś zaczęły królować w wątku.

2
Excelowiec napisał(a):

Będę wdzięczny za wszelkie tłumaczenie, wydaje mi się że te gałęzie to bardzo abstrakcyjne pojęcie.

Git jest elastyczny. Ale ma też dobrą dokumentację (za darmo!) dostępną w języku polskim. Tak więc żeby zrozumieć koncept czasem warto zajrzeć i przeczytać co do napisania mają na ten temat sami twórcy narzędzia:
https://git-scm.com/book/pl/v2/Ga%C5%82%C4%99zie-Gita-Czym-jest-ga%C5%82%C4%85%C5%BA

Reszta przyjdzie w praktyce i pracą zespołową bo git w przeciwieństwie do wcześniejszych systemów wersji nie wymusza konkretnego flow w projekcie.

1

Taka rada, że aby dobrze zrozumieć gita to trzeba w zespole poprogramować. Samemu na początku może być ciężko załapać niekotre koncepcje

0
Czitels napisał(a):

Taka rada, że aby dobrze zrozumieć gita to trzeba w zespole poprogramować. Samemu na początku może być ciężko załapać niekotre koncepcje

Zupełna nieprawda - spokojnie można samemu ogarnąć gita. Główna zaleta gita to jego model kontroli wersji, i to można w pełni wykorzystać nawet pisząc solo - również kiedy rozwijasz kilka featureów na raz.

1

Tak, przed utworzeniem i rozpoczęciem pracy na nowym branchu, wszystkie zmiany, które aktualnie masz musisz "zacommitować". Inaczej jest spora szansa, że je stracisz.
Tworzenie branchy, nawet w jednoosobowym projekcie może mieć sens. Przykładowe scenariusze:
Masz działający projekt i chcesz, żeby on działał. Wpadasz na pomysł "użyję sobie biblioteki X, zamiast aktualnie używanej Y". Jest spora szansa, że jest to ślepa uliczka. Tworzysz gałąź, sprawdzasz, jak działa to robisz merge do głównego brancha, jak nie wyjdzie to się przestawiasz na tego głównego brancha i porzucasz swoje eksperymenty.

Masz projekt, który działa. Zaczynasz rozwijać nową funkcję. Używasz do tego rozwoju brancha. Okazuje się, że ktoś znalazł poważny błąd w tym co "działa". Robisz commity tego co rozwijasz, przełączasz się na główny branch, poprawiasz błąd, wydajesz aplikację, wracasz na swojego "rozwojowego" brancha i kontynuujesz pracę.

1 użytkowników online, w tym zalogowanych: 0, gości: 1