-
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.8 Git na strežniku - GitLab
GitLab
GitWeb je konec koncev precej enostaven. Če iščete moderen strežnik Git s polno lastnostmi, je na voljo nekaj odprtokodnih rešitev, ki jih lahko namestite namesto tega. Ker je GitLab eden izmed popularnejših, bomo kot primer šli skozi namestitev in uporabo. To je nekoliko bolj kompleksno kot opcija GitWeb in bo zahtevalo več vzdrževanja, je pa polno opremljena možnost.
Namestitev
GitLab je spletna aplikacija podprta s podatkovno bazo, torej njegova namestitev vključuje nekoliko več vključevanja kot ostali strežniki Git. Na srečo je ta proces zelo dobro dokumentiran in podprt. GitLab močno priporoča namestitev GitLaba na vaš strežnik prek uradnega paketa Omnibus GitLab.
Druge možnosti namestitve so:
-
GitLab Helm chart za uporabo s Kubernetes.
-
Dockerizirani paketi GitLab za uporabo z Dockerjem.
-
Iz izvornih datotek.
-
Ponudniki oblakov, kot so AWS, Google Cloud Platform, Azure, OpenShift in Digital Ocean.
Za več informacij preberite GitLab Community Edition (CE) readme.
Administracija
GitLabov administracijski vmesnik je dostopen preko spleta.
Enostavno pokažite svoj brskalnik na ime gostitelja ali naslov IP, kjer je GitLab nameščen, in se prijavite kot uporabnik admin.
Privzeto uporabniško ime je admin@local.host in privzeto geslo je 5iveL!fe (ki ga morate takoj spremeniti).
Ko se enkrat prijavite, kliknite na ikono »Admin area« v meniju desno zgoraj.
Uporabniki
Vsakdo, ki uporablja strežnik GitLab, mora imeti uporabniški račun.
Uporabniški računi so precej preprosti, večinoma vsebujejo osebne informacije, ki so pripete k prijavnim podatkom.
Vsak uporabniški račun prihaja z imenskim prostorom, kar je logično grupiranje projektov, ki pripadajo temu uporabniku.
Če ima uporabnik jane projekt imenovan project, je URL projekta http://server/jane/project.
Uporabnika se lahko odstrani na dva načina: »Blokiranje« uporabnika prepreči prijavo v instanco GitLab, vendar bodo vsi podatki pod uporabniškim imenskim prostorom ohranjeni in potrditve, poslane s tem uporabniškim e-naslovom, bodo še vedno povezovale njegov profil.
»Uničenje« uporabnika po drugi strani v celoti odstrani uporabnika iz podatkovne baze in datotečnega sistema. Vsi projekti in podatki v imenskem prostoru uporabnika in katerekoli skupine, ki jih imajo v lasti, bodo tudi odstranjeni. To je očitno veliko bolj dokončna in destruktivna akcija ter njene uporabe so redke.
Skupine
Skupina GitLab je zbirka projektov skupaj s podatki o tem, kako lahko uporabniki dostopajo do teh projektov.
Vsaka skupina ima imenski prostor projekta (enako, kakor imajo to uporabniki), torej če ima skupina training projekt materials, bi bil njen URL http://server/training/materials.
Vsaka skupina je povezana s številom uporabnikov, vsak od njih ima nivo pravic za skupinske projekte in samo skupino. To obsega vse od »Guest« (samo težave in pogovor) do »Owner« (poln nadzor nad skupino, njenimi člani in njenimi projekti). Tipi pravic so tukaj preveč številni za izpis, vendar GitLab ima na administracijskem zaslonu koristno povezavo.
Projekti
Projekt GitLab približno ustreza enemu repozitoriju Git. Vsak projekt pripada enemu imenskemu prostoru uporabnika ali skupine. Če projekt pripada uporabniku, ima lastnik projekta neposreden nadzor nad tem, kdo ima dostop do projekta; če projekt pripada skupini, potem bodo imele učinek tudi pravice skupinskega nivoja uporabnika.
Vsak projekt ima tudi nivo vidnosti, kar nadzira, kdo ima dostop za branje do strani in repozitorijev tega projekta.
Če je projekt zaseben, mora lastnik projekta eksplicitno odobriti dostop določenim uporabnikom.
Interni projekt je viden kateremukoli prijavljenemu uporabniku in javni projekt je viden komurkoli.
Bodite pozorni, saj to nadzira tako dostop git fetch kot tudi dostop do spletnega uporabniškega vmesnika za ta projekt.
Kljuke
GitLab vključuje podporo za kljuke tako na projektnem kot na sistemskem nivoju. Za katerokoli od teh bo strežnik GitLab izvedel HTTP POST z nekim opisnim JSON, kadarkoli se zgodi relevanten dogodek. To je odličen način za povezavo vaših repozitorijev Git in instanco GitLab z vašo preostalo avtomatizacijo, kot je strežnik CI, pogovorne sobe ali nalagalna orodja.
Osnovna uporaba
Prva stvar, ki jo boste z GitLabom želeli narediti, je ustvariti nov projekt. To se doseže s klikom na ikono »+« na orodni vrstici. Vprašani boste za ime projekta, kateremu imenskemu prostoru naj bi pripadal in kakšen nivo vidnosti bi moral imeti. Večino, česar določite tu, ni dokončno in se lahko ponovno prilagodi kasneje skozi vmesnik nastavitev. Kliknite na »Create Project« in ste opravili.
Enkrat, ko projekt obstaja, ga boste verjetno želeli povezati z lokalnim repozitorijem Git.
Vsak projekt je dostopen preko HTTPS ali SSH, katerikoli od teh se lahko uporabi za nastavitev daljave Git.
URL-ji so vidni na vrhu domače strani projekta.
Za obstoječe lokalne repozitorije ta ukaz ustvari daljavo imenovano gitlab h gostujoči lokaciji:
$ git remote add gitlab https://server/namespace/project.gitČe nimate lokalne kopije repozitorija, jo lahko enostavno naredite na naslednji način:
$ git clone https://server/namespace/project.gitSpletni UI ponuja dostop do mnogih uporabnih pogledov samega repozitorija. Vsaka domača stran projekta prikazuje zadnjo dejavnost in povezave na vrhu vas bodo peljale do pogledov projektnih datotek in dnevnika potrjevanja.
Skupno delo
Najenostavnejši način skupnega dela na projektu GitLab je dati drugemu uporabniku neposredne pravice potiskanja v repozitorij Git. Projektu lahko dodate uporabnika tako, da greste na razdelek »Members« v nastavitvah tega projekta in povežete novega uporabnika z nivojem dostopa (različni nivoji dostopa so predebatirani nekoliko v odseku Skupine). Z dajanjem uporabniku nivo dostopa »Developer« ali več, lahko ta uporabnik potiska potrditve in veje neposredno v repozitorij.
Drug bolj razvezan način sodelovanja je z uporabo zahtevkov združevanja.
Ta lastnost omogoča na nadziran način, da katerikoli uporabnik vidi projekt za sodelovanje.
Uporabniki z neposrednim dostopom lahko enostavno ustvarijo vejo, vanjo potisnejo potrditve in odprejo zahtevek združevanja iz njihove veje nazaj v master ali katerokoli drugo vejo.
Uporabniki, ki nimajo pravic potiskanja za repozitorij, lahko naredijo t. i. »vejitev« (angl. fork) in ustvarijo njihovo lastno kopijo, pošljejo potrditve v njihovo kopijo in odprejo zahtevek združevanja iz njihove vejitve nazaj v glavni projekt.
Ta model omogoča lastniku, da ima polno kontrolo nad tem, kaj gre v repozitorij in kdaj, medtem ko omogoča sodelovanje z nezaupljivimi uporabniki.
Zahtevki združevanja in težave so glavne enote dolgo živečih diskusij v GitLabu. Vsak zahtevek združevanja omogoča debato po vrsticah predlagane spremembe (kar podpira enostaven način pregleda kode), kot tudi splošno skupno nit diskusije. Oboje se lahko določi uporabniku ali organizira v mejnike.
Ta razdelek je osredotočen v glavnem na lastnosti GitLaba povezane z Gitom, vendar kot zrel projekt ponuja mnoge ostale lastnosti, ki pomagajo vaši ekipi, da dela skupaj, kot so projektni wikiji in orodja vzdrževanja sistema. Ena izmed koristi GitLaba je ta, da ko je enkrat strežnik nastavljen in v pogonu, boste redko morali prilagoditi nastavitveno datoteko ali dostop do strežnika preko SSH; večino administracije in splošne uporabe se lahko doseže preko vmesnika znotraj brskalnika.
