Git - odnajdowanie się w gałęziach projektowego drzewa

Opublikowano śro 01 lipca 2020 w git • 3 min read

git-branch

System kontroli wersji jakim jest GIT (nie jest to akronim, a znaczenie tego słowa w kontekście IT jest dyskusyjne - ja trzymam się tej wersji, że jest ono połączone z brytyjskim slangiem oznaczającym bękarta - patrz wikipedia) pozwala na różne ścieżki rozwoju przygotowywanego "produktu" i najbardziej ogólnie można ująć tą kwestię stwierdzając, że może być ona liniowa (rozwój odbywa się na jedynej gałęzi (Master/Main)) jak i nieliniowa (oparta na równoległych gałęziach pobocznych tzw. niewolniczych(slave) lub też secondary). To właśnie ta druga historia rozwoju jest przedmiotem tego wpisu

Metadane

Pokaż wszystkie gałęzie

git branch -a

Wynik pokazuje te lokalne oraz remotes (-a -> all, jeśli mają być jedynie remotes to wówczas flaga -r)

Jeśli chcemy zobaczyć dokonane commity należy wpisać

git show-branch

W wyniku tego widzimy wiadomości powiązane z commitami oraz w jakich gałęziach się one znalazły

Trawersowanie

Jeśli chcemy przełączyć się na wybraną gałąź należy wpisać

git checkout <nazwa gałęzi>

Przykładowo

git checkout master

Tworzenie

Jeśli checmy stworzyć nową gałąź i się na nią również przełączyć to należy wpisać

git checkout -b <nazwa głęzi>

np.

git checkout -b issue_1.7

Jeśli chcemy stworzyć gałąź z konkretnej gałęzi wówczas należy ją wskazać po nazwie nowej gałęzi

git checkout -b <nazwa nowej gałęzi> <nazwa gałęzi, której ma wychodzić>

Przykładowo

git checkout -b issue_1.7 dev

Następnie

    git push origin < nazwa nowej gałęzi >

Usuwanie

Usuwanie gałęzi

git push origin --delete <nazwa gałęzi>

Przykładowo

git push origin --delete issue_1.5

lub jeśli jedynie lokalnie (wcześniej należy przełączyć się na inną gałąź)

git branch -d <nazwa gałęzi>

lub

git branch -D <nazwa gałęzi> // jeśli zachodzą pojawiają się ostrzeżenia ale jesteśmy pewnie swojej decyzji

>> Deleted branch issue_1.5 (was 9ef25f3).

Commit

Faza przejściowa => stage oraz komitowanie

-m -> --message/wiadomość -a -> --all wszystkie (pliki trafiają na stage/etap przejściowy )

więcej wyjaśnieni skrótów można znaleźć w explainshell

    git commit -a -m 'treść wiadomości'

alternatywnie można skorzystać z komendy -A (wymuszone all)

    git add -A

Spowoduje, że pliki, które do tej pory były edytowane (zawierają zmiany) trafią do stadium przejściowego (ich zmiana jest zauważona i odnotowana lokalnie) i wymagają wypchnięcia do remote repo jeśli mają być widoczne dla innych. Można tego dokonać poprzez...

    git commit -m "treść wiadomości"

Wizualizacja gałęzi

Wizualizacja repo przy pomocy git-grafu

    git log --all --decorate --oneline --graph

DOG

Uaktualnianie projektu lokalnego do zdalnego repo

    git fetch --all
    git pull --all

Uaktualnianie i łączenie gałęzi

Uaktualnianie gałęzi do stanu innej gałęzi można wykonać korzystając z komendy rebase (pobiera wówczas ew. zmiany np. z dałęzi głównej np. dev) lub poprzez mergowanie, dodatkowo można skorzystać z opcji --no-ff -> no fast forward.

Kolejność działania w przypadku wypychania zmian na gałąź rozwojową 1) uaktualniamy/łączymy gałąź na której pracujemy np. poprzez mergowanie do niej gałęzi rozwojowej 2) rozwiązujemy na niej ew. konflikty, jeśli wszystko działa możemy zgłosić ją do procesu recenzji (jeśli taka możliwość istnieje) 3) Gałąź rozwojową mergujemy z gałęzią, na której do tej pory pracowaliśmy

Merge

git merge <nazwa gałęzi> <nazwa gałęzi DO której ma być uaktualniona obecna>
=======
git merge feature_4.1 develop

Rebase

Rebase spowoduje, że część historii zmian zostanie stracona lub inaczej rzecz ujmując gałąź przejmująca zmiany nie przejmuje historii commitów i widoczne na niej będą jedynie te, które na niej wykonano a nie innej gałęzi - plusem jest to, że struktura jest czytelniejsza.

    git rebase <nazwa gałęzi DO której ma być uaktualniona obecna>
    ======
    git rebase develop

Fast forward vs non fast forward

Domyślnie mergowanie jest ustawione na -ff (fast forward) co oznacza - gładkie scalanie, w przypadku wykorzystania opcji --no-ff pojawia się dodatkowy węzeł wskazujący na moment połączenia się dwóch gałęzi

--no-ff -> no fast forward

git checkout <nazwa gałęzi DO której ma być dodana treść>

git merge --no-ff <nazwa gałęzi, która ma być przyłączona>

git add -A

git commit -m "treść wiadomości"

git push origin <nazwa gałęzi DO której ma być dodana treść>