-
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
10.5 Mechanizmy wewnętrzne w Git - Refspec
Refspec
W trakcie czytania tej książki, używałeś prostych mapowań ze zdalnych gałęzi do lokalnych referencji; jednak mogą one być znaczniej bardziej złożone. Załóżmy, że dodajesz zdalne repozytorium w taki sposób:
$ git remote add origin https://github.com/schacon/simplegit-progit
Doda to kolejną sekcję w pliku .git/config
, określającą nazwę zdalnego repozytorium (origin
), adres URL tego repozytorium, oraz refspec do pobierania:
[remote "origin"]
url = https://github.com/schacon/simplegit-progit
fetch = +refs/heads/*:refs/remotes/origin/*
Refspec składa się z opcjonalnego znaku {plus}
, oraz wskazania ścieżki źródłowej i docelowej <src>:<dst>
, gdzie <src>
wskazuje referencję na zewnętrznym serwerze, a <dst>
jest miejscem, w którym te referencje będą zapisywane lokalnie.
Znak {plus}
wskazuje Gitowi, aby wykonywał aktualizację nawet wtedy, gdy ta referencja nie jest zwykłym przesunięciem (ang. fast-forward).
W zwyczajnym przypadku, jest to zapisywane automatycznie przez komendę git remote add
, Git pobiera wszystkie referencje z refs/heads/
na serwerze i zapisuje je do refs/remotes/origin/
lokalnie.
Więc, jeżeli istnieje gałąź master
na serwerze, możesz uzyskać dostęp do logów tej gałęzi poprzez:
$ git log origin/master
$ git log remotes/origin/master
$ git log refs/remotes/origin/master
szystkie te komendy są równoważne, ponieważ Git rozwinie je wszystkie do refs/remotes/origin/master
.
Jeżeli chciałbyś, aby Git pobierał za każdym razem tylko gałąź master
, a nie wszystkie inne gałęzie na zdalnym serwerze, możesz zmienić linię fetch
na:
fetch = +refs/heads/master:refs/remotes/origin/master
Jest to po prostu domyślna definicja refspec używana przez komendę git fetch
podczas pobierania danych ze zdalnego repozytorium.
Jeżeli chcesz wykonać coś jednorazowo, możesz podać definicję refspec również z linii komend.
Aby pobrać gałąź master
z zdalnego serwera, do origin/mymaster
możesz uruchomić:
$ git fetch origin master:refs/remotes/origin/mymaster
Możesz również ustawić kilka refspec. Z linii komend, możesz pobrać kilka gałęzi za pomocą:
$ git fetch origin master:refs/remotes/origin/mymaster \
topic:refs/remotes/origin/topic
From git@github.com:schacon/simplegit
! [rejected] master -> origin/mymaster (non fast forward)
* [new branch] topic -> origin/topic
W tym wypadku, pobieranie gałęzi master
zostało odrzucone, ponieważ nie była to gałąź fast-forward (tzn. nie było możliwe wykonanie prostego przesunięcia w celu włączenia zmian).
Możesz to zmienić, poprzez ustawienie znaku {plus}
na początku definicji refspec.
Możesz również ustawić wiele definicji refspec w pliku konfiguracyjnym.
Jeżeli zawsze chcesz pobierać gałęzie master
i experiment
, dodaj dwie linie:
[remote "origin"]
url = https://github.com/schacon/simplegit-progit
fetch = +refs/heads/master:refs/remotes/origin/master
fetch = +refs/heads/experiment:refs/remotes/origin/experiment
Nie możesz użyć na ścieżkach symboli wieloznacznych z unixowego globbingu, więc takie ustawienie będzie błędne:
fetch = +refs/heads/qa*:refs/remotes/origin/qa*
Możesz jednak użyć przestrzeni nazw aby osiągnąć podobny efekt. Jeżeli masz zespół QA (ang. quality assurance, czyli zespół zapewniania jakości), który wypycha nowe gałęzie, a Ty chcesz pobrać tylko gałąź master oraz wszystkie gałęzie stworzone przez zespół QA, możesz wpisać w pliku konfiguracyjnym coś takiego:
[remote "origin"]
url = https://github.com/schacon/simplegit-progit
fetch = +refs/heads/master:refs/remotes/origin/master
fetch = +refs/heads/qa/*:refs/remotes/origin/qa/*
Jeżeli masz bardziej złożony sposób współpracy, w którym zespół QA wypycha gałęzie, programiści wypychają gałęzie, oraz zespół integrujący również wypycha oraz współpracuje ze zdalnymi gałęziami, możesz stworzyć dla każdego z nich przestrzenie nazw w ten sposób.
Wypychanie Refspecs
Fajnie, że w tym sposobem możesz pobrać referencje z konkretnych referencji, ale w jaki sposób zespół QA ma wstawiać swoje gałęzie do przestrzeni qa/
w pierwszej kolejności?
Możesz to osiągnąć, poprzez użycie refspec dla komendy push.
Jeżeli zespół QA chce wypychać swoją gałąź master
do qa/master
na zdalnym serwerze, mogą oni uruchomić:
$ git push origin master:refs/heads/qa/master
Jeżeli zechcą, aby Git robił to automatycznie za każdym razem po uruchomieniu git push origin
, mogą dodać definicję push
do swojego pliku konfiguracyjnego:
[remote "origin"]
url = https://github.com/schacon/simplegit-progit
fetch = +refs/heads/*:refs/remotes/origin/*
push = refs/heads/master:refs/heads/qa/master
I znowu, to spowoduje, że komenda git push origin
będzie domyślnie wypychała lokalną gałąź master
do zdalnej qa/master
.
Usuwanie referencji
Możesz również używać definicji refspec do usuwania referencji ze zdalnego serwera, poprzez uruchomienie komendy podobnej do:
$ git push origin :topic
Ponieważ refspec składa się z <src>:<dst>
, przez opuszczenie części <src>
, wskazujesz aby stworzyć nową pustą gałąź tematyczną, co ją kasuje.