Orphan branch – komu to potrzebne? A dlaczego?
Orphan (sierota) branch jest to specyficzny rodzaj brancha. Znajduje się on w naszym repozytorium, ale może on mieć całkowicie inną historię niż pozostałe branche.
Historia commitów – krótkie przypomnienie
Jak wszyscy wiemy tworząc nowe repozytorium, tworzy Nam się od razu nowy branch o nazwie master. Pierwszy commit jest specjalny, ponieważ nie posiada żadnego rodzica. Jest to tak zwany root commit. Wszystkie następne commity będą miały jakiegoś rodzica.
Większość commitów będzie miało tylko jednego rodzica, a bardzo mała liczba commitów będzie miała 2 rodziców. Chodzi o commity powstałe po operacji merge. Teoretycznie jeden commit może mieć nieskończenie wiele rodziców.
Co to jest orphan branch?
Orphan branch jest to branch z całkowicie nową historią. Tworząc go, jego historia będzie pusta. Pierwszy commit, który zostanie na nim zrobiony będzie jego root commitem.
Zastosowanie w praktyce
W tym momencie widzę 2 zastosowania takiego brancha:
- Tworzenie dokumentacji czy stronki WWW dla naszego projektu (np. korzystając z GitHub Pages), aby trzymać je w tym samym repozytorium, ale nie mieszać jej z kodem źródłowym projektu.
- Połączenie dwóch nie powiązanych ze sobą repozytoriów z różną historią.
Pierwszy przypadek zastosowania jest jasny, nie będę go więcej tłumaczył. W drugim chodzi o to, że w gicie można skopiować całe repozytorium (można nawet tylko wybrane katalogi) do innego z zachowaniem historii. W tym przypadku skopiowalibyśmy je do innego projektu, właśnie do takiego przygotowanego orphan branch. Następnie scalamy ten orphan branch z naszym branchem developerskim. W ten sposób mamy w naszym projekcie nowy kod, ale z zachowaniem jego historii z poprzedniego repozytorium.
Jak zrobić orphan branch?
git checkout --orphan <nazwa_brancha>
Wszystkie pliki z brancha z którego robiliśmy nasz nowy branch zostaną skopiowane i dodane do staging area. Skoro chcemy mieć brancha z całkowicie nową historią i innym kodem, należy te pliki usunąć:
git rm -rf .
Możemy dodać teraz pliki i zrobić pierwszy commit na tym branchu. Dodałem plik README.md i zrobiłem commit. W historii jest tylko jeden wpis.
Po wykonaniu commita widać w konsoli informację, że utworzony commit, to root-commit.
Podsumowanie
W tym wpisie pokazałem jak można zrobić orphan branch. Nie jest to wcale trudne. Taki rodzaj brancha jest bardzo rzadko wykorzystywany, ale czasem może się przydać.
Graf z początku wpisu jest zrobiony w narzędziu Visualize Git.
Źródła:
5 Komentarzy
marbel82 · 14 stycznia 2019 o 11 h 39 min
Czy mógłbyś wytłumaczyć co miałeś na myśli pisząc: “Teoretycznie jeden commit może mieć nieskończenie wiele commitów.”?
Tomasz Prasołek · 14 stycznia 2019 o 11 h 57 min
Już poprawione. Miało być “nieskończenie wiele rodziców”. Dzięki za zwrócenie uwagi.
jkwi · 22 lutego 2020 o 18 h 43 min
Orphan branch wydaje się dobrym rozwiązaniem dla projektów embedded (małych), gdzie jeden zespół utrzymuje wiele niepowiązanych ze sobą elementów projektu (albo powiązanych wyłącznie na poziomie koncepcyjnym). Mam tu na myśli projekt, który zawiera (oczywiście) kod źródłowy, a obok niego jeszcze schemat elektryczny urządzenia i projekt PCB, rysunek mechaniczny urządzenia, dokumenty techniczne np. specyfikacja, itd. Każdy z tych dodatkowych elementów może być trackowany na osobnym orphan branchu.
Viki · 20 kwietnia 2024 o 17 h 09 min
Dziękuję za opisanie tej opcji. Rzadko można trafić na jej opis, zwłaszcza po polsku.
Wypróbowałem tą opcję i jestem zaskoczony zachowaniem gita. Już tłumaczę. Mam dwie gałęzie: ‘master’ i osieroconą ‘orph_br’.
1) Zachowuję wszystko, czyli nie wykonuję “git rm -rf .”
2) Dodaję katalog z podkatalogami i plikami do gałęzi ‘orph_br’. Żeby przyspieszyć ten test, po prostu skopiowałem z jakiejś aplikacji taki katalog.
3) Zatwierdzam zamiany: “git commit -m ‘Nowy katalog z plikami’ ”
4) Przełączam się do gałęzi ‘master’.
Sprawdzam katalogi i pliki, i co? Okazuje się, że w ‘masterze’ pojawił się ten katalog z podkatalogami i z niektórymi plikami, to znaczy z tymi, które, jak zauważyłem, są uwzględnione w .gitignore za pomocą wpisu ‘pycache/’.
Spodziewałem się, że osierocona gałąź jest zupełnie samodzielnym bytem.
Czy możesz wytłumaczyć to zachowanie gita?
Z góry dzięki.
P.S. Także za artykuł – dzięki.
Tomasz Prasołek · 2 maja 2024 o 10 h 09 min
Hej
Zrobiłem tak jak napisałem w poście i … “u mnie działa” 🙂
A zrobiłeś
git add .przed punktem nr 3?Polecenie które po kolei robiłem:
1 d:
2 cd .\Projekty\
3 mkdir oprhanBranchTest
4 cd .\oprhanBranchTest\
5 git init
6 touch >> test.txt
7 echo "Test" >> test.txt
8 git status
9 git add .
10 git commit -m"Add file"
11 git lgg
12 start .
13 git status
14 git add .
15 git commit -m"Some cahnges"
16 git status
17 git add .
18 git commit -m"Some changes"
19 git checkout --orphan orphan_branch
20 git status
21 echo "new file" >> test2.txt
22 git status
23 git add .
24 git commit -m"Add new file"
25 git lgg
26 git checkout -
27 git checkout master
28 git status