-
1. Pierwsze kroki
- 1.1 Wprowadzenie do kontroli wersji
- 1.2 Krótka historia Git
- 1.3 Podstawy Git
- 1.4 Linia poleceń
- 1.5 Instalacja Git
- 1.6 Wstępna konfiguracja Git
- 1.7 Uzyskiwanie pomocy
- 1.8 Podsumowanie
-
2. Podstawy Gita
- 2.1 Pierwsze repozytorium Gita
- 2.2 Rejestrowanie zmian w repozytorium
- 2.3 Podgląd historii rewizji
- 2.4 Cofanie zmian
- 2.5 Praca ze zdalnym repozytorium
- 2.6 Tagowanie
- 2.7 Aliasy
- 2.8 Podsumowanie
-
3. Gałęzie Gita
- 3.1 Czym jest gałąź
- 3.2 Podstawy rozgałęziania i scalania
- 3.3 Zarządzanie gałęziami
- 3.4 Sposoby pracy z gałęziami
- 3.5 Gałęzie zdalne
- 3.6 Zmiana bazy
- 3.7 Podsumowanie
-
4. Git na serwerze
- 4.1 Protokoły
- 4.2 Uruchomienie Git na serwerze
- 4.3 Generowanie Twojego publicznego klucza SSH
- 4.4 Konfigurowanie serwera
- 4.5 Git Daemon
- 4.6 Smart HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Inne opcje hostowania przez podmioty zewnętrzne
- 4.10 Podsumowanie
-
5. Rozproszony Git
-
6. GitHub
-
7. Narzędzia Gita
- 7.1 Wskazywanie rewizji
- 7.2 Interaktywne używanie przechowali
- 7.3 Schowek i czyszczenie
- 7.4 Signing Your Work
- 7.5 Searching
- 7.6 Przepisywanie historii
- 7.7 Reset Demystified
- 7.8 Advanced Merging
- 7.9 Rerere
- 7.10 Debugowanie z Gitem
- 7.11 Moduły zależne
- 7.12 Bundling
- 7.13 Replace
- 7.14 Credential Storage
- 7.15 Podsumowanie
-
8. Dostosowywanie Gita
- 8.1 Konfiguracja Gita
- 8.2 Git Attributes
- 8.3 Git Hooks
- 8.4 An Example Git-Enforced Policy
- 8.5 Summary
-
9. Git i inne systemy
- 9.1 Git jako klient
- 9.2 Migracja do Gita
- 9.3 Podsumowanie
-
10. Mechanizmy wewnętrzne w Git
- 10.1 Komendy typu plumbing i porcelain
- 10.2 Obiekty Gita
- 10.3 Referencje w Git
- 10.4 Spakowane pliki (packfiles)
- 10.5 Refspec
- 10.6 Protokoły transferu
- 10.7 Konserwacja i odzyskiwanie danych
- 10.8 Environment Variables
- 10.9 Podsumowanie
-
A1. Appendix A: Git in Other Environments
- A1.1 Graphical Interfaces
- A1.2 Git in Visual Studio
- A1.3 Git in Eclipse
- A1.4 Git in Bash
- A1.5 Git in Zsh
- A1.6 Git in Powershell
- A1.7 Summary
-
A2. Appendix B: Embedding Git in your Applications
- A2.1 Command-line Git
- A2.2 Libgit2
- A2.3 JGit
-
A3. Appendix C: Git Commands
- A3.1 Setup and Config
- A3.2 Getting and Creating Projects
- A3.3 Basic Snapshotting
- A3.4 Branching and Merging
- A3.5 Sharing and Updating Projects
- A3.6 Inspection and Comparison
- A3.7 Debugging
- A3.8 Patching
- A3.9 Email
- A3.10 External Systems
- A3.11 Administration
- A3.12 Plumbing Commands
3.5 Gałęzie Gita - Gałęzie zdalne
Gałęzie zdalne
Zdalne gałęzie są odnośnikami do stanu gałęzi w zdalnym repozytorium. Są to lokalne gałęzie, których nie można zmieniać; są one modyfikowane automatycznie za każdym razem, kiedy wykonujesz jakieś operacje zdalne. Zdalne gałęzie zachowują się jak zakładki przypominające ci, gdzie znajdowały się gałęzie w Twoim zdalnym repozytorium ostatnim razem, kiedy się z nim łączyłeś.
Ich nazwy przybierają następującą formę (nazwa zdalnego repozytorium)/(nazwa gałęzi)
.
Na przykład, gdybyś chciał zobaczyć, jak wygląda gałąź master
w zdalnym repozytorium origin
z chwili, po raz ostatni się z nim komunikowałeś, musiałbyś sprawdzić gałąź origin/master
.
Jeśli na przykład pracowałeś nad zmianą wraz z partnerem który wypchnął gałąź iss53
, możesz mieć lokalną gałąź iss53
, ale gałąź na serwerze będzie wskazywała rewizję znajdującą się pod origin/iss53
.
Może być to nieco mylące, więc przyjrzyjmy się dokładniej przykładowi
Powiedzmy, że w swojej sieci masz serwer Git pod adresem git.ourcompany.com
.
Jeśli wykonasz z niego klonowanie repozytorium, komenda clone
Gita automatycznie nazwie je dla ciebie origin
, pobierze wszystkie dane, stworzy wskaźnik do miejsca gdzie znajduje się gałąź master
i nazwie ją lokalnie origin/master
.
Ponadto Git utworzy Twoją własną lokalną gałąź master
zaczynającą od tego samego miejsca, co gałąź źródła master
, więc możesz natychmiast zacząć pracę.
Note
|
“origin” nie jest wyjątkowe
Tak jak nazwa gałęzi “master” nie ma żadnego specjalnego znaczenia w Git, tak samo “origin”. “master” jest domyślną nazwą dla gałęzi początkowej kiedy wykonasz |
Jeśli wykonujesz na lokalnej gałęzi master pracę, a w międzyczasie ktoś inny wypchnie zmiany na git.ourcompany.com
oraz zaktualizuje gałąź master
, wówczas wasze historie przesuną się do przodu w różny sposób.
Co więcej, dopóki nie skontaktujesz się z serwerem zdalnym, Twój wskaźnik origin/master
nie przesunie się.
Aby zsynchronizować zmiany uruchom polecenie git fetch origin
.
Polecenie to sprawdzi który serwer to “origin” (w tym wypadku git.ourcompany.com
), pobierze z niego wszystkie dane, których jeszcze nie masz u siebie, zaktualizuje lokalną bazę, przesuwając Twój wskaźnik origin/master
na nową, bardziej aktualną pozycję.
git fetch
aktualizuje zdalne referencjeAby zademonstrować posiadanie kilku serwerów zdalnych oraz jak wyglądają gałęzie zdalne dla tych zdalnych projektów, przyjmijmy że posiadasz kolejny serwer Gita używany tylko do rozwoju przez jeden z Twoich zespołów.
Ten serwer jest pod adresem git.team1.ourcompany.com
.
Możesz dodać go jako nowe zdalne odniesienie do projektu nad którym obecnie pracujesz poprzez wykonanie komendy git remote add
jak zostało omówione w Podstawy Gita.
Nazwij to odniesienie teamone
, co będzie Twoim skrótem dla całego adresu URL.
Teraz możesz wykonać git fetch teamone
aby pobrać wszystko, co serwer teamone
posiada, a czego dotychczas nie miałeś lokalnie.
Ponieważ ten serwer posiada podzbiór danych które Twój serwer origin
ma obecnie, Git nie pobiera żadnych danych, ale tworzy gałąź zdalną o nazwie teamone/master
wskazującą na commit który teamone
ma jako gałąź master
.
teamone/master
Wypychanie
Kiedy chcesz podzielić się ze światem gałęzią, potrzebujesz wypchnąć ją na serwer, do którego posiadasz uprawnienia zapisu. Twoje lokalne gałęzie nie są automatycznie synchronizowane z serwerami do których zapisujesz dane - musisz jawnie wypchnąć gałęzie które chcesz udostępnić. Dzięki temu możesz używać lokalnych gałęzi których nie chcesz udostępniać do pracy, i wypychać tylko gałęzie nad którymi współpracujesz.
Jeśli posiadasz gałąź serverfix
nad którą chcesz pracować z innymi, możesz wypchnąć ją w taki sam sposób, jak wypchnąłeś swoją pierwszą gałąź.
Wykonaj git push (nazwa zdalnego repozytorium) (nazwa gałęzi)
:
$ git push origin serverfix
Counting objects: 24, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (15/15), done.
Writing objects: 100% (24/24), 1.91 KiB | 0 bytes/s, done.
Total 24 (delta 2), reused 0 (delta 0)
To https://github.com/schacon/simplegit
* [new branch] serverfix -> serverfix
Jest to tak naprawdę skrót.
Git automatycznie rozwija nazwę gałęzi serverfix
do refs/heads/serverfix:refs/heads/serverfix
, co oznacza “Weź moją lokalną gałąź serverfix i wypchnij ją aby zaktualizować zdalną gałąź serverfix.”
W szczegółach zajmiemy się częścią refs/heads/
w rozdziale Mechanizmy wewnętrzne w Git, aczkolwiek możesz ją teraz pominąć.
Możesz również wykonać git push origin serverfix:serverfix
, co wykonuje to samo – mówiąc, “Weź serverfix i stwórz zdalnie serverfix.”
Możesz wykorzystać ten format do wypchnięcia gałęzi lokalnej na gałąź zdalną która nazywa się inaczej.
Jeśli nie chcesz nazywać jej serverfix
na serwerze, możesz zamiast tego wykonać git push origin serverfix:awesomebranch
aby wypchnąć lokalną gałąź serverfix
na gałąź awesomebranch
w projekcie zdalnym.
Note
|
Nie wpisuj swojego hasła za każdym razem
Jeśli używasz HTTPS URL aby wypychać zmiany, serwer Git będzie pytał o Twoją nazwę użytkownika i hasło do autoryzacji. Domyślnie zapyta poprzez terminal o te informacje aby serwer mógł odpowiedzieć czy możesz wykonać wypchnięcie. Jeśli nie chcesz wpisywać tego za każdym razem kiedy wypychasz zmiany, możesz ustawić “cache danych autoryzacyjnych”. Najprościej jest je przechować w pamięci przez kilka minut, co możesz z łatwością ustawić wykonując Po więcej informacji na temat dostępnych różnych opcji cache’owania, spójrz na Credential Storage. |
Kiedy współpracownicy pobiorą następnym razem zmiany z serwera, otrzymają referencję do wersji serverfix
na serwerze pod gałęzią origin/serverfix
:
$ git fetch origin
remote: Counting objects: 7, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 3 (delta 0)
Unpacking objects: 100% (3/3), done.
From https://github.com/schacon/simplegit
* [new branch] serverfix -> origin/serverfix
Ważnym jest że gdy pobierasz zmiany które przynoszą nowe gałęzie zdalne, nie posiadasz automatycznie ich lokalnych, edytowalnych kopii.
Innymi słowy, w tym przypadku, nie posiadasz nowej gałęzi serverfix
– posiadasz tylko wskaźnik do origin/serverfix
którego nie możesz zmieniać.
Aby scalić tę pracę z Twoją obecnie wybraną gałęzią, możesz wykonać git merge origin/serverfix
.
Jeśli chcesz swoją własną gałąź serverfix
na której możesz pracować, możesz oprzeć ją o gałąź zdalną:
$ git checkout -b serverfix origin/serverfix
Branch serverfix set up to track remote branch serverfix from origin.
Switched to a new branch 'serverfix'
To daje gałąź lokalną na której można pracować, która rozpoczyna od miejsca, w którym znajduje się origin/serverfix
.
Śledzenie gałęzi
Przełączenie się na gałąź lokalną z gałęzi zdalnej automatycznie tworzy coś, co nazywane jest “gałęzią śledzącą” (lub czasami “gałęzią upstream”).
Gałęzie śledzące to lokalne gałęzie, które posiadają relację z gałęzią zdalną.
Jesli jesteś na gałęzi śledzącej i wpiszesz git pull
, Git automatycznie wie z którego serwera należy pobrać dane i zna gałąź którą należy scalić.
Kiedy klonujesz repozytorium, generalnie automatycznie tworzona jest gałąź master
która śledzi origin/master
.
Aczkolwiek, możesz ustawić inne gałęzie śledzące jeśli chcesz – takie które śledzą inne, zdalne, lub nie śledzą gałęzi master
.
Najprostszym przypadkiem jest ten która zobaczyłeś przed chwilą, wykonując git checkout -b [gałąź] [źródłozdalne]/[gałąź]
.
Jest to dość powszechna operacja do której git dokłada skrót --track
:
$ git checkout --track origin/serverfix
Branch serverfix set up to track remote branch serverfix from origin.
Switched to a new branch 'serverfix'
Aby ustawić gałąź lokalną z inną nazwą niż gałęzi zdalnej, możesz z łatwością wykorzystać pierwszą wersję z inną nazwą lokalnej gałęzi:
$ git checkout -b sf origin/serverfix
Branch sf set up to track remote branch serverfix from origin.
Switched to a new branch 'sf'
Teraz, Twoja gałąź lokalna sf
będzie automatycznie pobierać zmiany z origin/servefix
.
Jeśli masz już gałąź lokalną i chcesz ustawić jej śledzenie na gałąź zdalną z której właśnie pobrałeś zmiany, lub chcesz zmienić gałąź docelową którą śledzisz, możesz użyć opcji -u
lub --set-upstream-to
w git branch
aby jawnie ustawić ją w dowolnym momencie.
$ git branch -u origin/serverfix
Branch serverfix set up to track remote branch serverfix from origin.
Note
|
Skrót gałęzi docelowej
Jeśli masz ustawioną gałąź do śledzenia, możesz odwołać się do niej poprzez skrót |
Jeśli chcesz zobaczyć jakie gałęzie są śledzone, możesz wykorzystać opcję -vv
w git branch
. Spowoduje to wyświetlenie listy lokalnych gałęzi z większą ilością informacji, włączając w to jakie gałęzie są śledzone oraz czy gałąź lokalna jest przed, za, czy na równi z gałęzią zdalną.
$ git branch -vv
iss53 7e424c3 [origin/iss53: ahead 2] forgot the brackets
master 1ae2a45 [origin/master] deploying index fix
* serverfix f8674d9 [teamone/server-fix-good: ahead 3, behind 1] this should do it
testing 5ea463a trying something new
Możemy tu zobaczyć że nasza gałąź iss53
śledzi origin/iss53 i jest “przed” o dwa, co oznacza że mamy dwa commity lokalnie które nie są wypchnięte na serwer. Możemy również zobaczyć że nasza gałąź master
śledzi origin/master
i jest aktualna. Następnie możemy zobaczyć że nasza gałąź serverfix
śledzi gałąź server-fix-good
na serwerze teamone
i jest przed o trzy oraz za o jeden, co oznacza że jest commit na serwerze którego jeszcze nie scaliliśmy i trzy commity lokalnie których jeszcze nie wypchnęliśmy. Na koniec widzimy że nasza gałąź testing
nie śledzi żadnej gałęzi zdalnej.
Ważnym jest że te cyfry oddają stan na moment ostatniego pobrania zmian z serwera. Komenda ta nie sprawdza serwerów, mówi jedynie co zostało zapamiętane na temat serwerów lokalnie. Jeśli chcesz być zupełnie na bieżąco, musisz pobrać dane ze wszystkich zdalnych źródeł tuż przed wykonaniem tego polecenia. Możesz to osiągnąć tak: $ git fetch --all; git branch -vv
Pobieranie
Gdy komenda git fetch
pobierze wszystkie zmiany z serwera których dotychczas nie miałeś lokalnie, nie zmienia ona tak naprawdę danych projektu.
Pobiera ona jedynie dane i pozwala scalić je we własnym zakresie.
Jednakże, istnieje komenda git pull
która jest tak naprawdę komendą git fetch
za którą jest wykonana natychmiast komenda git merge
w większości przypadków.
Jeśli masz gałąź śledzącą ustawioną tak jak przedstawiono w poprzedniej sekcji, poprzez jawne ustawienie jej lub utworzenie jej przez komendy clone
lub checkout
, git pull
będzie sprawdzać jaki serwer i gałąź śledzi obecna gałąź, pobierze zmiany z tego serwera i spróbuje scalić tę zdalną gałąź.
Zazwyczaj jest lepiej po prostu użyć komend fetch
i merge
jawnie, przez wzgląd na to że magia git pull
może być często myląca.
Usuwanie zdalnych gałęzi
Załóżmy że skończyłeś pracę na gałęzią zdalną – powiedzmy że ty i Twoi współpracownicy zakończyliście pracę nad nową funkcją i scaliliście zmiany ze zdalną gałęzią główną master
(lub jakąkolwiek inną na której znajduje się stabilna wersja kodu).
Możesz usunąć zdalną gałąź wykorzystując opcję --delete
w git push
.
Jeśli chcesz usunąć Twoją gałąź serverfix
z serwera, możesz wykonać następującą komendę:
$ git push origin --delete serverfix
To https://github.com/schacon/simplegit
- [deleted] serverfix
Najprościej mówiąc usuwa to wskaźnik z serwera. Serwer Git przechowuje dane przez jakiś czas zanim sprzątanie ruszy, więc jeśli usunięcie danych było przypadkowe, zazwyczaj jest łatwe do odzyskania.