-
1. Začetek
- 1.1 O nadzoru različic
- 1.2 Kratka zgodovina Gita
- 1.3 Kaj je Git?
- 1.4 Ukazna vrstica
- 1.5 Namestitev Gita
- 1.6 Prva nastavitev Gita
- 1.7 Pridobivanje pomoči
- 1.8 Povzetek
-
2. Osnove Git
- 2.1 Pridobivanje repozitorija Git
- 2.2 Snemanje sprememb v repozitorij
- 2.3 Pregled zgodovine potrditev
- 2.4 Razveljavljanje stvari
- 2.5 Delo z daljavami
- 2.6 Označevanje
- 2.7 Aliasi Git
- 2.8 Povzetek
-
3. Veje Git
- 3.1 Veje na kratko
- 3.2 Osnove vej in združevanja
- 3.3 Upravljanje vej
- 3.4 Poteki dela z vejami
- 3.5 Oddaljene veje
- 3.6 Ponovno baziranje
- 3.7 Povzetek
-
4. Git na strežniku
- 4.1 Protokoli
- 4.2 Pridobitev Gita na strežniku
- 4.3 Generiranje vaših javnih ključev SSH
- 4.4 Nastavitev strežnika
- 4.5 Prikriti proces Git
- 4.6 Pametni HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Možnosti gostovanja pri tretjih ponudnikih
- 4.10 Povzetek
-
5. Porazdeljeni Git
- 5.1 Porazdeljeni poteki dela
- 5.2 Prispevek k projektu
- 5.3 Vzdrževanje projekta
- 5.4 Povzetek
-
6. GitHub
-
7. Orodja Git
- 7.1 Izbira revizije
- 7.2 Interaktivno pripravljanje
- 7.3 Shranjevanje na varno (angl. stashing) in čiščenje
- 7.4 Podpisovanje vašega dela
- 7.5 Iskanje
- 7.6 Prepisovanje zgodovine
- 7.7 Demistifikacija ponastavitve
- 7.8 Napredno združevanje
- 7.9 Rerere
- 7.10 Razhroščevanje z Gitom
- 7.11 Podmoduli
- 7.12 Povezovanje v pakete
- 7.13 Zamenjava
- 7.14 Shramba poverilnic
- 7.15 Povzetek
-
8. Prilagoditev Gita
- 8.1 Konfiguracija Git
- 8.2 Atributi Git
- 8.3 Kljuke Git
- 8.4 Primer pravilnika, ki ga uveljavlja Git
- 8.5 Povzetek
-
9. Git in ostali sistemi
- 9.1 Git kot odjemalec
- 9.2 Migracija na Git
- 9.3 Povzetek
-
10. Notranjost Gita
- 10.1 Napeljava in keramika
- 10.2 Objekti Git
- 10.3 Reference Git
- 10.4 Packfiles (datoteke zmanjšanih podatkov)
- 10.5 Refspec
- 10.6 Protokoli prenosa
- 10.7 Vzdrževanje in obnovitev podatkov
- 10.8 Spremenljivke okolja
- 10.9 Povzetek
-
A1. Dodatek A: Git v drugih okoljih
- A1.1 Grafični vmesniki
- A1.2 Git v Visual Studio
- A1.3 Git v Visual Studio Code
- A1.4 Git v IntelliJ / PyCharm / WebStorm / PhpStorm / RubyMine
- A1.5 Git v Sublime Text
- A1.6 Git v Bashu
- A1.7 Git v Zsh
- A1.8 Git v Powershellu
- A1.9 Povzetek
-
A2. Dodatek B: Vdelava Gita v vašo aplikacijo
- A2.1 Git v ukazni vrstici
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
- A2.5 Dulwich
-
A3. Dodatek C: Ukazi Git
- A3.1 Nastavitev in konfiguracija
- A3.2 Pridobivanje in ustvarjanje projektov
- A3.3 Osnove posnetkov
- A3.4 Veje in združevanje
- A3.5 Deljenje in posodabljanje projektov
- A3.6 Pregled in primerjava
- A3.7 Razhroščevanje
- A3.8 Popravljanje
- A3.9 E-pošta
- A3.10 Zunanji sistemi
- A3.11 Administracija
- A3.12 Orodja za sisteme napeljave
4.2 Git na strežniku - Pridobitev Gita na strežniku
Pridobitev Gita na strežniku
Sedaj bomo šli skozi nastavitve storitve Git, ki poganja te protokole na vašem lastnem strežniku.
Opomba
|
Tu bomo demonstrirali ukaze in potrebne korake za osnovne, poenostavljene namestitve na strežnikih, osnovanih na Linuxu, čeprav je možno poganjati te storitve tudi na strežnikih macOS ali Windows. V bistvu bo nastavitev produkcijskega strežnika znotraj vaše infrastrukture zagotovo povzročila razlike v varnostnih ukrepih ali orodjih operacijskih sistemov, vendar upajmo, da vam bo to dalo splošno idejo, kaj je vključeno. |
Da se začetno nastavi katerikoli strežnik Git, morate izvoziti obstoječi repozitorij v nov goli repozitorij — repozitorij, ki ne vsebuje delovnega direktorija.
To je v splošnem precej enostavno narediti.
Da klonirate svoj repozitorij, da ustvarite nov goli repozitorij, poženite ukaz kloniranja z možnostjo --bare
.
Po dogovoru se direktoriji golega repozitorija končajo z .git
:
$ git clone --bare my_project my_project.git
Cloning into bare repository 'my_project.git'...
done.
Sedaj bi morali imeti kopijo podatkov direktorija Git v vašem direktoriju my_project
.
To je v grobem enakovredno nečemu takemu:
$ cp -Rf my_project/.git my_project.git
V nastavitveni datoteki je nekaj manjših razlik; vendar za vaše namene je to blizu podobne stvari. Vzame sam repozitorij Git brez delovnega direktorija in ustvari direktorij posebej zanj.
Dodajanje golega repozitorija na strežnik
Sedaj, ko imate golo kopijo svojega repozitorija, je vse, kar morate narediti, da ga daste na strežnik in nastavite svoje protokole.
Recimo, da ste nastavili strežnik imenovan git.example.com
, do katerega imate dostop SSH, in želite shraniti vse vaše repozitorije Git pod direktorij /srv/git
.
Če predpostavljamo, da /srv/git
obstaja na tem strežniku, lahko nastavite vaš novi repozitorij s kopiranjem vašega golega repozitorija preko:
$ scp -r my_project.git user@git.example.com:/srv/git
Na tej točki lahko ostali uporabniki, ki imajo dostop SSH do istega strežnika, ki ima bralni dostop do direktorija /srv/git
, klonirajo vaš repozitorij s pogonom:
$ git clone user@git.example.com:/srv/git/my_project.git
Če se uporabnik prijavi preko SSH v strežnik in ima pisalni dostop do direktorija /srv/git/my_project.git
, bo imel avtomatično tudi dostop potiskanja.
Git bo avtomatično ustrezno dodal skupino pravic pisanja k repozitoriju, če poženete ukaz git init
z možnostjo --shared
.
Upoštevajte, saj zagon tega ukaza med postopkom ne bo uničil nobenih potrditev, referenc itd.
$ ssh user@git.example.com
$ cd /srv/git/my_project.git
$ git init --bare --shared
Vidite, kako enostavno je narediti repozitorij Git, ustvariti golo različico in ga postaviti na strežnik, do katerega imate vi in vaši sodelavci dostop preko SSH. Sedaj ste pripravljeni na sodelovanje na istem projektu.
Pomembno je omeniti, da je to dobesedno vse, kar morate pognati za uspešen strežnik Git, do katerega ima dostop več ljudi — na strežnik samo dodajte račune, ki imajo dostop SSH, in dodajte goli repozitorij nekam, da imajo vsi tisti uporabniki bralni in pisalni dostop do njega. Pripravljeni ste za pogon — nič drugega ni potrebnega.
V naslednjih nekaj razdelkih boste videli, kako to razširiti na bolj prefinjene nastavitve. Ta diskusija bo vključevala, da ni treba ustvariti uporabniških računov za vsakega uporabnika, dodajanje javnega bralnega dostopa k repozitorijem, nastavljanje spletnih uporabniških vmesnikov in več. Vendar pomnite, da za sodelovanje z več ljudmi na zasebnem projektu je vse, kar morate imeti, strežnik SSH in goli repozitorij.
Majhne nastavitve
Če gre za manjše stvari ali samo poskušate Git v vaši organizaciji in imate samo nekaj razvijalcev, so stvari lahko enostavne za vas. Eden najbolj zapletenih vidikov nastavljanja strežnika Git je upravljanje uporabnikov. Če želite, da je nekaj repozitorijev samo bralnih za določene uporabnike in bralno/pisalnih za ostale, je lahko malo bolj zahtevno urediti dostop in pravice.
Dostop SSH
Če imate strežnik, do katerega imajo dostop SSH že vsi vaši razvijalci, je v splošnem najenostavnejše nastaviti vaš prvi repozitorij tam, saj vam ni treba opraviti skoraj nič dela (kot smo pokrili v zadnjem razdelku). Če želite na svojih repozitorijih bolj kompleksen tip kontrole dostopa pravic, jih lahko upravljate z običajnimi pravicami datotečnega sistema operacijskega sistema, na katerem teče vaš strežnik.
Če želite postaviti svoje repozitorije na strežnik, ki nima računov za vsakogar v vaši ekipi, za katero želite imeti dostop pisanja, morate zanje nastaviti dostop SSH. Predpostavljamo, da če imate strežnik, s katerim to naredite, imate že nameščen strežnik SSH, in to je način, kako dostopate do strežnika.
Na voljo je nekaj načinov, na katere lahko daste dostop za vse v svoji ekipi.
Najprej se morajo nastaviti računi za vsakogar, kar je enostavno vendar okorno.
Morda ne želite poganjati adduser
(ali morebitne alternative useradd
) in nastavljati začasnih gesel za vsakega uporabnika.
Drugi način je ustvariti enega uporabnika git
na napravi, prositi vsakega uporabnika, ki bo imel pisalni dostop, da vam pošlje javni ključ SSH in dodati ta ključ v datoteko ~/.ssh/authorized_keys
vašega novega uporabnika git
.
Na tej točki bo vsak lahko dostopal do te naprave preko uporabnika git
.
To ne vpliva na podatke potrditev na kakršenkoli način — uporabnik SSH, s katerim se povezujete, ne vpliva na potrditve, ki jih snemate.
Drug način je, da mora vaš strežnik SSH overiti iz strežnika LDAP ali nekega drugega osrednjega overitvenega vira, ki ga že morda imate nastavljenega. Dokler lahko vsak uporabnik dobi lupinski dostop na napravi, bi moral delati katerikoli overitveni mehanizem SSH, ki si ga lahko zamislite.