-
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
4.2 Git na serwerze - Uruchomienie Git na serwerze
Uruchomienie Git na serwerze
Zajmiemy się teraz skonfigurowaniem usługi Git działającej ze wspomnianymi wyżej protokołami na Twoim własnym serwerze.
Note
|
Zademonstrujemy tutaj polecenia i kroki potrzebne do wykonania podstawowych, uproszczonych instalacji na serwerze opartym na Linuksie, choć możliwe jest również uruchomienie tych usług na serwerach Mac lub Windows. Skonfigurowanie serwera produkcyjnego w ramach Twojej infrastruktury z pewnością będzie się wiązało z różnicami w środkach bezpieczeństwa lub narzędziach systemu operacyjnego, ale miejmy nadzieję, że da Ci to ogólne pojęcie o tym, które czynności są wymagane. |
Aby wstępnie skonfigurować dowolny serwer Git należy wyeksportować istniejące repozytorium jak repozytorium czyste – takie, które nie posiada katalogu roboczego. Można to zrobić w bardzo prosty sposób.
Aby sklonować repozytorium jako nowe, czyste repozytorium, należy uruchomić polecenie clone
z opcją --bare
.
Zgodnie z przyjętą konwencję, czyste repozytorium przechowywane jest w katalogu, którego nazwa kończy się na .git
, np:
$ git clone --bare my_project my_project.git
Cloning into bare repository 'my_project.git'...
done.
Teraz powinieneś mieć kopię katalogu Git w katalogu my_project.git
.
Ogólnie rzecz biorąc odpowiada to następującemu poleceniu:
$ cp -Rf my_project/.git my_project.git
Istnieje kilka różnic w pliku konfiguracyjnym; ale dla naszych celów polecenia te wykonują te same czynności. Biorą samo repozytorium Git, bez kopii roboczej i tworzą dedykowany dla niego katalog.
Umieszczanie czystego repozytorium na serwerze
Teraz, gdy posiadasz już czystą kopię repozytorium, pozostaje jedynie umieścić ją na serwerze i odpowiednio skonfigurować wybrane protokoły.
Powiedzmy, że masz serwer git.example.com
, masz do niego dostęp po SSH i chcesz, żeby wszystkie repozytoria przechowywane były w katalogu /opt/git
.
Możesz dodać nowe repozytorium kopiując tam Twoje czyste repozytorium:
$ scp -r my_project.git user@git.example.com:/opt/git
Od tej chwili inni użytkownicy, którzy mają do tego serwera dostęp SSH oraz uprawnienia do odczytu katalogu /opt/git
mogą sklonować Twoje repozytorium za pomocą:
$ git clone user@git.example.com:/opt/git/my_project.git
Jeśli użytkownik może łączyć się z serwerem za pomocą SSH i ma uprawnienia do zapisu dla katalogu /opt/git/my_project.git
, automatycznie zyskuje możliwość pchania zmian do tego repozytorium.
Git automatycznie doda do katalogu dostęp do zapisu dla grupy jeśli uruchomisz polecenie git init
z opcją --shared
.
$ ssh user@git.example.com
$ cd /opt/git/my_project.git
$ git init --bare --shared
Widać zatem, że bardzo prosto jest wziąć repozytorium Git, utworzyć jego czystą kopię i umieścić na serwerze do którego posiadasz wraz ze współpracownikami dostęp SSH. Jesteś teraz przygotowany do wspólnej pracy nad danym projektem.
Warto zaznaczyć, że to właściwie wszystko czego potrzeba, aby utworzyć działający serwer Git, do którego dostęp ma kilka osób – wystarczy utworzyć dla nich konta SSH i wstawić czyste repozytorium gdzieś, gdzie osoby te mają dostęp i uprawnienia do zapisu i odczytu. Więcej nie trzeba – można działać.
W następnych sekcjach zobaczysz jak przeprowadzić bardziej zaawansowaną konfigurację. Sprawdzimy jak uniknąć konieczności tworzenia kont użytkowników dla każdej osoby, jak dodać publiczny dostęp tylko do odczytu, jak skonfigurować interfejs WWW i inne. Miej jednak na uwadze, że do pracy nad prywatnym projektem w kilka osób, wszystko, czego potrzebujesz, to serwer z dostępem SSH i czyste repozytorium.
Prosta konfiguracja
Jeśli pracujesz w niewielkim zespole, albo testujesz Git w firmie i nie masz wielu programistów, wszystko jest proste. Jednym z najbardziej skomplikowanych aspektów konfiguracji serwera Git jest zarządzanie użytkownikami. Jeśli chcesz udostępnić niektóre repozytoria tylko do odczytu dla wybranych użytkowników, a pozwolić innym na zapis do nich, mogą pojawić się problemy z poprawną konfiguracją uprawnień.
Dostęp SSH
eśli już masz serwer, do którego wszyscy programiści mają dostęp SSH najprościej jest właśnie na nim stworzyć pierwsze repozytorium, ponieważ nie wymaga to praktycznie żadnej pracy (jak opisaliśmy to w poprzedniej sekcji). Jeśli potrzebujesz bardziej wyrafinowanej konfiguracji uprawnień dla repozytoriów możesz skorzystać z normalnych uprawnień systemu plików Twojego systemu operacyjnego.
Jeśli zamierzasz umieścić Twoje repozytoria na serwerze, w którym nie istnieją konta użytkowników dla wszystkich osób z zespołu, którym chcesz nadać uprawnienia do zapisu, będziesz musiał dodać im możliwość dostępu po SSH. Zakładamy oczywiście, że na serwerze, na którym chcesz przechowywać repozytoria Git ma już zainstalowany serwer SSH i właśnie w ten sposób uzyskujesz do niego dostęp.
Istnieje kilka sposobów pozwolenia na dostęp osobom z zespołu.
Pierwszym z nich jest utworzenie dla wszystkich kont użytkowników, co jest prostą, aczkolwiek żmudną czyunnością.
Niekoniecznie możesz mieć ochotę wywoływania wiele razy adduser
oraz ustawiania haseł tymczasowych dla każdego użytkownika.
Drugi sposób polega na utworzeniu jednego konta użytkownika git
oraz poproszeniu każdego użytkownika, który ma mieć dostęp do zapisu, by przesłał Ci swój publiczny klucz SSH.
Nadesłane klucze należy dodać do pliku ~/.ssh/authorized_keys
w katalogu domowym użytkownika git
.
Od tej chwili każda z osób będzie miała dostęp do serwera jako użytkownik git
.
Nie wpływa to w żaden sposób na dane z rewizji – użytkownik SSH, na którego się logujesz nie jest używany do generowania tych danych.
Można jeszcze skonfigurować serwer SSH tak, aby dane uwierzytelniające przechowywane były na serwerze LDAP, albo w innym miejscu do tego przeznaczonym, które możesz posiadać w firmie. Jeśli tylko użytkownik ma dostęp do powłoki systemu każdy mechanizm uwierzytelniania SSH powinien działać.