diff --git a/external/book/content/book/af/_index.html b/external/book/content/book/af/_index.html
new file mode 100644
index 0000000000..66f29e25cc
--- /dev/null
+++ b/external/book/content/book/af/_index.html
@@ -0,0 +1,4 @@
+---
+### DO NOT EDIT! Generated by script/update-book2.rb
+redirect_to: book/af/v2
+---
diff --git a/external/book/content/book/af/v1/_index.html b/external/book/content/book/af/v1/_index.html
new file mode 100644
index 0000000000..66f29e25cc
--- /dev/null
+++ b/external/book/content/book/af/v1/_index.html
@@ -0,0 +1,4 @@
+---
+### DO NOT EDIT! Generated by script/update-book2.rb
+redirect_to: book/af/v2
+---
diff --git "a/external/book/content/book/af/v2/Aan-die-slag-Die-Opdragre\303\253l.html" "b/external/book/content/book/af/v2/Aan-die-slag-Die-Opdragre\303\253l.html"
new file mode 100644
index 0000000000..665dbbcb7b
--- /dev/null
+++ "b/external/book/content/book/af/v2/Aan-die-slag-Die-Opdragre\303\253l.html"
@@ -0,0 +1,34 @@
+---
+### DO NOT EDIT! Generated by script/update-book2.rb
+category: book
+section: learn
+subsection: book
+sidebar: book
+book:
+ language_code: af
+ chapter:
+ title: Aan die slag
+ number: 1
+ section:
+ title: Die Opdragreël
+ number: 3
+ cs_number: '1.3'
+ previous: book/af/v2/Aan-die-slag-Wat-is-Git%3F
+ next: book/af/v2/Aan-die-slag-Git-Installeer
+title: Git - Die Opdragreël
+url: "/book/af/v2/Aan-die-slag-Die-Opdragreël.html"
+---
+Die Opdragreël
+
+
Daar is baie verskillende maniere om Git te gebruik.
+Daar is die oorspronklike opdragreël-nutsmiddels (command line tools), en daar is talle grafiese gebruikerskoppelvlakke (GUI’s) met verskillende vermoëns.
+In hierdie boek gaan ons Git op die opdragreël (command line) gebruik.
+Dit is omdat die opdragreël die enigste plek is waar jy alle Git-opdragte kan uitvoer – die meeste GUI’s implementeer vir die gemak van die gebruiker slegs 'n deel van Git se funksionaliteit.
+As jy die opdragreël-weergawe kan gebruik, sal jy waarskynlik ook kan aanvoel hoe om 'n GUI-weergawe te gebruik, terwyl die omgekeerde nie altyd die geval is nie.
+Ten slotte: die keuse van grafiese hulpmiddel is 'n kwessie van persoonlike smaak, terwyl alle gebruikers die opdragreël-nutsmiddels geïnstalleer het en tot hul beskikking het.
+
+
Ons gaan dus daarvan uit dat jy weet hoe om 'n rekenaar-terminaal (terminal) in macOS te open, of 'n Command Prompt of PowerShell in Windows.
+As jy nie weet waarvan ons hier praat nie, is dit dalk verstandig om hier 'n bietjie te stop en dit op te soek sodat jy die res van die voorbeelde en beskrywings in hierdie boek kan volg.
+
Git Installeer
+
+
Voordat jy Git kan begin gebruik, moet jy dit eers op jou rekenaar beskikbaar stel.
+Selfs as dit reeds geïnstalleer is, is dit waarskynlik 'n goeie idee om die nuutste weergawe te installeer.
+Jy kan dit installeer as 'n pakket of via 'n ander installeerder, of die bronkode aflaai en self verpak (compileer).
+
+
+
+|
+ Note
+ |
+
+
+ Hierdie boek is geskryf met Git weergawe 2.8.0 as uitgangspunt.
+Alhoewel die meeste opdragte wat ons gebruik selfs in baie ou weergawes van Git behoort te werk, kan sommige dalk nie werk nie of effens anders reageer as jy 'n ouer weergawe gebruik.
+Omdat Git redelik goed is in die handhawing van terugwaartse verenigbaarheid (backwards compatibility), behoort enige weergawe na 2.0 prima te werk.
+ |
+
+
+
+
Installeer op Linux
+
+
+As jy direk die Git-gereedskap op Linux wil installeer, kan jy dit oor die algemeen doen via die standaard pakketbeheerstelsel wat saam met jou verspreiding (distribution) kom.
+As jy Fedora gebruik (of 'n direkte verwante RPM-gebaseerde verspreiding (distribution), soos RHEL of CentOS), kan jy dnf gebruik:
+
+
+
+
$ sudo dnf install git-all
+
+
+
+
As jy op 'n Debian-verwante verspreiding (distribution) is, soos Ubuntu, kan jy apt probeer:
+
+
+
+
$ sudo apt install git-all
+
+
+
+
+
Installeer op macOS
+
+
+Daar is verskeie maniere om Git op 'n Mac te installeer.
+Die eenvoudigste is om die Xcode command line tools te installeer.
+Op Mavericks (10.9) of hoër kan jy dit eenvoudig doen deur git vanaf die rekenaar-terminaal (terminal) by die heel eerste geleentheid aan te roep.
+
+
+
+
As jy dit nog nie geïnstalleer het nie, sal dit jou vra om dit te installeer.
+
+
+
As jy 'n meer onlangse weergawe wil installeer, kan jy dit via 'n binêre installeerder doen.
+'n macOS Git-installeerder word onderhou en is beskikbaar vir aflaai op die Git-webblad by https://git-scm.com/download/mac.
+
+
+
+
}}" alt="Git macOS installer">
+
+
Figure 7. Git macOS installer
+
+
+
Installeer op Windows
+
+
+Daar is ook 'n aantal maniere om Git op Windows te installeer.
+Die mees amptelike weergawe is beskikbaar vir aflaai op die Git-webblad.
+Gaan net na https://git-scm.com/download/win en die aflaai sal outomaties begin.
+Let daarop dat dit 'n projek is genaamd Git for Windows, wat apart van Git self bestaan; vir meer inligting hieromtrent, gaan na https://gitforwindows.org.
+
+
+
Om 'n geoutomatiseerde installasie te verkry, kan jy die Git Chocolatey-pakket gebruik.
+Let daarop dat die Chocolatey-pakket deur vrywilligers onderhou word.
+
+
+
Installeer vanaf bronkode
+
+
Sommige mense vind dit egter nuttig om Git vanaf die bronkode te installeer, omdat jy dan die mees onlangse weergawe kry.
+Die binêre installeerders loop dikwels effens agter, alhoewel dit minder probleme oplewer omdat Git in die laaste jare behoorlik volwasse geword het.
+
+
+
As jy Git vanaf die bronkode wil installeer, moet jy die volgende biblioteke hê waarvan Git afhanklik is: autotools, curl, zlib, openssl, expat en libiconv.
+Byvoorbeeld, as jy op 'n stelsel is wat dnf het (soos Fedora) of apt-get (soos 'n Debian-gebaseerde stelsel), kan jy een van die volgende opdragte gebruik om die minimale afhanklikhede te installeer vir die verpakking en installering van die Git binêre lêers:
+
+
+
+
$ sudo dnf install dh-autoreconf curl-devel expat-devel gettext-devel \
+ openssl-devel perl-devel zlib-devel
+$ sudo apt-get install dh-autoreconf libcurl4-gnutls-dev libexpat1-dev \
+ gettext libz-dev libssl-dev
+
+
+
+
Om ook die dokumente in die verskillende formate (doc, html, info) te kan byvoeg, is hierdie bykomende afhanklikhede nodig (let wel: gebruikers van RHEL en RHEL-afgeleides soos CentOS en Scientific Linux sal die EPEL repository moet aktiveer om die docbook2X pakket te laai):
+
+
+
+
$ sudo dnf install asciidoc xmlto docbook2X
+$ sudo apt-get install asciidoc xmlto docbook2x
+
+
+
+
As jy 'n RPM-gebaseerde verspreiding (distribution) gebruik, kan jy ook die getopt pakket benodig (wat reeds op 'n Debian-gebaseerde distro geïnstalleer is):
+
+
+
+
$ sudo dnf install getopt
+$ sudo apt-get install getopt
+
+
+
+
Aanvullend, as jy Fedora/RHEL/RHEL-afgeleides gebruik, moet jy ook dit doen:
+
+
+
+
$ sudo ln -s /usr/bin/db2x_docbook2texi /usr/bin/docbook2x-texi
+
+
+
+
vanweë binêre naamsafwykings.
+
+
+
Wanneer jy alle benodigde afhanklikhede het, kan jy voortgaan en die laaste geëtiketteerde (tagged) vrystellingslêer (release tarball) van een van die vele plekke aflaai.
+Jy kan dit via die kernel.org-blad kry by https://www.kernel.org/pub/software/scm/git, of die mirror op die GitHub-webblad by https://github.com/git/git/tags.
+Dit is oor die algemeen iets duideliker aangedui wat die laaste weergawe is op die GitHub-blad, en die kernel.org-blad het ook vrystellingshandtekeninge (release signatures) as jy die afgelaaide lêer wil verifieer.
+
+
+
Daarna, verpak (compileer) en installeer:
+
+
+
+
$ tar -zxf git-2.8.0.tar.gz
+$ cd git-2.8.0
+$ make configure
+$ ./configure --prefix=/usr
+$ make all doc info
+$ sudo make install install-doc install-html install-info
+
+
+
+
As dit afgehandel is, kan jy Git ook via Git self verkry vir opdaterings:
+
+
+
+
$ git clone https://git.kernel.org/pub/scm/git/git.git
+
+
+
Git klaarmaak vir eerste gebruik
+
+
Noudat jy Git op jou rekenaar het, is dit handig om 'n paar dinge te doen om jou Git-omgewing na jou voorkeure aan te pas.
+Jy hoef hierdie instellings normaalweg net een keer te doen; hulle bly dieselfde selfs wanneer jy 'n nuwe weergawe van Git installeer.
+Jy kan dit ook op enige oomblik weer verander deur die opdragte weer uit te voer.
+
+
Git bevat standaard 'n nutsmiddel genaamd git config, waarmee jy konfigurasie-eienskappe kan bekyk en verander wat alle aspekte van die voorkoms en gedrag van Git reël.
+Hierdie eienskappe kan op drie verskillende plekke bewaar word:
+
+
+-
+
Die lêer [path]/etc/gitconfig: Bevat eienskappe vir elke gebruiker op die rekenaar en al hul bewaarplekke (repositories).
+As jy die --system opsie aan git config meegee, sal dit die konfigurasiegegewens in hierdie lêer lees en skryf.
+(Omdat dit 'n stelsel-konfigurasielêer is, moet jy administratiewe of superuser-toestemming hê om dit te kan wysig.)
+
+-
+
Die lêer ~/.gitconfig of ~/.config/git/config: Eienskappe vir jou rekening.
+Jy kan Git hierdie lêer laat lees en skryf deur die --global opsie mee te gee, en dit het gevolge vir alle bewaarplekke waarmee jy op jou stelsel werk.
+
+-
+
Die konfigurasielêer in die Git-gids (dus .git/config) van die bewaarplek wat jy op die oomblik gebruik: Spesifiek vir daardie een bewaarplek.
+Jy kan Git hierdie lêer laat lees en skryf deur die --local opsie mee te gee, maar dit is in werklikheid die standaardwaarde.
+(Nie onverwags nie: jy moet iewers in 'n Git-bewaarplek staan vir hierdie opsie om korrek te werk.)
+
+
+
+
Elke vlak het voorrang bo die vorige, dus waardes wat in .git/config gebruik word, sal in die plek van dié in [path]/etc/gitconfig gebruik word.
+
+
Op stelsels met Windows soek Git na die .gitconfig-lêer in die $HOME-gids (C:\Users\$USER vir die meeste mense).
+Dit soek ook steeds na [path]/etc/gitconfig, hoewel dit gerelateer is aan die plek waar MSys is, en dit is die plek waar jy Git op jou Windows-rekenaar geïnstalleer het.
+As jy weergawe 2.x of later van Git for Windows gebruik, is daar ook 'n stelselvlak-konfigurasielêer in C:\Documents and Settings\All Users\Application Data\Git\config op Windows XP, en in C:\ProgramData\Git\config op Windows Vista en later.
+Hierdie konfigurasielêer kan slegs gewysig word met git config -f <file> as 'n administrateur.
+
+
Jy kan al jou instellings en waar hulle vandaan kom sien met hierdie opdrag:
+
+
+
$ git config --list --show-origin
+
+
+
Jou identiteit
+
+
Die eerste ding wat jy behoort te doen nadat jy Git geïnstalleer het, is om jou gebruikersnaam en e-posadres in te vul.
+Dit is belangrik omdat elke "'n commit" in Git hierdie inligting gebruik, en dit onveranderlik ingebed sit in die commits wat jy sal gaan maak:
+
+
+
+
$ git config --global user.name "John Doe"
+$ git config --global user.email johndoe@example.com
+
+
+
+
Weereens, dit hoef jy net een keer te doen as jy die --global opsie daarby opgee, omdat Git daardie inligting sal gebruik vir alles wat jy op daardie stelsel doen.
+As jy 'n ander naam of e-posadres wil gebruik vir spesifieke projekte, kan jy die opdrag uitvoer sonder die --global opsie wanneer jy in die gids van daardie projek is.
+
+
+
Baie van die GUI-nutsmiddels sal jou help om dit te doen wanneer jy hulle die eerste keer aanroep.
+
+
+
Jou redigeerder (editor)
+
+
Noudat Git weet wie jy is, kan jy die verstek-redigeerder instel wat gebruik sal word as Git jou 'n boodskap wil laat intik.
+As dit nie ingestel is nie, gebruik Git die stelsel se verstek-redigeerder.
+
+
+
As jy 'n ander redigeerder wil gebruik, soos Emacs, kan jy die volgende doen:
+
+
+
+
$ git config --global core.editor emacs
+
+
+
+
As jy, op 'n Windows-stelsel, 'n ander teksredigeerder wil gebruik, moet jy die volledige pad na die uitvoerbare lêer (executable) invul.
+Dit kan verskil, afhangende van hoe jou redigeerder gelewer is.
+
+
+
In die geval van Notepad++, 'n gewilde redigeerder, sal jy waarskynlik die 32-bit weergawe wil gebruik, omdat — op die oomblik van skryf — nie alle inproppe (plug-ins) deur die 64-bit weergawe ondersteun word nie.
+As jy op 'n 32-bit Windows-masjien werk, of jy het 'n 64-bit redigeerder op 'n 64-bit masjien, sal jy iets soos dit tik:
+
+
+
+
$ git config --global core.editor "'C:/Program Files/Notepad++/notepad++.exe' -multiInst -nosession"
+
+
+
+
As jy 'n 32-bit redigeerder op 'n 64-bit stelsel het, word die program in C:\Program Files (x86) geïnstalleer:
+
+
+
+
$ git config --global core.editor "'C:/Program Files (x86)/Notepad++/notepad++.exe' -multiInst -nosession"
+
+
+
+
+
+|
+ Note
+ |
+
+
+ Vim, Emacs en Notepad++ is gewilde teksredigeerders wat dikwels gebruik word deur ontwikkelaars op Unix-agtige stelsels soos Linux en macOS, of 'n Windows-stelsel.
+As jy nie bekend is met hierdie redigeerders nie, sal jy dalk moet soek vir spesifieke instruksies oor hoe om jou gunsteling redigeerder vir Git in te rig.
+ |
+
+
+
+
+
+
+|
+ Warning
+ |
+
+
+ As jy jou redigeerder nie op hierdie manier inrig nie, sou dit kon gebeur dat jy erg in verwarring raak as Git dit probeer opstart.
+'n Voorbeeld op 'n Windows-stelsel sou 'n voortydig beëindigde Git-operasie kon wees tydens 'n redigering wat deur Git opgestart is.
+ |
+
+
+
+
+
Jou instellings kontroleer
+
+
As jy jou instellings wil kontroleer, kan jy die git config --list opdrag gebruik vir 'n lys met al die instellings wat Git vanaf daardie ligging kan vind:
+
+
+
+
$ git config --list
+user.name=John Doe
+user.email=johndoe@example.com
+color.status=auto
+color.branch=auto
+color.interactive=auto
+color.diff=auto
+...
+
+
+
+
Jy sal sommige sleutels dalk meermale sien verbykom, omdat Git dieselfde sleutel uit verskillende lêers gelees het (byvoorbeeld [path]/etc/gitconfig en ~/.gitconfig).
+In hierdie geval gebruik Git die laaste waarde van elke unieke sleutel wat dit teëkom.
+
+
+
Jy kan ook bekyk wat Git as instelling het by 'n spesifieke sleutel deur git config <sleutel> in te voer:
+
+
+
+
$ git config user.name
+John Doe
+
+
+
+
+
+|
+ Note
+ |
+
+
+ Omdat Git dieselfde konfigurasiewaarde kan lees vanaf meer as een lêer, is dit moontlik dat jy 'n onverwagte waarde sien vir een van hierdie waardes en jy nie weet waarom nie.
+In daardie gevalle kan jy Git vra na die oorsprong (origin) van daardie waarde, en dit sal jou vertel watter konfigurasielêer die laaste woord gehad het in die bepaling van daardie waarde:
+
+
+ $ git config --show-origin rerere.autoUpdate
+file:/home/johndoe/.gitconfig false
+
+ |
+
+
+
+
Hulp Verkry
+
+
Indien jy ooit hulp nodig het terwyl jy Git gebruik, is daar drie gelykwaardige maniere om die omvattende handleiding (manpage) vir enige van die Git-opdragte te kry:
+
+
+
$ git help <verb>
+$ git <verb> --help
+$ man git-<verb>
+
+
+
Jy kan byvoorbeeld die handleiding vir die git config-opdrag kry deur dit uit te voer:
+
+
Hierdie opdragte is uiters handig omdat jy oral toegang daartoe het, selfs al is jy vanlyn.
+Indien die handleidings en hierdie boek nie voldoende is nie en jy persoonlike hulp benodig, kan jy die #git-, #github- of #gitlab-kanale op die Libera Chat IRC-bediener probeer, wat by https://libera.chat/ gevind kan word.
+Hierdie kanale is gereeld gevul met honderde mense wat baie kundig oor Git is en dikwels bereid is om te help.
+
+
Daarbenewens, as jy nie die volledige handleiding nodig het nie, maar bloot 'n vinnige herinnering oor die beskikbare opsies vir 'n Git-opdrag soek, kan jy die meer bondige “help”-uitvoer met die -h-opsie aanvra, soos hier:
+
+
+
$ git add -h
+usage: git add [<options>] [--] <pathspec>...
+
+ -n, --dry-run dry run
+ -v, --verbose be verbose
+
+ -i, --interactive interactive picking
+ -p, --patch select hunks interactively
+ -e, --edit edit current diff and apply
+ -f, --force allow adding otherwise ignored files
+ -u, --update update tracked files
+ --renormalize renormalize EOL of tracked files (implies -u)
+ -N, --intent-to-add record only the fact that the path will be added later
+ -A, --all add changes from all tracked and untracked files
+ --ignore-removal ignore paths removed in the working tree (same as --no-all)
+ --refresh don't add, only refresh the index
+ --ignore-errors just skip files which cannot be added because of errors
+ --ignore-missing check if - even missing - files are ignored in dry run
+ --chmod (+|-)x override the executable bit of the listed files
+ --pathspec-from-file <file> read pathspec from file
+ --pathspec-file-nul with --pathspec-from-file, pathspec elements are separated with NUL character
+
+
Hierdie hoofstuk handel oor hoe om met Git aan die slag te gaan.
+Ons sal begin deur 'n bietjie agtergrondinligting oor weergawebeheerstelsels te gee, daarna oorgaan na hoe om Git op jou stelsel aan die gang te kry, en laastens hoe om dit op te stel sodat jy daarmee kan begin werk.
+Aan die einde van hierdie hoofstuk behoort jy te verstaan waarom Git bestaan, hoekom jy dit moet gebruik, en sal jy ten volle gereed wees om daarmee aan die slag te gaan.
+Oor Weergawebeheer
+
+
+Wat is “weergawebeheer”, en waarom sou jy jou daaroor bekommer?
+Weergawebeheer is 'n stelsel wat veranderinge aan 'n lêer of 'n groep lêers oor tyd aanteken sodat jy later spesifieke weergawes kan herroep.
+In die voorbeelde in hierdie boek is dit sagteware-bronkode waarvan die weergawes beheer word, maar in die praktyk kan enige tipe lêer op 'n rekenaar aan weergawebeheer onderwerp word.
+
+
As jy 'n grafiese ontwerper is of webwerwe ontwerp en elke weergawe van 'n prent of uitleg wil bewaar (wat jy byna seker sal wil doen), is dit baie verstandig om 'n weergawebeheerstelsel (Version Control System, afgekort tot VCS) te gebruik.
+Die gebruik hiervan stel jou in staat om vroeëre weergawes van lêers of die hele projek terug te kry, veranderinge tussen twee oomblikke in tyd te vergelyk, te sien wie laas iets aangepas het wat 'n probleem kon veroorsaak, wie 'n probleem veroorsaak het en wanneer, en nog baie meer.
+Die gebruik van 'n VCS beteken gewoonlik ook dat jy die situasie maklik kan terugdraai as jy 'n fout maak of lêers kwytraak.
+Daarbij kom nog dat dit alles baie min ekstra werk verg.
+
+
Plaaslike Weergawebeheerstelsels
+
+
+Baie mense se voorkeurmetode vir weergawebeheer is om lêers na 'n ander gids te kopieer (en as hulle slim is, gee hulle daardie gids ook 'n datum in die naam).
+Hierdie metode word baie gebruik omdat dit so eenvoudig is, maar dit is ook ongelooflik foutgevoelig.
+Dit is maklik om te vergeet in watter gids jy is en in die verkeerde lêer te skryf, of onbedoeld oor lêers heen te kopieer.
+
+
+
Om hierdie probleem te hanteer, het programmeerders lank gelede plaaslike VCS’e ontwikkel wat 'n eenvoudige databasis gebruik om alle veranderinge aan lêers te beheer.
+
+
+
+
}}" alt="Plaaslike weergawebeheer diagram">
+
+
Figure 1. Plaaslike weergawebeheer diagram
+
+
+
Een van die gewildste gereedskappe vir VCS was 'n stelsel genaamd RCS, wat vandag nog met baie rekenaars saamgelever word.
+RCS werk deur versamelings van patches (dit is die verskille tussen lêers) van die opvolgende lêerweergawes in 'n spesiale formaat op die hardeskyf te stoor.
+So kan jy 'n lêer reproduseer soos dit gelyk het op enige willekeurige oomblik in tyd deur al die patches bymekaar te tel.
+
+
+
Gesentraliseerde Weergawebeheerstelsels
+
+
+Die volgende belangrike uitdaging waar mense mee te doen kry, is dat hulle moet saamwerk met ontwikkelaars op ander rekenaars.
+Om hierdie uitdaging aan te gaan, het hulle Gesentraliseerde Weergawebeheerstelsels (Centralized Version Control Systems, afgekort CVCS’e) ontwikkel.
+Hierdie stelsels, soos CVS, Subversion en Perforce, het een sentrale rekenaarbediener waarop al die weergawes van die lêers staan en 'n aantal werkstasies wat die lêers daarvandaan onttrek (check out).
+Vir baie jare was dit die standaard vir weergawebeheer.
+
+
+
+
}}" alt="Gesentraliseerde weergawebeheer diagram">
+
+
Figure 2. Gesentraliseerde weergawebeheer diagram
+
+
+
Hierdie manier van weergawebeheer bied baie voordele, veral teenoor plaaslike VCS’e.
+Byvoorbeeld: almal weet, tot op sekere hoogte, wat die ander projekmedewerkers aan die doen is.
+Beheerders het 'n hoë mate van beheer oor wie wat kan doen, en dit is baie eenvoudiger om 'n CVCS te beheer as om te moet werk met plaaslike databasisse op elke werkstasie.
+
+
+
Maar helaas, hierdie metode het ook behoorlike nadele.
+Die duidelikste is die single point of failure: as die sentrale rekenaarbediener platval en 'n uur later weer terug aanlyn kom, kan niemand in daardie uur saamwerk of weergawes bewaar van die dinge waaraan hulle werk nie.
+As die hardeskyf waarop die sentrale databasis staan korrup raak en daar is geen rugsteune (backups) van nie, verloor jy werklik alles; die hele geskiedenis van die projek, op die toevallige momentopnames na wat mense op hul eie rekenaars het.
+Plaaslike VCS-stelsels het dieselfde probleem: as jy die hele geskiedenis van die projek op een enkele plek bewaar, loop jy ook kans om alles te verloor.
+
+
+
Verspreide Weergawebeheerstelsels
+
+
+En hier verskyn Verspreide Weergawebeheerstelsels (Distributed Version Control Systems, DVCS’e) ten tonele.
+In 'n DVCS (soos Git, Mercurial, Bazaar of Darcs) laai werkstasies nie bloot die nuutste momentopnames van die lêers af nie; die hele opslagplek (die bewaarplek/repository) word gekopieer.
+Dus, as 'n willekeurige rekenaarbediener uitval en hierdie stelsels het via daardie rekenaarbediener saamgewerk, dan kan die bewaarplek van enige werkstasie teruggekopieer word na die rekenaarbediener om dit te herstel.
+Elke kloon is dus in werklikheid 'n volledige rugsteun van al die data.
+
+
+
+
}}" alt="Verspreide weergawebeheer diagram">
+
+
Figure 3. Verspreide weergawebeheer diagram
+
+
+
Boonop kan baie van hierdie stelsels behoorlik goed omgaan met verskeie (afgeleë) bewaarplekke gelyktydig, sodat jy met verskillende groepe mense op verskillende maniere gelyk aan dieselfde projek kan werk.
+Hierdeur kan jy verskillende werkprosesse (workflows) soos hiërargiese modelle opsit wat nie moontlik sou gewees het met gesentraliseerde stelsels nie.
+
+
+
'n Kort geskiedenis van Git
+
+
+Soos soveel goeie dinge in die lewe, het Git begin met 'n bietjie kreatiewe vernietiging en 'n hewige polemiek.
+
+
+
Die Linux-kern (kernel) is 'n oopbron-sagtewareprojek met 'n betreklik groot omvang.
+Vir 'n lang tyd tydens die instandhouding van die Linux-kern (1991–2002), is aanpassings aan die sagteware hoofsaaklik versprei via pleisters (patches) en gearchiveerde lêers.
+In 2002 het die projek begin om 'n geslote DVCS genaamd BitKeeper te gebruik.
+
+
+
In 2005 het die verhouding tussen die gemeenskap wat die Linux-kern ontwikkel het en die kommersiële maatskappy wat BitKeeper gemaak het, verbrokkel, en die program mag nie meer gratis gebruik word nie.
+Dit was die aanleiding vir die Linux-ontwikkelingsgemeenskap (en Linus Torvalds, die skepper van Linux, in die besonder) om hul eie gereedskap te ontwikkel, gebaseer op 'n aantal lesse wat geleer is toe hulle nog BitKeeper gebruik het.
+'n Aantal van die doelwitte wat hulle vir die nuwe stelsel gehad het, was soos volg:
+
+
+
+-
+
Snelheid
+
+-
+
Eenvoudige ontwerp
+
+-
+
Goeie ondersteuning vir nie-lineêre ontwikkeling (duisende parallelle vertakkings/branches)
+
+-
+
Volledig gedistribueerd
+
+-
+
In staat om doeltreffend om te gaan met groot projekte soos die Linux-kern (wat betref spoed sowel as opslagruimte)
+
+
+
+
+
Sedert sy ontstaan in 2005 het Git gegroei tot sy huidige vorm: dit is eenvoudig om te gebruik en het tog daardie oorspronklike eienskappe behou.
+Dit is ongelooflik vinnig, enorm doeltreffend met groot projekte en besit 'n ongeëwenaarde tak-stelsel (branch-system) vir die ondersteuning van nie-lineêre ontwikkeling (sien }}">Git Branching).
+
+
Opsomming
+
+
Jy behoort nou 'n basiese begrip te hê van wat Git is en hoe dit verskil van enige gesentraliseerde weergawebeheerstelsels wat jy dalk voorheen gebruik het.
+Jy behoort nou ook 'n werkende weergawe van Git op jou stelsel te hê wat met jou persoonlike identiteit opgestel is.
+Dit is nou tyd om 'n paar van die grondbeginsels van Git te leer.
+
Wat is Git?
+
+
Dus, wat is Git in 'n neutedop?
+Dit is 'n belangrike paragraaf om in jou op te neem omdat, as jy goed verstaan wat Git is en die fondamente van sy interne werking begryp, dit baie makliker word om Git effektief te gebruik.
+Probeer, terwyl jy Git leer, om te vergeet wat jy reeds weet van ander weergawestelsels (VCSen) soos CVS, Subversion of Perforce; dit sal jou help om verwarring te voorkom wanneer jy Git gebruik as gevolg van die subtiele verskille.
+Selfs al is die gebruikerskoppelvlak van Git redelik soortgelyk aan dié van ander VCSen, stoor Git die data anders en hanteer dit die inligting op 'n fundamenteel ander manier. Om hierdie verskille te verstaan, sal jou help om verwarring tydens die gebruik daarvan te voorkom.
+
+
Momentopnames, nie verskille nie
+
+
Die grootste verskil tussen Git en enige ander VCS (insluitend Subversion en ensovoorts) is die manier waarop Git oor sy data dink.
+Konseptueel stoor die meeste ander stelsels inligting as 'n lys van veranderinge per lêer.
+Hierdie ander stelsels (CVS, Subversion, Perforce, Bazaar, ensovoorts) dink aan die inligting wat hulle stoor as 'n groep lêers en die veranderinge wat oor tyd aan elk van hierdie lêers aangebring is (dit word gewoonlik beskryf as delta-gebaseerde weergawestelsels).
+
+
+
+
}}" alt="Die stoor van data as veranderinge aan 'n basisweergawe van elke lêer">
+
+
Figure 4. Die stoor van data as veranderinge aan 'n basisweergawe van elke lêer
+
+
+
Git dink en stoor data nie op hierdie manier nie.
+Git se kyk op data kan eerder verduidelik word as 'n reeks momentopnames (snapshots) van 'n miniatuur-lêerstelsel.
+Elke keer as jy "'n commit" doen (die status van jou projek in Git stoor), neem Git as 't ware 'n foto van die toestand van al jou lêers op daardie oomblik en stoor 'n verwysing na daardie momentopname.
+Uit oogpunt van doeltreffendheid stoor Git nie ongewysigde lêers elke keer weer nie, maar slegs 'n skakel na die vorige identiese lêer wat dit reeds gestoor het.
+Git beskou data meer as 'n stroom van momentopnames.
+
+
+
+
}}" alt="Git stoor data as momentopnames van die projek oor tyd">
+
+
Figure 5. Die stoor van data as momentopnames van die projek oor tyd
+
+
+
Dit is 'n belangrike onderskeid tussen Git en byna alle ander VCSen.
+Dit het Git gedwing om byna elke aspek van weergawestelsels te heroorweeg, terwyl die meeste ander stelsels dit van vorige generasies oorgeneem het.
+Dit maak van Git eerder 'n soort mini-lêerstelsel met 'n paar ongelooflik kragtige gereedskap bo-op, in plaas van slegs 'n weergawestelsel.
+Ons sal 'n paar van die voordele wat jy kry as jy op hierdie manier oor data dink, ondersoek wanneer ons vertakkings (branching) toelig in }}">Git Branching.
+
+
+
Byna alle handelinge is lokaal
+
+
Vir die meeste handelinge in Git is slegs plaaslike lêers en hulpmiddels nodig – normaalweg is geen inligting van 'n ander rekenaar in jou netwerk nodig nie.
+As jy gewoond is aan 'n CVCS, waar die meeste handelinge vertraag word deur netwerkvertraging, sal hierdie aspek van Git jou laat dink dat die gode van spoed Git met bonatuurlike kragte geseën het.
+Omdat jy die hele geskiedenis van die projek op jou plaaslike hardeskyf het, lyk die meeste aksies byna onmiddellik.
+
+
+
Byvoorbeeld: om die geskiedenis van jou projek te deurloop, hoef Git nie by 'n afgeleë rekenaarbediener in te skakel om die geskiedenis te gaan haal en vir jou te vertoon nie; dit lees dit bloot direk vanaf jou plaaslike databasis.
+Dit beteken dat die projekgeskiedenis byna oombliklik vir jou beskikbaar is.
+As jy die veranderinge wil sien tussen die huidige weergawe van 'n lêer en die lêer van 'n maand gelede, kan Git die lêer van 'n maand gelede opsoek en plaaslik 'n verskilberekening doen, in plaas daarvan om 'n rekenaarbediener te vra om dit te doen, of om 'n ouer weergawe van die lêer vanaf 'n afgeleë rekenaarbediener te moet aflaai om dit plaaslik te doen.
+
+
+
Dit beteken ook dat daar baie min is wat jy nie kan doen as jy vanlyn is of nie op 'n VPN is nie.
+As jy in 'n vliegtuig of trein is en jy wil 'n bietjie werk, kan jy vrolik voortgaan met "'n commit" (na jou plaaslike kopie, onthou?). Wanneer jy weer by 'n netwerkverbinding uitkom, kan jy dit oplaai.
+As jy by die huis kom en jou VPN-kliënt werk nie behoorlik nie, kan jy steeds voortwerk.
+In baie ander stelsels is dit óf onmoontlik óf baie onaangenaam.
+In Perforce, byvoorbeeld, kan jy nie veel doen as jy nie met die rekenaarbediener verbind is nie; met Subversion en CVS kan jy lêers wysig, maar jy kan nie "'n commit" na jou databasis maak nie (omdat die databasis vanlyn is).
+Dit lyk dalk nie na 'n groot saak nie, maar jy sal dalk verbaas wees watter groot verskil dit kan maak.
+
+
+
Git het integriteit
+
+
Alles in Git kry 'n kontrolesom (checksum) voordat dit gestoor word en daarna word daar slegs na daardie kontrolesom verwys.
+Dit beteken dat dit onmoontlik is om die inhoud van enige lêer of gids te verander sonder dat Git daarvan weet.
+Hierdie funksionaliteit is op die laagste vlakke van Git ingebou en staan sentraal in sy filosofie.
+Jy kan nie inligting tydens oordrag verloor of lêerkorrupsie kry sonder dat Git dit kan opmerk nie.
+
+
+
Die meganisme wat Git vir hierdie kontrolesom gebruik, word 'n SHA-1-hash genoem.
+Dit is 'n string van 40 karakters, bestaande uit heksadesimale karakters (0–9 en a–f) en word bereken gebaseer op die inhoud van 'n lêer of gidsstruktuur in Git.
+'n SHA-1-hash lyk soos volg:
+
+
+
+
24b9da6552252987aa493b52f8696cd6d3b00373
+
+
+
+
Jy sal hierdie hash-waardes oral in Git teëkom omdat dit so baie daarvan gebruik maak.
+Trouens, Git stoor alles in sy databasis nie onder 'n lêernaam nie, maar deur die hash-waarde van die inhoud as sleutel te gebruik.
+
+
+
Git voeg normaalweg net data by
+
+
Byna alles wat jy in Git doen, lei tot die toevoeging van data in die Git-databasis.
+Dit is baie moeilik om die stelsel iets te laat doen wat nie ongedaan gemaak kan word nie, of om data te laat wis op enige manier.
+Soos met enige VCS kan jy veranderinge verloor of deurmekaar krap as jy dit nog nie gecommit het nie, maar sodra jy 'n momentopname in Git gecommit het, is dit baie moeilik om daardie data te verloor, veral as jy jou databasis gereeld na 'n ander bewaarplek (repository) opstoot (met push).
+
+
+
Dit maak die gebruik van Git so plesierig omdat ons weet dat ons kan eksperimenteer sonder die gevaar om dinge heeltemal op te foeter.
+Vir 'n meer diepgaande kyk na hoe Git data stoor en hoe jy data wat verlore lyk kan terughaal, sien }}">Dinge ongedaan maak.
+
+
+
Die drie toestande
+
+
Let nou goed op – dit is die belangrikste ding om van Git te onthou as jy wil hê die res van jou leerproses moet glad verloop.
+Git het drie hoof-toestande waarin lêers kan verkeer: gewysig (modified), voorbereid (staged), en gecommit (committed):
+
+
+
+-
+
Gewysig (Modified) beteken dat jy die lêer verander het, maar dit nog nie na jou databasis gecommit het nie.
+
+-
+
Voorbereid (Staged) beteken dat jy 'n gewysigde lêer in sy huidige weergawe gemerk het om in jou volgende commit-momentopname ingesluit te word.
+
+-
+
Gecommit (Committed) beteken dat die data veilig in jou plaaslike databasis gestoor is.
+
+
+
+
+
Dit bring ons by die drie hoofonderdele van 'n Git-projek: die werk-boom (working tree), die voorbereidingsarea (staging area), en die Git-gids (Git directory).
+
+
+
+
}}" alt="Werk-boom, voorbereidingsarea en Git-gids">
+
+
Figure 6. Werk-boom, voorbereidingsarea en Git-gids
+
+
+
Die werk-boom is 'n enkele uitklok van een weergawe van die projek.
+Hierdie lêers word uit die saamgeperste databasis in die Git-gids gehaal en op die hardeskyf geplaas sodat jy dit kan gebruik of wysig.
+
+
+
Die voorbereidingsarea is 'n lêer, gewoonlik vervat in jou Git-gids, wat inligting stoor oor wat in jou volgende commit sal ingaan.
+Die tegniese naam in Git-vaktaal is die “index”, maar die uitdrukking “voorbereidingsarea” werk net so goed.
+
+
+
Die Git-gids is waar Git die metadata en objekdatabasis vir jou projek stoor.
+Dit is die belangrikste deel van Git, en dit is wat gekopieer word wanneer jy 'n bewaarplek vanaf 'n ander rekenaar kloon (clone).
+
+
+
Die basiese Git-werkstroom lyk ongeveer soos volg:
+
+
+
+-
+
Jy wysig lêers in jou werk-boom.
+
+-
+
Jy berei selektief net daardie veranderinge voor wat jy deel van jou volgende commit wil maak, wat slegs daardie veranderinge by die voorbereidingsarea voeg.
+
+-
+
Jy doen "'n commit", wat die lêers neem soos hulle in die voorbereidingsarea is en daardie momentopname permanent in jou Git-gids stoor.
+
+
+
+
+
As 'n spesifieke weergawe van 'n lêer in die Git-gids is, word dit as gecommit beskou.
+As dit gewysig is en by die voorbereidingsarea gevoeg is, is dit voorbereid (staged).
+En as dit verander is sedert dit uitgeklok is, maar nie voorberei is nie, is dit gewysig (modified).
+In }}">Git Basics sal jy meer leer oor hierdie toestande en hoe jy óf daarvan gebruik kan maak óf die voorbereidingsdeel heeltemal kan oorslaan.
+
+
'n Voorbeeld van 'n Git-Afgedwonge Beleid (An Example Git-Enforced Policy)
+
+
+In hierdie afdeling sal jy gebruik wat jy geleerd het om 'n Git-werkvloei te vestig wat kyk vir 'n pasgemaakte vasleggingsboodskapformaat, en slegs sekere gebruikers toelaat om sekere subgidse in 'n projek te wysig.
+Jy sal kliëntskrippe bou wat die ontwikkelaar laat weet of hul push geweiger gaan word, en bedienerskrippe wat werklik die beleid afdwing.
+
+
Die skrippe wat ons sal wys, is in Ruby geskryf; gedeeltelik as gevolg van ons eie intelektuele traagheid, maar ook omdat Ruby maklik is om te lees, selfs al kan jy dit nie noodwendig skryf nie.
+Enige taal sal egter werk – al die voorbeeldhaakskrippe wat saam met Git versprei word, is in óf Perl óf Bash, so jy kan ook talle voorbeelde van hake in daardie tale sien deur na die voorbeelde te kyk.
+
+
Bedienerkant-haak (Server-Side Hook)
+
+
Al die bedienerkantwerk sal in die update lêer in jou hooks gids ingaan.
+Die update haak loop een keer per tak wat gepush word en neem drie argumente:
+
+
+
+-
+
Die naam van die verwysing waarna gepusht word
+
+-
+
Die ou hersiening (revision) waar daardie tak was
+
+-
+
Die nuwe hersiening wat gepusht word
+
+
+
+
+
Jy het ook toegang tot die gebruiker wat die push doen as die push oor SSH uitgevoer word.
+As jy almal toegelaat het om met 'n enkele gebruiker (soos git) via publieke-sleutel-verifikasie te verbind, moet jy dalk daardie gebruiker 'n dop-toedraaier (shell wrapper) gee wat bepaal watter gebruiker verbind op grond van die publieke sleutel, en 'n omgewingsveranderlike dienooreenkomstig stel.
+Hier sal ons aanneem dat die verbindende gebruiker in die $USER omgewingsveranderlike is, sodat jou update-skrip begin deur al die inligting wat jy nodig het, te versamel:
+
+
+
+
#!/usr/bin/env ruby
+
+$refname = ARGV[0]
+$oldrev = ARGV[1]
+$newrev = ARGV[2]
+$user = ENV['USER']
+
+puts "Enforcing Policies..."
+puts "(#{$refname}) (#{$oldrev[0,6]}) (#{$newrev[0,6]})"
+
+
+
+
Ja, dit is globale veranderlikes.
+Moenie oordeel nie – dit is makliker om dit op hierdie manier te demonstreer.
+
+
+
+
+
Jou eerste uitdaging is om af te dwing dat elke vasleggingsboodskap by 'n bepaalde formaat hou.
+Net om 'n teiken te hê, aanvaar dat elke boodskap 'n string moet insluit wat so lyk as “ref: 1234” omdat jy wil hê elke vaslegging moet skakel na 'n werkitem in jou kaartjiesisteem (ticketing system).
+Jy moet kyk na elke vaslegging wat opgestoot word, kyk of daardie string in die vasleggingsboodskap is, en, indien die string van enige van die vasleggings afwesig is, nie-nul uitstaan (exit non-zero) sodat die push geweiger word.
+
+
+
Jy kan 'n lys kry van die SHA-1 waardes van al die vasleggings wat gepusht word deur die $newrev en $oldrev waardes te neem en dit aan 'n Git-loodgietersopdrag genaamd git rev-list te gee.
+Dit is basies die git log opdrag, maar by verstek druk dit slegs die SHA-1 waardes uit en geen ander inligting nie.
+Dus, om 'n lys te kry van al die vaslegging SHA-1’s wat ingestel is tussen een vaslegging SHA-1 en 'n ander, kan jy iets soos dit uitvoer:
+
+
+
+
$ git rev-list 538c33..d14fc7
+d14fc7c847ab946ec39590d87783c69b031bdfb7
+9f585da4401b0a3999e84113824d15245c13f0be
+234071a1be950e2a8d078e6141f5cd20c1e61ad3
+dfa04c9ef3d5197182f13fb5b9b1fb7717d2222a
+17716ec0f1ff5c77eff40b7fe912f9f6cfd0e475
+
+
+
+
Jy kan daardie afvoer neem, deur elkeen van daardie vaslegging SHA-1’s loop, die boodskap daarvoor gryp, en daardie boodskap toets teen 'n gereelde uitdrukking (regular expression) wat soek na 'n patroon.
+
+
+
Jy moet uitvind hoe om die vasleggingsboodskap van elkeen van hierdie vasleggings te kry om te toets.
+Om die rou vasleggingsdata te kry, kan jy 'n ander loodgietersopdrag genaamd git cat-file gebruik.
+Ons sal in detail deur al hierdie loodgietersopdragte gaan in }}">Git Internals; maar vir eers is dit wat daardie opdrag vir jou gee:
+
+
+
+
$ git cat-file commit ca82a6
+tree cfda3bf379e4f8dba8717dee55aab78aef7f4daf
+parent 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
+author Scott Chacon <schacon@gmail.com> 1205815931 -0700
+committer Scott Chacon <schacon@gmail.com> 1240030591 -0700
+
+Change the version number
+
+
+
+
'n Eenvoudige manier om die vasleggingsboodskap van 'n vaslegging te kry wanneer jy die SHA-1 waarde het, is om na die eerste leë reël te gaan en alles daarna te neem.
+Jy kan dit doen met die sed opdrag op Unix-stelsels:
+
+
+
+
$ git cat-file commit ca82a6 | sed '1,/^$/d'
+Change the version number
+
+
+
+
Jy kan daardie beswering (incantation) gebruik om die vasleggingsboodskap te gryp van elke vaslegging wat probeer word om gepush te word en uit te staan as jy iets sien wat nie ooreenstem nie.
+Om die skrip te verlaat en die push te weiger, voer 'n nie-nul uitstaan uit.
+Die hele metode lyk soos volg:
+
+
+
+
$regex = /\[ref: (\d+)\]/
+
+# enforced custom commit message format
+def check_message_format
+ missed_revs = `git rev-list #{$oldrev}..#{$newrev}`.split("\n")
+ missed_revs.each do |rev|
+ message = `git cat-file commit #{rev} | sed '1,/^$/d'`
+ if !$regex.match(message)
+ puts "[POLICY] Your message is not formatted correctly"
+ exit 1
+ end
+ end
+end
+check_message_format
+
+
+
+
Om dit in jou update skrip te plaas, sal opdaterings verwerp wat vasleggings bevat met boodskappe wat nie by jou reël hou nie.
+
+
+
+
Afdwing van 'n Gebruikergebaseerde ACL-stelsel (Enforcing a User-Based ACL System)
+
+
Veronderstel jy wil 'n meganisme byvoeg wat 'n toegangsbeheerelys (Access Control List - ACL) gebruik wat spesifiseer watter gebruikers toegelaat word om veranderings te push na watter dele van jou projekte.
+Sommige mense het volle toegang, en ander kan slegs veranderings push na sekere subgidse of spesifieke lêers.
+Om dit af te dwing, sal jy daardie reëls skryf na 'n lêer genaamd acl wat in jou kaal (bare) Git-bewaarplek op die bediener leef.
+Jy sal hê dat die update haak na daardie reëls kyk, sien watter lêers ingestel word vir al die vasleggings wat gepusht word, en bepaal of die gebruiker wat die push doen toegang het om al daardie lêers op te dateer.
+
+
+
Die eerste ding wat jy sal doen is om jou ACL te skryf.
+Hier sal jy 'n formaat gebruik wat baie lyk soos die CVS ACL-meganisme: dit gebruik 'n reeks reëls, waar die eerste veld avail of unavail is, die volgende veld 'n kommaskeiding-lys is van die gebruikers op wie die regel van toepassing is, en die laaste veld die pad is waarop die regel van toepassing is (leeg beteken oop toegang).
+Al hierdie velde word deur 'n pyp (|) karakter geskei.
+
+
+
In hierdie geval het jy 'n paar administrateurs, 'n paar dokumentasieskrywers met toegang tot die doc gids, en een ontwikkelaar wat slegs toegang tot die lib en tests gidse het, en jou ACL-lêer lyk soos dit:
+
+
+
+
avail|nickh,pjhyett,defunkt,tpw
+avail|usinclair,cdickens,ebronte|doc
+avail|schacon|lib
+avail|schacon|tests
+
+
+
+
Jy begin deur hierdie data in 'n struktuur in te lees wat jy kan gebruik.
+In hierdie geval, om die voorbeeld eenvoudig te hou, sal jy slegs die avail direktiewe afdwing.
+Hier is 'n metode wat vir jou 'n assosiatiewe skikking (associative array) gee waar die sleutel die gebruikersnaam is en die waarde 'n skikking van paaie is waartoe die gebruiker skryftoegang het:
+
+
+
+
def get_acl_access_data(acl_file)
+ # read in ACL data
+ acl_file = File.read(acl_file).split("\n").reject { |line| line == '' }
+ access = {}
+ acl_file.each do |line|
+ avail, users, path = line.split('|')
+ next unless avail == 'avail'
+ users.split(',').each do |user|
+ access[user] ||= []
+ access[user] << path
+ end
+ end
+ access
+end
+
+
+
+
Op die ACL-lêer waarna jy vroeër gekyk het, gee hierdie get_acl_access_data metode 'n datastruktuur terug wat so lyk:
+
+
+
+
{"defunkt"=>[nil],
+ "tpw"=>[nil],
+ "nickh"=>[nil],
+ "pjhyett"=>[nil],
+ "schacon"=>["lib", "tests"],
+ "cdickens"=>["doc"],
+ "usinclair"=>["doc"],
+ "ebronte"=>["doc"]}
+
+
+
+
Noudat jy die toestemmings uitsorteer het, moet jy bepaal watter paaie die vasleggings wat gepusht word gewysig het, sodat jy seker kan maak die gebruiker wat push het toegang tot almal van hulle.
+
+
+
Jy kan baie maklik sien watter lêers in 'n enkelvoudige vaslegging gewysig is met die --name-only opsie vir die git log opdrag (kortliks genoem in }}">Git Basics):
+
+
+
+
$ git log -1 --name-only --pretty=format:'' 9f585d
+
+README
+lib/test.rb
+
+
+
+
As jy die ACL-struktuur gebruik wat van die get_acl_access_data metode teruggegee word en dit kontroleer teen die gelysde lêers in elkeen van die vasleggings, kan jy bepaal of die gebruiker toegang het om al hul vasleggings te push:
+
+
+
+
# only allows certain users to modify certain subdirectories in a project
+def check_directory_perms
+ access = get_acl_access_data('acl')
+
+ # see if anyone is trying to push something they can't
+ new_commits = `git rev-list #{$oldrev}..#{$newrev}`.split("\n")
+ new_commits.each do |rev|
+ files_modified = `git log -1 --name-only --pretty=format:'' #{rev}`.split("\n")
+ files_modified.each do |path|
+ next if path.size == 0
+ has_file_access = false
+ access[$user].each do |access_path|
+ if !access_path # user has access to everything
+ || (path.start_with? access_path) # access to this path
+ has_file_access = true
+ end
+ end
+ if !has_file_access
+ puts "[POLICY] You do not have access to push to #{path}"
+ exit 1
+ end
+ end
+ end
+end
+
+check_directory_perms
+
+
+
+
Jy kry 'n lys van nuwe vasleggings wat na jou bediener gepush word met git rev-list.
+Dan, vir elkeen van daardie vasleggings, vind jy watter lêers gewysig is en maak seker die gebruiker wat push het toegang tot al die paaie wat gewysig word.
+
+
+
Nou kan jou gebruikers nie enige vasleggings push met sleg gevormde boodskappe of met gewysigde lêers buite hul aangewese paaie nie.
+
+
+
+
Toetsing Dit Uit (Testing It Out)
+
+
As jy chmod u+x .git/hooks/update uitvoer, wat die lêer is waarin jy al hierdie kode moes geplaas het, en dan probeer om 'n vaslegging te push met 'n nie-nakomende boodskap, kry jy iets soos dit:
+
+
+
+
$ git push -f origin master
+Counting objects: 5, done.
+Compressing objects: 100% (3/3), done.
+Writing objects: 100% (3/3), 323 bytes, done.
+Total 3 (delta 1), reused 0 (delta 0)
+Unpacking objects: 100% (3/3), done.
+Enforcing Policies...
+(refs/heads/master) (8338c5) (c5b616)
+[POLICY] Your message is not formatted correctly
+error: hooks/update exited with error code 1
+error: hook declined to update refs/heads/master
+To git@gitserver:project.git
+ ! [remote rejected] master -> master (hook declined)
+error: failed to push some refs to 'git@gitserver:project.git'
+
+
+
+
Daar is 'n paar interessante dinge hier.
+Eerstens sien jy dit waar die haak begin loop.
+
+
+
+
Enforcing Policies...
+(refs/heads/master) (fb8c72) (c56860)
+
+
+
+
Onthoud dat jy dit aan die allerbegin van jou update-skrip uitgevoer (gedruk) het.
+Enigiets wat jou skrip na stdout eggo, sal na die kliënt oorgedra word.
+
+
+
Die volgende ding wat jy sal opmerk, is die foutboodskap.
+
+
+
+
[POLICY] Your message is not formatted correctly
+error: hooks/update exited with error code 1
+error: hook declined to update refs/heads/master
+
+
+
+
Die eerste reël is deur jou gedruk, die ander twee was Git wat jou vertel het dat die update-skrip nie-nul uitgestaan het en dit is wat jou push van die hand wys.
+Laastens het jy dit:
+
+
+
+
To git@gitserver:project.git
+ ! [remote rejected] master -> master (hook declined)
+error: failed to push some refs to 'git@gitserver:project.git'
+
+
+
+
Jy sal 'n remote-afgewese boodskap sien vir elke verwysing wat jou haak van die hand gewys het, en dit sê vir jou dat dit spesifiek van die hand gewys is as gevolg van 'n haakfaling.
+
+
+
Verder, as iemand probeer om 'n lêer te redigeer waartoe hulle nie toegang het nie en 'n vaslegging wat dit bevat te push, sal hulle iets soortgelyks sien.
+Byvoorbeeld, as 'n dokumentasieskrywer probeer om 'n vaslegging te push wat iets in die lib gids wysig, sien hulle:
+
+
+
+
[POLICY] You do not have access to push to lib/test.rb
+
+
+
+
Van nou af, solank daardie update skrip daar en uitvoerbaar is, sal jou bewaarplek nooit 'n vasleggingsboodskap sonder jou patroon daarin hê nie, en jou gebruikers sal in 'n sandput (sandboxed) wees.
+
+
+
+
Kliëntkant-hake (Client-Side Hooks)
+
+
Die nadeel van hierdie benadering is die gekerm wat onvermydelik sal volg wanneer jou gebruikers se vasleggingspushes geweiger word.
+Om te sien dat hul sorgvuldig vervaardigde werk op die laaste oomblik geweiger word, kan uiterst frustrerend en verwarrend wees; en bowendien sal hulle hul geskiedenis moet redigeer om dit te korrigeer, wat nie altyd vir die flouhartiges is nie.
+
+
+
Die antwoord op hierdie dilemma is om 'n paar kliëntkant-hake te verskaf wat gebruikers kan uitvoer om hulle te ken te gee wanneer hulle iets doen wat die bediener waarskynlik sal weier.
+Op daardie manier kan hulle enige probleme korrigeer voor vaslegging en voordat daardie kwessies moeiliker word om reg te maak.
+Omdat hake nie saam met 'n kloon van 'n projek oorgedra word nie, moet jy hierdie skrippe op 'n ander manier versprei en dan jou gebruikers dit na hul .git/hooks gids laat kopieer en dit uitvoerbaar maak.
+Jy kan hierdie hake binne die projek of in 'n aparte projek versprei, maar Git sal dit nie outomaties opstel nie.
+
+
+
Om te begin, moet jy jou vasleggingsboodskap net voor elke vaslegging opgeteken word, kontroleer sodat jy weet die bediener sal nie jou veranderings weier as gevolg van sleg geformatteerde vasleggingsboodskappe nie.
+Om dit te doen, kan jy die commit-msg haak byvoeg.
+As jy dit die boodskap laat lees uit die lêer wat as die eerste argument deurgegee word en dit vergelyk met die patroon, kan jy Git dwing om die vaslegging te staak as daar geen ooreenkoms is nie:
+
+
+
+
#!/usr/bin/env ruby
+message_file = ARGV[0]
+message = File.read(message_file)
+
+$regex = /\[ref: (\d+)\]/
+
+if !$regex.match(message)
+ puts "[POLICY] Your message is not formatted correctly"
+ exit 1
+end
+
+
+
+
As daardie skrip in plek is (in .git/hooks/commit-msg) en uitvoerbaar is, en jy vaslê met 'n boodskap wat nie behoorlik geformatteer is nie, sien jy dit:
+
+
+
+
$ git commit -am 'Test'
+[POLICY] Your message is not formatted correctly
+
+
+
+
Geen vaslegging is in daardie instansie voltooi nie.
+As jou boodskap egter die juiste patroon bevat, laat Git jou toe om vas te lê:
+
+
+
+
$ git commit -am 'Test [ref: 132]'
+[master e05c914] Test [ref: 132]
+ 1 file changed, 1 insertions(+), 0 deletions(-)
+
+
+
+
Vervolgens wil jy seker maak dat jy nie lêers wysig wat buite jou ACL-omvang is nie.
+As jou projek se .git gids 'n kopie bevat van die ACL-lêer wat jy vroeër gebruik het, dan sal die volgende pre-commit skrip daardie beperkings vir jou afdwing:
+
+
+
+
#!/usr/bin/env ruby
+
+$user = ENV['USER']
+
+# [ insert acl_access_data method from above ]
+
+# only allows certain users to modify certain subdirectories in a project
+def check_directory_perms
+ access = get_acl_access_data('.git/acl')
+
+ files_modified = `git diff-index --cached --name-only HEAD`.split("\n")
+ files_modified.each do |path|
+ next if path.size == 0
+ has_file_access = false
+ access[$user].each do |access_path|
+ if !access_path || (path.index(access_path) == 0)
+ has_file_access = true
+ end
+ if !has_file_access
+ puts "[POLICY] You do not have access to push to #{path}"
+ exit 1
+ end
+ end
+end
+
+check_directory_perms
+
+
+
+
Hierdie is rofweg dieselfde skrip as die bedienerkant-deel, maar met twee belangrike verskille.
+Eerstens is die ACL-lêer op 'n ander plek, omdat hierdie skrip vanaf jou werkgids loop, nie vanaf jou .git gids nie.
+Jy moet die pad na die ACL-lêer hiervan verander:
+
+
+
+
access = get_acl_access_data('acl')
+
+
+
+
+
+
access = get_acl_access_data('.git/acl')
+
+
+
+
Die ander belangrike verskil is die manier waarop jy 'n lys kry van die lêers wat verander is.
+Omdat die bedienerkant-metode na die log van vasleggings kyk, en op hierdie punt is die vaslegging nog nie opgeteken nie, moet jy jou lêerlys uit die voorbereidingsarea (staging area) in plaas daarvan kry.
+In plaas van:
+
+
+
+
files_modified = `git log -1 --name-only --pretty=format:'' #{ref}`
+
+
+
+
+
+
files_modified = `git diff-index --cached --name-only HEAD`
+
+
+
+
Maar dit is die enigste twee verskille – anders werk die skrip op dieselfde manier.
+Een voorbehoud is dat dit verwag dat jy plaaslik sal loop as dieselfde gebruiker as wat jy as op die afgeleë masjien push.
+As dit anders is, moet jy die $user veranderlike handmatig stel.
+
+
+
Nog 'n ding wat ons hier kan doen, is om seker te maak die gebruiker push nie nie-vinnig-voorwaartse verwysings (non-fast-forwarded references) nie.
+Om 'n verwysing te kry wat nie 'n vinnige-voorwaartse is nie, moet jy óf verby 'n vaslegging rebase wat jy reeds opgestoot het, of probeer om 'n ander plaaslike tak na dieselfde afgeleë tak op te stoot.
+
+
+
Vermoedelik is die bediener reeds gekonfigureer met receive.denyDeletes en receive.denyNonFastForwards om hierdie beleid af te dwing, sodat die enigste toevallige ding wat jy kan probeer vasvang, die rebase is van vasleggings wat reeds gepush is.
+
+
+
Hier is 'n voorbeeld pre-rebase skrip wat daarvoor kyk.
+Dit kry 'n lys van al die vasleggings wat jy op die punt staan om te herskryf en kyk of hulle in enige van jou afgeleë verwysings bestaan.
+As dit een sien wat bereikbaar is vanaf een van jou afgeleë verwysings, staak dit die rebase.
+
+
+
+
#!/usr/bin/env ruby
+
+base_branch = ARGV[0]
+if ARGV[1]
+ topic_branch = ARGV[1]
+else
+ topic_branch = "HEAD"
+end
+
+target_shas = `git rev-list #{base_branch}..#{topic_branch}`.split("\n")
+remote_refs = `git branch -r`.split("\n").map { |r| r.strip }
+
+target_shas.each do |sha|
+ remote_refs.each do |remote_ref|
+ shas_pushed = `git rev-list ^#{sha}^@ refs/remotes/#{remote_ref}`
+ if shas_pushed.split("\n").include?(sha)
+ puts "[POLICY] Commit #{sha} has already been pushed to #{remote_ref}"
+ exit 1
+ end
+ end
+end
+
+
+
+
+
+
`git rev-list ^#{sha}^@ refs/remotes/#{remote_ref}`
+
+
+
+
Die SHA^@ sintaksis los op na al die ouers van daardie vaslegging.
+Jy soek na enige vaslegging wat bereikbaar is vanaf die laaste vaslegging op die remote en wat nie bereikbaar is vanaf enige ouer van enige van die SHA-1’s wat jy probeer opstoot nie – wat beteken dit is 'n vinnige-voorwaartse.
+
+
+
Die belangrikste nadeel van hierdie benadering is dat dit baie stadig kan wees en dikwels onnodig is – as jy nie probeer om die push te forceer met -f nie, sal die bediener jou waarsku en nie die push aanvaar nie.
+Dit is egter 'n interessante oefening en kan in teorie help om 'n rebase te vermy wat jy dalk later sal moet teruggaan en regmaak.
+
+
Git Eienskappe (Git Attributes)
+
+
+Sommige van hierdie instellings kan ook vir 'n pad gespesifiseer word, sodat Git daardie instellings slegs vir 'n subgids of subset van lêers toepas.
+Hierdie padspesifieke instellings word Git-eienskappe genoem en word óf in 'n .gitattributes lêer in een van jou gidse (gewoonlik die wortel van jou projek) óf in die .git/info/attributes lêer gestel as jy nie wil hê die eienskaplêer moet saam met jou projek vasgelê (committed) word nie.
+
+
Deur die gebruik van eienskappe kan jy dinge doen soos om aparte saamsmeltingsstrategieë (merge strategies) vir individuele lêers of gidse in jou projek te spesifiseer, vir Git te vertel hoe om nie-tekslêers te diff, of Git die inhoud te laat filter voordat jy dit in of uit Git in- of uittrek (check in or check out).
+In hierdie afdeling sal jy leer oor sommige van die eienskappe wat jy op jou paaie in jou Git-projek kan stel en 'n paar voorbeelde sien van die gebruik van hierdie kenmerk in die praktyk.
+
+
Binêre Lêers (Binary Files)
+
+
+Een oulike truuk waarvoor jy Git-eienskappe kan gebruik, is om vir Git te sê watter lêers binêr is (in gevalle waar dit andersins dalk nie sal kan agterkom nie) en vir Git spesiale instruksies te gee oor hoe om daardie lêers te hanteer.
+Sommige tekslêers kan byvoorbeeld masjiengenererend wees en nie diff-baar wees nie, terwyl sommige binêre lêers wel diff-baar is.
+Jy sal sien hoe om vir Git te sê watter is watter.
+
+
+
Identifisering van Binêre Lêers (Identifying Binary Files)
+
+
Sommige lêers lyk soos tekslêers, maar moet vir alle praktiese doeleindes as binêre data hanteer word.
+Byvoorbeeld, Xcode-projekte op macOS bevat 'n lêer wat eindig op .pbxproj, wat basies 'n JSON (gewone teks JavaScript-dataformaat) datastel is wat na die skyf geskryf word deur die IDE, wat jou bou-instellings ensovoorts aanteken.
+Alhoewel dit tegnies 'n tekslêer is (want dit is alles UTF-8), wil jy dit nie as sodanig hanteer nie, want dit is eintlik 'n liggewig databasis – jy kan nie die inhoud saamsmelt as twee mense dit verander nie, en diffs is oor die algemeen nie nuttig nie.
+Die lêer is bedoel om deur 'n masjien verbruik te word.
+In wese wil jy dit soos 'n binêre lêer hanteer.
+
+
+
Om vir Git te sê om alle pbxproj lêers as binêre data te hanteer, voeg die volgende reël by jou .gitattributes lêer:
+
+
+
+
Nou sal Git nie probeer om CRLF kwessies te omskep of reg te maak nie; en sal ook nie probeer om 'n diff te bereken of af te druk vir veranderings in hierdie lêer wanneer jy git show of git diff op jou projek uitvoer nie.
+
+
+
+
Diffing van Binêre Lêers (Diffing Binary Files)
+
+
Jy kan ook die Git-eienskap-funksionaliteit gebruik om binêre lêers effektief te diff.
+Jy doen dit deur vir Git te sê hoe om jou binêre data om te skakel na 'n teksformaat wat via die normale diff vergelyk kan word.
+
+
+
Eerstens sal jy hierdie tegniek gebruik om een van die mees irriterende probleme wat aan die mensdom bekend is, op te los: die weergawebeheer (version-controlling) van Microsoft Word dokumente.
+As jy Word-dokumente onder weergawebeheer wil plaas, kan jy dit in 'n Git-bewaarplek steek en af en toe vaslê; maar wat help dit?
+As jy git diff normaalweg uitvoer, sien jy net so iets:
+
+
+
+
$ git diff
+diff --git a/chapter1.docx b/chapter1.docx
+index 88839c4..4afcb7c 100644
+Binary files a/chapter1.docx and b/chapter1.docx differ
+
+
+
+
Jy kan nie twee weergawes direk vergelyk nie tensy jy hulle uittrek (check out) en handmatig deurkyk, reg?
+Dit blyk dat jy dit redelik goed kan doen deur Git-eienskappe te gebruik.
+Plaas die volgende reël in jou .gitattributes lêer:
+
+
+
+
Dit vertel vir Git dat enige lêer wat ooreenstem met hierdie patroon (.docx), die “word” filter moet gebruik wanneer jy 'n diff wat veranderings bevat, probeer besigtig.
+Wat is die “word” filter?
+Jy moet dit opstel.
+Hier sal jy Git konfigureer om die docx2txt program te gebruik om Word-dokumente in leesbare tekslêers om te skakel, wat dit dan behoorlik sal diff.
+
+
+
Eerstens moet jy docx2txt installeer; jy kan dit aflaai by https://sourceforge.net/projects/docx2txt.
+Volg die instruksies in die INSTALL lêer om dit iewers te plaas waar jou dop (shell) dit kan vind.
+Volgende skryf jy 'n toedraai-skrip (wrapper script) om die afvoer om te skakel na die formaat wat Git verwag.
+Skep 'n lêer wat iewers in jou pad is genaamd docx2txt, en voeg hierdie inhoud by:
+
+
+
+
#!/bin/bash
+docx2txt.pl "$1" -
+
+
+
+
Moenie vergeet om chmod a+x op daardie lêer uit te voer nie.
+Laastens kan jy Git opstel om hierdie skrip te gebruik:
+
+
+
+
$ git config diff.word.textconv docx2txt
+
+
+
+
Nou weet Git dat as dit 'n diff tussen twee momentopnames (snapshots) probeer doen, en enige van die lêers eindig op .docx, moet dit daardie lêers deur die “word” filter hardloop, wat as die docx2txt program gedefinieer is.
+Dit maak effektief oulike teksgebaseerde weergawes van jou Word-lêers voordat dit poog om hulle te diff.
+
+
+
Hier is 'n voorbeeld: Hoofstuk 1 van hierdie boek is na Word-formaat omgeskakel en in 'n Git-bewaarplek vasgelê.
+Toe is 'n nuwe paragraaf bygevoeg.
+Hier is wat git diff wys:
+
+
+
+
$ git diff
+diff --git a/chapter1.docx b/chapter1.docx
+index 0b013ca..ba25db5 100644
+--- a/chapter1.docx
++++ b/chapter1.docx
+@@ -2,6 +2,7 @@
+ This chapter will be about getting started with Git. We will begin at the beginning by explaining some background on version control tools, then move on to how to get Git running on your system and finally how to get it setup to start working with. At the end of this chapter you should understand why Git is around, why you should use it and you should be all setup to do so.
+ 1.1. About Version Control
+ What is "version control", and why should you care? Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later. For the examples in this book you will use software source code as the files being version controlled, though in reality you can do this with nearly any type of file on a computer.
++Testing: 1, 2, 3.
+ If you are a graphic or web designer and want to keep every version of an image or layout (which you would most certainly want to), a Version Control System (VCS) is a very wise thing to use. It allows you to revert files back to a previous state, revert the entire project back to a previous state, compare changes over time, see who last modified something that might be causing a problem, who introduced an issue and when, and more. Using a VCS also generally means that if you screw things up or lose files, you can easily recover. In addition, you get all this for very little overhead.
+ 1.1.1. Local Version Control Systems
+ Many people's version-control method of choice is to copy files into another directory (perhaps a time-stamped directory, if they're clever). This approach is very common because it is so simple, but it is also incredibly error prone. It is easy to forget which directory you're in and accidentally write to the wrong file or copy over files you don't mean to.
+
+
+
+
Git vertel ons suksesvol en bondig dat ons die string “Testing: 1, 2, 3.” bygevoeg het, wat korrek is.
+Dit is nie perfek nie – formateringsveranderings sou nie hier verskyn nie – maar dit werk beslis.
+
+
+
Nog 'n interessante probleem wat jy op hierdie manier kan oplos, behels die diffing van beeldlêers.
+Een manier om dit te doen is om beeldlêers deur 'n filter te laat loop wat hul EXIF inligting onttrek – metadata wat by die meeste beeldformate aangeteken word.
+As jy die exiftool program aflaai en installeer, kan jy dit gebruik om jou beelde na teks oor die metadata om te skakel, so ten minste sal die diff vir jou 'n tekstuele verteenwoordiging wys van enige veranderings wat plaasgevind het.
+Plaas die volgende reël in jou .gitattributes lêer:
+
+
+
+
Konfigureer Git om hierdie instrument te gebruik:
+
+
+
+
$ git config diff.exif.textconv exiftool
+
+
+
+
As jy 'n beeld in jou projek vervang en git diff uitvoer, sien jy iets soos dit:
+
+
+
+
diff --git a/image.png b/image.png
+index 88839c4..4afcb7c 100644
+--- a/image.png
++++ b/image.png
+@@ -1,12 +1,12 @@
+ ExifTool Version Number : 7.74
+-File Size : 70 kB
+-File Modification Date/Time : 2009:04:21 07:02:45-07:00
++File Size : 94 kB
++File Modification Date/Time : 2009:04:21 07:02:43-07:00
+ File Type : PNG
+ MIME Type : image/png
+-Image Width : 1058
+-Image Height : 889
++Image Width : 1056
++Image Height : 827
+ Bit Depth : 8
+ Color Type : RGB with Alpha
+
+
+
+
Jy kan maklik sien dat die lêergrootte en beeldafmetings albei verander het.
+
+
+
+
Sleutelwoorduitbreiding (Keyword Expansion)
+
+
+SVN- of CVS-styl sleutelwoorduitbreiding word dikwels versoek deur ontwikkelaars wat gewoond is aan daardie stelsels.
+Die hoofprobleem hiermee in Git is dat jy nie 'n lêer met inligting oor die vaslegging kan wysig nadat jy vasgelê het nie, want Git doen eers 'n kontrolesom (checksums) van die lêer.
+Jy kan egter teks in 'n lêer inspuit wanneer dit uitgetrek word en dit weer verwyder voordat dit by 'n vaslegging gevoeg word.
+Git-eienskappe bied vir jou twee maniere om dit te doen.
+
+
+
Eerstens kan jy outomaties die SHA-1 kontrolesom van 'n blob in 'n $Id$ veld in die lêer inspuit.
+As jy hierdie eienskap op 'n lêer of stel lêers stel, sal Git die volgende keer as jy daardie tak uittrek (check out), daardie veld vervang met die SHA-1 van die blob.
+Dit is belangrik om op te let dat dit nie die SHA-1 van die vaslegging is nie, maar van die blob self.
+Plaas die volgende reël in jou .gitattributes lêer:
+
+
+
+
Voeg 'n $Id$ verwysing by 'n toetslêer:
+
+
+
+
$ echo '$Id$' > test.txt
+
+
+
+
Die volgende keer as jy hierdie lêer uittrek, spuit Git die SHA-1 van die blob in:
+
+
+
+
$ rm test.txt
+$ git checkout -- test.txt
+$ cat test.txt
+$Id: 42812b7653c7b88933f8a9d6cad0ca16714b9bb3 $
+
+
+
+
Die resultaat is egter van beperkte nut.
+As jy sleutelwoordvervanging (keyword substitution) in CVS of Subversion gebruik het, kan jy 'n datumstempel insluit – die SHA-1 is nie so nuttig nie, want dit is redelik willekeurig en jy kan nie sien of een SHA-1 ouer of nuwer as 'n ander is net deur na hulle te kyk nie.
+
+
+
+
+
}}" alt="The “smudge” filter is run on checkout">
+
+
Figure 182. Die “smudge” filter word tydens checkout uitgevoer
+
+
+
+
}}" alt="The “clean” filter is run when files are staged">
+
+
Figure 183. Die “clean” filter word uitgevoer wanneer lêers voorberei (staged) word
+
+
+
Die oorspronklike vasleggingsboodskap vir hierdie kenmerk gee 'n eenvoudige voorbeeld om al jou C-bronkode deur die indent program te laat loop voordat jy vaslê.
+Jy kan dit opstel deur die filter-eienskap in jou .gitattributes lêer te stel om \*.c lêers te filter met die “indent” filter:
+
+
+
+
Sê dan vir Git wat die “indent” filter op smudge en clean doen:
+
+
+
+
$ git config --global filter.indent.clean indent
+$ git config --global filter.indent.smudge cat
+
+
+
+
In hierdie geval, wanneer jy lêers vaslê wat by *.c pas, sal Git hulle deur die indent program laat loop voordat dit hulle voorberei (stages) en dan deur die cat program laat loop voordat dit hulle weer na die skyf uittrek.
+Die cat program doen in wese niks nie: dit spoeg dieselfde data uit wat inkom.
+Hierdie kombinasie filter effektief alle C-bronkodelêers deur indent voor dit vasgelê word.
+
+
+
Nog 'n interessante voorbeeld kry $Date$ sleutelwoorduitbreiding (keyword expansion), RCS styl.
+Om dit behoorlik te doen, het jy 'n klein skrip nodig wat 'n lêernaam neem, die laaste vasleggingsdatum vir hierdie projek uitwerk, en die datum in die lêer invoeg.
+Hier is 'n klein Ruby-skrip wat dit doen:
+
+
+
+
#! /usr/bin/env ruby
+data = STDIN.read
+last_date = `git log --pretty=format:"%ad" -1`
+puts data.gsub('$Date$', '$Date: ' + last_date.to_s + '$')
+
+
+
+
Al wat die skrip doen is om die jongste vasleggingsdatum vanaf die git log opdrag te kry, dit in enige $Date$ stringe wat dit in stdin sien in te plak, en die resultate te druk – dit behoort maklik te wees om dit te doen in watter taal jy ook al die gemaklikste mee is.
+Jy kan hierdie lêer expand_date noem en dit in jou pad plaas.
+Nou moet jy 'n filter in Git opstel (noem dit dater) en sê dat dit jou expand_date filter moet gebruik om die lêers tydens checkout te smudge.
+Jy sal 'n Perl uitdrukking (expression) gebruik om dit tydens vaslegging (commit) skoon te maak (clean):
+
+
+
+
$ git config filter.dater.smudge expand_date
+$ git config filter.dater.clean 'perl -pe "s/\\\$Date[^\\\$]*\\\$/\\\$Date\\\$/"'
+
+
+
+
Hierdie Perl-brokkie (snippet) stroop enigiets wat dit in 'n $Date$ string sien weg, om terug te kom na waar jy begin het.
+Noudat jou filter gereed is, kan jy dit toets deur 'n Git-eienskap vir daardie lêer op te stel wat die nuwe filter inwerk, en 'n lêer met jou $Date$ sleutelwoord te skep:
+
+
+
+
date*.txt filter=dater
+
+
+
+
+
$ echo '# $Date$' > date_test.txt
+
+
+
+
As jy daardie veranderings vaslê en die lêer weer uittrek, sien jy die sleutelwoord wat behoorlik vervang is:
+
+
+
+
$ git add date_test.txt .gitattributes
+$ git commit -m "Test date expansion in Git"
+$ rm date_test.txt
+$ git checkout date_test.txt
+$ cat date_test.txt
+# $Date: Tue Apr 21 07:26:52 2009 -0700$
+
+
+
+
Jy kan sien hoe kragtig hierdie tegniek vir pasgemaakte toepassings kan wees.
+Jy moet egter versigtig wees, aangesien die .gitattributes lêer vasgelê word en saam met die projek versprei word, maar die drywer (in hierdie geval, dater) word nie, so dit sal nie oral werk nie.
+Wanneer jy hierdie filters ontwerp, moet hulle in staat wees om op 'n beheerde manier te faal (fail gracefully) en die projek behoort steeds behoorlik te werk.
+
+
+
Uitvoer van Jou Bewaarplek (Exporting Your Repository)
+
+
+Git-eienskap-data laat jou ook toe om 'n paar interessante dinge te doen wanneer jy 'n argief van jou projek uitvoer (exporting).
+
+
+
export-ignore
+
+
Jy kan vir Git sê om nie sekere lêers of gidse uit te voer wanneer 'n argief gegenereer word nie.
+As daar 'n subgids of lêer is wat jy nie in jou argieflêer wil insluit nie, maar wat jy wel in jou projek ingecheck wil hê, kan jy daardie lêers bepaal via die export-ignore eienskap.
+
+
+
Sê byvoorbeeld jy het 'n paar toetslêers in 'n test/ subgids, en dit maak nie sin om dit by die tarball-uitvoer van jou projek in te sluit nie.
+Jy kan die volgende reël by jou Git-eienskappe lêer voeg:
+
+
+
+
Nou, as jy git archive uitvoer om 'n tarball van jou projek te skep, sal daardie gids nie by die argief ingesluit word nie.
+
+
+
+
export-subst
+
+
Wanneer jy lêers vir ontplooiing (deployment) uitvoer, kan jy git log se formatering en sleutelwoorduitbreiding-verwerking (keyword-expansion processing) toepas op geselekteerde gedeeltes van lêers wat met die export-subst eienskap gemerk is.
+
+
+
Byvoorbeeld, as jy 'n lêer genaamd LAST_COMMIT by jou projek wil insluit, en metadata oor die laaste vaslegging outomaties daarin wil hê sodra git archive uitgevoer word, kan jy jou .gitattributes en LAST_COMMIT lêers soos volg opstel:
+
+
+
+
LAST_COMMIT export-subst
+
+
+
+
+
$ echo 'Last commit date: $Format:%cd by %aN$' > LAST_COMMIT
+$ git add LAST_COMMIT .gitattributes
+$ git commit -am 'adding LAST_COMMIT file for archives'
+
+
+
+
Wanneer jy git archive uitvoer, sal die inhoud van die geargiveerde lêer soos volg lyk:
+
+
+
+
$ git archive HEAD | tar xCf ../deployment-testing -
+$ cat ../deployment-testing/LAST_COMMIT
+Last commit date: Tue Apr 21 08:38:48 2009 -0700 by Scott Chacon
+
+
+
+
Die vervangings kan byvoorbeeld die vasleggingsboodskap en enige git notes insluit, en git log kan eenvoudige woordomvouing (word wrapping) doen:
+
+
+
+
$ echo '$Format:Last commit: %h by %aN at %cd%n%+w(76,6,9)%B$' > LAST_COMMIT
+$ git commit -am 'export-subst uses git log'\''s custom formatter
+
+git archive uses git log'\''s `pretty=format:` processor
+directly, and strips the surrounding `$Format:` and `$`
+markup from the output.
+'
+$ git archive @ | tar xfO - LAST_COMMIT
+Last commit: 312ccc8 by Jim Hill at Fri May 8 09:14:04 2015 -0700
+ export-subst uses git log's custom formatter
+
+ git archive uses git log's `pretty=format:` processor directly, and
+ strips the surrounding `$Format:` and `$` markup from the output.
+
+
+
+
Die resulterende argief is geskik vir ontplooiingswerk, maar soos enige uitgevoerde argief is dit nie geskik vir verdere ontwikkelingswerk nie.
+
+
+
+
Saamsmeltingsstrategieë (Merge Strategies)
+
+
+Jy kan ook Git-eienskappe gebruik om vir Git te sê om verskillende saamsmeltingsstrategieë vir spesifieke lêers in jou projek te gebruik.
+Een baie nuttige opsie is om vir Git te sê om nie te probeer om spesifieke lêers saam te smelt as hulle konflikte het nie, maar eerder om jóú kant van die saamsmelting te gebruik bo iemand anders s’n.
+
+
+
Dit is nuttig as 'n tak in jou projek afgewyk het (diverged) of gespesialiseerd is, maar jy veranderings daaruit wil kan terug insmelt, en jy wil sekere lêers ignoreer.
+Sê jy het 'n databasisinstellingslêer genaamd database.xml wat in twee takke verskil, en jy wil in jou ander tak insmelt sonder om die databasislêer deurmekaar te krap.
+Jy kan 'n eienskap soos hierdie opstel:
+
+
+
+
database.xml merge=ours
+
+
+
+
En definieer dan 'n fiktiewe (dummy) ours saamsmeltingsstrategie met:
+
+
+
+
$ git config --global merge.ours.driver true
+
+
+
+
As jy die ander tak insmelt, in plaas daarvan om saamsmeltingskonflikte met die database.xml lêer te hê, sien jy so iets:
+
+
+
+
$ git merge topic
+Auto-merging database.xml
+Merge made by recursive.
+
+
+
+
In hierdie geval bly database.xml by watter weergawe jy ook al oorspronklik gehad het.
+
+
So far, we’ve covered the basics of how Git works and how to use it, and we’ve introduced a number of tools that Git provides to help you use it easily and efficiently.
+In this chapter, we’ll see how you can make Git operate in a more customized fashion, by introducing several important configuration settings and the hooks system.
+With these tools, it’s easy to get Git to work exactly the way you, your company, or your group needs it to.
+Git Konfigurasie (Git Configuration)
+
+
+Soos jy kortliks gelees het in }}">Aan die slag, kan jy Git-konfigurasie-instellings spesifiseer met die git config opdrag.
+Een van die eerste dinge wat jy gedoen het, was om jou naam en e-posadres op te stel:
+
+
+
$ git config --global user.name "John Doe"
+$ git config --global user.email johndoe@example.com
+
+
+
Nou sal jy 'n paar van die meer interessante opsies leer wat jy op hierdie manier kan stel om jou Git-gebruik te pasmaak.
+
+
Eerstens, 'n vinnige oorsig: Git gebruik 'n reeks konfigurasielêers om nie-verstekgedrag te bepaal wat jy dalk verlang.
+Die eerste plek waar Git na hierdie waardes kyk, is in die stelselbreë [path]/etc/gitconfig lêer, wat instellings bevat wat toegepas word op elke gebruiker op die stelsel en al hul bewaarplekke.
+As jy die --system opsie na git config deursgee, lees en skryf dit spesifiek van hierdie lêer af.
+
+
Die volgende plek waar Git kyk, is die ~/.gitconfig (of ~/.config/git/config) lêer, wat spesifiek vir elke gebruiker is.
+Jy kan Git laat lees en skryf na hierdie lêer deur die --global opsie deur te gee.
+
+
Laastens kyk Git vir konfigurasiewarades in die konfigurasielêer in die Git-gids (.git/config) van watter bewaarplek jy ook al tans gebruik.
+Hierdie waardes is spesifiek vir daardie enkelvoudige bewaarplek, en verteenwoordig die deurgang van die --local opsie na git config.
+As jy nie spesifiseer met watter vlak jy wil werk nie, is dit die verstek.
+
+
Elkeen van hierdie “vlakke” (system, global, local) oorskryf waardes in die vorige vlak, sodat waardes in .git/config byvoorbeeld dié in [path]/etc/gitconfig troef.
+
+
+
+|
+ Note
+ |
+
+
+ Git se konfigurasielêers is gewone tekslêers, so jy kan ook hierdie waardes stel deur die lêer handmatig te redigeer en die korrekte sintaksis in te voeg.
+Dit is oor die algemeen egter makliker om die git config opdrag uit te voer.
+ |
+
+
+
+
Basiese Kliëntkonfigurasie (Basic Client Configuration)
+
+
Die konfigurasie-opsies wat deur Git erken word, val in twee kategorieë: kliëntkant en bedienerkant.
+Die meerderheid van die opsies is kliëntkant – dit behels die konfigurasie van jou persoonlike werksvoorkeure.
+Baie, baie konfigurasie-opsies word ondersteun, maar 'n groot fraksie daarvan is slegs nuttig in sekere randgevalle; ons sal net die mees algemene en nuttige opsies hier dek.
+As jy 'n lys wil sien van al die opsies wat jou weergawe van Git erken, kan jy die volgende uitvoer:
+
+
+
+
+
+
+|
+ Note
+ |
+
+
+ Vir gevorderde gebruiksgevalle wil jy dalk na "Conditional includes" soek in die dokumentasie wat hierbo genoem is.
+ |
+
+
+
+
+
core.editor
+
+
+By verstek gebruik Git dit wat jy as jou standaard teksredigeerder gestel het via een van die dop-omgewingsveranderlikes (shell environment variables) VISUAL of EDITOR, of val anders terug op die vi redigeerder om jou vasleggings- en merkerboodskappe te skep en te redigeer.
+Om daardie verstek na iets anders te verander, kan jy die core.editor instelling gebruik:
+
+
+
+
$ git config --global core.editor emacs
+
+
+
+
Nou, ongeag wat as jou standaard dop-redigeerder gestel is, sal Git Emacs aanskakel om boodskappe te redigeer.
+
+
+
+
commit.template
+
+
+As jy dit stel op die pad van 'n lêer op jou stelsel, sal Git daardie lêer as die verstek aanvanklijke boodskap gebruik wanneer jy vaslê (commit).
+Die waarde van die skep van 'n pasgemaakte vasleggingsjabloon is dat jy dit kan gebruik om jouself (of andere) te herinner aan die korrekte formaat en styl wanneer jy 'n vasleggingsboodskap skep.
+
+
+
Oorweeg byvoorbeeld 'n sjabloonlêer by ~/.gitmessage.txt wat so lyk:
+
+
+
+
Subject line (try to keep under 50 characters)
+
+Multi-line description of commit,
+feel free to be detailed.
+
+[Ticket: X]
+
+
+
+
Let op hoe hierdie vasleggingsjabloon die vaslêer herinner om die onderwerpregel kort te hou (ter wille van git log --oneline afvoer), om verdere detail daaronder by te voeg, en om na 'n kwessie- of foutopsporingkaartjienommer (ticket number) te verwys indien een bestaan.
+
+
+
Om vir Git te sê om dit te gebruik as die verstekboodskap wat in jou redigeerder verskyn wanneer jy git commit uitvoer, stel die commit.template konfigurasiewaarde:
+
+
+
+
$ git config --global commit.template ~/.gitmessage.txt
+$ git commit
+
+
+
+
Dan sal jou redigeerder oopmaak met iets soos dit vir jou duimplaasvasleggingsboodskap wanneer jy vaslê:
+
+
+
+
Subject line (try to keep under 50 characters)
+
+Multi-line description of commit,
+feel free to be detailed.
+
+[Ticket: X]
+# Please enter the commit message for your changes. Lines starting
+# with '#' will be ignored, and an empty message aborts the commit.
+# On branch master
+# Changes to be committed:
+# (use "git reset HEAD <file>..." to unstage)
+#
+# modified: lib/test.rb
+#
+~
+~
+".git/COMMIT_EDITMSG" 14L, 297C
+
+
+
+
As jou span 'n beleid vir vasleggingsboodskappe het, dan kan die plasing van 'n sjabloon vir daardie beleid op jou stelsel en die konfigurasie van Git om dit by verstek te gebruik, help om die kans te verhoog dat daardie beleid gereeld gevolg word.
+
+
+
+
+
+
+Hierdie instelling bepaal watter blaaier (pager) gebruik word wanneer Git afvoer soos log and diff bladsy vir bladsy vertoon.
+Jy kan dit stel op more of jou gunsteling blaaier (by verstek is dit less), of jy kan dit afskakel deur dit op 'n leë string te stel:
+
+
+
+
$ git config --global core.pager ''
+
+
+
+
As jy dit uitvoer, sal Git die hele afvoer van alle opdragte druk, ongeag hoe lank dit is.
+
+
+
+
user.signingkey
+
+
+As jy getekende geannoteerde merkers maak (soos bespreek in }}">Ondertekening van Jou Werk (Signing Your Work)), maak die instelling van jou GPG-ondertekeningsleutel as 'n konfigurasie-instelling dinge makliker.
+Stel jou sleutel-ID soos volg in:
+
+
+
+
$ git config --global user.signingkey <gpg-key-id>
+
+
+
+
Nou kan jy merkers onderteken sonder om elke keer jou sleutel te hoef te spesifiseer met die git tag opdrag:
+
+
+
+
$ git tag -s <tag-name>
+
+
+
+
+
core.excludesfile
+
+
+Jy kan patrone in jou projek se .gitignore lêer plaas sodat Git hulle nie beskou as onopgespoorde lêers of probeer om hulle voorberei (stage) wanneer jy git add daarop uitvoer nie, soos bespreek in }}">Lêers ignoreer.
+
+
+
Maar soms wil jy sekere lêers vir alle bewaarplekke waarmee jy werk, ignoreer.
+As jou rekenaar macOS laat loop, is jy waarskynlik bekend met .DS_Store lêers.
+As jou voorkeurredigeerder Emacs of Vim is, ken jy lêername wat eindig op 'n ~ of .swp.
+
+
+
Hierdie instelling laat jou 'n soort globale .gitignore lêer skryf.
+As jy 'n ~/.gitignore_global lêer met hierdie inhoud skep:
+
+
+
+
…en jy voer git config --global core.excludesfile ~/.gitignore_global uit, sal Git jou nooit weer lastig val oor daardie lêers nie.
+
+
+
+
help.autocorrect
+
+
+As jy 'n opdrag verkeerd tik, wys dit vir jou iets soos dit:
+
+
+
+
$ git chekcout master
+git: 'chekcout' is not a git command. See 'git --help'.
+
+The most similar command is
+ checkout
+
+
+
+
Git probeer behulpsaam uit te vind wat jy bedoel het, maar weier steeds om dit te doen.
+As jy help.autocorrect op 1 stel, sal Git eintlik hierdie opdrag vir jou uitvoer:
+
+
+
+
$ git chekcout master
+WARNING: You called a Git command named 'chekcout', which does not exist.
+Continuing under the assumption that you meant 'checkout'
+in 0.1 seconds automatically...
+
+
+
+
Let op daardie “0.1 sekondes” besigheid.
+help.autocorrect is eintlich 'n heelgetal (integer) wat tiendes van 'n sekonde verteenwoordig.
+Dus as jy dit op 50 stel, sal Git jou 5 sekondes gee om van gedagte te verander voordat die outokorrekte opdrag uitgevoer word.
+
+
+
+
Kleure in Git (Colors in Git)
+
+
+Git ondersteun gekleurde terminaalafvoer ten volle, wat grootliks help om opdragafvoer vinnig en maklik visueel te ontleed.
+'n Aantal opsies kan jou help om die kleuring na jou voorkeur te stel.
+
+
+
color.ui
+
+
Git kleur outomaties die meeste van sy afvoer, maar daar is 'n hoofskakelaar as jy nie van hierdie gedrag hou nie.
+Om al Git se gekleurde terminaalafvoer af te skakel, doen dit:
+
+
+
+
$ git config --global color.ui false
+
+
+
+
Die verstekinstelling is auto, wat afvoer kleur wanneer dit direk na 'n terminaal gaan, maar die kleurbeheerkodes weglat wanneer die afvoer na 'n pyp (pipe) of 'n lêer omgeleid word.
+
+
+
Jy kan dit ook stel op always om die verskil tussen terminale en pype te ignoreer.
+Jy sal dit selde wil hê; in die meeste scenario’s, as jy kleurkodes in jou omgeleide afvoer wil hê, kan jy in plaas daarvan 'n --color vlag na die Git-opdrag deursgee om dit te dwing om kleurkodes te gebruik.
+Die verstekinstelling is byna altyd dit wat jy sal wil hê.
+
+
+
+
color.*
+
+
As jy meer spesifiek wil wees oor watter opdragte gekleur word en hoe, bied Git werkwoordspesifieke kleurinstellings.
+Elkeen hiervan kan gestel word op true, false, of always:
+
+
+
+
color.branch
+color.diff
+color.interactive
+color.status
+
+
+
+
Daarbenewens het elkeen hiervan subinstellings wat jy kan gebruik om spesifieke kleure vir dele van die afvoer te stel, as jy elke kleur wil oorskryf.
+Byvoorbeeld, om die metainligting in jou diff-afvoer te stel op blou voorgrond, swart agtergrond en vetgedrukte teks, kan jy die volgende uitvoer:
+
+
+
+
$ git config --global color.diff.meta "blue black bold"
+
+
+
+
Jy kan die kleur stel op enige van die volgende waardes: normal, black, red, green, yellow, blue, magenta, cyan, of white.
+As jy 'n eienskap soos vetgedruk (bold) in die vorige voorbeeld wil hê, kan jy kies uit bold, dim, ul (onderstreep), blink, en reverse (omruil voor- en agtergrond).
+
+
+
+
+
+
+Alhoewel Git 'n interne implementering van diff het, wat is wat ons in hierdie boek gewys het, kan jy in plaas daarvan 'n eksterne hulpmiddel opstel.
+Jy kan ook 'n grafiese saamsmeltingskonflik-oplosmiddel opstel in plaas daarvan om konflikte handmatig te moet oplos.
+Ons sal die opstel van die Perforce Visual Merge Tool (P4Merge) demonstreer om jou diffs en saamsmeltingsresolusies te doen, omdat dit 'n oulike grafiese hulpmiddel is en dit gratis is.
+
+
+
As jy dit wil uitprobeer, P4Merge werk op alle groot platforms, so jy behoort dit te kan doen.
+Ons sal padname in die voorbeelde gebruik wat op macOS- en Linux-stelsels werk; vir Windows sal jy /usr/local/bin moet verander na 'n uitvoerbare pad in jou omgewing.
+
+
+
Om te begin, laai P4Merge af van Perforce.
+Volgende sal jy eksterne toedraai-skripte (wrapper scripts) opstel om jou opdragte uit te voer.
+Ons sal die macOS-pad vir die uitvoerbare lêer gebruik; in ander stelsels sal dit wees waar jou p4merge binêre lêer geïnstalleer is.
+Stel 'n samesmeltings-toedraaiskrip op genaamd extMerge wat jou binêre lêer met al die verskafde argumente aanroep:
+
+
+
+
$ cat /usr/local/bin/extMerge
+#!/bin/sh
+/Applications/p4merge.app/Contents/MacOS/p4merge $*
+
+
+
+
Die diff-toedraaier kontroleer om seker te maak sewe argumente word verskaf en gee twee daarvan deur na jou samesmeltingsskrip.
+By verstek gee Git die volgende argumente deur na die diff-program:
+
+
+
+
path old-file old-hex old-mode new-file new-hex new-mode
+
+
+
+
Omdat jy slegs die old-file en new-file argumente wil hê, gebruik jy die toedraaiskrip om die talle deur te gee wat jy benodig.
+
+
+
+
$ cat /usr/local/bin/extDiff
+#!/bin/sh
+[ $# -eq 7 ] && /usr/local/bin/extMerge "$2" "$5"
+
+
+
+
Jy moet ook seker maak dat hierdie hulpmiddels uitvoerbaar is:
+
+
+
+
$ sudo chmod +x /usr/local/bin/extMerge
+$ sudo chmod +x /usr/local/bin/extDiff
+
+
+
+
Nou kan jy jou konfigurasielêer opstel om jou pasgemaakte samesmeltingsresolusie- en diff-hulpmiddels te gebruik.
+Dit verg 'n aantal pasgemaakte instellings: merge.tool om vir Git te sê watter strategie om te gebruik, mergetool.<tool>.cmd om te spesifiseer hoe om die opdrag uit te voer, mergetool.<tool>.trustExitCode om vir Git te sê of die uitgangskode (exit code) van daardie program 'n suksesvolle samesmeltingsresolusie aangedui het al dan nie, en diff.external om vir Git te sê watter opdrag om vir diffs uit te voer.
+Dus kan jy of vier konfigurasie-opdragte uitvoer:
+
+
+
+
$ git config --global merge.tool extMerge
+$ git config --global mergetool.extMerge.cmd \
+ 'extMerge "$BASE" "$LOCAL" "$REMOTE" "$MERGED"'
+$ git config --global mergetool.extMerge.trustExitCode false
+$ git config --global diff.external extDiff
+
+
+
+
of jy kan jou ~/.gitconfig lêer redigeer om hierdie reëls by te voeg:
+
+
+
+
[merge]
+ tool = extMerge
+[mergetool "extMerge"]
+ cmd = extMerge "$BASE" "$LOCAL" "$REMOTE" "$MERGED"
+ trustExitCode = false
+[diff]
+ external = extDiff
+
+
+
+
Nadat al hierdie ingestel is, as jy diff-opdragte soos hierdie uitvoer:
+
+
+
+
$ git diff 32d1776b1^ 32d1776b1
+
+
+
+
In plaas daarvan om die diff-afvoer op die opdragreël te kry, skakel Git P4Merge aan, wat so iets lyk:
+
+
+
+
}}" alt="P4Merge">
+
+
Figure 181. P4Merge
+
+
+
As jy probeer om twee takke aaneen te smelt en gevolgelyk saamsmeltingskonflikte het, kan jy die opdrag git mergetool uitvoer; dit begin P4Merge om jou in staat te stel om die konflikte deur daardie GUI-hulpmiddel op te los.
+
+
+
Die oulike ding van hierdie toedraai-opstelling is dat jy jou diff- en samesmeltingshulpmiddels maklik kan verander.
+Byvoorbeeld, om jou extDiff en extMerge hulpmiddels te verander om eerder die KDiff3 hulpmiddel uit te voer, hoef jy al wat te doen is net jou extMerge lêer te redigeer:
+
+
+
+
$ cat /usr/local/bin/extMerge
+#!/bin/sh
+/Applications/kdiff3.app/Contents/MacOS/kdiff3 $*
+
+
+
+
Nou sal Git die KDiff3 hulpmiddel gebruik vir diff-besigtiging en saamsmeltingskonflikoplossing.
+
+
+
Git kom vooraf ingestel om 'n aantal ander samesmeltingsresolusie-hulpmiddels te gebruik sonder dat jy die cmd-konfigurasie hoef op te stel.
+Om 'n lys te sien van die hulpmiddels wat dit ondersteun, probeer dit:
+
+
+
+
$ git mergetool --tool-help
+'git mergetool --tool=<tool>' may be set to one of the following:
+ emerge
+ gvimdiff
+ gvimdiff2
+ opendiff
+ p4merge
+ vimdiff
+ vimdiff2
+
+The following tools are valid, but not currently available:
+ araxis
+ bc3
+ codecompare
+ deltawalker
+ diffmerge
+ diffuse
+ ecmerge
+ kdiff3
+ meld
+ tkdiff
+ tortoisemerge
+ xxdiff
+
+Some of the tools listed above only work in a windowed
+environment. If run in a terminal-only session, they will fail.
+
+
+
+
As jy nie belangstel om KDiff3 vir diff te gebruik nie, maar dit eerder net vir samesmeltingsresolusie wil gebruik, en die kdiff3 opdrag is in jou pad, dan kan jy uitvoer:
+
+
+
+
$ git config --global merge.tool kdiff3
+
+
+
+
As jy dit uitvoer in plaas daarvan om die extMerge en extDiff lêers op te stel, sal Git KDiff3 vir saamsmeltingsresolusie gebruik en die normale Git diff hulpmiddel vir diffs.
+
+
+
+
+
+Formatering en witruimtekwessies is van die mees frustrerende en subtiele probleme wat baie ontwikkelaars teëkom wanneer hulle saamwerk, veral kruisplatform (cross-platform).
+Dit is baie maklik vir pleisters (patches) of ander saamgewerkte werk om subtiele witruimteveranderings bekend te stel omdat redigeerders dit stilweg inbring, en as jou lêers ooit 'n Windows-stelsel aanraak, kan hul reëlyne vervang word.
+Git het 'n paar konfigurasie-opsies om met hierdie kwessies te help.
+
+
+
core.autocrlf
+
+
+As jy op Windows programmeer en werk met mense wat dit nie doen nie (of omgekeerd), sal jy waarskynlik op 'n stadium met reëlynekwessies te kampe kry.
+Dit is omdat Windows sowel 'n wa-terugvoerkarakter (carriage-return) as 'n reëlvoerkarakter (linefeed) vir nuwe reëls in sy lêers gebruik, terwyl macOS- en Linux-stelsels slegs die reëlvoerkarakter gebruik.
+Dit is 'n subtiele maar ongelofelijk irriterende feit van kruisplatformwerk; baie redigeerders op Windows vervang stilweg bestaande LF-styl reëlyne met CRLF, of voeg beide reëlynekarakters in wanneer die gebruiker die enter-sleutel slaan.
+
+
+
Git kan dit hanteer deur CRLF-reëlyne outomaties in LF om te skakel wanneer jy 'n lêer by die indeks voeg, en omgekeerd wanneer dit kode na jou lêerstelsel uittrek.
+Jy kan hierdie funksionaliteit aanskakel met die core.autocrlf instelling.
+As jy op 'n Windows-masjien is, stel dit op true — dit skakel LF-eindpunte om na CRLF wanneer jy kode uittrek:
+
+
+
+
$ git config --global core.autocrlf true
+
+
+
+
As jy op 'n Linux- of macOS-stelsel is wat LF-reëlyne gebruik, dan wil jy nie hê dat Git hulle outomaties omskep wanneer jy lêers uittrek nie; egter, as 'n lêer met CRLF-eindpunte per ongeluk ingevoer word, wil jy dalk hê dat Git dit moet regmaak.
+Jy kan vir Git sê om CRLF na LF om te skakel met vaslegging (commit), maar nie andersom nie deur core.autocrlf op input te stel:
+
+
+
+
$ git config --global core.autocrlf input
+
+
+
+
Hierdie opstelling behoort jou te laat met CRLF-eindpunte in Windows-checkouts, maar LF-eindpunte op macOS- en Linux-stelsels en in die bewaarplek.
+
+
+
As jy 'n Windows-programmeerder is wat aan 'n projek slegs vir Windows werk, kan jy hierdie funksionaliteit afskakel, en die wa-terugvoerkarakters in die bewaarplek aanteken deur die konfigurasiewaarde op false te stel:
+
+
+
+
$ git config --global core.autocrlf false
+
+
+
+
+
core.whitespace
+
+
Git kom vooraf ingestel om sekere witruimtekwessies te detekteer en reg te maak.
+Dit kan kyk na ses primêre witruimtekwessies — drie word by verstek geaktiveer en kan afgeskakel word, en drie word by verstek gedeaktiveer maar kan geaktiveer word.
+
+
+
Die drie wat by verstek aangeskakel is, is blank-at-eol, wat kyk vir spasies aan die einde van 'n reël; blank-at-eof, wat leë reëls aan die einde van 'n lêer opmerk; en space-before-tab, wat kyk vir spasies voor tabs aan die begin van 'n reël.
+
+
+
Die drie wat by verstek gedeaktiveer is maar aangeskakel kan word, is indent-with-non-tab, wat kyk vir reëls wat begin met spasies in plaas van tabs (en word deur die tabwidth opsie beheers); tab-in-indent, wat waak vir tabs in die inspringingsgedeelte van 'n reël; en cr-at-eol, wat vir Git sê dat wa-terugvoere aan die einde van reëls OK is.
+
+
+
Jy kan vir Git sê watter van hierdie jy wil hê moet geaktiveer word deur core.whitespace te stel op die waardes wat jy aan of af wil hê, geskei deur kommas.
+Jy kan 'n opsie deaktiveer deur 'n - voor sy naam te plaas, of die verstekwaarde gebruik deur dit heeltemal uit die instellingstring weg te laat.
+Byvoorbeeld, as jy wil hê dat alles behalwe space-before-tab gestel moet word, kan jy dit so doen (met trailing-space as 'n kortskrif om beide blank-at-eol en blank-at-eof te dek):
+
+
+
+
$ git config --global core.whitespace \
+ trailing-space,-space-before-tab,indent-with-non-tab,tab-in-indent,cr-at-eol
+
+
+
+
Of jy kan slegs die pasmaakgedeelte spesifiseer:
+
+
+
+
$ git config --global core.whitespace \
+ -space-before-tab,indent-with-non-tab,tab-in-indent,cr-at-eol
+
+
+
+
Git sal hierdie kwessies detekteer wanneer jy 'n git diff opdrag uitvoer en probeer om hulle te kleur sodat jy dit moontlik kan regmaak voordat jy vaslê.
+Dit sal ook hierdie waardes gebruik om jou te help wanneer jy pleisters met git apply toepas.
+Wanneer jy pleisters toepas, kan jy vir Git vra om jou te waarsku as dit pleisters toepas met die gespesifiseerde witruimtekwessies:
+
+
+
+
$ git apply --whitespace=warn <patch>
+
+
+
+
Of jy kan hê dat Git probeer om die kwessie outomaties reg te maak voordat die pleister toegepas word:
+
+
+
+
$ git apply --whitespace=fix <patch>
+
+
+
+
Hierdie opsies is ook van toepassing op die git rebase opdrag.
+As jy witruimtekwessies vasgelê het maar nog nie stroomop gepush het nie, kan jy git rebase --whitespace=fix uitvoer sodat Git outomaties witruimtekwessies kan regmaak terwyl dit die pleisters herskryf.
+
+
+
+
Bedienerkonfigurasie (Server Configuration)
+
+
Nie annenaard so baie konfigurasie-opsies is beskikbaar vir die bedienerkant van Git nie, maar daar is 'n paar interessante waarvan jy dalk kennis wil neem.
+
+
+
receive.fsckObjects
+
+
Git is in staat om seker te maak dat elke objek wat tydens 'n push ontvang word, steeds ooreenstem met sy SHA-1 kontrolesom en na geldige objekte wys.
+Dit doen dit egter nie by verstek nie; dit is 'n redelik duur bewerking, en kan die bewerking vertraag, veral op groot bewaarplekke of pushes.
+Als jy wil hê dat Git objekkonsekwentheid op elke push moet kontroleer, kan jy dit dwing om dit te doen deur receive.fsckObjects op true te stel:
+
+
+
+
$ git config --system receive.fsckObjects true
+
+
+
+
Nou sal Git die integriteit van jou bewaarplek kontroleer voordat elke push aanvaar word om seker te maak dat foutiewe (of kwaadwillige) kliënte nie korrupte data inbring nie.
+
+
+
+
receive.denyNonFastForwards
+
+
As jy vasleggings rebased wat jy reeds gepusht het en dan weer probeer push, of andersins probeer om 'n vaslegging na 'n afgeleë tak te push wat nie die vaslegging bevat waarna die afgeleë tak tans wys nie, sal jy geweier word.
+Dit is oor die algemeen 'n goeie beleid; maar in die geval van die rebase, kan jy vasstel dat jy weet wat jy doen en die afgeleë tak geforceerd opdateer met 'n -f vlag vir jou push-opdrag.
+
+
+
Om vir Git te sê om geforceerde pushes te weier, stel receive.denyNonFastForwards:
+
+
+
+
$ git config --system receive.denyNonFastForwards true
+
+
+
+
Die ander manier waarop jy dit kan doen is via bedienerkant-ontvangshooks (receive hooks), wat ons binnekort sal dek.
+Daardie benadering laat jou toe om meer komplekse dinge te doen soos om nie-vinnige-voorwaartses (non-fast-forwards) aan 'n sekere subgroep gebruikers te weier.
+
+
+
+
receive.denyDeletes
+
+
Een van die omseilings van die denyNonFastForwards beleid is vir die gebruiker om die tak te verwyder en dit dan met die nuwe verwysing terug op te push.
+Om dit te vermy, stel receive.denyDeletes op true:
+
+
+
+
$ git config --system receive.denyDeletes true
+
+
+
+
+
Git-hake (Git Hooks)
+
+
+Net soos baie ander weergawebeheerstelsels, het Git 'n manier om pasgemaakte skrippe (scripts) te laat afgaan wanneer sekere belangrike aksies plaasvind.
+Daar is twee groepe van hierdie hake: kliëntkant en bedienerkant.
+Kliëntkant-hake word geaktiveer deur bewerkings soos vaslê (committing) en saamsmelt (merging), terwyl bedienerkant-hake op netwerkbewerkings soos die ontvang van gepushte vasleggings loop.
+Jy kan hierdie hake vir allerhande redes gebruik.
+
+
Installasie van 'n Haak (Installing a Hook)
+
+
Die hake word almal gestoor in die hooks subgids van die Git-gids.
+In die meeste projekte is dit .git/hooks.
+Wanneer jy 'n nuwe bewaarplek met git init inisialiseer, vul Git die hake-gids met 'n trop voorbeeldskrippe, waarvan baie op hul eie nuttig is; maar hulle dokumenteer ook die toevoerwaardes van elke skrip.
+Al die voorbeelde is geskryf as dopskrippe (shell scripts), met 'n bietjie Perl bygevoeg, maar enige behoorlik genaamde uitvoerbare skrippe sal goed werk – jy kan dit in Ruby of Python skryf of watter taal jy ook al mee vertroud is.
+As jy die gebundelde haakskrippe wil gebruik, sal jy hulle moet hernoem; hul lêername eindig almal met .sample.
+
+
+
Om 'n haakskrip te aktiveer, plaas 'n lêer in die hooks subgids van jou .git gids wat gepas genaamd is (sonder enige uitbreiding) en uitvoerbaar is.
+Van daardie punt af behoort dit geroep te word.
+Ons sal die meeste van die belangrikste haaklêername hier dek.
+
+
+
Kliëntkant-hake (Client-Side Hooks)
+
+
Daar is 'n hele paar kliëntkant-hake.
+Hierdie afdeling verdeel hulle in vasleggingswerkvloei-hake (committing-workflow hooks), e-pos-werkvloeiskrippe, en al die res.
+
+
+
+
Vasleggingswerkvloei-hake (Committing-Workflow Hooks)
+
+
Die eerste vier hake het te make met die vasleggingsproses.
+
+
+
Die pre-commit haak word eerste uitgevoer, selfs voordat jy 'n vasleggingsboodskap intik.
+Dit word gebruik om die momentopname (snapshot) te inspekteer wat op die punt staan om vasgelê te word, om te sien of jy iets vergeet het, om seker te maak toetse loop, of om te ondersoek wat jy ook al in die kode moet inspekteer.
+As dit nie-nul uitstaan (exiting non-zero) van hierdie haak, word die vaslegging gestaak, al kan jy dit omseil met git commit --no-verify.
+Jy kan dinge doen soos om te kyk vir kodestyl (voer lint of iets ekwivalents uit), kyk vir agtereenvolgende witruimte (die verstellingshaak doen presies dit), of kyk vir gepaste dokumentasie oor nuwe metodes.
+
+
+
Die prepare-commit-msg haak word uitgevoer voordat die vasleggingsboodskap-redigeerder aangeskakel word, maar nadat die verstekboodskap geskep is.
+Dit laat jou toe om die verstekboodskap te redigeer voordat die vasleggingsouteur dit sien.
+Hierdie haak neem 'n paar parameters: die pad na die lêer wat die vasleggingsboodskap tot dusver hou, die tipe vaslegging, en die vaslegging SHA-1 as dit 'n geamendeerde (amended) vaslegging is.
+Hierdie haak is oor die algemeen nie nuttig vir normale vasleggings nie; dit is eerder goed vir vasleggings waar die verstekboodskap outomaties gegenereer word, soos sjabloon-vasleggingsboodskappe, saamsmeltingsvasleggings (merge commits), saamgeperste vasleggings (squashed commits), en geamendeerde vasleggings.
+Jy kan dit gebruik in samehang met 'n vasleggingsjabloon om programmaties inligting in te voeg.
+
+
+
Die commit-msg haak neem een parameter, wat weer die pad is na 'n tydelike lêer wat die vasleggingsboodskap bevat wat deur die ontwikkelaar geskryf is.
+As hierdie skrip nie-nul uitstaan, staak Git die vasleggingsproses, sodat jy dit kan gebruik om jou projektoestand of vasleggingsboodskap te valideer voordat jy toelaat dat 'n vaslegging deurgaan.
+In die laaste afdeling van hierdie hoofstuk sal ons demonstreer hoe om hierdie haak te gebruik om te kyk dat jou vasleggingsboodskap aan 'n vereiste patroon voldoen.
+
+
+
Nadat die hele vasleggingsproses voltooi is, loop die post-commit haak.
+Dit neem geen parameters nie, maar jy kan maklik die laaste vaslegging kry deur git log -1 HEAD uit te voer.
+Oor die algemeen word hierdie skrip gebruik vir kennisgewing of iets soortgelyks.
+
+
+
+
E-poswerkvloei-hake (Email Workflow Hooks)
+
+
Jy kan drie kliëntkant-hake opstel vir 'n e-posgebaseerde werkvloei.
+Hulle word almal opgeroep deur die git am opdrag, so as jy nie daardie opdrag in jou werkvloei gebruik nie, kan jy veilig na die volgende afdeling oorslaan.
+As jy pleisters (patches) oor e-pos aanvaar wat deur git format-patch voorberei is, dan kan sommige hiervan vir jou nuttig wees.
+
+
+
Die eerste haak wat uitgevoer word, is applypatch-msg.
+Dit neem 'n enkele argument: die naam van die tydelike lêer wat die voorgestelde vasleggingsboodskap bevat.
+Git staak die pleister as hierdie skrip nie-nul uitstaan.
+Jy kan dit gebruik om seker te maak dat 'n vasleggingsboodskap behoorlik geformatteer is, of om die boodskap te normaliseer deur te hê dat die skrip dit ter plaatse redigeer.
+
+
+
Die volgende haak om te loop wanneer pleisters via git am toegepas word, is pre-applypatch.
+Taamlik verwarrend word dit uitgevoer nadat die pleister toegepas is, maar voordat 'n vaslegging gemaak word, sodat jy dit kan gebruik om die momentopname te inspekteer voordat jy die vaslegging maak.
+Jy kan toetse uitvoer of andersins die werkboom (working tree) met hierdie skrip inspekteer.
+As iets ontbreek of die toetse nie slaag nie, staak die uitstaan van nie-nul die git am skrip sonder om die pleister vas te lê.
+
+
+
Die laaste haak om te loop tydens 'n git am bewerking is post-applypatch, wat loop nadat die vaslegging gemaak is.
+Jy kan dit gebruik om 'n groep of die outeur van die pleister wat jy ingetrek het te ken te gee dat jy dit gedoen het.
+Jy kan nie die pleisterproses met hierdie skrip stop nie.
+
+
+
+
Ander Kliënthake (Other Client Hooks)
+
+
Die pre-rebase haak loop voordat jy enigiets rebase en kan die proses tot 'n stilstand bring deur nie-nul uit te staan.
+Jy kan hierdie haak gebruik om te verbied om enige vasleggings te rebase wat reeds gepush is.
+Die voorbeeld pre-rebase haak wat Git installeer, doen dit, hoewel dit sekere aannames maak wat dalk nie ooreenstem met jou werkvloei nie.
+
+
+
Die post-rewrite haak word uitgevoer deur opdragte wat vasleggings vervang, soos git commit --amend en git rebase (hoewel nie deur git filter-branch nie).
+Sy enkele argument is watter opdrag die herskrywing geaktiveer het, en dit ontvang 'n lys van herskrywings op stdin.
+Hierdie haak het baie van dieselfde gebruike as die post-checkout en post-merge hake.
+
+
+
Nadat jy 'n suksesvolle git checkout uitgevoer het, loop die post-checkout haak; jy kan dit gebruik om jou werkgids behoorlik op te stel vir jou projekomgewing.
+Dit kan beteken dat groot binêre lêers ingebring word wat jy nie onder weergawebeheer wil hê nie, dokumentasie outomaties gegenereer word, of iets langs daardie lyne.
+
+
+
Die post-merge haak loop na 'n suksesvolle merge opdrag.
+Jy kan dit gebruik om data in die werkboom te herstel wat Git nie kan naspoor nie, soos toegangsregte (permissions) data.
+Hierdie haak kan eweneens die teenwoordigheid valideer van lêers ekstern aan Git-beheer wat jy dalk wil hê ingekopieer moet word wanneer die werkboom verander.
+
+
+
Die pre-push haak loop tydens git push, nadat die afgeleë verwysings (remote refs) opgedateer is, maar voordat enige objekte oorgedra is.
+Dit ontvang die naam en ligging van die remote as parameters, en 'n lys van te-word-opgedateerde verwysings deur stdin.
+Jy kan dit gebruik om 'n stel verwysingsopdaterings te valideer voordat 'n push plaasvind ('n nie-nul uitgangskode sal die push staak).
+
+
+
Git doen afvalinsameling (garbage collection) van tyd tot tyd as deel van sy normale werking deur git gc --auto op te roep.
+Die pre-auto-gc haak word opgeroep net voordat die afvalinsameling plaasvind, en kan gebruik word om jou te ken te gee dat dit gebeur, of om die insameling te staak as nou nie 'n goeie tyd is nie.
+
+
+
+
Bedienerkant-hake (Server-Side Hooks)
+
+
Benewens die kliëntkant-hake, kan jy 'n paar belangrike bedienerkant-hake as 'n stelseladministrateur gebruik om byna enige soort beleid vir jou projek af te dwing.
+Hierdie skrippe loop voor en na pushes na die bediener.
+Die pre-hake kan op enige stadium nie-nul uitstaan om die push te verwerp sowel as om 'n foutboodskap terug na die kliënt te druk; jy kan 'n push-beleid opstel wat so kompleks is as wat jy verlang.
+
+
+
pre-receive
+
+
Die eerste skrip om te loop wanneer 'n push van 'n kliënt gehanteer word, is pre-receive.
+Dit neem 'n lys van verwysings wat vanaf stdin gepush word; as dit nie-nul uitstaan, word nie een van hulle aanvaar nie.
+Jy kan hierdie haak gebruik om dinge te doen soos om seker te maak geen van die opgedateerde verwysings is nie-vinnig-voorwaarts (non-fast-forwards) nie, of om toegangsbeheer te doen vir al die verwysings en lêers wat hulle met die push wysig.
+
+
+
+
update
+
+
Die update skrip is baie soos die pre-receive skrip, behalwe dat dit een keer loop vir elke tak wat die stootder (pusher) probeer opdateer.
+As die stootder probeer om na veelvuldige takke te push, loop pre-receive slegs een keer, terwyl update een keer loop per tak waarna hulle push.
+In plaas van om van stdin te lees, neem hierdie skrip drie argumente: die naam van die verwysing (tak), die SHA-1 waarna daardie verwysing voor die push gewys het, en die SHA-1 wat die gebruiker probeer push.
+As die update skrip nie-nul uitstaan, word slegs daardie verwysing geweier; ander verwysings kan steeds opgedateer word.
+
+
+
+
post-receive
+
+
Die post-receive haak loop nadat die hele proses voltooi is en kan gebruik word om ander dienste op te dateer of gebruikers in kennis te stel.
+Dit neem dieselfde stdin-data as die pre-receive haak.
+Voorbeelden sluit in om 'n lys te e-pos, 'n deurlopende integrasie-bediener (continuous integration server) in kennis te stel, of om 'n kaartjie-opsporingstelsel (ticket-tracking system) op te dateer – jy kan selfs die vasleggingsboodskappe ontleed om te kyk of enige kaartjies geopen, gewysig of gesluit moet word.
+Hierdie skrip kan nie die push-proses stop nie, maar die kliënt ontkoppel nie voordat dit voltooi is nie, so wees versigtig as jy iets probeer doen wat lank kan neem.
+
+
+
+
+|
+ Tip
+ |
+
+
+ As jy 'n skrip/haak skryf wat andere sal moet lees, verkies die lang weergawes van opdragreëlvlae; oor ses maande sal jy ons bedank.
+ |
+
+
+
+
+
Summary
+
+
We’ve covered most of the major ways that you can customize your Git client and server to best fit your workflow and projects.
+You’ve learned about all sorts of configuration settings, file-based attributes, and event hooks, and you’ve built an example policy-enforcing server.
+You should now be able to make Git fit nearly any workflow you can dream up.
+
Bydrae tot 'n Projek (Contributing to a Project)
+
+
+Die hoofmoeilikheid met die beskrywing van hoe om tot 'n projek by te dra, is die talle variasies van hoe om dit te doen.
+Omdat Git baie buigsaam is, kan mense op baie maniere saamwerk en doen hulle dit ook, en dit is problematies om te beskryf hoe jy moet bydra — elke projek is 'n bietjie anders.
+Sommige van die veranderlikes betrokke is die aktiewe bydraertelling, gekose werkvloei (workflow), jou vasleggingstoegang (commit access), en moontlik die eksterne bydrae-metode.
+
+
Die eerste veranderidg is die aktiewe bydraertelling — hoeveel gebruikers dra aktief kode by tot hierdie projek, en hoe gereeld?
+In baie gevalle sal jy twee of 'n paar ontwikkelaars hê met 'n paar vasleggings per dag, of moontlik minder vir ietwat slapende projekte.
+Vir groter maatskappye of projekte kan die aantal ontwikkelaars in die duisende wees, met honderde of duisende vasleggings wat elke dag binnekom.
+Dit is belangrik omdat jy met meer en meer ontwikkelaars meer kwessies teëkom om seker te maak dat jou kode skoon toepas of maklik saamgesmelt (merge) kan word.
+Veranderings wat jy indien, kan verouderd of erg gebreek gemaak word deur werk wat ingesmelt word terwyl jy gewerk het of terwyl jou veranderings gewag het om goedgekeur of toegepas te word.
+Hoe kan jy jou kode deurlopend op datum en jou vasleggings geldig hou?
+
+
Die volgende veranderlike is die werkvloei wat vir die projek gebruik word.
+Is dit gesentraliseerd, waar elke ontwikkelaar gelyke skryftoegang tot die hooftak het?
+Het die projek 'n instandhouer (maintainer) of integrasiebestuurder wat al die pleisters (patches) nagaan?
+Word al die pleisters deur gelykes hersien (peer-reviewed) en goedgekeurd?
+Is jy betrokke by daardie proses?
+Is 'n luitenantstelsel in plek, en moet jy jou werk eers aan hulle voorlê?
+
+
Die volgende veranderlike is jou vasleggingstoegang (commit access).
+Die werkvloei wat vereis word om tot 'n projek by te dra, is baie verskillend as jy skryftoegang tot die projek het as wanneer jy dit nie het nie.
+As jy nie skryftoegang het nie, hoe verkies die projek om bygedragen werk te aanvaar?
+Het dit selfs 'n beleid?
+Hoeveel werk dra jy op 'n slag by?
+Hoe gereeld dra jy by?
+
+
Al hierdie vrae kan beïnvloed hoe jy doeltreffend tot 'n projek bydra en watter werkvloeie vir jou verkieslik of beskikbaar is.
+Ons sal aspekte van elkeen hiervan dek in 'n reeks gebruikscenarios, wat beweeg van eenvoudig tot meer kompleks; jy behoort in staat te wees om die spesifieke werkvloeie wat jy in die praktyk benodig uit hierdie voorbeelden op te bou.
+
+
Vasleggingsriglyne (Commit Guidelines)
+
+
Voordat ons na die spesifieke gebruikscenarios begin kyk, is hier 'n vinnige nota oor vasleggingsboodskappe.
+Om 'n goeie riglyn vir die skep van vasleggings te hê en daarby te hou, maak dit 'n lot makliker om met Git te werk en met ander saam te werk.
+Die Git-projek voorsien 'n dokument wat 'n aantal goeie wenke uiteensit vir die skep van vasleggings om pleisters van in te dien — jy kan dit lees in die Git-bronkode in die Documentation/SubmittingPatches lêer.
+
+
+
+Eerstens moet jou submissies geen witruimtefoute bevat nie.
+Git bied 'n maklike manier om hiervoor te kontroleer — voordat jy vaslê (commit), voer git diff --check uit, wat moontlike witruimtefoute identifiseer en dit vir jou lys.
+
+
+
+
}}" alt="Output of `git diff --check`">
+
+
Figure 69. Afvoer van git diff --check
+
+
+
+
As jy daardie opdrag voor vaslegging uitvoer, kan jy sê of jy op die punt staan om witruimtekwessies vas te lê wat ander ontwikkelaars kan irriteer.
+
+
+
Probeer dan om elke vaslegging 'n logies afsonderlike veranderingset (changeset) te maak.
+As jy kan, probeer om jou veranderings verteerbaar te maak — moenie vir 'n hele weke-eind op vyf verskillende kwessies kodeer en dit dan alles as een massiewe vaslegging op Maandag indien nie.
+Selfs al lê jy nie gedurende die weke-eind vas nie, gebruik die voorbereidingsarea (staging area) op Maandag om jou werk op te splits in ten minste een vaslegging per kwessie, met 'n nuttige boodskap per vaslegging.
+As sommige van die veranderings dieselfde lêer wysig, probeer om git add --patch te gebruik om lêers gedeeltelik te voorberei (in detail gedek in }}">Interaktiewe Voorbereiding (Interactive Staging)).
+Die projekmomentopname aan die punt van die tak is identies, ongeag of jy een vaslegging of vyf doen, solank al die veranderings op een of ander punt bygevoeg word, so probeer om dinge makliker te maak vir jou mede-ontwikkelaars wanneer hulle jou veranderings moet hersien.
+
+
+
Hierdie benadering maak dit ook makliker om een van die veranderingsette uit te trek of terug te rol (revert) indien jy dit later benodig.
+}}">Herskryf van Geskiedenis (Rewriting History) beskryf 'n aantal nuttige Git-truuks vir die herskryf van geskiedenis en interaktiewe voorbereiding van lêers — gebruik hierdie gereedskap om te help om 'n skone en verstaanbare geskiedenis te vorm voordat jy die werk aan iemand anders stuur.
+
+
+
Die laaste ding om in gedagte te hou is die vasleggingsboodskap.
+Om die gewoonte aan te leer om kwaliteitsvasleggingsboodskappe te skep, maak die gebruik van en samewerking met Git 'n lot makliker.
+As 'n algemene reël moet jou boodskappe begin met 'n enkele reël wat nie meer as ongeveer 50 karakters is nie en die veranderingset bondig beskryf, gevolg deur 'n leë reël, gevolg deur 'n meer gedetailleerde verduideliking.
+Die Git-projek vereis dat die meer gedetailleerde verduideliking jou motivering vir die verandering insluit en die implementering daarvan kontrasteer met vorige gedrag — dit is 'n goeie riglyn om te volg.
+Skryf jou vasleggingsboodskap in die gebiedende wys (imperative): "Fix bug" en nie "Fixed bug" of "Fixes bug" nie.
+Hier is 'n sjabloon wat jy kan volg, wat ons lig aangepas het vanaf een oorspronklik geskryf deur Tim Pope:
+
+
+
+
Capitalized, short (50 chars or less) summary
+
+More detailed explanatory text, if necessary. Wrap it to about 72
+characters or so. In some contexts, the first line is treated as the
+subject of an email and the rest of the text as the body. The blank
+line separating the summary from the body is critical (unless you omit
+the body entirely); tools like rebase will confuse you if you run the
+two together.
+
+Write your commit message in the imperative: "Fix bug" and not "Fixed bug"
+or "Fixes bug." This convention matches up with commit messages generated
+by commands like git merge and git revert.
+
+Further paragraphs come after blank lines.
+
+- Bullet points are okay, too
+
+- Typically a hyphen or asterisk is used for the bullet, followed by a
+ single space, with blank lines in between, but conventions vary here
+
+- Use a hanging indent
+
+
+
+
As al jou vasleggingsboodskappe hierdie model volg, sal dinge vir jou en die ontwikkelaars met wie jy saamwerk baie makliker wees.
+Die Git-projek het goed geformatteerde vasleggingsboodskappe — probeer om git log --no-merges daar uit te voer om te sien hoe 'n mooi geformatteerde projekvasleggingsgeskiedenis lyk.
+
+
+
+
+|
+ Note
+ |
+
+ Doen soos ons sê, nie soos ons doen nie.
+
+ Om ontheffing van beknoptheid het baie van die voorbeelde in hierdie boek nie mooi geformatteerde vasleggingsboodskappe soos hierdie nie; in plaas daarvan gebruik ons eenvoudig die -m opsie vir git commit.
+
+ Kortom, doen soos ons sê, nie soos ons doen nie.
+ |
+
+
+
+
+
Beslote Klein Span (Private Small Team)
+
+
+Die eenvoudigste opstelling wat jy waarskynlik sal teëkom, is 'n beslote projek met een of twee ander ontwikkelaars.
+“Beslote” in hierdie konteks beteken geslote bronkode — nie toeganklik vir die buitewêreld nie.
+Jy en die ander ontwikkelaars het almal push-toegang tot die bewaarplek (repository).
+
+
+
In hierdie omgewing kan jy 'n werkvloei volg wat soortgelyk is aan wat jy dalk sou doen wanneer jy Subversion of 'n ander gesentraliseerde stelsel gebruik.
+Jy kry steeds die voordele van dinge soos vanlyn vaslegging en baie eenvoudiger vertakking en saamsmelting, maar die werkvloei kan baie dieselfde wees; die belangrikste verskil is dat saamsmeltings aan die kliëntkant plaasvind eerder as op die bediener ten tyde van vaslegging.
+Kom ons kyk hoe dit kan lyk wanneer twee ontwikkelaars begin saamwerk met 'n gedeelde bewaarplek.
+Die eerste ontwikkelaar, John, kloon die bewaarplek, maak 'n verandering, en lê plaaslik vas (commits).
+Die protokolboodskappe is in hierdie voorbeelde met … vervang om hulle ietwat te verkort.
+
+
+
+
# John's Machine
+$ git clone john@githost:simplegit.git
+Cloning into 'simplegit'...
+...
+$ cd simplegit/
+$ vim lib/simplegit.rb
+$ git commit -am 'Remove invalid default value'
+[master 738ee87] Remove invalid default value
+ 1 files changed, 1 insertions(+), 1 deletions(-)
+
+
+
+
Die tweede ontwikkelaar, Jessica, doen dieselfde ding — kloon die bewaarplek en lê 'n verandering vas:
+
+
+
+
# Jessica's Machine
+$ git clone jessica@githost:simplegit.git
+Cloning into 'simplegit'...
+...
+$ cd simplegit/
+$ vim TODO
+$ git commit -am 'Add reset task'
+[master fbff5bc] Add reset task
+ 1 files changed, 1 insertions(+), 0 deletions(-)
+
+
+
+
Nou push Jessica haar werk na die bediener, wat heeltemal goed werk:
+
+
+
+
# Jessica's Machine
+$ git push origin master
+...
+To jessica@githost:simplegit.git
+ 1edee6b..fbff5bc master -> master
+
+
+
+
Die laaste reël van die afvoer hierbo toon 'n nuttige terugkeerboodskap van die push-operasie.
+Die basiese formaat is <oldref>..<newref> fromref → toref, waar oldref die ou verwysing beteken, newref beteken die nuwe verwysing, fromref is die naam van die plaaslike verwysing wat gepush word, en toref is die naam van die afgeleë verwysing wat opgedateer word.
+Jy sal soortgelyke afvoer soos hierdie hieronder in die besprekings sien, so om 'n basiese idee van die betekenis te hê, sal help om die verskillende toestande van die bewaarplekke te verstaan.
+Meer besonderhede is beskikbaar in die dokumentasie vir git-push.
+
+
+
Voortsettend met hierdie voorbeeld, maak John kort daarna 'n paar veranderings, lê dit vas in sy plaaslike bewaarplek, en probeer dit na dieselfde bediener push:
+
+
+
+
# John's Machine
+$ git push origin master
+To john@githost:simplegit.git
+ ! [rejected] master -> master (non-fast forward)
+error: failed to push some refs to 'john@githost:simplegit.git'
+
+
+
+
In hierdie geval misluk John se push as gevolg van Jessica se vroeër push van haar veranderings.
+Dit is veral belangrik om te verstaan as jy gewoond is aan Subversion, omdat jy sal merk dat die twee ontwikkelaars nie dieselfde lêer gewysig het nie.
+Alhoewel Subversion outomaties so 'n saamsmelting op die bediener doen as verskillende lêers gewysig word, moet jy met Git eers die vasleggings plaasliik saamsmelt.
+Met ander woorde, John moet eers Jessica se stroomopwaartse veranderings afhaal (fetch) en dit in sy plaaslike bewaarplek insmelt voordat hy toegelaat sal word om te push.
+
+
+
As 'n eerste stap haal John Jessica se werk af (dit haal slegs Jessica se stroomopwaartse werk af, dit smelt dit nog nie in John se werk in nie):
+
+
+
+
$ git fetch origin
+...
+From john@githost:simplegit
+ + 049d078...fbff5bc master -> origin/master
+
+
+
+
Op hierdie punt lyk John se plaaslike bewaarplek so iets soos dit:
+
+
+
+
}}" alt="John’s divergent history">
+
+
Figure 70. John se afgewykte geskiedenis
+
+
+
Nou kan John Jessica se werk wat hy afgehaal het, in sy eie plaaslike werk insmelt:
+
+
+
+
$ git merge origin/master
+Merge made by the 'recursive' strategy.
+ TODO | 1 +
+ 1 files changed, 1 insertions(+), 0 deletions(-)
+
+
+
+
Solank daardie plaaslike saamsmelting glad verloop, sal John se opgedateerde geskiedenis nou so lyk:
+
+
+
+
}}" alt="John’s repository after merging `origin/master`">
+
+
Figure 71. John se bewaarplek na die saamsmelting van origin/master
+
+
+
+
Op hierdie punt wil John dalk hierdie nuwe kode toets om seker te maak dat niks van Jessica se werk enige van syne beïnvloed nie en, solank alles goed lyk, kan hy uiteindelik die nuwe saamgesmelte werk opstuur na die bediener:
+
+
+
+
$ git push origin master
+...
+To john@githost:simplegit.git
+ fbff5bc..72bbc59 master -> master
+
+
+
+
Ten slotte sal John se vasleggingsgeskiedenis so lyk:
+
+
+
+
}}" alt="John’s history after pushing to the `origin` server">
+
+
Figure 72. John se geskiedenis na push na die origin bediener
+
+
+
Intussen het Jessica 'n nuwe onderwerp-tak genaamd issue54 geskep, en drie vasleggings op daardie tak gemaak.
+Sy het nog nie John se veranderings afgehaal nie, so haar vasleggingsgeskiedenis lyk so:
+
+
+
+
}}" alt="Jessica’s topic branch">
+
+
Figure 73. Jessica se onderwerp-tak
+
+
+
Skielik verneem Jessica dat John nuwe werk na die bediener gepush het en sy wil daarna kyk, sodat sy al die nuwe inhoud van die bediener kan afhaal wat sy nog nie het nie met:
+
+
+
+
# Jessica's Machine
+$ git fetch origin
+...
+From jessica@githost:simplegit
+ fbff5bc..72bbc59 master -> origin/master
+
+
+
+
Dit trek die werk af wat John intussen opgestuur het.
+Jessica se geskiedenis lyk nou so:
+
+
+
+
}}" alt="Jessica’s history after fetching John’s changes">
+
+
Figure 74. Jessica se geskiedenis na die afhaling van John se veranderings
+
+
+
Jessica dink haar onderwerp-tak is gereed, maar sy wil weet watter deel van John se afgehaalde werk sy in haar werk moet insmelt sodat sy kan push.
+Sy voer git log uit om uit te vind:
+
+
+
+
$ git log --no-merges issue54..origin/master
+commit 738ee872852dfaa9d6634e0dea7a324040193016
+Author: John Smith <jsmith@example.com>
+Date: Fri May 29 16:01:27 2009 -0700
+
+ Remove invalid default value
+
+
+
+
Die issue54..origin/master sintaksis is 'n log-filter wat Git vra om slegs daardie vasleggings te vertoon wat op laasgenoemde tak is (in hierdie geval origin/master) en wat nie op die eerste tak is nie (in hierdie geval issue54).
+Ons sal hierdie sintaksis in detail dek in }}">Vasleggingsreekse (Commit Ranges).
+
+
+
Uit bogenoemde afvoer kan ons sien dat daar 'n enkele vaslegging is wat John gemaak het wat Jessica nie in haar plaaslike werk ingesmelt het nie.
+As sy origin/master insmelt, is dit die enkele vaslegging wat haar plaaslike werk sal wysig.
+
+
+
Nou kan Jessica haar onderwerp-werk in haar master tak insmelt, John se werk (origin/master) in haar master tak insmelt, en dan weer terug push na die bediener toe.
+
+
+
Eerstens (nadat sy al die werk op haar issue54 onderwerp-tak vasgelê het), skakel Jessica terug na haar master tak ter voorbereiding vir die integrasie van al hierdie werk:
+
+
+
+
$ git checkout master
+Switched to branch 'master'
+Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded.
+
+
+
+
Jessica kan óf origin/master óf issue54 eerste insmelt — hulle is albei stroomop, dus maak die volgorde nie saak nie.
+Die eindmomentopname behoort identies te wees, ongeag watter volgorde sy kies; slegs die geskiedenis sal verskil.
+Sy kies om die issue54 tak eerste in te smelt:
+
+
+
+
$ git merge issue54
+Updating fbff5bc..4af4298
+Fast forward
+ README | 1 +
+ lib/simplegit.rb | 6 +++++-
+ 2 files changed, 6 insertions(+), 1 deletions(-)
+
+
+
+
Geen probleme kom voor nie; soos jy kan sien was dit 'n eenvoudige vinnig-vorentoe saamsmelting (fast-forward merge).
+Jessica voltooi nou die plaaslike saamsmeltingsproses deur John se vroeër afgehaalde werk wat in die origin/master tak sit, in te smelt:
+
+
+
+
$ git merge origin/master
+Auto-merging lib/simplegit.rb
+Merge made by the 'recursive' strategy.
+ lib/simplegit.rb | 2 +-
+ 1 files changed, 1 insertions(+), 1 deletions(-)
+
+
+
+
Alles smelt skoon saam, en Jessica se geskiedenis lyk nou so:
+
+
+
+
}}" alt="Jessica’s history after merging John’s changes">
+
+
Figure 75. Jessica se geskiedenis na die saamsmelting van John se veranderings
+
+
+
Nou is origin/master bereikbaar vanaf Jessica se master tak, so sy behoort suksesvol te kan push (aannemende dat John nie intussen selfs meer veranderings gepush het nie):
+
+
+
+
$ git push origin master
+...
+To jessica@githost:simplegit.git
+ 72bbc59..8059c15 master -> master
+
+
+
+
Elke ontwikkelaar het 'n paar keer vasgelê en elkaars werk suksesvol saamgesmelt.
+
+
+
+
}}" alt="Jessica’s history after pushing all changes back to the server">
+
+
Figure 76. Jessica se geskiedenis na die opstuur van alle veranderings terug na die bediener
+
+
+
Dit is een van die eenvoudigste werkvloeie.
+Jy werk vir 'n rukkie (oor die algemeen in 'n onderwerp-tak), en smelt daardie werk in jou master tak in wanneer dit gereed is om geïntegreer te word.
+Wanneer jy daardie werk wil deel, haal jy af en smelt jou master uit origin/master in as dit verander het, en push uiteindelik na die master tak op die bediener.
+Die algemene volgorde is iets soos dit:
+
+
+
+
}}" alt="General sequence of events for a simple multiple-developer Git workflow">
+
+
Figure 77. Algemene volgorde van gebeure vir 'n eenvoudige meervoudige-ontwikkelaar Git-werkvloei
+
+
+
Beslote Bestuurde Span (Private Managed Team)
+
+
+In hierdie volgende scenario sal jy kyk na bydraerols in 'n groter beslote groep.
+Jy sal leer hoe om te werk in 'n omgewing waar klein groepe aan kenmerke saamwerk, waarna daardie span-gebaseerde bydraes deur 'n ander party geïntegreer word.
+
+
+
Kom ons sê dat John and Jessica saam aan een kenmerk werk (noem dit “featureA”), terwyl Jessica en 'n derde ontwikkelaar, Josie, aan 'n tweede werk (sê nou, “featureB”).
+In hierdie geval gebruik die maatskappy 'n tipe integrasiebestuurder-werkvloei waar die werk van die individuele groepe slegs deur sekere ingenieurs geïntegreer word, en die master tak van die hoofbewaarplek slegs deur daardie ingenieurs opgedateer kan word.
+In hierdie scenario word al die werk in span-gebaseerde takke gedoen en later deur die integrators saamgetrek.
+
+
+
Kom ons volg Jessica se werkvloei terwyl sy aan haar twee kenmerke werk, en in parallel met twee verskillende ontwikkelaars in hierdie omgewing saamwerk.
+Aannemende dat sy reeds haar bewaarplek gekloon het, besluit sy om eerste aan featureA te werk.
+Sy skep 'n nuwe tak vir die kenmerk en doen 'n bietjie werk daaraan daar:
+
+
+
+
# Jessica's Machine
+$ git checkout -b featureA
+Switched to a new branch 'featureA'
+$ vim lib/simplegit.rb
+$ git commit -am 'Add limit to log function'
+[featureA 3300904] Add limit to log function
+ 1 files changed, 1 insertions(+), 1 deletions(-)
+
+
+
+
Op hierdie punt moet sy haar werk met John deel, so sy push haar featureA takvasleggings op na die bediener.
+Jessica het nie push-toegang tot die master tak nie — slegs die integrators het — so sy moet na 'n ander tak push om met John saam te werk:
+
+
+
+
$ git push -u origin featureA
+...
+To jessica@githost:simplegit.git
+ * [new branch] featureA -> featureA
+
+
+
+
Jessica e-pos John om hom te sê dat sy bietjie werk opgesit het in 'n tak genaamd featureA en dat hy nou daarna kan kyk.
+Terwyl sy wag vir terugvoer van John, besluit Jessica om aan featureB te begin werk met Josie.
+Om te begin, begin sy 'n nuwe kenmerktak, gebaseer op die bediener se master tak:
+
+
+
+
# Jessica's Machine
+$ git fetch origin
+$ git checkout -b featureB origin/master
+Switched to a new branch 'featureB'
+
+
+
+
Nou maak Jessica 'n paar vasleggings op die featureB tak:
+
+
+
+
$ vim lib/simplegit.rb
+$ git commit -am 'Make ls-tree function recursive'
+[featureB e5b0fdc] Make ls-tree function recursive
+ 1 files changed, 1 insertions(+), 1 deletions(-)
+$ vim lib/simplegit.rb
+$ git commit -am 'Add ls-files'
+[featureB 8512791] Add ls-files
+ 1 files changed, 5 insertions(+), 0 deletions(-)
+
+
+
+
Jessica se bewaarplek lyk nou so:
+
+
+
+
}}" alt="Jessica’s initial commit history">
+
+
Figure 78. Jessica se aanvanklike vasleggingsgeskiedenis
+
+
+
Sy is gereed om haar werk te push, maar kry 'n e-pos van Josie dat 'n tak met 'n paar aanvanklijke “featureB” werk daaroor reeds op die bediener gepush is as die featureBee tak.
+Jessica moet daardie veranderings met haar eie insmelt voordat sy haar werk na die bediener kan push.
+Jessica haal eers Josie se veranderings af met git fetch:
+
+
+
+
$ git fetch origin
+...
+From jessica@githost:simplegit
+ * [new branch] featureBee -> origin/featureBee
+
+
+
+
Aannemende dat Jessica steeds op haar uitgecheckte featureB tak is, kan sy nou Josie se werk in daardie tak insmelt met git merge:
+
+
+
+
$ git merge origin/featureBee
+Auto-merging lib/simplegit.rb
+Merge made by the 'recursive' strategy.
+ lib/simplegit.rb | 4 ++++
+ 1 files changed, 4 insertions(+), 0 deletions(-)
+
+
+
+
Op hierdie punt wil Jessica al hierdie saamgesmelte “featureB” werk terug push na die bediener, maar sy wil nie eenvoudig haar eie featureB tak push nie.
+Liewer, aangesien Josie reeds 'n stroomopwaartse featureBee tak begin het, wil Jessica na daardie tak push, wat sy doen met:
+
+
+
+
$ git push -u origin featureB:featureBee
+...
+To jessica@githost:simplegit.git
+ fba9af8..cd685d1 featureB -> featureBee
+
+
+
+
Dit word 'n refspec genoem.
+Sien }}">Die Refspec (Verwysingspesifikasie) vir 'n meer gedetailleerde bespreking van Git refspecs en verskillende dinge wat jy daarmee kan doen.
+Let ook op die -u vlag; dit is kort vir --set-upstream, wat die takke opstel vir makliker push en pull later.
+
+
+
Skielik kry Jessica e-pos van John, wat haar vertel dat hy 'n paar veranderings na die featureA tak gepush het waarop hulle saamwerk, en hy vra Jessica om daarna te kyk.
+Weereens voer Jessica 'n eenvoudige git fetch uit om al die nuwe inhoud van die bediener af te haal, insluitend (natuurlik) John se jongste werk:
+
+
+
+
$ git fetch origin
+...
+From jessica@githost:simplegit
+ 3300904..aad881d featureA -> origin/featureA
+
+
+
+
Jessica kan die log van John se nuwe werk vertoon deur die inhoud van die nuut afgelaaide featureA tak te vergelyk met haar plaaslike kopie van dieselfde tak:
+
+
+
+
$ git log featureA..origin/featureA
+commit aad881d154acdaeb2b6b18ea0e827ed8a6d671e6
+Author: John Smith <jsmith@example.com>
+Date: Fri May 29 19:57:33 2009 -0700
+
+ Increase log output to 30 from 25
+
+
+
+
As Jessica hou van wat sy sien, kan sy John se nuwe werk in haar plaaslike featureA tak insmelt met:
+
+
+
+
$ git checkout featureA
+Switched to branch 'featureA'
+$ git merge origin/featureA
+Updating 3300904..aad881d
+Fast forward
+ lib/simplegit.rb | 10 +++++++++-
+1 files changed, 9 insertions(+), 1 deletions(-)
+
+
+
+
Ten slotte wil Jessica dalk 'n paar klein veranderings aan al daardie saamgesmelte inhoud maak, so sy is vry om daardie veranderings te maak, dit in haar plaaslike featureA tak vas te lê, en die eindresultaat terug te push na die bediener:
+
+
+
+
$ git commit -am 'Add small tweak to merged content'
+[featureA 774b3ed] Add small tweak to merged content
+ 1 files changed, 1 insertions(+), 1 deletions(-)
+$ git push
+...
+To jessica@githost:simplegit.git
+ 3300904..774b3ed featureA -> featureA
+
+
+
+
Jessica se vasleggingsgeskiedenis lyk nou so iets soos dit:
+
+
+
+
}}" alt="Jessica’s history after committing on a feature branch">
+
+
Figure 79. Jessica se geskiedenis na vaslegging op 'n kenmerktak
+
+
+
Op een of ander punt lig Jessica, Josie en John die integrators in dat die featureA en featureBee takke op die bediener gereed is vir integrasie in die hooftak.
+Nadat die integrators hierdie takke in die hooftak ingesmelt het, sal 'n afhaling die nuwe saamsmeltingsvaslegging (merge commit) aftrek, wat die geskiedenis so laat lyk:
+
+
+
+
}}" alt="Jessica’s history after merging both her topic branches">
+
+
Figure 80. Jessica se geskiedenis na die saamsmelting van beide haar onderwerp-takke
+
+
+
Baie groepe skakel oor na Git as gevolg van hierdie vermoë om verskeie spanne in parallel te laat werk, en die verskillende werklyne laat in die proses saam te smelt.
+Die vermoë van kleiner subgroepe van 'n span om via afgeleë takke saam te werk sonder om noodwendig die hele span te betrek of te belemmer, is 'n enorme voordeel van Git.
+Die volgorde vir die werkvloei wat jy hier gesien het, is iets soos dit:
+
+
+
+
}}" alt="Basic sequence of this managed-team workflow">
+
+
Figure 81. Basiese volgorde van hierdie bestuurde-span werkvloei
+
+
+
Gevorkte Openbare Projek (Forked Public Project)
+
+
+Om tot openbare projekte by te dra is 'n bietjie anders.
+Omdat jy nie die regte het om takke op die projek direk op te dateer nie, moet jy die werk op 'n ander manier by die instandhouers kry.
+Hierdie eerste voorbeeld beskryf bydraes via forking op Git-gashere wat maklike forking ondersteun.
+Baie gasheerwebtuistes ondersteun dit (insluitend GitHub, BitBucket, repo.or.cz, en ander), en baie projekinstandhouers verwag hierdie styl van bydrae.
+Die volgende afdeling handel oor projekte wat verkies om bygedragen pleisters via e-pos te aanvaar.
+
+
+
Eerstens wil jy waarskynlik die hoofbewaarplek kloon, 'n onderwerp-tak skep vir die pleister of pleisterreeks wat jy van plan is om by te dra, en jou werk daar doen.
+Die volgorde lyk basies soos dit:
+
+
+
+
$ git clone <url>
+$ cd project
+$ git checkout -b featureA
+ ... work ...
+$ git commit
+ ... work ...
+$ git commit
+
+
+
+
+
+|
+ Note
+ |
+
+
+ Jy wil dalk rebase -i gebruik om jou werk af te pers (squash) tot 'n enkele vaslegging, of om die werk in die vasleggings te herschik om die pleister makliker vir die instandhouer te maak om te hersien — sien }}">Herskryf van Geskiedenis (Rewriting History) vir meer inligting oor interaktiewe herbasering.
+ |
+
+
+
+
+
Wanneer jou takwerk klaar is en jy gereed is om dit aan die instandhouers terug te gee, gaan na die oorspronklike projekblad en klik op die “Fork” knoppie, wat jou eie skryfbare fork van die projek skep.
+Jy moet dan hierdie bewaarplek-URL as 'n nuwe remote van jou plaaslike bewaarplek byvoeg; in hierdie voorbeeld, noem ons dit myfork:
+
+
+
+
$ git remote add myfork <url>
+
+
+
+
Jy moet dan jou nuwe werk na hierdie bewaarplek push.
+Dit is die maklikste om die onderwerp-tak waaraan jy werk na jou gevorkte bewaarplek te push, eerder as om daardie werk in jou master tak te smelt en dit te push.
+Die rede hiervan is dat as jou werk nie aanvaar word nie of gekies word (cherry-picked), jy nie jou master tak hoef terug te rol nie (die Git cherry-pick operasie word meer in detail gedek in }}">Herbasering en Cherry-Picking Werkvloeie (Rebasing and Cherry-Picking Workflows)).
+As die instandhouers jou werk merge, rebase, of cherry-pick, sal jy dit uiteindelik terugkry deur van hulle bewaarplek af te pull enigenaars.
+
+
+
In elk geval kan jy jou werk push met:
+
+
+
+
$ git push -u myfork featureA
+
+
+
+
+Sodra jou werk na jou fork van die bewaarplek gepush is, moet jy die instandhouers van die oorspronklike projek in kennis stel dat jy werk het wat jy wil hê hulle moet saamsmelt.
+Dit word dikwels 'n pull request genoem, en jy genereer tipies so 'n versoek óf via die webwerf — GitHub het sy eie “Pull Request” meganisme wat ons sal dek in }}">GitHub — óf jy kan die git request-pull opdrag uitvoer en die daaropvolgende afvoer per e-pos aan die projekinstandhouer handmatig stuur.
+
+
+
Die git request-pull opdrag neem die basistak waarin jy wil hê jou onderwerp-tak moet gepulled word en die Git-bewaarplek-URL waarvan jy wil hê hulle moet pull, en produseer 'n opsomming van al die veranderings wat jy vra om gepulled te word.
+Byvoorbeeld, as Jessica vir John 'n pull request wil stuur, en sy het twee vasleggings gemaak op die onderwerp-tak wat sy pas gepush het, kan sy dit uitvoer:
+
+
+
+
$ git request-pull origin/master myfork
+The following changes since commit 1edee6b1d61823a2de3b09c160d7080b8d1b3a40:
+Jessica Smith (1):
+ Create new function
+
+are available in the git repository at:
+
+ https://githost/simplegit.git featureA
+
+Jessica Smith (2):
+ Add limit to log function
+ Increase log output to 30 from 25
+
+ lib/simplegit.rb | 10 +++++++++-
+ 1 files changed, 9 insertions(+), 1 deletions(-)
+
+
+
+
Hierdie afvoer kan aan die instandhouer gestuur word — dit vertel hulle waar die werk van afgetak is, som die vasleggings op, en identifiseer waarvandaan die nuwe werk gepulled moet word.
+
+
+
Op 'n projek waarvoor jy nie die instandhouer is nie, is dit oor die algemeen makliker om 'n tak soos master altyd origin/master te laat naspeur (track) en om jou werk te doen in onderwerp-takke wat jy maklik kan weggooi as hulle geweier word.
+Om werktemas geïsoleer te hou in onderwerp-takke maak dit ook vir jou makliker om jou werk te rebase as die punt van die hoofbewaarplek in die tussentijd beweeg het en jou vasleggings nie meer skoon toepas nie.
+Byvoorbeeld, as jy 'n tweede onderwerp van werk by die projek wil indien, moenie aanhou werk aan die onderwerp-tak wat jy pas opgesit het nie — begin oor vanaf die hoofbewaarplek se master tak:
+
+
+
+
$ git checkout -b featureB origin/master
+ ... work ...
+$ git commit
+$ git push myfork featureB
+$ git request-pull origin/master myfork
+ ... email generated request pull to maintainer ...
+$ git fetch origin
+
+
+
+
Nou is elkeen van jou onderwerpe vervat binne 'n silo — soortgelyk aan 'n pleistertou — wat jy kan herskryf, rebase en wysig sonder dat die onderwerpe inmeng of van mekaar afhanklik is, soos dit:
+
+
+
+
}}" alt="Initial commit history with `featureB` work">
+
+
Figure 82. Aanvanklijke vasleggingsgeskiedenis met featureB werk
+
+
+
Sê nou die projekinstandhouer het 'n bos ander pleisters ingetrek en jou eerste tak probeer, maar dit smelt nie meer skoon saam nie.
+In hierdie geval kan jy probeer om daardie tak bo-op origin/master te rebase, die konflikte vir die instandhouer op te los, en dan jou veranderings opnieuw in te dien:
+
+
+
+
$ git checkout featureA
+$ git rebase origin/master
+$ git push -f myfork featureA
+
+
+
+
+
+
}}" alt="Commit history after `featureA` work">
+
+
Figure 83. Vasleggingsgeskiedenis na featureA werk
+
+
+
Omdat jy die tak gerebase het, moet jy die -f spesifiseer vir jou push-opdrag om die featureA tak op die bediener te kan vervang met 'n vaslegging wat nie 'n afstammeling daarvan is nie.
+'n Alternatief sou wees om hierdie nuwe werk na 'n ander tak op die bediener te push (miskien featureAv2 genoem).
+
+
+
Kom ons kyk na nog een moontlike scenario: die instandhouer het gekyk na werk in jou tweede tak en hou van die konsep, maar wil hê jy moet 'n implementeringsdetail verander.
+Jy sal ook hierdie geleentheid aangryp om die werk te skuif om gebaseer te wees op die projek se huidige master tak.
+Jy begin 'n nuwe tak gebaseer op die huidige origin/master tak, pers (squash) die featureB veranderings daar saam, los enige konflikte op, maak die implementeringsverandering, en push dit dan as 'n nuwe tak:
+
+
+
+
+
$ git checkout -b featureBv2 origin/master
+$ git merge --squash featureB
+ ... change implementation ...
+$ git commit
+$ git push myfork featureBv2
+
+
+
+
Die --squash opsie neem al die werk op die saamgesmelte tak en pers dit saam in een veranderingset wat die bewaarplektoestand lewer as 'n ware saamsmelting plaasgevind het, sonder om werklik 'n saamsmeltingsvaslegging te maak.
+Dit beteken jou toekomstige vaslegging sal slegs een ouer hê en laat jou toe om al die veranderings van 'n ander tak in te voer en dan meer veranderings te maak voordat jy die nuwe vaslegging vaslê.
+Ook die --no-commit opsie kan nuttig wees om die saamsmeltingsvaslegging uit te stel in geval van die verstek saamsmeltingsproses.
+
+
+
Op hierdie punt kan jy die instandhouer in kennis stel dat jy die gevraagde veranderings gemaak het, en dat hulle daardie veranderings in jou featureBv2 tak kan vind.
+
+
+
+
}}" alt="Commit history after `featureBv2` work">
+
+
Figure 84. Vasleggingsgeskiedenis na featureBv2 werk
+
+
+
Openbare Projek per E-pos (Public Project over Email)
+
+
+Baie projekte het vasgestelde prosedures vir die aanvaarding van pleisters — jy sal die spesifieke reëls vir elke projek moet kontroleer, omdat hulle sal verskil.
+Aangesien daar verskeie ouer, groter projekte is wat pleisters via 'n ontwikkelaarmaillys aanvaar, gaan ons nou 'n voorbeeld daarvan dek.
+
+
+
Die werkvloei is soortgelyk aan die vorige gebruikscenario — jy skep onderwerp-takke vir elke pleisterreeks waaraan jy werk.
+Die verskil is hoe jy dit by die projek indien.
+In plaas daarvan om die projek te fork en na jou eie skryfbare weergawe te push, genereer jy e-posweergawes van elke vasleggingsreeks en e-pos dit aan die ontwikkelaarmaillys:
+
+
+
+
$ git checkout -b topicA
+ ... work ...
+$ git commit
+ ... work ...
+$ git commit
+
+
+
+
+Nou het jy twee vasleggings wat jy na die maillys wil stuur.
+Jy gebruik git format-patch om die mbox-geformatteerde lêers te genereer wat jy aan die lys kan e-pos — dit verander elke vaslegging in 'n e-posboodskap met die eerste reël van die vasleggingsboodskap as die onderwerp en die res van die boodskap plus die pleister wat die vaslegging bekendstel as die liggaam.
+Die lekker ding hiervan is dat die toepassing van 'n pleister vanaf 'n e-pos wat met format-patch gegenereer is, al die vasleggingsinligting behoorlik behou.
+
+
+
+
$ git format-patch -M origin/master
+0001-add-limit-to-log-function.patch
+0002-increase-log-output-to-30-from-25.patch
+
+
+
+
Die format-patch opdrag druk die name uit van die pleisterlêers wat dit skep.
+Die -M skakelaar sê vir Git om te kyk vir hernoemings.
+Die lêers eindig op om so te lyk:
+
+
+
+
$ cat 0001-add-limit-to-log-function.patch
+From 330090432754092d704da8e76ca5c05c198e71a8 Mon Sep 17 00:00:00 2001
+From: Jessica Smith <jessica@example.com>
+Date: Sun, 6 Apr 2008 10:17:23 -0700
+Subject: [PATCH 1/2] Add limit to log function
+
+Limit log functionality to the first 20
+
+---
+ lib/simplegit.rb | 2 +-
+ 1 files changed, 1 insertions(+), 1 deletions(-)
+
+diff --git a/lib/simplegit.rb b/lib/simplegit.rb
+index 76f47bc..f9815f1 100644
+--- a/lib/simplegit.rb
++++ b/lib/simplegit.rb
+@@ -14,7 +14,7 @@ class SimpleGit
+ end
+
+ def log(treeish = 'master')
+- command("git log #{treeish}")
++ command("git log -n 20 #{treeish}")
+ end
+
+ def ls_tree(treeish = 'master')
+--
+2.1.0
+
+
+
+
Jy kan ook hierdie pleisterlêers wysig om meer inligting vir die e-poslys by te voeg wat jy nie wil hê in die vasleggingsboodskap moet verskyn nie.
+As jy teks byvoeg tussen die --- reël en die begin van die pleister (die diff --git reël), kan die ontwikkelaars dit lees, maar daardie inhoud word geïgnoreer deur die pleisterproses.
+
+
+
Om dit aan 'n maillys te e-pos, kan jy óf die lêer in jou e-posprogram plak óf dit via 'n opdragreëlprogram stuur.
+Om die teks te plak veroorsaak dikwels formateringskwessies, veral met “slim” kliënte wat nie nuwelyne en ander witruimte gepas behou nie.
+Gelukkig bied Git 'n gereedschap om jou te help om behoorlijk geformatteerde pleisters via IMAP te stuur, wat makliker vir jou kan wees.
+Ons sal demonstreer hoe om 'n pleister via Gmail te stuur, wat toevallig die e-posagent is wat ons die beste ken; jy kan gedetailleerde instruksies lees vir 'n aantal posprogramme aan die einde van die bogenoemde Documentation/SubmittingPatches lêer in die Git-bronkode.
+
+
+
+Eerstens moet jy die imap-afdeling in jou ~/.gitconfig lêer opstel.
+Jy kan elke waarde afsonderlik stel met 'n reeks git config opdragte, of jy kan dit handmatig byvoeg, maar uiteindelik behoort jou konfigurasielêer so iets soos dit te lyk:
+
+
+
+
[imap]
+ folder = "[Gmail]/Drafts"
+ host = imaps://imap.gmail.com
+ user = user@gmail.com
+ pass = YX]8g76G_2^sFbd
+ port = 993
+ sslverify = false
+
+
+
+
As jou IMAP-bediener nie SSL gebruik nie, is die laaste twee reëls waarskynlik nie nodig nie, en die gasheerwaarde sal imap:// wees in plaas van imaps://.
+Wanneer dit opgestel is, kan jy git imap-send gebruik om die pleisterreeks in die Drafts-gids van die gespesifiseerde IMAP-bediener te plaas:
+
+
+
+
$ cat *.patch |git imap-send
+Resolving imap.gmail.com... ok
+Connecting to [74.125.142.109]:993... ok
+Logging in...
+sending 2 messages
+100% (2/2) done
+
+
+
+
Op hierdie punt behoort jy in staat te wees om na jou Drafts-gids te gaan, die To-veld te verander na die maillys waarna jy die pleister stuur, moontlik die instandhouer of persoon verantwoordelik vir daardie afdeling te CC, en dit weg te stuur.
+
+
+
Jy kan ook die pleisters deur 'n SMTP-bediener stuur.
+So voorheen, kan jy elke waarde afsonderlik stel met 'n reeks git config opdragte, of jy kan dit handmatig byvoeg in die sendemail-afdeling in jou ~/.gitconfig lêer:
+
+
+
+
[sendemail]
+ smtpencryption = tls
+ smtpserver = smtp.gmail.com
+ smtpuser = user@gmail.com
+ smtpserverport = 587
+
+
+
+
Nadat dit gedoen is, kan jy git send-email gebruik om jou pleisters te stuur:
+
+
+
+
$ git send-email *.patch
+0001-add-limit-to-log-function.patch
+0002-increase-log-output-to-30-from-25.patch
+Who should the emails appear to be from? [Jessica Smith <jessica@example.com>]
+Emails will be sent from: Jessica Smith <jessica@example.com>
+Who should the emails be sent to? jessica@example.com
+Message-ID to be used as In-Reply-To for the first email? y
+
+
+
+
Dan spoeg Git 'n bos loginligting uit wat lyk soos iets soos dit vir elke pleister wat jy stuur:
+
+
+
+
(mbox) Adding cc: Jessica Smith <jessica@example.com> from
+ \line 'From: Jessica Smith <jessica@example.com>'
+OK. Log says:
+Sendmail: /usr/sbin/sendmail -i jessica@example.com
+From: Jessica Smith <jessica@example.com>
+To: jessica@example.com
+Subject: [PATCH 1/2] Add limit to log function
+Date: Sat, 30 May 2009 13:29:15 -0700
+Message-Id: <1243715356-61726-1-git-send-email-jessica@example.com>
+X-Mailer: git-send-email 1.6.2.rc1.20.g8c5b.dirty
+In-Reply-To: <y>
+References: <y>
+
+Result: OK
+
+
+
+
+
+|
+ Tip
+ |
+
+
+ Vir hulp met die opstel van jou stelsel en e-pos, meer wenke en truuks, en 'n sandput om 'n proefpleister via e-pos te stuur, gaan na git-send-email.io.
+ |
+
+
+
+
+
Opsomming (Summary)
+
+
In hierdie afdeling het ons meervoudige werkvloeie gedek, en gepraat oor die verskille tussen om te werk as deel van 'n klein span op geslotebron-projekte teenoor die bydrae tot 'n groot openbare projek.
+Jy weet om te kyk vir witruimtefoute voordat jy vaslê, en kan 'n wonderlike vasleggingsboodskap skryf.
+Jy het geleer hoe om pleisters te formateer, en dit per e-pos aan 'n ontwikkelaarmaillys te stuur.
+Die hantering van saamsmeltings is ook gedek in die konteks van die verskillende werkvloeie.
+Jy is nou goed voorbereid om aan enige projek saam te werk.
+
+
+
Volgens sal jy sien hoe om die ander kant van die munt te werk: die instandhouding van 'n Git-projek.
+Jy sal leer hoe om 'n welwillende diktator of integrasiebestuurder te wees.
+
+
Die Beheer van 'n Projek (Maintaining a Project)
+
+
+Benewens om te weet hoe om doeltreffend tot 'n projek by te dra, sal jy waarskynlik ook moet weet hoe om een te beheer.
+Dit kan bestaan uit die aanvaarding en toepassing van pleisters (patches) wat via format-patch gegenereer en aan jou gemail is, of die integrasie van veranderings in afgeleë takke (remote branches) vir bewaarplekke wat jy as remotes by jou projek gevoeg het.
+Of jy nou 'n kanonieke bewaarplek beheer of wil help deur pleisters te verifieer of goed te keur, jy moet weet hoe om werk te aanvaar op 'n manier wat die duidelikste is vir ander bydraers en volhoubaar is vir jou oor die lang termyn.
+
+
Werken in Onderwerp-takke (Working in Topic Branches)
+
+
+Wanneer jy daaraan dink om nuwe werk te integreer, is dit oor die algemeen 'n goeie idee om dit uit te probeer in 'n onderwerp-tak (topic branch) — 'n tydelike tak wat spesifiek gemaak is om daardie nuwe werk uit te probeer.
+Op hierdie manier is dit maklik om 'n pleister individueel te aanpas en dit te los as dit nie werk nie, totdat jy tyd het om daarna terug te keer.
+As jy 'n eenvoudige taknaam skep gebaseer op die tema van die werk wat jy gaan probeer, soos ruby_client of iets soortgelyks beskrywend, kan jy dit maklik onthou as jy dit vir 'n rukkie moet laat vaar en later terugkeer.
+Die instandhouer (maintainer) van die Git-projek is ook geneig om hierdie takke in naamruimtes (namespaces) te plaas — soos sc/ruby_client, waar sc kort is vir die persoon wat die werk bygedragen het.
+Soos jy sal onthou, kan jy die tak gebaseer op jou master tak so skep:
+
+
+
+
$ git branch sc/ruby_client master
+
+
+
+
Of, as jy ook dadelik daarna wil oorskakel, kan jy die checkout -b opsie gebruik:
+
+
+
+
$ git checkout -b sc/ruby_client master
+
+
+
+
Nou is jy gereed om die bygedrae werk wat jy ontvang het by hierdie onderwerp-tak te voeg en te bepaal of jy dit in jou langertermyn-takke wil insmelt.
+
+
+
Pleisters vanaf E-pos Toepassing (Applying Patches from Email)
+
+
+As jy 'n pleister oor e-pos ontvang wat jy in jou projek moet integreer, moet jy die pleister in jou onderwerp-tak toepas om dit te evalueer.
+Daar is twee maniere om 'n gemailde pleister toe te pas: met git apply of met git am.
+
+
+
Toepassing van 'n Pleister met apply (Applying a Patch with apply)
+
+
+As jy die pleister ontvang het van iemand wat dit met git diff of een of ander variasie van die Unix diff opdrag gegenereer het (wat nie aanbeveel word nie; sien die volgende afdeling), kan jy dit toepas met die git apply opdrag.
+Aannemende dat jy die pleister by /tmp/patch-ruby-client.patch gestoor het, kan jy die pleister so toepas:
+
+
+
+
$ git apply /tmp/patch-ruby-client.patch
+
+
+
+
Dit wysig die lêers in jou werkgids (working directory).
+Dit is amper identies aan die uitvoering van 'n patch -p1 opdrag om die pleister toe te pas, alhoewel dit meer paranoïed is en minder vae ooreenkomste (fuzzy matches) as patch aanvaar.
+Dit hanteer ook lêerbyvoegings, -verwyderings en -hernoemings as dit in die git diff formaat beskryf word, wat patch nie sal doen nie.
+Ten slotte is git apply 'n “pas alles toe of breek alles af” model waar óf alles toegepas word óf niks, terwyl patch pleisterlêers gedeeltelik kan toepas en jou werkgids in 'n vreemde toestand kan laat.
+git apply is oor die algemeen baie meer konserwatief as patch.
+Dit sal nie 'n vaslegging (commit) vir jou skep nie — nadat dit uitgevoer is, moet jy die veranderings wat ingestel is handmatig voorberei (stage) en vaslê.
+
+
+
Jy kan ook git apply gebruik om te sien of 'n pleister skoon toepas voordat jy dit werklik probeer toepas — jy kan git apply --check met die pleister uitvoer:
+
+
+
+
$ git apply --check 0001-see-if-this-helps-the-gem.patch
+error: patch failed: ticgit.gemspec:1
+error: ticgit.gemspec: patch does not apply
+
+
+
+
As daar geen afvoer is nie, behoort die pleister skoon toe te pas.
+Hierdie opdrag sluit ook af met 'n nie-nul status as die kontrole misluk, sodat jy dit in skrifte kan gebruik as jy wil.
+
+
+
+
Toepassing van 'n Pleister met am (Applying a Patch with am)
+
+
+As die bydraer 'n Git-gebruiker is en goed genoeg was om die format-patch opdrag te gebruik om hul pleister te genereer, is jou werk makliker omdat die pleister outeurinligting en 'n vasleggingsboodskap vir jou bevat.
+As jy kan, moedig jou bydraers aan om format-patch in plaas van diff te gebruik om pleisters vir jou te genereer.
+Jy behoort slegs git apply te hoef te gebruik vir erfenis-pleisters (legacy patches) en dinge soos dit.
+
+
+
Om 'n pleister wat deur format-patch gegenereer is toe te pas, gebruik jy git am (die opdrag is am genoem aangesien dit gebruik word om "a reeks pleisters van 'n posbus af toe te pas" — apply a series of patches from a mailbox).
+Tegnies is git am gebou om 'n mbox-lêer te lees, wat 'n eenvoudige, gewone-teksformaat is om een of meer e-posboodskappe in een tekslêer te stoor.
+Dit lyk min of meer so:
+
+
+
+
From 330090432754092d704da8e76ca5c05c198e71a8 Mon Sep 17 00:00:00 2001
+From: Jessica Smith <jessica@example.com>
+Date: Sun, 6 Apr 2008 10:17:23 -0700
+Subject: [PATCH 1/2] Add limit to log function
+
+Limit log functionality to the first 20
+
+
+
+
Dit is die begin van die afvoer van die git format-patch opdrag wat jy in die vorige afdeling gesien het; dit verteenwoordig ook 'n geldige mbox-e-posformaat.
+As iemand jou die pleister behoorlik gemail het deur git send-email te gebruik, en jy laai dit af in 'n mbox-formaat, dan kan jy git am na daardie mbox-lêer wys, en dit sal begin om al die pleisters wat dit sien toe te pas.
+As jy 'n poskliënt (mail client) laat loop wat verskeie e-posse in mbox-formaat kan stoor, kan jy hele pleisterreekse in 'n lêer stoor en dan git am gebruik om dit een op 'n keer toe te pas.
+
+
+
As iemand egter 'n pleisterlêer wat via format-patch gegenereer is op 'n kaartjiesisteem (ticketing system) of iets soortgelyks opgelaai het, kan jy die lêer plaaslik stoor en dan daardie lêer wat op jou skyf gestoor is aan git am deurgee om dit toe te pas:
+
+
+
+
$ git am 0001-limit-log-function.patch
+Applying: Add limit to log function
+
+
+
+
Jy kan sien dat dit skoon toegepas is en outomaties die nuwe vaslegging vir jou geskep het.
+Die outeurinligting word geneem uit die e-pos se From en Date opskrifte (headers), en die boodskap van die vaslegging word geneem uit die Subject en liggaam (voor die pleister) van die e-pos.
+Byvoorbeeld, as hierdie pleister toegepas is vanaf die mbox-voorbeeld hierbo, sou die gegenereerde vaslegging so iets so lyk:
+
+
+
+
$ git log --pretty=fuller -1
+commit 6c5e70b984a60b3cecd395edd5b48a7575bf58e0
+Author: Jessica Smith <jessica@example.com>
+AuthorDate: Sun Apr 6 10:17:23 2008 -0700
+Commit: Scott Chacon <schacon@gmail.com>
+CommitDate: Thu Apr 9 09:19:06 2009 -0700
+
+ Add limit to log function
+
+ Limit log functionality to the first 20
+
+
+
+
Die Commit inligting dui die persoon aan wat die pleister toegepas het en die tyd wat dit toegepas is.
+Die Author inligting is die individu wat oorspronklik die pleister geskep het en wanneer dit oorspronklik geskep is.
+
+
+
Maar dit is moontlik dat die pleister nie skoon sal toepas nie.
+Miskien het jou hooftak te ver afgewyk van die tak waarvan die pleister gebou is, of die pleister hang af van 'n ander pleister wat jy nog nie toegepas het nie.
+In daardie geval sal die git am proses misluk en jou vra wat jy wil doen:
+
+
+
+
$ git am 0001-see-if-this-helps-the-gem.patch
+Applying: See if this helps the gem
+error: patch failed: ticgit.gemspec:1
+error: ticgit.gemspec: patch does not apply
+Patch failed at 0001.
+When you have resolved this problem run "git am --resolved".
+If you would prefer to skip this patch, instead run "git am --skip".
+To restore the original branch and stop patching run "git am --abort".
+
+
+
+
Hierdie opdrag plaas konflikmerkers in enige lêers waarmee dit kwessies het, baie soos 'n gekonflikteerde saamsmeltings- (merge) of herbaserings- (rebase) operasie.
+Jy los hierdie kwessie op dieselfde manier op — wysig die lêer om die konflik op te los, voorberei (stage) die nuwe lêer, en voer dan git am --resolved uit om na die volgende pleister voort te gaan:
+
+
+
+
$ (fix the file)
+$ git add ticgit.gemspec
+$ git am --resolved
+Applying: See if this helps the gem
+
+
+
+
As jy wil hê Git moet 'n bietjie meer intelligent probeer om die konflik op te los, kan jy 'n -3 opsie daaraan deurgee, wat Git 'n drierigting-saamsmelting (three-way merge) laat probeer.
+Hierdie opsie is nie by verstek aan nie omdat dit nie werk nie as die vaslegging wat die pleister sê dit op gebaseer is, nie in jou bewaarplek is nie.
+As jy wel daardie vaslegging het — as die pleister gebaseer was op 'n openbare vaslegging — dan is die -3 opsie oor algemeen baie slim oor die toepassing van 'n gekonflikteerde pleister:
+
+
+
+
$ git am -3 0001-see-if-this-helps-the-gem.patch
+Applying: See if this helps the gem
+error: patch failed: ticgit.gemspec:1
+error: ticgit.gemspec: patch does not apply
+Using index info to reconstruct a base tree...
+Falling back to patching base and 3-way merge...
+No changes -- Patch already applied.
+
+
+
+
In hierdie geval, sonder die -3 opsie sou die pleister as 'n konflik beskou gewees het.
+Aangesien die -3 opsie gebruik is, het die pleister skoon toegepas.
+
+
+
As jy 'n aantal pleisters van 'n mbox toepas, kan jy ook die am opdrag in interaktiewe modus uitvoer, wat stop by elke pleister wat dit vind en vra of jy dit wil toepas:
+
+
+
+
$ git am -3 -i mbox
+Commit Body is:
+--------------------------
+See if this helps the gem
+--------------------------
+Apply? [y]es/[n]o/[e]dit/[v]iew patch/[a]ccept all
+
+
+
+
Dit is gaaf as jy 'n aantal pleisters gestoor het, omdat jy eers die pleister kan bekyk as jy nie onthou wat dit is nie, of nie die pleister toepas as jy dit reeds gedoen het nie.
+
+
+
Wanneer al die pleisters vir jou onderwerp toegepas en vasgelê is in jou tak, kan jy kies óf en hoe om dit in 'n langlopende tak te integreer.
+
+
+
Uitcheck van Afgeleë Takke (Checking Out Remote Branches)
+
+
+As jou bydrag gekom het van 'n Git-gebruiker wat hul eie bewaarplek opgestel het, 'n aantal veranderings daarin gepush het, en toe vir jou die URL na die bewaarplek en die naam van die afgeleë tak waarin die veranderings is gestuur het, kan jy hulle as 'n remote byvoeg en saamsmeltings plaaslik doen.
+
+
+
Byvoorbeeld, as Jessica vir jou 'n e-pos stuur waarin sy sê dat sy 'n wonderlike nuwe kenmerk in die ruby-client tak van haar bewaarplek het, kan jy dit toets deur die remote by te voeg en daardie tak plaaslik uit te check:
+
+
+
+
$ git remote add jessica https://github.com/jessica/myproject.git
+$ git fetch jessica
+$ git checkout -b rubyclient jessica/ruby-client
+
+
+
+
As sy jou later weer e-pos met 'n ander tak wat 'n ander wonderlike kenmerk bevat, kan jy direk fetch en checkout omdat jy reeds die remote-opstelling het.
+
+
+
Dit is die nuttigste as jy konsekwent met 'n persoon werk.
+As iemand net af en toe 'n enkele pleister het om by te dra, dan is dit dalk minder tydrowend om dit oor e-pos te aanvaar as om te vereis dat almal hul eie bediener laat loop en voortdurend remotes moet byvoeg en verwyder om 'n paar pleisters te kry.
+Dit is ook onwaarskynlik dat jy honderde remotes wil hê, elk vir iemand wat net 'n pleister of twee bydra.
+Skrifte en gehoste dienste kan dit egter makliker maak — dit hang grootliks af van hoe jy ontwikkel en hoe jou bydraers ontwikkel.
+
+
+
Die ander voordeel van hierdie benadering is dat jy ook die geskiedenis van die vasleggings kry.
+Alhoewel jy dalk wettige saamsmeltingskwessies kan hê, weet jy waar in jou geskiedenis hul werk gebaseer is; 'n behoorlijke drierigting-saamsmelting is die verstek eerder as om 'n -3 te moet verskaf en te hoop dat die pleister gegenereer is van 'n openbare vaslegging waartoe jy toegang het.
+
+
+
As jy nie konsekwent met 'n persoon werk nie, maar tog op hierdie manier van hulle wil pull, kan jy die URL van die afgeleë bewaarplek aan die git pull opdrag verskaf.
+Dit doen 'n eenmalige pull en stoor nie die URL as 'n afgeleë verwysing nie:
+
+
+
+
$ git pull https://github.com/onetimeguy/project
+From https://github.com/onetimeguy/project
+ * branch HEAD -> FETCH_HEAD
+Merge made by the 'recursive' strategy.
+
+
+
+
Bepaling van Wat Ingestel Is (Determining What Is Introduced)
+
+
+Nou het jy 'n onderwerp-tak wat bijgedragen werk bevat.
+Op hierdie punt kan jy bepaal wat jy daarmee wil doen.
+Hierdie afdeling hersien 'n paar opdragte sodat jy kan sien hoe jy dit kan gebruik om presies te hersien wat jy sal instel as jy dit in jou hooftak insmelt.
+
+
+
Dit is dikwels nuttig om 'n oorsig te kry van al die vasleggings wat in hierde tak is, maar wat nie in jou master tak is nie.
+Jy kan vasleggings in die master tak uitsluit deur die --not opsie voor die taknaam by te voeg.
+Dit doen dieselfde ding as die master..contrib formaat wat ons vroeër gebruik het.
+Byvoorbeeld, as jou bydraer vir jou twee pleisters stuur en jy skep 'n tak genaamd contrib en het daardie pleisters daar toegepas, kan jy dit uitvoer:
+
+
+
+
$ git log contrib --not master
+commit 5b6235bd297351589efc4d73316f0a68d484f118
+Author: Scott Chacon <schacon@gmail.com>
+Date: Fri Oct 24 09:53:59 2008 -0700
+
+ See if this helps the gem
+
+commit 7482e0d16d04bea79d0dba8988cc78df655f16a0
+Author: Scott Chacon <schacon@gmail.com>
+Date: Mon Oct 22 19:38:36 2008 -0700
+
+ Update gemspec to hopefully work better
+
+
+
+
Om te sien watter veranderings elke vaslegging instel, onthou dat jy die -p opsie aan git log kan deurgee en dit sal die verskil (diff) wat by elke vaslegging ingestel is, aanheg.
+
+
+
Om 'n volledige diff te sien van wat sal gebeur as jy hierdie onderwerp-tak met 'n ander tak insmelt, moet jy dalk 'n vreemde truuk gebruik om die korrekte resultate te kry.
+Jy dink dalk om dit uit te voer:
+
+
+
+
Hierdie opdrag gee vir jou 'n diff, maar dit kan misleidend wees.
+As jou master tak vorentoe beweeg het sedert jy die onderwerp-tak daarvan geskep het, dan sal jy oënskynlik vreemde resultate kry.
+Dit gebeur omdat Git die momentopnames van die laaste vaslegging van die onderwerp-tak waarop jy is en die momentopname van die laaste vaslegging op die master tak direk vergelyk.
+Byvoorbeeld, as jy 'n reël in 'n lêer op die master tak bygevoeg het, sal 'n direkte vergelyking van die momentopnames lyk of die onderwerp-tak daardie reël gaan verwyder.
+
+
+
As master 'n direkte voorouer van jou onderwerp-tak is, is dit nie 'n probleem nie; maar as die twee geskiedenisse afgewyk het, sal die diff lyk of jy al die nuwe dinge in jou onderwerp-tak byvoeg en alles wat uniek is aan die master tak verwyder.
+
+
+
Wat jy regtig wil sien, is die veranderings wat by die onderwerp-tak gevoeg is — die werk wat jy sal instel as jy hierdie tak met master insmelt.
+Jy doen dit deur te hê dat Git die laaste vaslegging op jou onderwerp-tak vergelyk met die eerste gemeenskaplike voorouer wat dit met die master tak het.
+
+
+
Tegnies kan jy dit doen deur die gemeenskaplike voorouer eksplisiet uit te vind en dan jou diff daarop uit te voer:
+
+
+
+
$ git merge-base contrib master
+36c7dba2c95e6bbb78dfa822519ecfec6e1ca649
+$ git diff 36c7db
+
+
+
+
+
+
$ git diff $(git merge-base contrib master)
+
+
+
+
Neltemin is nie een van dié besonder gerieflik nie, so Git bied 'n ander kortpad om dieselfde ding te doen: die driedubbelpunt-sintaksis.
+In die konteks van die git diff opdrag, kan jy drie punte na 'n ander tak plaas om 'n diff te doen tussen die laaste vaslegging van die tak waarop jy is en sy gemeenskaplike voorouer met 'n ander tak:
+
+
+
+
$ git diff master...contrib
+
+
+
+
Hierdie opdrag wys jou slegs die werk wat jou huidige onderwerp-tak ingestel het sedert sy gemeenskaplike voorouer met master.
+Dit is 'n baie nuttige sintaksis om te onthou.
+
+
+
Integrasie van Bygedragen Werk (Integrating Contributed Work)
+
+
+Wanneer al die werk in jou onderwerp-tak gereed is om in 'n meer hooflyntak geïntegreer te word, is die vraag hoe om dit te doen.
+Verder, watter algemene werkvloei wil jy gebruik om jou projek te beheer?
+Jy het 'n aantal keuses, so ons sal 'n paar van hulle dek.
+
+
+
Saamsmeltingswerkvloeie (Merging Workflows)
+
+
+Een basiese werkvloei is om eenvoudig al daardie werk direk in jou master tak in te smelt.
+In hierdie scenario het jy 'n master tak wat basies stabiele kode bevat.
+Wanneer jy werk in 'n onderwerp-tak het wat jy dink jy voltooi het, of werk wat iemand anders bygedragen het en jy geverifieer het, smelt jy dit in jou master tak in, vee daardie pas-saamgesmelte onderwerp-tak uit, en herhaal.
+
+
+
+
+
}}" alt="History with several topic branches">
+
+
Figure 85. Geskiedenis met verskeie onderwerp-takke
+
+
+
+
}}" alt="After a topic branch merge">
+
+
Figure 86. Na 'n onderwerp-tak saamsmelting
+
+
+
Dit is waarskynlijk die eenvoudigste werkvloei, maar dit kan moontlik problematies wees as jy te make het met groter of stabielere projecte waar jy regtig versigtig wil wees oor wat jy instel.
+
+
+
As jy 'n belangriker projek het, wil jy dalk 'n tweefase-saamsmeltingsiklus gebruik.
+In hierdie scenario het jy twee langlopende takke, master en develop, waarin jy bepaal dat master slegs opgedateer word wanneer 'n baie stabiele vrystelling (release) gesny word en alle nuwe kode in die develop tak geïntegreer word.
+Jy push albei hierdie takke gereeld na die openbare bewaarplek.
+Elke keer as jy 'n nuwe onderwerp-tak het om in te smelt (}}">Voor 'n onderwerp-tak saamsmelting), smelt jy dit in develop in (}}">Na 'n onderwerp-tak saamsmelting); dan, wanneer jy 'n vrystelling merk (tag), skuif jy master vinnig-vorentoe (fast-forward) na waar die nou-stabiele develop tak ook al is (}}">Na 'n projekvrystelling).
+
+
+
+
}}" alt="Before a topic branch merge">
+
+
Figure 87. Voor 'n onderwerp-tak saamsmelting
+
+
+
+
}}" alt="After a topic branch merge">
+
+
Figure 88. Na 'n onderwerp-tak saamsmelting
+
+
+
+
}}" alt="After a project release">
+
+
Figure 89. Na 'n projekvrystelling
+
+
+
Op hierdie manier, wanneer mense jou projek se bewaarplek kloon, kan hulle óf master uitcheck om die nuutste stabiele weergawe te bou en maklik daardie op datum te hou, óf hulle kan develop uitcheck, wat die meer nuutste inhoud is.
+Jy kan ook hierdie konsep uitbrei deur 'n integrate tak te hê waar al die werk saamgesmelt word.
+Dan, wanneer die kodetal op daardie tak stabiel is en toetse slaag, smelt jy dit in 'n develop tak in; en wanneer dit homself vir 'n rukkie as stabiel bewys het, skuif jy jou master tak vinnig-vorentoe.
+
+
+
+
Grootskaalse Saamsmeltingswerkvloeie (Large-Merging Workflows)
+
+
+Die Git-projek het vier langlopende takke: master, next, en seen (voorheen 'pu' — voorgestelde opdaterings / proposed updates) vir nuwe werk, en maint vir onderhoudsterugplaatsings (maintenance backports).
+Wanneer nuwe werk deur bydraers ingestel word, word dit versamel in onderwerp-takke in die instandhouer se bewaarplek op 'n manier soortgelyk aan wat ons beskryf het (sien }}">Bestuur van 'n komplekse reeks parallelle bygedragen onderwerp-takke).
+Op hierdie punt word die onderwerpe geëvalueer om te bepaal of hulle veilig en gereed is vir verbruik of dat hulle meer werk nodig het.
+As hulle veilig is, word hulle in next ingesmelt, en daardie tak word opgestup sodat almal die geïntegreerde onderwerpe kan probeer.
+
+
+
+
}}" alt="Managing a complex series of parallel contributed topic branches">
+
+
Figure 90. Bestuur van 'n komplekse reeks parallelle bygedragen onderwerp-takke
+
+
+
As die onderwerpe steeds werk nodig het, word hulle in plaas daarvan in seen ingesmelt.
+Wanneer vasgestel word dat hulle heeltemal stabiel is, word die onderwerpe heringesmelt in master.
+Die next en seen takke word dan herbou vanaf die master.
+Dit beteken master beweeg byna altyd vorentoe, next word af en toe gerebase, en seen word selfs meer gereeld gerebase:
+
+
+
+
}}" alt="Merging contributed topic branches into long-term integration branches">
+
+
Figure 91. Saamsmelting van bygedragen onderwerp-takke in langtermyn-integrasietakke
+
+
+
Wanneer 'n onderwerp-tak uiteindelik in master ingesmelt is, word dit van die bewaarplek verwyder.
+Die Git-projek het ook 'n maint tak wat afgetak is van die laaste vrystelling om teruggeplaatste pleisters te voorsien ingeval 'n onderhoudsvrystelling vereis word.
+Dus, wanneer jy die Git-beheerplek kloon, het jy vier takke wat jy kan uitcheck om die projek in verskillende stadia van ontwikkeling te evalueer, afhangende van hoe nuut jy wil wees of hoe jy wil bydra; en die instandhouer het 'n gestructureerde werkvloei om hulle te help om nuwe bydraes te keur.
+Die Git-projek se werkvloei is gespesialiseerd.
+Om dit duidelik te verstaan, kan jy na die Git Maintainer’s guide kyk.
+
+
+
+
Herbasering en Cherry-Picking Werkvloeie (Rebasing and Cherry-Picking Workflows)
+
+
+Ander instandhouers verkies om bygedragen werk bo-op hul master tak te rebase of te cherry-pick, eerder as om dit in te smelt, om 'n meestal lineêre geskiedenis te behou.
+Wanneer jy werk in 'n onderwerp-tak het en bepaal het dat jy dit wil integreer, beweeg jy na daardie tak en voer die rebase opdrag uit om die veranderings bo-op jou huidige master (of develop, ensovoorts) tak te herbou.
+As dit goed werk, kan jy jou master tak vinnig-vorentoe stuur, en jy sal eindig met 'n lineêre projekgeskiedenis.
+
+
+
+Die ander manier om ingestelde werk van een tak na 'n ander te skuif, is om dit te cherry-pick.
+'n Cherry-pick in Git is soos 'n rebase vir 'n enkele vaslegging.
+Dit neem die pleister wat in 'n vaslegging ingestel is en probeer dit weer toepas op die tak waarop jy tans is.
+Dit is nuttig as jy 'n aantal vasleggings op 'n onderwerp-tak het en slegs een van hulle wil integreer, of as jy net een vaslegging op 'n onderwerp-tak het en verkies om dit te cherry-pick eerder as om rebase uit te voer.
+Byvoorbeeld, veronderstel jy het 'n projek wat so lyk:
+
+
+
+
}}" alt="Example history before a cherry-pick">
+
+
Figure 92. Voorbeeldgeskiedenis voor 'n cherry-pick
+
+
+
As jy vaslegging e43a6 in jou master tak wil pull, kan jy uitvoer:
+
+
+
+
$ git cherry-pick e43a6
+Finished one cherry-pick.
+[master]: created a0a41a9: "More friendly message when locking the index fails."
+ 3 files changed, 17 insertions(+), 3 deletions(-)
+
+
+
+
Dit trek dieselfde verandering in e43a6 ingestel af, maar jy kry 'n nuwe vaslegging SHA-1 waarde, omdat die toegepaste datum anders is.
+Nou lyk jou geskiedenis so:
+
+
+
+
}}" alt="History after cherry-picking a commit on a topic branch">
+
+
Figure 93. Geskiedenis na die cherry-pick van 'n vaslegging op 'n onderwerp-tak
+
+
+
Nou kan jy jou onderwerp-tak verwyder en die vasleggings laat vaar wat jy nie in wou pull nie.
+
+
+
+
Rerere
+
+
+As jy baie saamsmelt en rebase, of jy 'n langlopende onderwerp-tak beheer, het Git 'n kenmerk genaamd “rerere” wat kan help.
+
+
+
Rerere staan vir “reuse recorded resolution” (hergebruik opgeneemde resolusie) — dit is 'n manier om handmatige konflikoplossing te kort te sny.
+Wanneer rerere aangeskakel is, sal Git 'n stel voor- en na-beelde van suksesvolle saamsmeltings hou, en as dit opmerk dat daar 'n konflik is wat presies lyk soos een wat jy reeds opgelos het, sal dit net die regmaak van die laaste keer gebruik, sonder om jou daarmee te lastig te val.
+
+
+
Hierdie kenmerk kom in twee dele: 'n konfigurasie-instelling en 'n opdrag.
+Die konfigurasie-instelling is rerere.enabled, en dit is handig genoeg om in jou globale konfigurasie te plaas:
+
+
+
+
$ git config --global rerere.enabled true
+
+
+
+
Nou, wanneer jy ook al 'n saamsmelting doen wat konflikte oplos, sal die resolusie in die kas (cache) opgeneem word vir ingeval jy dit in die toekoms nodig het.
+
+
+
As jy moet, kan jy met die rerere-kas wisselwerking hê deur die git rerere opdrag te gebruik.
+Wanneer dit alleen aangeroep word, kontroleer Git sy databasis van resolusies en probeer 'n ooreenkoms vind met enige huidige saamsmeltingskonflikte en dit oplos (al word dit outomaties gedoen as rerere.enabled op true gestel is).
+Daar is ook subopdracks om te sien wat opgeneem sal word, om spesifieke resolusies uit die kas te wis, en om die hele kas skoon te maak.
+Ons sal rerere in meer detail dek in }}">Rerere.
+
+
+
+
Merk van Jou Vrystellings (Tagging Your Releases)
+
+
+Wanneer jy besluit het om 'n vrystelling te sny (cut a release), wil jy waarskynlik 'n merker (tag) toewys sodat jy daardie vrystelling op enige punt vorentoe kan herskep.
+Jy kan 'n nuwe merker skep soos bespreek in }}">Git Basics.
+As jy besluit om die merker as die instandhouer te teken, kan die merking so iets so lyk:
+
+
+
+
$ git tag -s v1.5 -m 'my signed 1.5 tag'
+You need a passphrase to unlock the secret key for
+user: "Scott Chacon <schacon@gmail.com>"
+1024-bit DSA key, ID F721C45A, created 2009-02-09
+
+
+
+
As jy wel jou merkers teken, het jy dalk die probleem om die publieke PGP-sleutel wat gebruik word om jou merkers te teken, te versprei.
+Die instandhouer van die Git-projek het hierdie kwessie opgelos deur hul publieke sleutel as 'n blob in die bewaarplek in te sluit en dan 'n merker by te voeg wat direk na daardie inhoud wys.
+Om dit te doen, kan jy uitvind watter sleutel jy wil hê deur gpg --list-keys uit te voer:
+
+
+
+
$ gpg --list-keys
+/Users/schacon/.gnupg/pubring.gpg
+---------------------------------
+pub 1024D/F721C45A 2009-02-09 [expires: 2010-02-09]
+uid Scott Chacon <schacon@gmail.com>
+sub 2048g/45D02282 2009-02-09 [expires: 2010-02-09]
+
+
+
+
Dan kan jy die sleutel direk in die Git-databasis invoer deur dit te eksporteer en dit deur git hash-object te pyp, wat 'n nuwe blob met daardie inhoud in Git skryf en vir jou die SHA-1 van die blob teruggee:
+
+
+
+
$ gpg -a --export F721C45A | git hash-object -w --stdin
+659ef797d181633c87ec71ac3f9ba29fe5775b92
+
+
+
+
Nou dat jy die inhoud van jou sleutel in Git het, kan jy 'n merker skep wat direk daarna wys deur die nuwe SHA-1 waarde te spesifiseer wat die hash-object opdrag vir jou gegee het:
+
+
+
+
$ git tag -a maintainer-pgp-pub 659ef797d181633c87ec71ac3f9ba29fe5775b92
+
+
+
+
As jy git push --tags uitvoer, sal die maintainer-pgp-pub merker met almal gedeel word.
+As iemand 'n merker wil verifieer, kan hulle jou PGP-sleutel direk invoer deur die blob direk uit die databasis te pull en dit in GPG in te voer:
+
+
+
+
$ git show maintainer-pgp-pub | gpg --import
+
+
+
+
Hulle kan daardie sleutel gebruik om al jou getekende merkers te verifieer.
+Ook, as jy instruksies in die merkerboodskap insluit, sal die uitvoering van git show <tag> jou in staat stel om die eindgebruiker meer spesifieke instruksies oor merkerverifikasie te gee.
+
+
+
Generering van 'n Bou-nommer (Generating a Build Number)
+
+
+Omdat Git nie monotoon toenemende nommers soos 'v123' of die ekwivalent het om by elke vaslegging te pas nie, as jy 'n mensleesbare naam wil hê om by 'n vaslegging te pas, kan jy git describe op daardie vaslegging uitvoer.
+In reaksie daarop genereer Git 'n string wat bestaan uit die naam van die mees resente merker vroeër as daardie vaslegging, gevolg deur die aantal vasleggings sedert daardie merker, gevolg uiteindelik deur 'n gedeeltelijke SHA-1 waarde van die vaslegging wat beskryf word (voorafgegaan deur die letter "g" wat Git beteken):
+
+
+
+
$ git describe master
+v1.6.2-rc1-20-g8c5b85c
+
+
+
+
Op hierdie manier kan jy 'n momentopname of bou (build) eksporteer en dit noem iets wat verstaanbaar is vir mense.
+Trouens, as jy Git bou vanaf bronkode gekloon uit die Git-bewaarplek, gee git --version vir jou iets wat so lyk.
+As jy 'n vaslegging beskryf wat jy direk gemerk het, gee dit vir jou eenvoudig die merikernaam.
+
+
+
By verstek vereis die git describe opdrag geannoteerde merkers (merkers geskep met die -a of -s vlag); as jy ook wil voordeel trek uit liggewig (nie-geannoteerde) merkers, voeg die --tags opsie by die opdrag.
+Jy kan ook hierdie string gebruik as die teiken van 'n git checkout of git show opdrag, alhoewel dit staatmaak op die afgebeorte (abbreviated) SHA-1 waarde aan die einde, sodat dit dalk nie vir ewig geldig mag wees nie.
+Byvoorbeeld, die Linux-kern het onlangs gespring van 8 na 10 karakters om te verseker dat SHA-1 objekte uniek is, sodat ouer git describe afvoername ongeldig gemaak is.
+
+
+
Voorbereiding van 'n Vrystelling (Preparing a Release)
+
+
+Nou wil jy 'n bou (build) vrystel.
+Een van die dinge wat jy wil doen, is om 'n argief van die nuutste momentopname van jou kode te skep vir daardie arme siele wat nie Git gebruik nie.
+Die opdrag om dit te doen is git archive:
+
+
+
+
$ git archive master --prefix='project/' | gzip > `git describe master`.tar.gz
+$ ls *.tar.gz
+v1.6.2-rc1-20-g8c5b85c.tar.gz
+
+
+
+
As iemand daardie teerbal (tarball) oopmaak, kry hulle die nuutste momentopname van jou projek onder 'n project gids.
+Jy kan ook 'n zip-argief op baie dieselfde manier skep, maar deur die --format=zip opsie aan git archive te gee:
+
+
+
+
$ git archive master --prefix='project/' --format=zip > `git describe master`.zip
+
+
+
+
Jy het nou 'n mooi teerbal en 'n zip-argief van jou projekvrystelling wat jy na jou webwerf kan oplaai of aan mense kan e-pos.
+
+
+
Die Kortlog (The Shortlog)
+
+
+Dis tyd om jou poslys van mense wat wil weet wat in jou projek gebeur, te e-pos.
+'n Goeie manier om vinnig 'n soort veranderingslogboek (changelog) te kry van wat by jou projek gevoeg is sedert jou laaste vrystelling of e-pos, is om die git shortlog opdrag te gebruik.
+Dit vat al die vasleggings in die reeks wat jy dit gee, saam; die volgende gee jou byvoorbeeld 'n opsomming van al die vasleggings sedert jou laaste vrystelling, as jou laaste vrystelling v1.0.1 geheet het:
+
+
+
+
$ git shortlog --no-merges master --not v1.0.1
+Chris Wanstrath (6):
+ Add support for annotated tags to Grit::Tag
+ Add packed-refs annotated tag support.
+ Add Grit::Commit#to_patch
+ Update version and History.txt
+ Remove stray `puts`
+ Make ls_tree ignore nils
+
+Tom Preston-Werner (4):
+ fix dates in history
+ dynamic version method
+ Version bump to 1.0.2
+ Regenerated gemspec for version 1.0.2
+
+
+
+
Jy kry 'n skoon opsomming van al die vasleggings sedert v1.0.1, gegroepeer volgens outeur, wat jy na jou lys kan e-pos.
+
+
Summary
+
+
You should feel fairly comfortable contributing to a project in Git as well as maintaining your own project or integrating other users' contributions.
+Congratulations on being an effective Git developer!
+In the next chapter, you’ll learn about how to use the largest and most popular Git hosting service, GitHub.
+
Die vasleggingsgeskiedenis (Commit History) bekyk
+
+
Nadat jy verskeie vasleggings (commits) geskep het, of as jy 'n bewaarplek (repository) met 'n bestaande vasleggingsgeskiedenis gekloon (cloned) het, sal jy waarskynlik wil terugkyk om te sien wat gebeur het.
+Die mees basiese en kragtige instrument om dit te doen, is die git log opdrag.
+
+
Hierdie voorbeelde gebruik 'n baie eenvoudige projek genaamd “simplegit”.
+Om die projek te kry, voer uit:
+
+
+
$ git clone https://github.com/schacon/simplegit-progit
+
+
+
Wanneer jy git log in hierdie projek uitvoer, behoort jy afvoer (output) te kry wat min of meer so lyk:
+
+
+
$ git log
+commit ca82a6dff817ec66f44342007202690a93763949
+Author: Scott Chacon <schacon@gee-mail.com>
+Date: Mon Mar 17 21:52:11 2008 -0700
+
+ Change version number
+
+commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
+Author: Scott Chacon <schacon@gee-mail.com>
+Date: Sat Mar 15 16:40:33 2008 -0700
+
+ Remove unnecessary test
+
+commit a11bef06a3f659402fe7563abf99ad00de2209e6
+Author: Scott Chacon <schacon@gee-mail.com>
+Date: Sat Mar 15 10:31:28 2008 -0700
+
+ Initial commit
+
+
+
By verstek, sonder enige argumente, lys git log die vasleggings (commits) wat in daardie bewaarplek (repository) gemaak is in omgekeerde chronologiese volgorde; dit wil sê, die mees onlangse vasleggings wys eerste.
+Soos jy kan sien, lys hierdie opdrag elke vaslegging met sy SHA-1 kontrolesom (checksum), die outeur (author) se naam en e-pos, die datum geskryf, en die vasleggingsboodskap (commit message).
+
+
'n Groot aantal en verskeidenheid opsies vir die git log opdrag is beskikbaar om vir jou presies te wys waarna jy soek.
+Hier sal ons jou 'n paar van die gewildstes wys.
+
+
Een van die nuttiger opsies is -p of --patch, wat die verskil (die patch afvoer) wys wat in elke vaslegging (commit) ingestel is.
+Jy kan ook die aantal log-inskrywings (log entries) wat vertoon word beperk, soos om -2 te gebruik om slegs die laaste twee inskrywings te wys.
+
+
+
$ git log -p -2
+commit ca82a6dff817ec66f44342007202690a93763949
+Author: Scott Chacon <schacon@gee-mail.com>
+Date: Mon Mar 17 21:52:11 2008 -0700
+
+ Change version number
+
+diff --git a/Rakefile b/Rakefile
+index a874b73..8f94139 100644
+--- a/Rakefile
++++ b/Rakefile
+@@ -5,7 +5,7 @@ require 'rake/gempackagetask'
+ spec = Gem::Specification.new do |s|
+ s.platform = Gem::Platform::RUBY
+ s.name = "simplegit"
+- s.version = "0.1.0"
++ s.version = "0.1.1"
+ s.author = "Scott Chacon"
+ s.email = "schacon@gee-mail.com"
+ s.summary = "A simple gem for using Git in Ruby code."
+
+commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
+Author: Scott Chacon <schacon@gee-mail.com>
+Date: Sat Mar 15 16:40:33 2008 -0700
+
+ Remove unnecessary test
+
+diff --git a/lib/simplegit.rb b/lib/simplegit.rb
+index a0a60ae..47c6340 100644
+--- a/lib/simplegit.rb
++++ b/lib/simplegit.rb
+@@ -18,8 +18,3 @@ class SimpleGit
+ end
+
+ end
+-
+-if $0 == __FILE__
+- git = SimpleGit.new
+- puts git.show
+-end
+
+
+
Hierdie opsie vertoon dieselfde inligting, maar met 'n verskil (diff) wat direk na elke inskrywing volg.
+Dit is baie nuttig vir kodehersiening (code review) of om vinnig te blaai deur wat gebeur het tydens 'n reeks vasleggings (commits) wat 'n medewerker bygevoeg het.
+Jy kan ook 'n reeks opsommende opsies saam met git log gebruik.
+Byvoorbeeld, as jy 'n paar verkorte statistieke vir elke vaslegging (commit) wil sien, kan jy die --stat opsie gebruik:
+
+
+
$ git log --stat
+commit ca82a6dff817ec66f44342007202690a93763949
+Author: Scott Chacon <schacon@gee-mail.com>
+Date: Mon Mar 17 21:52:11 2008 -0700
+
+ Change version number
+
+ Rakefile | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
+Author: Scott Chacon <schacon@gee-mail.com>
+Date: Sat Mar 15 16:40:33 2008 -0700
+
+ Remove unnecessary test
+
+ lib/simplegit.rb | 5 -----
+ 1 file changed, 5 deletions(-)
+
+commit a11bef06a3f659402fe7563abf99ad00de2209e6
+Author: Scott Chacon <schacon@gee-mail.com>
+Date: Sat Mar 15 10:31:28 2008 -0700
+
+ Initial commit
+
+ README | 6 ++++++
+ Rakefile | 23 +++++++++++++++++++++++
+ lib/simplegit.rb | 25 +++++++++++++++++++++++++
+ 3 files changed, 54 insertions(+)
+
+
+
Soos jy kan sien, druk die --stat opsie onder elke vasleggingsinskrywing 'n lys van gewysigde lêers af, hoeveel lêers verander is, en hoeveel reëls in daardie lêers bygevoeg en verwyder is.
+Dit plaas ook 'n opsomming van die inligting aan die einde.
+
+
'n Ander baie nuttige opsie is --pretty.
+Hierdie opsie verander die log-afvoer na ander formate as die verstek.
+'n Paar voorafgeboude opsiewaardes is beskikbaar vir jou om te gebruik.
+Die oneline waarde vir hierdie opsie druk elke vaslegging (commit) op 'n enkele reël af, wat nuttig is as jy na baie vasleggings kyk.
+Daarbenewens wys die short, full, en fuller waardes die afvoer in min of meer dieselfde formaat, maar met onderskeidelik minder of meer inligting:
+
+
+
$ git log --pretty=oneline
+ca82a6dff817ec66f44342007202690a93763949 Change version number
+085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 Remove unnecessary test
+a11bef06a3f659402fe7563abf99ad00de2209e6 Initial commit
+
+
+
Die mees interessante opsiewaarde is format, wat jou toelaat om jou eie log-afvoerformaat te spesifiseer.
+Dit is veral nuttig wanneer jy afvoer genereer vir masjienontleding (machine parsing) — omdat jy die formaat eksplisiet spesifiseer, weet jy dit sal nie verander met opdaterings aan Git nie:
+
+
+
$ git log --pretty=format:"%h - %an, %ar : %s"
+ca82a6d - Scott Chacon, 6 years ago : Change version number
+085bb3b - Scott Chacon, 6 years ago : Remove unnecessary test
+a11bef0 - Scott Chacon, 6 years ago : Initial commit
+
+
+
Jy wonder dalk wat die verskil tussen outeur (author) en vaslêer (committer) is.
+Die outeur is die persoon wat oorspronklik die werk geskryf het, terwyl die vaslêer die persoon is wat die werk laaste toegepas het.
+Dus, as jy 'n pleister (patch) na 'n projek instuur en een van die kernlede (core members) pas die patch toe, kry julle albei erkenning — jy as die outeur, en die kernlid as die vaslêer (committer).
+Ons sal hierdie onderskeid 'n bietjie meer dek in }}">Distributed Git.
+
+
Die oneline en format opsiewaardes is veral nuttig saam met 'n ander log opsie genaamd --graph.
+Hierdie opsie voeg 'n oulike klein ASCII-grafiek by wat jou tak- en saamsmeltingsgeskiedenis (branch and merge history) wys:
+
+
+
$ git log --pretty=format:"%h %s" --graph
+* 2d3acf9 Ignore errors from SIGCHLD on trap
+* 5e3ee11 Merge branch 'master' of https://github.com/dustin/grit.git
+|\
+| * 420eac9 Add method for getting the current branch
+* | 30e367c Timeout code and tests
+* | 5a09431 Add timeout protection to grit
+* | e1193f8 Support for heads with slashes in them
+|/
+* d6016bc Require time for xmlschema
+* 11d191e Merge branch 'defunkt' into local
+
+
+
Hierdie tipe afvoer sal meer interessant word soos ons in die volgende hoofstuk deur vertakking (branching) en saamsmelting (merging) gaan.
+
+
Dit is slegs 'n paar eenvoudige afvoerformateringsopsies vir git log — daar is baie meer.
+}}">Algemene opsies vir git log lys die opsies wat ons tot dusver gedek het, sowel as 'n paar ander algemene formateringsopsies wat nuttig kan wees, saam met hoe dit die afvoer van die log opdrag verander.
+
+Table 2. Algemene opsies vir git log
+
+
+
+
+
+
+
+| Opsie |
+Beskrywing |
+
+
+
+
+-p
|
+Wys die pleister (patch) wat met elke vaslegging (commit) ingestel is. |
+
+
+--stat
|
+Wys statistieke vir lêers wat in elke vaslegging gewysig is. |
+
+
+--shortstat
|
+Vertoon slegs die veranderings/invoegings/skrappings reël van die --stat opdrag. |
+
+
+--name-only
|
+Wys die lys van gewysigde lêers na die vasleggingsinligting. |
+
+
+--name-status
|
+Wys ook die lys van geaffekteerde lêers tesame met bygevoegde/gewysigde/geskrapte inligting. |
+
+
+--abbrev-commit
|
+Wys slegs die eerste paar karakters van die SHA-1 kontrolesom in plaas van al 40. |
+
+
+--relative-date
|
+Vertoon die datum in 'n relatiewe formaat (byvoorbeeld, “2 weeks ago”) in plaas daarvan om die volle datumformaat te gebruik. |
+
+
+--graph
|
+Vertoon 'n ASCII-grafiek van die tak- en saamsmeltingsgeskiedenis (branch and merge history) langs die log-afvoer. |
+
+
+--pretty
|
+Wys vasleggings (commits) in 'n alternatiewe formaat. Opsiewaardes sluit in oneline, short, full, fuller, en format (waar jy jou eie formaat spesifiseer). |
+
+
+--oneline
|
+Kortpad vir --pretty=oneline --abbrev-commit wat saam gebruik word. |
+
+
+
+
+
Log-afvoer Beperk (Limiting Log Output)
+
+
Benewens afvoerformateringsopsies, neem git log 'n aantal nuttige beperkingsopsies (limiting options); dit wil sê, opsies wat jou toelaat om slegs 'n subset van vasleggings (commits) te wys.
+Jy het reeds een so 'n opsie gesien — die -2 opsie, wat slegs die laaste twee vasleggings vertoon.
+Trouens, jy kan -<n> doen, waar n enige heelgetal (integer) is om die laaste n vasleggings te wys.
+In werklikheid is dit onwaarskynlik dat jy dit dikwels sal gebruik, omdat Git by verstek (by default) alle afvoer deur 'n blaai-program (pager) stuur sodat jy net een bladsy log-afvoer op 'n slag sien.
+
+
+
Die tydsbeperkingsopsies (time-limiting options) soos --since en --until is egter baie nuttig.
+Byvoorbeeld, hierdie opdrag kry die lys van vasleggings wat in die afgelope twee weke gemaak is:
+
+
+
+
$ git log --since=2.weeks
+
+
+
+
Hierdie opdrag werk met baie formate — jy kan 'n spesifieke datum soos "2008-01-15" spesifiseer, of 'n relatiewe datum soos "2 years 1 day 3 minutes ago".
+
+
+
Jy kan ook die lys filter na vasleggings (commits) wat by sekere soekkriteria pas.
+Die --author opsie laat jou toe om op 'n spesifieke outeur te filter, en die --grep opsie laat jou soek na sleutelwoorde in die vasleggingsboodskappe (commit messages).
+
+
+
+
+|
+ Note
+ |
+
+
+ Jy kan meer as een instansie van beide die --author en --grep soekkriteria spesifiseer, wat die vasleggingsafvoer sal beperk tot vasleggings wat by enige van die --author patrone en enige van die --grep patrone pas; die byvoeging van die --all-match opsie beperk die afvoer egter verder tot slegs daardie vasleggings wat by alle --grep patrone pas.
+ |
+
+
+
+
+
'n Ander baie nuttige filter is die -S opsie (in die volksmond bekend as Git se “pickaxe” opsie), wat 'n string neem en slegs daardie vasleggings (commits) wys wat die aantal voorkomste van daardie string verander het.
+Byvoorbeeld, as jy die laaste vaslegging wil vind wat 'n verwysing na 'n spesifieke funksie bygevoeg of verwyder het, kan jy dit oproep:
+
+
+
+
$ git log -S function_name
+
+
+
+
Die laaste baie nuttige opsie om as 'n filter na git log deur te gee, is 'n pad (path).
+As jy 'n gids (directory) of lêernaam spesifiseer, kan jy die log-afvoer beperk tot vasleggings wat 'n verandering aan daardie lêers ingestel het.
+Dit is altyd die laaste opsie en word gewoonlik voorafgegaan deur dubbele koppeltekens (--) om die paaie van die opsies te skei:
+
+
+
+
$ git log -- path/to/file
+
+
+
+
+Table 3. Opsies om die afvoer van git log te beperk
+
+
+
+
+
+
+| Opsie |
+Beskrywing |
+
+
+
+
+-<n>
|
+Wys slegs die laaste n vasleggings (commits). |
+
+
+--since, --after
|
+Beperk die vasleggings tot dié wat na die gespesifiseerde datum gemaak is. |
+
+
+--until, --before
|
+Beperk die vasleggings tot dié wat voor die gespesifiseerde datum gemaak is. |
+
+
+--author
|
+Wys slegs vasleggings waar die outeur-inskrywing pas by die gespesifiseerde string. |
+
+
+--committer
|
+Wys slegs vasleggings waar die vaslêer-inskrywing (committer entry) pas by die gespesifiseerde string. |
+
+
+--grep
|
+Wys slegs vasleggings met 'n vasleggingsboodskap (commit message) wat die string bevat. |
+
+
+-S
|
+Wys slegs vasleggings wat kode byvoeg of verwyder wat by die string pas. |
+
+
+
+
+
Byvoorbeeld, as jy wil sien watter vasleggings (commits) wat toetslêers in die Git-bronkodegeskiedenis wysig, in die maand Oktober 2008 deur Junio Hamano vasgelê (committed) is en nie saamsmeltingsvasleggings (merge commits) is nie, kan jy iets soos hierdie uitvoer:
+
+
+
+
$ git log --pretty="%h - %s" --author='Junio C Hamano' --since="2008-10-01" \
+ --before="2008-11-01" --no-merges -- t/
+5610e3b - Fix testcase failure when extended attributes are in use
+acd3b9e - Enhance hold_lock_file_for_{update,append}() API
+f563754 - demonstrate breakage of detached checkout with symbolic link HEAD
+d1a43f2 - reset --hard/read-tree --reset -u: remove unmerged new paths
+51a94af - Fix "checkout --track -b newbranch" on detached HEAD
+b0ad11e - pull: allow "git pull origin $something:$current_branch" into an unborn branch
+
+
+
+
Van die byna 40,000 vasleggings (commits) in die Git-bronkodegeskiedenis, wys hierdie opdrag die 6 wat by daardie kriteria pas.
+
+
+
+
+|
+ Tip
+ |
+
+ Voorkom die vertoning van saamsmeltingsvasleggings (merge commits)
+
+ Afhangende van die werkvloei (workflow) wat in jou bewaarplek (repository) gebruik word, is dit moontlik dat 'n aansienlike persentasie van die vasleggings in jou log-geskiedenis net saamsmeltingsvasleggings (merge commits) is, wat tipies nie baie insiggewend is nie.
+Om te verhoed dat die vertoning van saamsmeltingsvasleggings jou log-geskiedenis bemors, voeg bloot die log opsie --no-merges by.
+ |
+
+
+
+
Dinge ongedaan maak
+
+
Op enige stadium wil jy dalk iets ongedaan maak.
+Hier sal ons 'n paar basiese instrumente hersien om veranderings wat jy gemaak het, ongedaan te maak (undo).
+Wees versigtig, want jy kan nie altyd van hierdie aksies terugrol (revert) nie.
+Dit is een van die min areas in Git waar jy dalk werk kan verloor as jy dit verkeerd doen.
+
+
Een van die algemeenste ongedaan-maak aksies vind plaas wanneer jy te vroeg vaslê (commit) en moontlik vergeet om sommige lêers by te voeg, of jou vasleggingsboodskap (commit message) opmors.
+As jy daardie vaslegging (commit) wil oordoen, maak die bykomende veranderings wat jy vergeet het, berei hulle voor (stage), en lê weer vas (commit) deur die --amend opsie te gebruik:
+
+
Hierdie opdrag neem jou voorbereidingsarea (staging area) en gebruik dit vir die vaslegging (commit).
+As jy geen veranderings sedert jou laaste vaslegging (commit) gemaak het nie (byvoorbeeld, jy voer hierdie opdrag uit onmiddellik na jou vorige vaslegging), sal jou momentopname (snapshot) presies dieselfde lyk, en al wat jy sal verander, is jou vasleggingsboodskap (commit message).
+
+
Dieselfde vasleggingsboodskap-redigeerder (commit-message editor) maak oop, maar dit bevat reeds die boodskap van jou vorige vaslegging (commit).
+Jy kan die boodskap wysig soos altyd, maar dit oorskryf (overwrites) jou vorige vaslegging (commit).
+
+
As 'n voorbeeld, as jy vaslê (commit) en dan besef jy het vergeet om die veranderings voor te berei (stage) in 'n lêer wat jy by hierdie vaslegging (commit) wou voeg, kan jy so iets doen:
+
+
+
$ git commit -m 'Initial commit'
+$ git add forgotten_file
+$ git commit --amend
+
+
+
Jy eindig met 'n enkele vaslegging (commit) — die tweede vaslegging vervang die resultate van die eerste.
+
+
+
+|
+ Note
+ |
+
+
+ Dit is belangrik om te verstaan dat wanneer jy jou laaste vaslegging wysig (amend), jy dit nie soseer regmaak nie, as wat jy dit heeltemal vervang met 'n nuwe, verbeterde vaslegging (commit) wat die ou vaslegging uit die pad stoot en die nuwe vaslegging in sy plek plaas.
+Effektief is dit asof die vorige vaslegging (commit) nooit gebeur het nie, en dit sal nie in jou bewaarplek (repository) se geskiedenis wys nie.
+
+ Die duidelike waarde van die wysiging (amending) van vasleggings (commits) is om klein verbeterings aan jou laaste vaslegging (commit) aan te bring, sonder om jou bewaarplek (repository) se geskiedenis te bemors met vasleggingsboodskappe (commit messages) in die vorm van, “Oeps, vergeet om 'n lêer by te voeg” of “Vervlaks, 'n tikfout in laaste commit reggemaak”.
+ |
+
+
+
+
+
+|
+ Note
+ |
+
+
+ Wysig (amend) slegs vasleggings (commits) wat nog plaaslik (local) is en nie iewers heen opgestuur (pushed) is nie.
+Om voorheen opgestuurde (pushed) vasleggings (commits) te wysig (amend) en die tak (branch) met dwang op te stuur (force push), sal probleme vir jou medewerkers veroorsaak.
+Vir meer inligting oor wat gebeur wanneer jy dit doen en hoe om te herstel as jy aan die ontvangkant is, lees }}">Die Gevare van Rebasing (The Perils of Rebasing).
+ |
+
+
+
+
'n Voorbereide lêer onttrek (Unstaging a Staged File)
+
+
Die volgende twee afdelings demonstreer hoe om met veranderings in jou voorbereidingsarea (staging area) en werkgids (working directory) te werk.
+Die lekker deel is dat die opdrag wat jy gebruik om die toestand van daardie twee areas te bepaal, jou ook herinner hoe om veranderings aan hulle ongedaan te maak.
+Byvoorbeeld, sê nou jy het twee lêers verander en wil hulle as twee aparte veranderings vaslê (commit), maar jy tik per ongeluk git add * en berei albei voor (stage).
+Hoe kan jy een van die twee onttrek (unstage)?
+Die git status opdrag herinner jou:
+
+
+
+
$ git add *
+$ git status
+On branch master
+Changes to be committed:
+ (use "git reset HEAD <file>..." to unstage)
+
+ renamed: README.md -> README
+ modified: CONTRIBUTING.md
+
+
+
+
Net onder die “Changes to be committed” teks, sê dit gebruik git reset HEAD <file>… om te onttrek (unstage).
+So, kom ons gebruik daardie raad om die CONTRIBUTING.md lêer te onttrek (unstage):
+
+
+
+
$ git reset HEAD CONTRIBUTING.md
+Unstaged changes after reset:
+M CONTRIBUTING.md
+$ git status
+On branch master
+Changes to be committed:
+ (use "git reset HEAD <file>..." to unstage)
+
+ renamed: README.md -> README
+
+Changes not staged for commit:
+ (use "git add <file>..." to update what will be committed)
+ (use "git checkout -- <file>..." to discard changes in working directory)
+
+ modified: CONTRIBUTING.md
+
+
+
+
Die opdrag is 'n bietjie vreemd, maar dit werk.
+Die CONTRIBUTING.md lêer is gewysig maar weereens onttrek (unstaged).
+
+
+
+
+|
+ Note
+ |
+
+
+ Dit is waar dat git reset 'n gevaarlike opdrag kan wees, veral as jy die --hard vlag (flag) verskaf.
+In die scenario wat hierbo beskryf is, word die lêer in jou werkgids (working directory) egter nie geraak nie, so dit is relatief veilig.
+ |
+
+
+
+
+
Vir eers is hierdie tower-opdrag al wat jy hoef te weet oor die git reset opdrag.
+Ons sal in baie meer detail ingaan oor wat reset doen en hoe om dit te bemeester om werklik interessante dinge te doen in }}">Reset Ontmystifiseer (Reset Demystified).
+
+
+
'n Gewysigde lêer ongewysig maak (Unmodifying a Modified File)
+
+
Wat as jy besef dat jy nie jou veranderings aan die CONTRIBUTING.md lêer wil behou nie?
+Hoe kan jy dit maklik ongewysig maak — dit terugrol (revert) na hoe dit gelyk het toe jy laas vasgelê (committed) het (of oorspronklik gekloon (cloned) het, of hoe jy dit ook al in jou werkgids (working directory) gekry het)?
+Gelukkig vertel git status jou ook hoe om dit te doen.
+In die laaste voorbeeld se afvoer, lyk die onttrekte area (unstaged area) soos volg:
+
+
+
+
Changes not staged for commit:
+ (use "git add <file>..." to update what will be committed)
+ (use "git checkout -- <file>..." to discard changes in working directory)
+
+ modified: CONTRIBUTING.md
+
+
+
+
Dit vertel jou redelik eksplisiet hoe om die veranderings wat jy gemaak het weg te gooi (discard).
+Kom ons doen wat dit sê:
+
+
+
+
$ git checkout -- CONTRIBUTING.md
+$ git status
+On branch master
+Changes to be committed:
+ (use "git reset HEAD <file>..." to unstage)
+
+ renamed: README.md -> README
+
+
+
+
Jy kan sien dat die veranderings teruggerol (reverted) is.
+
+
+
+
+|
+ Important
+ |
+
+
+ Dit is belangrik om te verstaan dat git checkout — <file> 'n gevaarlike opdrag is.
+Enige plaaslike veranderings wat jy aan daardie lêer gemaak het, is weg — Git het net daardie lêer vervang met die laaste voorbereide (staged) of vasgelegde (committed) weergawe.
+Moet nooit hierdie opdrag gebruik nie, tensy jy absoluut seker is dat jy nie daardie ongestoorde (unsaved) plaaslike veranderings wil hê nie.
+ |
+
+
+
+
+
As jy die veranderings wat jy aan daardie lêer gemaak het, wil behou, maar dit vir eers uit die pad wil kry, sal ons oor wegbêre (stashing) en vertakking (branching) in }}">Git Branching praat; dit is oor die algemeen beter maniere om dinge te hanteer.
+
+
+
Onthou, enigiets wat in Git vasgelê (committed) is, kan byna altyd herstel word.
+Selfs vasleggings (commits) wat op takke (branches) was wat uitgevee is, of vasleggings (commits) wat oorskryf (overwritten) is met 'n --amend vaslegging (commit), kan herstel word (sien }}">Dataherwinning vir dataherwinning).
+Enigiets wat jy egter verloor wat nooit vasgelê (committed) is nie, sal waarskynlik nooit weer gesien word nie.
+
+
+
Dinge ongedaan maak met git restore
+
+
Git weergawe 2.23.0 het 'n nuwe opdrag bekendgestel: git restore.
+Dit is basies 'n alternatief vir git reset wat ons pas gedek het.
+Vanaf Git weergawe 2.23.0 en verder sal Git git restore in plaas van git reset vir baie ongedaan-maak operasies gebruik.
+
+
+
Kom ons gaan terug op ons voetspore en maak dinge met git restore ongedaan in plaas van git reset.
+
+
+
'n Voorbereide lêer onttrek met git restore (Unstaging a Staged File with git restore)
+
+
Die volgende twee afdelings demonstreer hoe om met veranderings in jou voorbereidingsarea (staging area) en werkgids (working directory) met git restore te werk.
+Die lekker deel is dat die opdrag wat jy gebruik om die toestand van daardie twee areas te bepaal, jou ook herinner hoe om veranderings aan hulle ongedaan te maak.
+Byvoorbeeld, sê nou jy het twee lêers verander en wil hulle as twee aparte veranderings vaslê (commit), maar jy tik per ongeluk git add * en berei albei voor (stage).
+Hoe kan jy een van die twee onttrek (unstage)?
+Die git status opdrag herinner jou:
+
+
+
+
$ git add *
+$ git status
+On branch master
+Changes to be committed:
+ (use "git restore --staged <file>..." to unstage)
+ modified: CONTRIBUTING.md
+ renamed: README.md -> README
+
+
+
+
Net onder die “Changes to be committed” teks, sê dit gebruik git restore --staged <file>… om te onttrek (unstage).
+So, kom ons gebruik daardie raad om die CONTRIBUTING.md lêer te onttrek (unstage):
+
+
+
+
$ git restore --staged CONTRIBUTING.md
+$ git status
+On branch master
+Changes to be committed:
+ (use "git restore --staged <file>..." to unstage)
+ renamed: README.md -> README
+
+Changes not staged for commit:
+ (use "git add <file>..." to update what will be committed)
+ (use "git restore <file>..." to discard changes in working directory)
+ modified: CONTRIBUTING.md
+
+
+
+
Die CONTRIBUTING.md lêer is gewysig maar weereens onttrek (unstaged).
+
+
+
+
'n Gewysigde lêer ongewysig maak met git restore (Unmodifying a Modified File with git restore)
+
+
Wat as jy besef dat jy nie jou veranderings aan die CONTRIBUTING.md lêer wil behou nie?
+Hoe kan jy dit maklik ongewysig maak — dit terugrol (revert) na hoe dit gelyk het toe jy laas vasgelê (committed) het (of oorspronklik gekloon (cloned) het, of hoe jy dit ook al in jou werkgids (working directory) gekry het)?
+Gelukkig vertel git status jou ook hoe om dit te doen.
+In die laaste voorbeeld se afvoer, lyk die onttrekte area (unstaged area) soos volg:
+
+
+
+
Changes not staged for commit:
+ (use "git add <file>..." to update what will be committed)
+ (use "git restore <file>..." to discard changes in working directory)
+ modified: CONTRIBUTING.md
+
+
+
+
Dit vertel jou redelik eksplisiet hoe om die veranderings wat jy gemaak het weg te gooi (discard).
+Kom ons doen wat dit sê:
+
+
+
+
$ git restore CONTRIBUTING.md
+$ git status
+On branch master
+Changes to be committed:
+ (use "git restore --staged <file>..." to unstage)
+ renamed: README.md -> README
+
+
+
+
+
+|
+ Important
+ |
+
+
+ Dit is belangrik om te verstaan dat git restore <file> 'n gevaarlike opdrag is.
+Enige plaaslike veranderings wat jy aan daardie lêer gemaak het, is weg — Git het net daardie lêer vervang met die laaste voorbereide (staged) of vasgelegde (committed) weergawe.
+Moet nooit hierdie opdrag gebruik nie, tensy jy absoluut seker is dat jy nie daardie ongestoorde (unsaved) plaaslike veranderings wil hê nie.
+ |
+
+
+
+
+
Git-aliasse
+
+
+Voordat ons aanbeweeg na die volgende hoofstuk, wil ons 'n funksie bekendstel wat jou Git-ervaring eenvoudiger, makliker en meer eie kan maak: aliasse.
+Ter wille van duidelikheid sal ons hulle nêrens anders in hierdie boek gebruik nie, maar as jy voortgaan om Git met enige gereeldheid te gebruik, is aliasse iets waarvan jy behoort te weet.
+
+
Git sal nie outomaties jou opdrag aflei as jy dit net gedeeltelik intik nie.
+As jy niet die hele teks van elke Git-opdrag wil intik nie, kan jy maklik 'n alias vir elke opdrag opstel deur git config te gebruik.
+Hier is 'n paar voorbeelde wat jy dalk sal wil opstel:
+
+
+
$ git config --global alias.co checkout
+$ git config --global alias.br branch
+$ git config --global alias.ci commit
+$ git config --global alias.st status
+
+
+
Dit beteken dat jy, byvoorbeeld, in plaas van git commit te tik, net git ci hoef in te tik.
+Soos jy voortgaan om Git te gebruik, sal jy waarskynlik ook ander opdragte gereeld begin gebruik; moet dus nie huiwer om nuwe aliasse te skep nie.
+
+
Hierdie tegniek kan ook baie nuttig wees om opdragte te skep wat jy dink behoort te bestaan.
+Byvoorbeeld, om die bruikbaarheidsprobleem wat jy ondervind het met die unstaging van 'n lêer reg te stel, kan jy jou eie unstage-alias by Git voeg:
+
+
+
$ git config --global alias.unstage 'reset HEAD --'
+
+
+
Dit maak die volgende twee opdragte gelykwaardig:
+
+
+
$ git unstage fileA
+$ git reset HEAD -- fileA
+
+
+
Dit lyk 'n bietjie duideliker.
+Dit is ook algemeen om 'n last-opdrag by te voeg, soos hierdie:
+
+
+
$ git config --global alias.last 'log -1 HEAD'
+
+
+
Op hierdie manier kan jy die laaste commit maklik sien:
+
+
+
$ git last
+commit 66938dae3329c7aebe598c2246a8e6af90d04646
+Author: Josh Goebel <dreamer3@example.com>
+Date: Tue Aug 26 19:48:51 2008 +0800
+
+ Test for current head
+
+ Signed-off-by: Scott Chacon <schacon@example.com>
+
+
+
Soos jy kan sien, vervang Git eenvoudig die nuwe opdrag met dit waarvoor jy dit 'n alias gegee het.
+Miskien wil jy egter 'n eksterne opdrag uitvoer, in plaas van 'n Git-subopdrag.
+In daardie geval begin jy die opdrag met 'n ! karakter.
+Dit is nuttig as jy jou eie nutsmiddels skryf wat met 'n Git-bewaarplek (repository) werk.
+Ons kan dit demonstreer deur 'n alias vir git visual te maak sodat dit gitk uitvoer:
+
+
+
$ git config --global alias.visual '!gitk'
+
+
Summary
+
+
At this point, you can do all the basic local Git operations — creating or cloning a repository, making changes, staging and committing those changes, and viewing the history of all the changes the repository has been through.
+Next, we’ll cover Git’s killer feature: its branching model.
+
Tagging
+
+
+Soos die meeste VCS’e, het Git die vermoë om spesifieke punte in 'n bewaarplek (repository) se geskiedenis as belangrik te tag.
+Gewoonlik gebruik mense hierdie funksionaliteit om vrystellingspunte (release points) te merk (v1.0, v2.0 en so aan).
+In hierdie afdeling sal jy leer hoe om bestaande tags te lys, hoe om tags te skep en uit te vee, en wat die verskillende tipes tags is.
+
+
+
+
Om die bestaande tags in Git te lys, is eenvoudig.
+Tik net git tag (met 'n opsionele -l of --list):
+
+
+
+
Hierdie opdrag lys die tags in alfabetiese volgorde; die volgorde waarin hulle vertoon word, het geen werklike betekenis nie.
+
+
+
Jy kan ook soek vir tags wat by 'n spesifieke patroon pas.
+Die Git bron-bewaarplek (source repo), byvoorbeeld, bevat meer as 500 tags.
+As jy net daarin belangstel om na die 1.8.5-reeks te kyk, kan jy hierdie uitvoer:
+
+
+
+
$ git tag -l "v1.8.5*"
+v1.8.5
+v1.8.5-rc0
+v1.8.5-rc1
+v1.8.5-rc2
+v1.8.5-rc3
+v1.8.5.1
+v1.8.5.2
+v1.8.5.3
+v1.8.5.4
+v1.8.5.5
+
+
+
+
+
+|
+ Note
+ |
+
+ Om tag-wildcards te lys vereis die -l of --list opsie
+
+ As jy net die hele lys van tags wil hê, neem die git tag opdrag implisiet aan dat jy 'n lys wil hê en verskaf een; die gebruik van -l of --list in hierdie geval is opsioneel.
+
+ As jy egter 'n wildcard-patroon verskaf om by tag-name te pas, is die gebruik van -l of --list verpligtend.
+ |
+
+
+
+
+
+
+
Git ondersteun twee tipes tags: lightweight (liggewig) en annotated (geannoteer).
+
+
+
'n Lightweight tag is baie soos 'n branch wat nie verander nie — dit is net 'n wyser (pointer) na 'n spesifieke commit.
+
+
+
Annotated tags word egter as volledige objekte in die Git-databasis gestoor.
+Hulle het 'n kontrolesom (checksum); bevat die tagger se naam, e-pos, en datum; het 'n tag-boodskap; en kan met GNU Privacy Guard (GPG) geteken en geverifieer word.
+Dit word oor die algemeen aanbeveel dat jy annotated tags skep sodat jy al hierdie inligting kan hê; maar as jy 'n tydelike tag wil hê of om een of ander rede nie die ander inligting wil behou nie, is lightweight tags ook beskikbaar.
+
+
+
+
+
+Om 'n annotated tag in Git te skep, is eenvoudig.
+Die maklikste manier is om -a te spesifiseer wanneer jy die tag opdrag uitvoer:
+
+
+
+
$ git tag -a v1.4 -m "my version 1.4"
+$ git tag
+v0.1
+v1.3
+v1.4
+
+
+
+
Die -m spesifiseer 'n tag-boodskap, wat saam met die tag gestoor word.
+As jy nie 'n boodskap vir 'n annotated tag spesifiseer nie, maak Git jou redigeerder (editor) oop sodat jy dit kan intik.
+
+
+
Jy kan die tag-data saam met die commit wat getag is sien deur die git show opdrag te gebruik:
+
+
+
+
$ git show v1.4
+tag v1.4
+Tagger: Ben Straub <ben@straub.cc>
+Date: Sat May 3 20:19:12 2014 -0700
+
+my version 1.4
+
+commit ca82a6dff817ec66f44342007202690a93763949
+Author: Scott Chacon <schacon@gee-mail.com>
+Date: Mon Mar 17 21:52:11 2008 -0700
+
+ Change version number
+
+
+
+
Dit wys die tagger-inligting, die datum waarop die commit getag is, en die annotasie-boodskap voordat die commit-inligting gewys word.
+
+
+
+
+
+Nog 'n manier om commits te tag is met 'n lightweight tag.
+Dit is basies die commit-checksum wat in 'n lêer gestoor word — geen ander inligting word behou nie.
+Om 'n lightweight tag te skep, moenie enige van die -a, -s, of -m opsies verskaf nie, verskaf net 'n tag-naam:
+
+
+
+
$ git tag v1.4-lw
+$ git tag
+v0.1
+v1.3
+v1.4
+v1.4-lw
+v1.5
+
+
+
+
Hierdie keer, as jy git show op die tag uitvoer, sien jy nie die ekstra tag-inligting nie.
+Die opdrag wys net die commit:
+
+
+
+
$ git show v1.4-lw
+commit ca82a6dff817ec66f44342007202690a93763949
+Author: Scott Chacon <schacon@gee-mail.com>
+Date: Mon Mar 17 21:52:11 2008 -0700
+
+ Change version number
+
+
+
+
Later tag
+
+
Jy kan ook commits tag nadat jy verby hulle beweeg het.
+Veronderstel jou commit-geskiedenis lyk so:
+
+
+
+
$ git log --pretty=oneline
+15027957951b64cf874c3557a0f3547bd83b3ff6 Merge branch 'experiment'
+a6b4c97498bd301d84096da251c98a07c7723e65 Create write support
+0d52aaab4479697da7686c15f77a3d64d9165190 One more thing
+6d52a271eda8725415634dd79daabbc4d9b6008e Merge branch 'experiment'
+0b7434d86859cc7b8c3d5e1dddfed66ff742fcbc Add commit function
+4682c3261057305bdd616e23b64b0857d832627b Add todo file
+166ae0c4d3f420721acbb115cc33848dfcc2121a Create write support
+9fceb02d0ae598e95dc970b74767f19372d61af8 Update rakefile
+964f16d36dfccde844893cac5b347e7b3d44abbc Commit the todo
+8a5cbc430f1a9c3d00faaeffd07798508422908a Update readme
+
+
+
+
Veronderstel nou jy het vergeet om die projek by v1.2 te tag, wat by die “Update rakefile” commit was.
+Jy kan dit agterna byvoeg.
+Om daardie commit te tag, spesifiseer jy die commit-checksum (of 'n deel daarvan) aan die einde van die opdrag:
+
+
+
+
$ git tag -a v1.2 9fceb02
+
+
+
+
Jy kan sien dat jy die commit getag het:
+
+
+
+
$ git tag
+v0.1
+v1.2
+v1.3
+v1.4
+v1.4-lw
+v1.5
+
+$ git show v1.2
+tag v1.2
+Tagger: Scott Chacon <schacon@gee-mail.com>
+Date: Mon Feb 9 15:32:16 2009 -0800
+
+version 1.2
+commit 9fceb02d0ae598e95dc970b74767f19372d61af8
+Author: Magnus Chacon <mchacon@gee-mail.com>
+Date: Sun Apr 27 20:43:35 2008 -0700
+
+ Update rakefile
+...
+
+
+
+
+
+
By verstek dra die git push opdrag nie tags oor na remote bedieners nie.
+Jy sal tags eksplisiet na 'n gedeelde bediener moet push nadat jy hulle geskep het.
+Hierdie proses is net soos om remote branches te deel — jy kan git push origin <tagnaam> uitvoer.
+
+
+
+
$ git push origin v1.5
+Counting objects: 14, done.
+Delta compression using up to 8 threads.
+Compressing objects: 100% (12/12), done.
+Writing objects: 100% (14/14), 2.05 KiB | 0 bytes/s, done.
+Total 14 (delta 3), reused 0 (delta 0)
+To git@github.com:schacon/simplegit.git
+ * [new tag] v1.5 -> v1.5
+
+
+
+
As jy baie tags het wat jy gelyktydig wil op-push, kan jy ook die --tags opsie by die git push opdrag gebruik.
+Dit sal al jou tags wat nog nie daar is nie, na die remote bediener oordra.
+
+
+
+
$ git push origin --tags
+Counting objects: 1, done.
+Writing objects: 100% (1/1), 160 bytes | 0 bytes/s, done.
+Total 1 (delta 0), reused 0 (delta 0)
+To git@github.com:schacon/simplegit.git
+ * [new tag] v1.4 -> v1.4
+ * [new tag] v1.4-lw -> v1.4-lw
+
+
+
+
Nou, wanneer iemand anders jou bewaarplek (repository) kloon of daaruit pull, sal hulle ook al jou tags kry.
+
+
+
+
+|
+ Note
+ |
+
+
+git push push beide tipes tags
+
+ git push <remote> --tags sal beide lightweight en annotated tags push.
+Daar is tans geen opsie om slegs lightweight tags te push nie, maar as jy git push <remote> --follow-tags gebruik sal slegs annotated tags na die remote gepush word.
+ |
+
+
+
+
+
+
+
Om 'n tag op jou plaaslike bewaarplek te verwyder, kan jy git tag -d <tagnaam> gebruik.
+Byvoorbeeld, ons kan ons lightweight tag hierbo as volg verwyder:
+
+
+
+
$ git tag -d v1.4-lw
+Deleted tag 'v1.4-lw' (was e7d5add)
+
+
+
+
Let daarop dat dit nie die tag van enige remote bedieners verwyder nie.
+Daar is twee algemene variasies om 'n tag van 'n remote bediener uit te vee.
+
+
+
Die eerste variasie is git push <remote> :refs/tags/<tagnaam>:
+
+
+
+
$ git push origin :refs/tags/v1.4-lw
+To /git@github.com:schacon/simplegit.git
+ - [deleted] v1.4-lw
+
+
+
+
Die manier om bogenoemde te interpreteer, is om dit te lees as dat die nul-waarde voor die dubbelpunt na die remote tag-naam gepush word, wat dit effektief uitvee.
+
+
+
Die tweede (en meer intuïtiewe) manier om 'n remote tag uit te vee is met:
+
+
+
+
$ git push origin --delete <tagnaam>
+
+
+
+
+
+
As jy na die weergawes van lêers waarna 'n tag wys wil kyk, kan jy 'n git checkout van daardie tag doen, alhoewel dit jou bewaarplek in 'n “detached HEAD” toestand plaas, wat 'n paar slegte newe-effekte het:
+
+
+
+
$ git checkout v2.0.0
+Note: switching to 'v2.0.0'.
+
+You are in 'detached HEAD' state. You can look around, make experimental
+changes and commit them, and you can discard any commits you make in this
+state without impacting any branches by performing another checkout.
+
+If you want to create a new branch to retain commits you create, you may
+do so (now or later) by using -c with the switch command. Example:
+
+ git switch -c <new-branch-name>
+
+Or undo this operation with:
+
+ git switch -
+
+Turn off this advice by setting config variable advice.detachedHead to false
+
+HEAD is now at 99ada87... Merge pull request #89 from schacon/appendix-final
+
+$ git checkout v2.0-beta-0.1
+Previous HEAD position was 99ada87... Merge pull request #89 from schacon/appendix-final
+HEAD is now at df3f601... Add atlas.json and cover image
+
+
+
+
In 'n “detached HEAD” toestand, as jy veranderinge maak en dan 'n commit skep, sal die tag dieselfde bly, maar jou nuwe commit sal nie aan enige branch behoort nie en sal onbereikbaar wees, behalwe deur die presiese commit-hash te gebruik.
+Dus, as jy veranderinge moet maak — sê nou jy is besig om 'n fout op 'n ouer weergawe reg te maak — sal jy oor die algemeen 'n branch wil skep:
+
+
+
+
$ git checkout -b version2 v2.0.0
+Switched to a new branch 'version2'
+
+
+
+
As jy dit doen en 'n commit maak, sal jou version2 branch effens anders wees as jou v2.0.0 tag aangesien dit vorentoe sal beweeg met jou nuwe veranderinge, so wees versigtig.
+
+
Veranderinge aan die repository vaslê
+
+
Op hierdie stadium behoort jy 'n ware Git repository op jou plaaslike masjien te hê, en 'n checkout of werkkopie van al sy lêers voor jou.
+Normaalweg sal jy veranderinge wil begin maak en snapshots van daardie veranderinge na jou repository commit elke keer as die projek 'n toestand bereik wat jy wil vaslê.
+
+
Onthou dat elke lêer in jou werkdirectory in een van twee toestande kan wees: tracked of untracked.
+Tracked lêers is lêers wat in die laaste snapshot was, asook enige nuwe gestagede lêers; hulle kan ongewysig (unmodified), gewysig (modified) of klaargesit (staged) wees.
+Kortom, tracked lêers is lêers waarvan Git bewus is.
+
+
Untracked lêers is alles anders — enige lêers in jou werkdirectory wat nie in jou laaste snapshot was nie en ook nie in jou staging area is nie.
+Wanneer jy vir die eerste keer 'n repository kloon, sal al jou lêers tracked en ongewysig wees, omdat Git dit pas uitgecheck het en jy nog niks geredigeer het nie.
+
+
Sodra jy lêers redigeer, sien Git hulle as modified, omdat jy hulle verander het sedert jou laaste commit.
+Terwyl jy werk, stage jy selektief hierdie gewysigde lêers en commit dan al daardie gestagede veranderinge, en die siklus herhaal homself.
+
+
+
}}" alt="Die lewensiklus van die status van jou lêers">
+
+
Figure 8. Die lewensiklus van die status van jou lêers
+
+
Die status van jou lêers nagaan
+
+
Die hoofhulpmiddel wat jy gebruik om te bepaal watter lêers in watter toestand is, is die git status opdrag.
+As jy hierdie opdrag direk na 'n kloon uitvoer, behoort jy iets soos die volgende te sien:
+
+
+
+
$ git status
+On branch master
+Your branch is up-to-date with 'origin/master'.
+nothing to commit, working tree clean
+
+
+
+
Dit beteken jy het 'n skoon werkdirectory; met ander woorde, daar is geen tracked lêers wat gewysig is nie.
+Git sien ook geen untracked lêers nie, anders sou hulle hier gelys word.
+Ten slotte vertel die opdrag jou op watter tak (branch) jy is en lig jou in dat dit nie afgewyk het van dieselfde tak op die bediener nie.
+Vir eers is daardie tak altyd master, wat die verstek is; jy hoef jou nog nie daaroor te bekommer nie.
+}}">Git Branching sal takke en verwysings in detail behandel.
+
+
+
+
+|
+ Note
+ |
+
+
+ GitHub het in middel-2020 die verstek taknaam van master na main verander, en ander Git gashere het gevolg.
+Jy mag dus vind dat die verstek taknaam in sommige nuutgeskepte repositories main is en nie master nie.
+Daarbenewens kan die verstek taknaam verander word (soos jy gesien het in }}">[_new_default_branch]), so jy sal moontlik 'n ander naam vir die verstek tak sien.
+
+ Alhoewel, Git self gebruik steeds master as die verstek, dus sal ons dit regdeur die boek gebruik.
+ |
+
+
+
+
+
Kom ons sê jy voeg 'n nuwe lêer by jou projek, 'n eenvoudige README lêer.
+As die lêer voorheen nog nie bestaan het nie, en jy voer git status uit, sal jy jou untracked lêer soos volg sien:
+
+
+
+
$ echo 'My Project' > README
+$ git status
+On branch master
+Your branch is up-to-date with 'origin/master'.
+Untracked files:
+ (use "git add <file>..." to include in what will be committed)
+
+ README
+
+nothing added to commit but untracked files present (use "git add" to track)
+
+
+
+
Jy kan sien dat jou nuwe README lêer untracked is, omdat dit onder die “Untracked files” opskrif in jou status uitvoer staan.
+Untracked beteken basies dat Git 'n lêer sien wat jy nie in die vorige snapshot (commit) gehad het nie, en wat nog nie gestaged is nie; Git sal dit nie in jou commit snapshots begin insluit totdat jy dit uitdruklik aansê om dit te doen nie.
+Dit doen dit sodat jy nie per ongeluk gegenereerde binêre lêers of ander lêers insluit wat jy nie bedoel het om in te sluit nie.
+Jy wil wel die README insluit, so kom ons begin die lêer track.
+
+
+
Nuwe lêers track
+
+
Om 'n nuwe lêer te begin track, gebruik jy die git add opdrag.
+Om die README lêer te begin track, kan jy dit uitvoer:
+
+
+
+
As jy jou status opdrag weer uitvoer, kan jy sien dat jou README lêer nou tracked en staged is om gecommit te word:
+
+
+
+
$ git status
+On branch master
+Your branch is up-to-date with 'origin/master'.
+Changes to be committed:
+ (use "git restore --staged <file>..." to unstage)
+
+ new file: README
+
+
+
+
Jy kan sien dat dit gestaged is omdat dit onder die “Changes to be committed” opskrif gelys is.
+As jy op hierdie punt commit, sal die weergawe van die lêer op die tydstip wat jy git add uitgevoer het, in die daaropvolgende historiese snapshot bygevoeg word.
+Jy onthou dalk dat toe jy vroeër git init uitgevoer het, jy daarna git add <files> uitgevoer het — dit was om lêers in jou directory te begin track.
+Die git add opdrag neem 'n padnaam in vir óf 'n lêer óf 'n directory; as dit 'n directory is, voeg die opdrag al die lêers in daardie directory rekursief by.
+
+
+
Gewysigde lêers stage
+
+
Kom ons verander 'n lêer wat reeds tracked was.
+As jy 'n voorheen tracked lêer genaamd CONTRIBUTING.md wysig en dan weer jou git status opdrag uitvoer, kry jy iets wat so lyk:
+
+
+
+
$ git status
+On branch master
+Your branch is up-to-date with 'origin/master'.
+Changes to be committed:
+ (use "git reset HEAD <file>..." to unstage)
+
+ new file: README
+
+Changes not staged for commit:
+ (use "git add <file>..." to update what will be committed)
+ (use "git checkout -- <file>..." to discard changes in working directory)
+
+ modified: CONTRIBUTING.md
+
+
+
+
Die CONTRIBUTING.md lêer verskyn onder 'n afdeling genaamd “Changes not staged for commit” — wat beteken dat 'n lêer wat tracked is, in die werkdirectory gewysig is maar nog nie gestaged is nie.
+Om dit te stage, voer jy die git add opdrag uit.
+git add is 'n veeldoelige opdrag — jy gebruik dit om nuwe lêers te begin track, om lêers te stage, en om ander dinge te doen soos om lêers met 'n merge-konflik as opgelos te merk.
+Dit mag help om daaraan te dink as “voeg presies hierdie inhoud by die volgende commit” eerder as “voeg hierdie lêer by die projek”.
+Kom ons voer nou git add uit om die CONTRIBUTING.md lêer te stage, en voer dan weer git status uit:
+
+
+
+
$ git add CONTRIBUTING.md
+$ git status
+On branch master
+Your branch is up-to-date with 'origin/master'.
+Changes to be committed:
+ (use "git reset HEAD <file>..." to unstage)
+
+ new file: README
+ modified: CONTRIBUTING.md
+
+
+
+
Beide lêers is gestaged en sal in jou volgende commit ingaan.
+Op hierdie stadium onthou jy dalk nog een klein verandering wat jy wil maak in CONTRIBUTING.md voordat jy dit commit.
+Jy maak dit weer oop en maak daardie verandering, en jy is gereed om te commit.
+Kom ons voer egter git status nog een keer uit:
+
+
+
+
$ vim CONTRIBUTING.md
+$ git status
+On branch master
+Your branch is up-to-date with 'origin/master'.
+Changes to be committed:
+ (use "git reset HEAD <file>..." to unstage)
+
+ new file: README
+ modified: CONTRIBUTING.md
+
+Changes not staged for commit:
+ (use "git add <file>..." to update what will be committed)
+ (use "git checkout -- <file>..." to discard changes in working directory)
+
+ modified: CONTRIBUTING.md
+
+
+
+
Wat gaan hier aan?
+Nou word CONTRIBUTING.md as beide gestaged en unstaged gelys.
+Hoe is dit moontlik?
+Dit blyk dat Git 'n lêer stage presies soos dit is wanneer jy die git add opdrag uitvoer.
+As jy nou commit, sal die weergawe van CONTRIBUTING.md soos dit was toe jy laas die git add opdrag uitgevoer het in die commit beland, nie die weergawe van die lêer soos dit in jou werkdirectory lyk wanneer jy git commit uitvoer nie.
+As jy 'n lêer wysig nadat jy git add uitgevoer het, moet jy weer git add uitvoer om die nuutste weergawe van die lêer te stage:
+
+
+
+
$ git add CONTRIBUTING.md
+$ git status
+On branch master
+Your branch is up-to-date with 'origin/master'.
+Changes to be committed:
+ (use "git reset HEAD <file>..." to unstage)
+
+ new file: README
+ modified: CONTRIBUTING.md
+
+
+
+
Kort status
+
+
Terwyl die git status uitvoer redelik omvattend is, is dit ook nogal woordryk.
+Git het ook 'n kort status vlag sodat jy jou veranderinge op 'n meer kompakte manier kan sien.
+As jy git status -s of git status --short uitvoer, kry jy 'n baie eenvoudiger uitvoer van die opdrag:
+
+
+
+
$ git status -s
+ M README
+MM Rakefile
+A lib/git.rb
+M lib/simplegit.rb
+?? LICENSE.txt
+
+
+
+
Nuwe lêers wat nie tracked is nie het 'n ?? langs hulle, nuwe lêers wat by die staging area bygevoeg is het 'n A, gewysigde lêers het 'n M en so aan.
+Daar is twee kolomme in die uitvoer — die linkerkolom dui die status van die staging area aan en die regterkolom dui die status van die werkdirectory aan.
+So byvoorbeeld in daardie uitvoer is die README lêer gewysig in die werkdirectory maar nog nie gestaged nie, terwyl die lib/simplegit.rb lêer gewysig en gestaged is.
+Die Rakefile is gewysig, gestaged en toe weer gewysig, so daar is veranderinge daaraan wat beide gestaged en unstaged is.
+
+
+
Lêers ignoreer
+
+
Dikwels sal jy 'n klas lêers hê wat jy nie wil hê Git outomaties moet byvoeg of selfs as untracked vir jou wys nie.
+Dit is oor die algemeen outomaties gegenereerde lêers soos loglêers of lêers wat deur jou bou-stelsel geproduseer word.
+In sulke gevalle kan jy 'n lêer skep met die naam .gitignore wat patrone bevat om by hulle te pas.
+Hier is 'n voorbeeld van 'n .gitignore lêer:
+
+
+
+
$ cat .gitignore
+*.[oa]
+*~
+
+
+
+
Die eerste reël sê vir Git om enige lêers te ignoreer wat op “.o” of “.a” eindig — objek- en argieflêers wat dalk die produk van jou kodebouery is.
+Die tweede reël sê vir Git om alle lêers te ignoreer waarvan die name met 'n tilde (~) eindig, wat deur baie teksredigeerders soos Emacs gebruik word om tydelike lêers te merk.
+Jy kan ook 'n log, tmp, of pid directory insluit; outomaties gegenereerde dokumentasie; en so meer.
+Om 'n .gitignore lêer vir jou nuwe repository op te stel voordat jy aan die gang kom, is oor die algemeen 'n goeie idee sodat jy nie per ongeluk lêers commit wat jy regtig nie in jou Git repository wil hê nie.
+
+
+
Die reëls vir die patrone wat jy in die .gitignore lêer kan plaas, is soos volg:
+
+
+
+-
+
Leë reëls of reëls wat met # begin, word geïgnoreer.
+
+-
+
Standaard glob-patrone werk, en sal rekursief regdeur die hele werkdirectory toegepas word.
+
+-
+
Jy kan patrone met 'n vorentoe skuinsstreep (/) begin om rekursie te vermy.
+
+-
+
Jy kan patrone met 'n vorentoe skuinsstreep (/) eindig om 'n directory te spesifiseer.
+
+-
+
Jy kan 'n patroon ontken (negate) deur dit met 'n uitroepteken (!) te begin.
+
+
+
+
+
Glob-patrone is soos vereenvoudigde gereelde uitdrukkings (regular expressions) wat shells gebruik.
+'n Sterretjie ([abc] pas by enige karakter binne die blokhakies (in hierdie geval a, b, of c); 'n vraagteken (?) pas by 'n enkele karakter; en blokhakies wat karakters insluit wat deur 'n streepie geskei is ([0-9]), pas by enige karakter tussen hulle (in hierdie geval 0 tot 9).
+Jy kan ook twee sterretjies gebruik om geneste directories te pas; a/*/z sal by a/z, a/b/z, a/b/c/z, en so aan pas.
+
+
+
Hier is nog 'n voorbeeld van 'n .gitignore lêer:
+
+
+
+
# ignore all .a files
+*.a
+
+# but do track lib.a, even though you're ignoring .a files above
+!lib.a
+
+# only ignore the TODO file in the current directory, not subdir/TODO
+/TODO
+
+# ignore all files in any directory named build
+build/
+
+# ignore doc/notes.txt, but not doc/server/arch.txt
+doc/*.txt
+
+# ignore all .pdf files in the doc/ directory and any of its subdirectories
+doc/**/*.pdf
+
+
+
+
+
+|
+ Tip
+ |
+
+
+ GitHub onderhou 'n redelik omvattende lys van goeie .gitignore lêer voorbeelde vir dosyne projekte en tale by https://github.com/github/gitignore as jy 'n beginpunt vir jou projek wil hê.
+ |
+
+
+
+
+
+
+|
+ Note
+ |
+
+
+ In die eenvoudige geval kan 'n repository 'n enkele .gitignore lêer in sy wortel-directory hê, wat rekursief op die hele repository van toepassing is.
+Dit is egter ook moontlik om bykomende .gitignore lêers in subgidse (subdirectories) te hê.
+Die reëls in hierdie geneste .gitignore lêers is slegs van toepassing op die lêers onder die directory waar hulle geplaas is.
+Die Linux kernel bron-repository het 206 .gitignore lêers.
+
+ Dit val buite die bestek van hierdie boek om in te gaan op die besonderhede van veelvuldige .gitignore lêers; sien man gitignore vir die besonderhede.
+ |
+
+
+
+
+
Jou gestagede en unstaged veranderinge bekyk
+
+
As die git status opdrag te vaag is vir jou — jy wil presies weet wat jy verander het, nie net watter lêers verander is nie — kan jy die git diff opdrag gebruik.
+Ons sal git diff later in meer detail behandel, maar jy sal dit waarskynlik die meeste gebruik om hierdie twee vrae te beantwoord: Wat het jy verander maar nog nie gestaged nie?
+En wat het jy gestaged wat jy op die punt staan om te commit?
+Alhoewel git status daardie vrae baie algemeen beantwoord deur die lêername te lys, wys git diff jou die presiese reëls wat bygevoeg en verwyder is — die patch, as’t ware.
+
+
+
Kom ons sê jy wysig en stage die README lêer weer en wysig dan die CONTRIBUTING.md lêer sonder om dit te stage.
+As jy jou git status opdrag uitvoer, sien jy weereens iets soos hierdie:
+
+
+
+
$ git status
+On branch master
+Your branch is up-to-date with 'origin/master'.
+Changes to be committed:
+ (use "git reset HEAD <file>..." to unstage)
+
+ modified: README
+
+Changes not staged for commit:
+ (use "git add <file>..." to update what will be committed)
+ (use "git checkout -- <file>..." to discard changes in working directory)
+
+ modified: CONTRIBUTING.md
+
+
+
+
Om te sien wat jy verander het maar nog nie gestaged het nie, tik git diff met geen ander argumente nie:
+
+
+
+
$ git diff
+diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
+index 8ebb991..643e24f 100644
+--- a/CONTRIBUTING.md
++++ b/CONTRIBUTING.md
+@@ -65,7 +65,8 @@ branch directly, things can get messy.
+ Please include a nice description of your changes when you submit your PR;
+ if we have to read the whole diff to figure out why you're contributing
+ in the first place, you're less likely to get feedback and have your change
+-merged in.
++merged in. Also, split your changes into comprehensive chunks if your patch is
++longer than a dozen lines.
+
+ If you are starting to work on a particular area, feel free to submit a PR
+ that highlights your work in progress (and note in the PR title that it's
+
+
+
+
Daardie opdrag vergelyk wat in jou werkdirectory is met wat in jou staging area is.
+Die resultaat vertel jou watter veranderinge jy gemaak het wat jy nog nie gestaged het nie.
+
+
+
As jy wil sien wat jy gestaged het wat in jou volgende commit sal ingaan, kan jy git diff --staged gebruik.
+Hierdie opdrag vergelyk jou gestagede veranderinge met jou laaste commit:
+
+
+
+
$ git diff --staged
+diff --git a/README b/README
+new file mode 100644
+index 0000000..03902a1
+--- /dev/null
++++ b/README
+@@ -0,0 +1 @@
++My Project
+
+
+
+
Dit is belangrik om daarop te let dat git diff op sy eie nie alle veranderinge wys wat gemaak is sedert jou laaste commit nie — slegs veranderinge wat steeds unstaged is.
+As jy al jou veranderinge gestaged het, sal git diff vir jou geen uitvoer gee nie.
+
+
+
Vir nog 'n voorbeeld, as jy die CONTRIBUTING.md lêer stage en dit dan wysig, kan jy git diff gebruik om die veranderinge in die lêer te sien wat gestaged is en die veranderinge wat unstaged is.
+As ons omgewing so lyk:
+
+
+
+
$ git add CONTRIBUTING.md
+$ echo '# test line' >> CONTRIBUTING.md
+$ git status
+On branch master
+Your branch is up-to-date with 'origin/master'.
+Changes to be committed:
+ (use "git reset HEAD <file>..." to unstage)
+
+ modified: CONTRIBUTING.md
+
+Changes not staged for commit:
+ (use "git add <file>..." to update what will be committed)
+ (use "git checkout -- <file>..." to discard changes in working directory)
+
+ modified: CONTRIBUTING.md
+
+
+
+
Nou kan jy git diff gebruik om te sien wat steeds unstaged is:
+
+
+
+
$ git diff
+diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
+index 643e24f..87f08c8 100644
+--- a/CONTRIBUTING.md
++++ b/CONTRIBUTING.md
+@@ -119,3 +119,4 @@ at the
+ ## Starter Projects
+
+ See our [projects list](https://github.com/libgit2/libgit2/blob/development/PROJECTS.md).
++# test line
+
+
+
+
en git diff --cached om te sien wat jy tot dusver gestaged het (--staged en --cached is sinonieme):
+
+
+
+
$ git diff --cached
+diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
+index 8ebb991..643e24f 100644
+--- a/CONTRIBUTING.md
++++ b/CONTRIBUTING.md
+@@ -65,7 +65,8 @@ branch directly, things can get messy.
+ Please include a nice description of your changes when you submit your PR;
+ if we have to read the whole diff to figure out why you're contributing
+ in the first place, you're less likely to get feedback and have your change
+-merged in.
++merged in. Also, split your changes into comprehensive chunks if your patch is
++longer than a dozen lines.
+
+ If you are starting to work on a particular area, feel free to submit a PR
+ that highlights your work in progress (and note in the PR title that it's
+
+
+
+
+
+|
+ Note
+ |
+
+ Git Diff in 'n Eksterne Hulpmiddel
+
+ Ons sal voortgaan om die git diff opdrag op verskeie maniere deur die res van die boek te gebruik.
+Daar is 'n ander manier om na hierdie diffs te kyk as jy eerder 'n grafiese of eksterne diff-besigtigingsprogram verkies.
+As jy git difftool uitvoer in plaas van git diff, kan jy enige van hierdie diffs bekyk in sagteware soos emerge, vimdiff en vele meer (insluitend kommersiële produkte).
+Voer git difftool --tool-help uit om te sien wat beskikbaar is op jou stelsel.
+ |
+
+
+
+
+
Jou veranderinge commit
+
+
Nou dat jou staging area opgestel is soos jy dit wil hê, kan jy jou veranderinge commit.
+Onthou dat enigiets wat steeds unstaged is — enige lêers wat jy geskep of gewysig het waarop jy nie git add uitgevoer het sedert jy dit geredigeer het nie — nie in hierdie commit sal ingaan nie.
+Hulle sal as gewysigde lêers op jou skyf bly staan.
+In hierdie geval, kom ons sê dat die laaste keer wat jy git status uitgevoer het, jy gesien het dat alles gestaged is, so jy is gereed om jou veranderinge te commit.
+Die maklikste manier om te commit is om git commit te tik:
+
+
+
+
Deur dit te doen begin jou gekose redigeerder.
+
+
+
+
+|
+ Note
+ |
+
+
+ Dit word gestel deur jou shell se EDITOR omgewingsveranderlike — gewoonlik vim of emacs, alhoewel jy dit kan konfigureer met wat jy ook al wil hê deur die git config --global core.editor opdrag te gebruik soos jy in }}">Aan die slag gesien het.
+ |
+
+
+
+
+
Die redigeerder wys die volgende teks (hierdie voorbeeld is 'n Vim-skerm):
+
+
+
+
# Please enter the commit message for your changes. Lines starting
+# with '#' will be ignored, and an empty message aborts the commit.
+# On branch master
+# Your branch is up-to-date with 'origin/master'.
+#
+# Changes to be committed:
+# new file: README
+# modified: CONTRIBUTING.md
+#
+~
+~
+~
+".git/COMMIT_EDITMSG" 9L, 283C
+
+
+
+
Jy kan sien dat die verstek commit-boodskap die nuutste uitvoer van die git status opdrag as kommentaar bevat en een leë reël heel bo.
+Jy kan hierdie kommentare verwyder en jou eie commit-boodskap intik, of jy kan hulle daar laat om jou te help onthou wat jy besig is om te commit.
+
+
+
+
+|
+ Note
+ |
+
+
+ Vir 'n nog meer eksplisiete herinnering van wat jy gewysig het, kan jy die -v opsie aan git commit meegee.
+Deur dit te doen plaas dit ook die diff van jou veranderinge in die redigeerder sodat jy presies kan sien watter veranderinge jy commit.
+ |
+
+
+
+
+
Wanneer jy die redigeerder verlaat, skep Git jou commit met daardie commit-boodskap (met die kommentare en diff verwyder).
+
+
+
As 'n alternatief kan jy jou commit-boodskap inlyn intik met die commit opdrag deur dit na 'n -m vlag te spesifiseer, soos hier:
+
+
+
+
$ git commit -m "Story 182: fix benchmarks for speed"
+[master 463dc4f] Story 182: fix benchmarks for speed
+ 2 files changed, 2 insertions(+)
+ create mode 100644 README
+
+
+
+
Nou het jy jou eerste commit gemaak!
+Jy kan sien dat die commit jou 'n bietjie uitvoer oor homself gegee het: op watter tak jy gecommit het (master), watter SHA-1 checksum die commit het (463dc4f), hoeveel lêers verander is, en statistieke oor reëls bygevoeg en verwyder in die commit.
+
+
+
Onthou dat die commit die snapshot opneem wat jy in jou staging area opgestel het.
+Enigiets wat jy nie gestaged het nie, sit nog steeds daar gewysig; jy kan nog 'n commit doen om dit by jou geskiedenis te voeg.
+Elke keer as jy 'n commit uitvoer, lê jy 'n snapshot van jou projek vas waarna jy later kan terugkeer of dit mee kan vergelyk.
+
+
+
Die Staging Area oorslaan
+
+
+Alhoewel dit ongelooflik nuttig kan wees om commits presies te vorm soos jy hulle wil hê, is die staging area soms 'n bietjie meer kompleks as wat jy in jou werkvloei benodig.
+As jy die staging area wil oorslaan, bied Git 'n eenvoudige kortpad.
+Deur die -a opsie by die git commit opdrag te voeg, maak dat Git outomaties elke lêer wat reeds tracked is stage voordat die commit gedoen word, wat jou toelaat om die git add gedeelte oor te slaan:
+
+
+
+
$ git status
+On branch master
+Your branch is up-to-date with 'origin/master'.
+Changes not staged for commit:
+ (use "git add <file>..." to update what will be committed)
+ (use "git checkout -- <file>..." to discard changes in working directory)
+
+ modified: CONTRIBUTING.md
+
+no changes added to commit (use "git add" and/or "git commit -a")
+$ git commit -a -m 'Add new benchmarks'
+[master 83e38c7] Add new benchmarks
+ 1 file changed, 5 insertions(+), 0 deletions(-)
+
+
+
+
Let op hoe jy in hierdie geval nie git add op die CONTRIBUTING.md lêer hoef uit te voer voordat jy commit nie.
+Dit is omdat die -a vlag alle veranderde lêers insluit.
+Dit is gerieflik, maar wees versigtig; soms sal hierdie vlag veroorsaak dat jy ongewenste veranderinge insluit.
+
+
+
Lêers verwyder
+
+
+Om 'n lêer uit Git te verwyder, moet jy dit van jou tracked lêers verwyder (meer akkuraat, verwyder dit uit jou staging area) en dan commit.
+Die git rm opdrag doen dit, en verwyder ook die lêer uit jou werkdirectory sodat jy dit nie volgende keer as 'n untracked lêer sien nie.
+
+
+
As jy bloot die lêer uit jou werkdirectory verwyder, wys dit onder die “Changes not staged for commit” (dit wil sê, unstaged) area van jou git status uitvoer:
+
+
+
+
$ rm PROJECTS.md
+$ git status
+On branch master
+Your branch is up-to-date with 'origin/master'.
+Changes not staged for commit:
+ (use "git add/rm <file>..." to update what will be committed)
+ (use "git checkout -- <file>..." to discard changes in working directory)
+
+ deleted: PROJECTS.md
+
+no changes added to commit (use "git add" and/or "git commit -a")
+
+
+
+
Dan, as jy git rm uitvoer, stage dit die lêer se verwydering:
+
+
+
+
$ git rm PROJECTS.md
+rm 'PROJECTS.md'
+$ git status
+On branch master
+Your branch is up-to-date with 'origin/master'.
+Changes to be committed:
+ (use "git reset HEAD <file>..." to unstage)
+
+ deleted: PROJECTS.md
+
+
+
+
Die volgende keer as jy commit, sal die lêer weg wees en nie meer tracked word nie.
+As jy die lêer gewysig het of reeds by die staging area bygevoeg het, moet jy die verwydering forseer met die -f opsie.
+Dit is 'n veiligheidskenmerk om die toevallige verwydering van data wat nog nie in 'n snapshot vasgelê is nie en wat nie uit Git herwin kan word nie, te voorkom.
+
+
+
Nog 'n nuttige ding wat jy dalk wil doen, is om die lêer in jou werkdirectory te hou maar dit uit jou staging area te verwyder.
+Met ander woorde, jy wil dalk die lêer op jou hardeskyf hou, maar nie hê Git moet dit meer track nie.
+Dit is veral nuttig as jy vergeet het om iets by jou .gitignore lêer te voeg en dit per ongeluk gestaged het, soos 'n groot loglêer of 'n klomp .a saamgestelde lêers.
+Om dit te doen, gebruik die --cached opsie:
+
+
+
+
$ git rm --cached README
+
+
+
+
Jy kan lêers, directories, en file-glob patrone aan die git rm opdrag meegee.
+Dit beteken jy kan dinge doen soos:
+
+
+
+
Let op die truskuinsstreep (backslash) (\) voor die *.
+Dit is nodig omdat Git sy eie lêernaam-uitbreiding doen, bykomend tot jou shell se lêernaam-uitbreiding.
+Hierdie opdrag verwyder alle lêers wat die .log uitbreiding in die log/ directory het.
+Of, jy kan iets soos hierdie doen:
+
+
+
+
Hierdie opdrag verwyder alle lêers waarvan die name eindig met 'n ~.
+
+
+
Lêers skuif
+
+
+Anders as baie ander VCS’e, track Git nie uitdruklik die verskuiwing van lêers nie.
+As jy 'n lêer in Git hernoem, word geen metadata in Git gestoor wat vir hom sê jy het die lêer hernoem nie.
+Git is egter redelik slim om dit agterna uit te pluis — ons sal 'n bietjie later na die opsporing van lêerverskuiwings kyk.
+
+
+
Dit is dus 'n bietjie verwarrend dat Git 'n mv opdrag het.
+As jy 'n lêer in Git wil hernoem, kan jy iets soos dit uitvoer:
+
+
+
+
$ git mv file_from file_to
+
+
+
+
en dit werk heeltemal goed.
+Eintlik, as jy so iets uitvoer en na die status kyk, sal jy sien dat Git dit as 'n hernoemde lêer beskou:
+
+
+
+
$ git mv README.md README
+$ git status
+On branch master
+Your branch is up-to-date with 'origin/master'.
+Changes to be committed:
+ (use "git reset HEAD <file>..." to unstage)
+
+ renamed: README.md -> README
+
+
+
+
Dit is egter gelykstaande aan die uitvoer van so iets:
+
+
+
+
$ mv README.md README
+$ git rm README.md
+$ git add README
+
+
+
+
Git vind implisiet uit dat dit 'n hernoeming is, so dit maak nie saak of jy 'n lêer op daardie manier of met die mv opdrag hernoem nie.
+Die enigste werklike verskil is dat git mv een opdrag in plaas van drie is — dit is 'n geriefsfunksie.
+Belangriker nog, jy kan enige hulpmiddel gebruik wat jy wil om 'n lêer te hernoem, en die add/rm later hanteer, net voor jy commit.
+
+
If you can read only one chapter to get going with Git, this is it.
+This chapter covers every basic command you need to do the vast majority of the things you’ll eventually spend your time doing with Git.
+By the end of the chapter, you should be able to configure and initialize a repository, begin and stop tracking files, and stage and commit changes.
+We’ll also show you how to set up Git to ignore certain files and file patterns, how to undo mistakes quickly and easily, how to browse the history of your project and view changes between commits, and how to push and pull from remote repositories.
+Verkry 'n Git-bewaarplek (repository)
+
+
Jy sal tipies op een van twee maniere 'n Git-bewaarplek (repository) verkry:
+
+
+-
+
Jy kan 'n plaaslike gids (directory) neem wat tans nie onder weergawebeheer
+is nie, en dit in 'n Git-bewaarplek (repository) verander, of
+
+-
+
Jy kan 'n bestaande Git-bewaarplek (repository) van iewers anders af kloon (clone).
+
+
+
+
In beide gevalle eindig jy met 'n Git-bewaarplek (repository) op jou plaaslike
+masjien, gereed om mee te werk.
+
+
Initialiseer 'n Bewaarplek (repository) in 'n Bestaande Gids (directory)
+
+
As jy 'n projek-gids (directory) het wat tans nie onder weergawebeheer is nie en
+jy wil dit met Git begin bestuur, moet jy eers na daardie projek-gids (directory)
+toe gaan. As jy dit nog nooit vantevore gedoen het nie, lyk dit 'n bietjie
+anders afhangend van die stelsel waarop jy werk:
+
+
+
+
+
$ cd /home/user/my_project
+
+
+
+
+
+
$ cd /Users/user/my_project
+
+
+
+
+
+
$ cd C:/Users/user/my_project
+
+
+
+
+
+
Dit skep 'n nuwe sub-gids (directory) genaamd .git wat al jou nodige bewaarplek-lêers
+(repository files) bevat — 'n Git-bewaarplek (repository) raamwerk. Op hierdie
+stadium word niks in jou projek nog nagespoor (tracked) nie. Sien
+}}">Git Internals vir meer inligting oor presies watter
+lêers binne-in die .git gids (directory) is wat jy pas geskep het.
+
+
+
As jy bestaande lêers onder weergawebeheer wil plaas (in teenstelling met 'n
+leë gids (directory)), sal jy waarskynlik daardie lêers moet begin naspoor (track)
+en 'n aanvanklike commit doen. Jy kan dit bereik met 'n paar git add opdragte
+wat die lêers spesifiseer wat jy wil naspoor, gevolg deur 'n git commit:
+
+
+
+
$ git add *.c
+$ git add LICENSE
+$ git commit -m 'Initial project version'
+
+
+
+
Ons sal binnekort in meer detail verduidelik wat hierdie opdragte doen.
+Op hierdie punt het jy 'n Git-bewaarplek (repository) met lêers wat nagespoor
+word (tracked files) en 'n aanvanklike commit.
+
+
+
Kloon 'n Bestaande Bewaarplek (repository)
+
+
As jy 'n kopie wil kry van 'n bestaande Git-bewaarplek (repository) — byvoorbeeld 'n projek
+waartoe jy wil bydra — is git clone die opdrag wat jy benodig. As jy vertroud
+is met ander weergawebeheerstelsels (VCSs) soos Subversion, sal jy opmerk dat
+die opdrag "clone" is en nie "checkout" nie. Dit is 'n belangrike onderskeid — in plaas daarvan om net 'n werkskopie (working copy) te kry, ontvang Git 'n
+volledige kopie van byna alle data wat die bediener (server) het.
+
+
+
Elke weergawe van elke lêer in die hele geskiedenis van die projek word by
+verstek afgelaai wanneer jy git clone hardloop. In werklikheid, as jou
+bediener se hardeskyf korrup raak, kan jy dikwels byna enige van die klone op
+enige kliënt gebruik om die bediener terug te bring na die toestand waarin dit
+was toe dit gekloon is (jy mag dalk 'n paar bediener-kant "hooks" en dergelike
+verloor, maar al die weergawe-data sal daar wees — sien
+}}">Git op 'n Bediener kry (Getting Git on a Server) vir meer besonderhede).
+
+
+
Jy kloon 'n bewaarplek (repository) met git clone <url>.
+Byvoorbeeld, as jy die Git koppelbare biblioteek (linkable library) genaamd
+libgit2 wil kloon, kan jy dit soos volg doen:
+
+
+
+
$ git clone https://github.com/libgit2/libgit2
+
+
+
+
Dit skep 'n gids (directory) genaamd libgit2, initialiseer 'n .git gids (directory)
+daarbinne, laai al die data vir daardie bewaarplek (repository) af, en doen 'n
+checkout van 'n werkskopie van die nuutste weergawe. As jy in die nuwe libgit2
+gids (directory) inbeweeg wat pas geskep is, sal jy die projeklêers daarbinne vind,
+gereed om op te werk of te gebruik.
+
+
+
As jy die bewaarplek (repository) in 'n gids (directory) wil kloon met 'n ander
+naam as libgit2, kan jy die nuwe gids-naam (directory name) as 'n bykomende
+argument spesifiseer:
+
+
+
+
$ git clone https://github.com/libgit2/libgit2 mylibgit
+
+
+
+
Daardie opdrag doen dieselfde as die vorige een, maar die teikengids
+(target directory) word mylibgit genoem.
+
+
+
Git het 'n aantal verskillende oordragprotokolle (transfer protocols) wat
+jy kan gebruik. Die vorige voorbeeld gebruik die https:// protokol, maar
+jy kan ook git:// of user@server:path/to/repo.git teëkom, wat die
+SSH-oordragprotokol gebruik. }}">Git op 'n Bediener kry (Getting Git on a Server)
+sal al die beskikbare opsies bekendstel wat die bediener kan opstel om toegang
+tot jou Git-bewaarplek (repository) te bied, en die voor- en nadele van elk.
+
+
Werk met afgeleë bewaarplekke (remotes)
+
+
Om op enige Git-projek te kan saamwerk, moet jy weet hoe om jou afgeleë bewaarplekke (remote repositories) te bestuur.
+Afgeleë bewaarplekke (remote repositories) is weergawes van jou projek wat iewers op die internet of op 'n netwerk gehuisves word.
+Jy kan verskeie van hulle hê, waarvan elkeen oor die algemeen óf leesalleen (read-only) óf lees/skryf (read/write) vir jou is.
+Om met ander saam te werk, behels die bestuur van hierdie afgeleë bewaarplekke (remote repositories) en om data na en van hulle te push en te pull wanneer jy werk moet deel.
+Die bestuur van afgeleë bewaarplekke (remote repositories) sluit in om te weet hoe om afgeleë bewaarplekke (remote repositories) by te voeg, ongeldige remotes te verwyder, verskeie remote branches te bestuur en hulle as tracked of nie te definieer nie, en meer.
+In hierdie afdeling sal ons van hierdie remote-bestuursvaardighede dek.
+
+
+
+|
+ Note
+ |
+
+ Afgeleë bewaarplekke (remote repositories) kan op jou plaaslike masjien wees.
+
+ Dit is heeltemal moontlik dat jy met 'n “remote” bewaarplek (remote repository) werk wat in werklikheid op dieselfde gasheer (host) is as waarop jy werk.
+Die woord “remote” impliseer nie noodwendig dat die bewaarplek iewers anders op die netwerk of internet is nie, net dat dit elders is.
+Om met so 'n afgeleë bewaarplek (remote repository) te werk, sal steeds al die standaard push-, pull- en fetch-bewerkings behels soos met enige ander remote.
+ |
+
+
+
+
Jou remotes wys
+
+
Om te sien watter remote bedieners jy opgestel het, kan jy die git remote opdrag uitvoer.
+Dit lys die kortname (shortnames) van elke remote-hanteerder wat jy gespesifiseer het.
+As jy jou bewaarplek gekloon het, behoort jy ten minste origin te sien — dit is die versteknaam wat Git gee aan die bediener waarvan jy gekloon het:
+
+
+
+
$ git clone https://github.com/schacon/ticgit
+Cloning into 'ticgit'...
+remote: Reusing existing pack: 1857, done.
+remote: Total 1857 (delta 0), reused 0 (delta 0)
+Receiving objects: 100% (1857/1857), 374.35 KiB | 268.00 KiB/s, done.
+Resolving deltas: 100% (772/772), done.
+Checking connectivity... done.
+$ cd ticgit
+$ git remote
+origin
+
+
+
+
Jy kan ook -v spesifiseer, wat vir jou die URL’e wys wat Git vir die kortnaam gestoor het om gebruik te word wanneer daar na daardie remote gelees en geskryf word:
+
+
+
+
$ git remote -v
+origin https://github.com/schacon/ticgit (fetch)
+origin https://github.com/schacon/ticgit (push)
+
+
+
+
As jy meer as een remote het, lys die opdrag hulle almal.
+Byvoorbeeld, 'n bewaarplek met veelvuldige remotes om saam met verskeie medewerkers te werk, kan dalk so iets lyk:
+
+
+
+
$ cd grit
+$ git remote -v
+bakkdoor https://github.com/bakkdoor/grit (fetch)
+bakkdoor https://github.com/bakkdoor/grit (push)
+cho45 https://github.com/cho45/grit (fetch)
+cho45 https://github.com/cho45/grit (push)
+defunkt https://github.com/defunkt/grit (fetch)
+defunkt https://github.com/defunkt/grit (push)
+koke git://github.com/koke/grit.git (fetch)
+koke git://github.com/koke/grit.git (push)
+origin git@github.com:mojombo/grit.git (fetch)
+origin git@github.com:mojombo/grit.git (push)
+
+
+
+
Dit beteken ons kan bydraes van enige van hierdie gebruikers redelik maklik pull.
+Ons kan moontlik ook toestemming hê om na een of meer van hulle te push, alhoewel ons dit nie hier kan sien nie.
+
+
+
+
Afgeleë bewaarplekke (remote repositories) byvoeg
+
+
Ons het genoem en gedemonstreer hoe die git clone opdrag implisiet die origin remote vir jou byvoeg.
+Hier is hoe om 'n nuwe remote eksplisiet by te voeg.
+Om 'n nuwe afgeleë Git-bewaarplek (remote Git repository) by te voeg as 'n kortnaam waarna jy maklik kan verwys, voer git remote add <kortnaam> <url> uit:
+
+
+
+
$ git remote
+origin
+$ git remote add pb https://github.com/paulboone/ticgit
+$ git remote -v
+origin https://github.com/schacon/ticgit (fetch)
+origin https://github.com/schacon/ticgit (push)
+pb https://github.com/paulboone/ticgit (fetch)
+pb https://github.com/paulboone/ticgit (push)
+
+
+
+
Nou kan jy die string pb op die opdragreël gebruik in plaas van die hele URL.
+Byvoorbeeld, as jy al die inligting wil fetch wat Paul het, maar wat jy nog nie in jou bewaarplek het nie, kan jy git fetch pb uitvoer:
+
+
+
+
$ git fetch pb
+remote: Counting objects: 43, done.
+remote: Compressing objects: 100% (36/36), done.
+remote: Total 43 (delta 10), reused 31 (delta 5)
+Unpacking objects: 100% (43/43), done.
+From https://github.com/paulboone/ticgit
+ * [new branch] master -> pb/master
+ * [new branch] ticgit -> pb/ticgit
+
+
+
+
Paul se master branch is nou plaaslik toeganklik as pb/master — jy kan dit in een van jou branches merge, of jy kan 'n plaaslike branch op daardie punt checkout as jy dit wil inspekteer.
+Ons sal in baie meer detail in }}">Git Branching oorgaan wat branches is en hoe om dit te gebruik.
+
+
+
Vanaf jou remotes fetch en pull
+
+
Soos jy pas gesien het, om data van jou remote projekte te kry, kan jy die volgende uitvoer:
+
+
+
+
Die opdrag gaan na daardie remote projek en haal al die data van daardie remote projek af wat jy nog nie het nie.
+Nadat jy dit gedoen het, behoort jy verwysings te hê na al die branches van daardie remote, wat jy enige tyd kan merge of inspekteer.
+
+
+
As jy 'n bewaarplek (repository) kloon, voeg die opdrag daardie afgeleë bewaarplek (remote repository) outomaties by onder die naam “origin”.
+Dus, git fetch origin fetch enige nuwe werk wat na daardie bediener gepush is sedert jy dit gekloon het (of laas daarvan gefetch het).
+Dit is belangrik om daarop te let dat die git fetch opdrag slegs die data na jou plaaslike bewaarplek (local repository) aflaai — dit merge dit nie outomaties met enige van jou werk of verander dit waaraan jy tans werk nie.
+Jy moet dit met die hand in jou werk merge wanneer jy gereed is.
+
+
+
As jou huidige branch opgestel is om 'n remote branch te track (sien die volgende afdeling en }}">Git Branching vir meer inligting), kan jy die git pull opdrag gebruik om daardie remote branch outomaties te fetch en dan in jou huidige branch te merge.
+Dit kan dalk 'n makliker of gemakliker werkvloei vir jou wees; en by verstek stel die git clone opdrag outomaties jou plaaslike master branch op om die remote master branch (of wat die verstek-branch ook al genoem word) te track op die bediener waarvan jy gekloon het.
+Om git pull uit te voer, fetch oor die algemeen data van die bediener af waarvan jy oorspronklik gekloon het en probeer outomaties om dit te merge in die kode waaraan jy tans werk.
+
+
+
+
+|
+ Note
+ |
+
+
+ Vanaf Git weergawe 2.27 sal git pull 'n waarskuwing gee as die pull.rebase veranderlike nie gestel is nie.
+Git sal aanhou om jou te waarsku totdat jy die veranderlike stel.
+
+ As jy die verstekgedrag van Git wil hê (fast-forward as dit moontlik is, andersins skep 'n merge commit):
+git config --global pull.rebase "false"
+
+ As jy wil rebase wanneer jy pull:
+git config --global pull.rebase "true"
+ |
+
+
+
+
+
Na jou remotes push
+
+
Wanneer jou projek by 'n punt is waar jy dit wil deel, moet jy dit stroomop (upstream) push.
+Die opdrag hiervoor is eenvoudig: git push <remote> <branch>.
+As jy jou master branch na jou origin bediener wil push (weereens, kloning stel oor die algemeen albei daardie name outomaties vir jou op), dan kan jy hierdie uitvoer om enige commits wat jy gedoen het terug op die bediener te push:
+
+
+
+
$ git push origin master
+
+
+
+
Hierdie opdrag werk slegs as jy gekloon het van 'n bediener waartoe jy skryftoegang het en as niemand intussen gepush het nie.
+As jy en iemand anders terselfdertyd kloon en hulle push upstream en dan push jy upstream, sal jou push tereg verwerp word.
+Jy sal eers hul werk moet fetch en dit by joune inkorporeer voordat jy toegelaat sal word om te push.
+Sien }}">Git Branching vir meer gedetailleerde inligting oor hoe om na remote bedieners te push.
+
+
+
'n Remote inspekteer
+
+
As jy meer inligting oor 'n spesifieke remote wil sien, kan jy die git remote show <remote> opdrag gebruik.
+As jy hierdie opdrag met 'n spesifieke kortnaam uitvoer, soos origin, kry jy iets soos hierdie:
+
+
+
+
$ git remote show origin
+* remote origin
+ Fetch URL: https://github.com/schacon/ticgit
+ Push URL: https://github.com/schacon/ticgit
+ HEAD branch: master
+ Remote branches:
+ master tracked
+ dev-branch tracked
+ Local branch configured for 'git pull':
+ master merges with remote master
+ Local ref configured for 'git push':
+ master pushes to master (up to date)
+
+
+
+
Dit lys die URL vir die afgeleë bewaarplek (remote repository) asook die tracking branch inligting.
+Die opdrag vertel jou behulpsaam dat as jy op die master branch is en jy git pull uitvoer, dit outomaties die remote se master branch in die plaaslike een sal merge nadat dit gefetch is.
+Dit lys ook al die remote verwysings wat dit gepull het.
+
+
+
Dit is 'n eenvoudige voorbeeld wat jy waarskynlik sal teëkom.
+Wanneer jy Git egter meer intensief gebruik, sal jy dalk baie meer inligting by git remote show sien:
+
+
+
+
$ git remote show origin
+* remote origin
+ URL: https://github.com/my-org/complex-project
+ Fetch URL: https://github.com/my-org/complex-project
+ Push URL: https://github.com/my-org/complex-project
+ HEAD branch: master
+ Remote branches:
+ master tracked
+ dev-branch tracked
+ markdown-strip tracked
+ issue-43 new (next fetch will store in remotes/origin)
+ issue-45 new (next fetch will store in remotes/origin)
+ refs/remotes/origin/issue-11 stale (use 'git remote prune' to remove)
+ Local branches configured for 'git pull':
+ dev-branch merges with remote dev-branch
+ master merges with remote master
+ Local refs configured for 'git push':
+ dev-branch pushes to dev-branch (up to date)
+ markdown-strip pushes to markdown-strip (up to date)
+ master pushes to master (up to date)
+
+
+
+
Hierdie opdrag wys na watter branch daar outomaties gepush word wanneer jy git push uitvoer terwyl jy op sekere branches is.
+Dit wys ook vir jou watter remote branches op die bediener jy nog nie het nie, watter remote branches jy het wat van die bediener verwyder is, en verskeie plaaslike branches wat outomaties met hul remote-tracking branch kan merge wanneer jy git pull uitvoer.
+
+
+
Remotes hernoem en verwyder
+
+
Jy kan git remote rename uitvoer om 'n remote se kortnaam te verander.
+Byvoorbeeld, as jy pb na paul wil hernoem, kan jy dit doen met git remote rename:
+
+
+
+
$ git remote rename pb paul
+$ git remote
+origin
+paul
+
+
+
+
Dit is die moeite werd om te noem dat dit al jou remote-tracking branch name ook verander.
+Wat voorheen na verwys is as pb/master, is nou paul/master.
+
+
+
As jy om een of ander rede 'n remote wil verwyder — jy het die bediener geskuif of gebruik nie meer 'n spesifieke spieël (mirror) nie, of miskien dra 'n medewerker nie meer by nie — kan jy óf git remote remove óf git remote rm gebruik:
+
+
+
+
$ git remote remove paul
+$ git remote
+origin
+
+
+
+
Sodra jy die verwysing na 'n remote op hierdie manier uitvee, word alle remote-tracking branches en konfigurasie-instellings wat met daardie remote geassosieer word, ook uitgevee.
+
+
Afgeleë Takke (Remote Branches)
+
+
+Afgeleë verwysings (remote references) is verwysings (wysers/pointers) in jou afgeleë bewaarplekke (remote repositories), insluitend takke, merkers (tags), ensovoorts.
+Jy kan 'n volledige lys van afgeleë verwysings eksplisiet kry met git ls-remote <remote>, of git remote show <remote> vir afgeleë takke asook vir meer inligting.
+Nietemin is 'n meer algemene manier om voordeel te trek uit afgeleë-naspeur takke (remote-tracking branches).
+
+
Remote-tracking takke is verwysings na die toestand van afgeleë takke (remote branches).
+Dit is plaaslike (local) verwysings wat jy nie kan skuif nie; Git skuif hulle outomaties vir jou wanneer jy enige netwerkkommunikasie doen, om seker te maak hulle verteenwoordig die toestand van die afgeleë bewaarplek akkuraat.
+Dink aan hulle as boekmerke, om jou te herinner waar die takke in jou afgeleë bewaarplekke was die laaste keer toe jy met hulle gekonnekteer het.
+
+
Remote-tracking takname neem die vorm <remote>/<branch> aan.
+Byvoorbeeld, as jy wil sien hoe die master tak op jou origin remote gelyk het die laaste keer toe jy daarmee gekommunikeer het, sal jy die origin/master tak nagaan.
+As jy saam met 'n vennoot aan 'n kwessie gewerk het en hulle het 'n iss53 tak opgestuur (pushed), het jy dalk jou eie plaaslike iss53 tak, maar die tak op die bediener sal verteenwoordig word deur die remote-tracking tak origin/iss53.
+
+
Dit mag dalk 'n bietjie verwarrend wees, so kom ons kyk na 'n voorbeeld.
+Kom ons sê jy het 'n Git-bediener op jou netwerk by git.ourcompany.com.
+As jy hiervan af kloon, noem Git se clone opdrag dit outomaties origin vir jou, trek al die data daarvan af (pulls down), skep 'n wyser na waar sy master tak is, en noem dit plaaslik origin/master.
+Git gee jou ook jou eie plaaslike master tak wat op dieselfde plek as origin se master tak begin, sodat jy iets het om van af te werk.
+
+
+
+|
+ Note
+ |
+
+ “origin” is nie spesiaal nie
+
+ Net soos die taknaam “master” geen spesiale betekenis in Git het nie, het “origin” ook nie.
+Terwyl “master” die versteknaam (default name) is vir 'n begin-tak wanneer jy git init uitvoer, wat die enigste rede is hoekom dit wyd gebruik word, is “origin” die versteknaam vir 'n remote wanneer jy git clone uitvoer.
+As jy eerder git clone -o booyah uitvoer, sal jy booyah/master as jou verstek afgeleë tak (default remote branch) hê.
+ |
+
+
+
+
+
}}" alt="Server and local repositories after cloning">
+
+
Figure 30. Bediener en plaaslike bewaarplekke na kloning
+
+
As jy bietjie werk op jou plaaslike master tak doen, en in die tussentyd stuur (push) iemand anders na git.ourcompany.com en dateer hul master tak op, dan beweeg julle geskiedenisse verskillend vorentoe.
+Boonop, solank jy uit kontak met jou origin bediener bly, skuif jou origin/master wyser nie.
+
+
+
}}" alt="Local and remote work can diverge">
+
+
Figure 31. Plaaslike en afgeleë werk kan afwyk (diverge)
+
+
Om jou werk met 'n gegewe remote te sinchroniseer, voer jy 'n git fetch <remote> opdrag uit (in ons geval, git fetch origin).
+Hierdie opdrag kyk watter bediener “origin” is (in hierdie geval is dit git.ourcompany.com), haal (fetch) enige data daarvan af wat jy nog nie het nie, en dateer jou plaaslike databasis op, wat jou origin/master wyser na sy nuwe, meer onlangse posisie skuif.
+
+
+
}}" alt="`git fetch` updates your remote-tracking branches">
+
+
Figure 32. git fetch dateer jou remote-tracking takke op
+
+
Om te demonstreer hoe om veelvuldige afgeleë bedieners (remote servers) te hê en hoe afgeleë takke vir daardie afgeleë projekte lyk, kom ons aanvaar jy het nog 'n interne Git-bediener wat slegs vir ontwikkeling deur een van jou naellope-spanne (sprint teams) gebruik word.
+Hierdie bediener is by git.team1.ourcompany.com.
+Jy kan dit as 'n nuwe afgeleë verwysing (remote reference) byvoeg by die projek waaraan jy tans werk deur die git remote add opdrag uit te voer, soos ons in }}">Git Basics gedek het.
+Noem hierdie remote teamone, wat jou kortnaam (shortname) vir daardie hele URL sal wees.
+
+
+
}}" alt="Adding another server as a remote">
+
+
Figure 33. Voeg nog 'n bediener as 'n remote by
+
+
Nou kan jy git fetch teamone uitvoer om alles af te haal (fetch) wat die afgeleë teamone bediener het wat jy nog nie het nie.
+Omdat daardie bediener 'n subset het van die data wat jou origin bediener op die oomblik het, haal Git geen data af nie, maar stel 'n remote-tracking tak genaamd teamone/master op om te wys na die vaslegging (commit) wat teamone as sy master tak het.
+
+
+
}}" alt="Remote-tracking branch for `teamone/master`">
+
+
Figure 34. Remote-tracking tak vir teamone/master
+
+
+
Opstuur (Pushing)
+
+
+Wanneer jy 'n tak met die wêreld wil deel, moet jy dit opstuur (push) na 'n remote waartoe jy skryftoegang het.
+Jou plaaslike takke word nie outomaties gesinchroniseer met die remotes waarna jy skryf nie — jy moet die takke wat jy wil deel, eksplisiet push.
+Op dié manier kan jy privaat takke gebruik vir werk wat jy nie wil deel nie, en slegs die onderwerp-takke (topic branches) push waaraan jy wil saamwerk.
+
+
+
As jy 'n tak genaamd serverfix het waaraan jy saam met ander wil werk, kan jy dit op dieselfde manier push as wat jy jou eerste tak gepush het.
+Voer git push <remote> <branch> uit:
+
+
+
+
$ 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
+
+
+
+
Dit is 'n bietjie van 'n kortpad.
+Git brei outomaties die serverfix taknaam uit na refs/heads/serverfix:refs/heads/serverfix, wat beteken, “Neem my serverfix plaaslike tak en push dit om die remote se serverfix tak op te dateer.”
+Ons sal in }}">Git Internals in detail deur die refs/heads/ deel gaan, maar jy kan dit oor die algemeen uitlaat.
+Jy kan ook git push origin serverfix:serverfix doen, wat dieselfde ding doen — dit sê, “Neem my serverfix en maak dit die remote se serverfix.”
+Jy kan hierdie formaat gebruik om 'n plaaslike tak te push na 'n afgeleë tak wat anders genoem word.
+As jy nie wou hê dit moet serverfix op die remote genoem word nie, kon jy in plaas daarvan git push origin serverfix:awesomebranch uitvoer om jou plaaslike serverfix tak na die awesomebranch tak op die afgeleë projek te push.
+
+
+
+
+|
+ Note
+ |
+
+ Moenie jou wagwoord elke keer tik nie
+
+ As jy 'n HTTPS URL gebruik om oor te push, sal die Git-bediener jou vra vir jou gebruikersnaam en wagwoord vir verifikasie (authentication).
+By verstek (by default) sal dit jou op die terminaal vir hierdie inligting vra sodat die bediener kan vasstel of jy toegelaat word om te push.
+
+ As jy dit nie elke liewe keer wil intik wanneer jy push nie, kan jy 'n “credential cache” opstel.
+Die eenvoudigste is om dit net vir 'n paar minute in die geheue te hou, wat jy maklik kan opstel deur git config --global credential.helper cache uit te voer.
+ |
+
+
+
+
+
Die volgende keer as een van jou medewerkers van die bediener afhaal (fetch), sal hulle 'n verwysing kry na waar die bediener se weergawe van serverfix is onder die afgeleë tak 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
+
+
+
+
Dit is belangrik om daarop te let dat wanneer jy 'n fetch doen wat nuwe remote-tracking takke aftrek, jy nie outomaties plaaslike, redigeerbare kopieë daarvan het nie.
+Met ander woorde, in hierdie geval het jy nie 'n nuwe serverfix tak nie — jy het slegs 'n origin/serverfix wyser wat jy nie kan verander nie.
+
+
+
Om hierdie werk in jou huidige werkstak in te smelt (merge), kan jy git merge origin/serverfix uitvoer.
+As jy jou eie serverfix tak wil hê waarop jy kan werk, kan jy dit op jou remote-tracking tak baseer:
+
+
+
+
$ git checkout -b serverfix origin/serverfix
+Branch serverfix set up to track remote branch serverfix from origin.
+Switched to a new branch 'serverfix'
+
+
+
+
Dit gee jou 'n plaaslike tak waaraan jy kan werk wat begin waar origin/serverfix is.
+
+
+
Naspeur-takke (Tracking Branches)
+
+
+Om 'n plaaslike tak vanaf 'n remote-tracking tak uit te check (checkout), skep outomaties wat 'n “tracking branch” (naspeur-tak) genoem word (en die tak wat dit naspeur, word 'n “upstream branch” of stroomop-tak genoem).
+Tracking branches is plaaslike takke wat 'n direkte verhouding met 'n afgeleë tak (remote branch) het.
+As jy op 'n tracking branch is en git pull tik, weet Git outomaties van watter bediener om af te haal (fetch) en watter tak om in te smelt (merge).
+
+
+
Wanneer jy 'n bewaarplek (repository) kloon, skep dit oor die algemeen outomaties 'n master tak wat origin/master naspeur (track).
+Jy kan egter ander tracking branches opstel as jy wil — takke wat takke op ander remotes naspeur, of wat nie die master tak naspeur nie.
+Die eenvoudige geval is die voorbeeld wat jy pas gesien het, deur git checkout -b <branch> <remote>/<branch> uit te voer.
+Dit is 'n algemene genoeg operasie dat Git die --track kortpad bied:
+
+
+
+
$ git checkout --track origin/serverfix
+Branch serverfix set up to track remote branch serverfix from origin.
+Switched to a new branch 'serverfix'
+
+
+
+
Trouens, dit is so algemeen dat daar selfs 'n kortpad vir daardie kortpad is.
+As die taknaam wat jy probeer uitcheck (a) nie bestaan nie en (b) presies ooreenstem met 'n naam op slegs een remote, sal Git 'n tracking branch vir jou skep:
+
+
+
+
$ git checkout serverfix
+Branch serverfix set up to track remote branch serverfix from origin.
+Switched to a new branch 'serverfix'
+
+
+
+
Om 'n plaaslike tak met 'n ander naam as die afgeleë tak op te stel, kan jy maklik die eerste weergawe met 'n ander plaaslike taknaam gebruik:
+
+
+
+
$ git checkout -b sf origin/serverfix
+Branch sf set up to track remote branch serverfix from origin.
+Switched to a new branch 'sf'
+
+
+
+
Nou sal jou plaaslike tak sf outomaties van origin/serverfix af aftrek (pull).
+
+
+
As jy reeds 'n plaaslike tak het en dit wil koppel aan 'n afgeleë tak wat jy pas afgetrek het, of as jy die stroomop-tak (upstream branch) wat jy naspeur wil verander, kan jy die -u of --set-upstream-to opsie saam met git branch gebruik om dit enige tyd eksplisiet in te stel.
+
+
+
+
$ git branch -u origin/serverfix
+Branch serverfix set up to track remote branch serverfix from origin.
+
+
+
+
+
+|
+ Note
+ |
+
+ Stroomop (Upstream) kortpad
+
+ Wanneer jy 'n tracking branch opgestel het, kan jy na sy stroomop-tak (upstream branch) verwys met die @{upstream} of @{u} kortpad.
+Dus, as jy op die master tak is en dit spoor origin/master na, kan jy iets soos git merge @{u} gebruik in plaas van git merge origin/master as jy wil.
+ |
+
+
+
+
+
As jy wil sien watter tracking branches jy opgestel het, kan jy die -vv opsie saam met git branch gebruik.
+Dit sal jou plaaslike takke lys met meer inligting, insluitend wat elke tak naspeur en of jou plaaslike tak voor (ahead), agter (behind), of albei is.
+
+
+
+
$ git branch -vv
+ iss53 7e424c3 [origin/iss53: ahead 2] Add forgotten brackets
+ master 1ae2a45 [origin/master] Deploy index fix
+* serverfix f8674d9 [teamone/server-fix-good: ahead 3, behind 1] This should do it
+ testing 5ea463a Try something new
+
+
+
+
So hier kan ons sien dat ons iss53 tak origin/iss53 naspeur en twee “ahead” is, wat beteken dat ons plaaslik twee vasleggings (commits) het wat nog nie na die bediener gepush is nie.
+Ons kan ook sien dat ons master tak origin/master naspeur en op datum (up to date) is.
+Vervolgens kan ons sien dat ons serverfix tak die server-fix-good tak op ons teamone bediener naspeur en drie voor is en een agter is, wat beteken dat daar een vaslegging op die bediener is wat ons nog nie ingesmelt (merged) het nie en drie vasleggings plaaslik is wat ons nog nie gepush het nie.
+Laastens kan ons sien dat ons testing tak geen afgeleë tak naspeur nie.
+
+
+
Dit is belangrik om daarop te let dat hierdie nommers slegs akkuraat is sedert die laaste keer wat jy van elke bediener af afgehaal (fetched) het.
+Hierdie opdrag maak nie kontak met die bedieners nie; dit vertel jou net van wat dit plaaslik van hierdie bedieners af gekas (cached) het.
+As jy heeltemal op datum voor- en agter-nommers wil hê, sal jy van al jou remotes moet fetch net voordat jy hierdie uitvoer.
+Jy kan dit so doen:
+
+
+
+
$ git fetch --all; git branch -vv
+
+
+
+
Aftrek (Pulling)
+
+
+Terwyl die git fetch opdrag al die veranderings op die bediener sal afhaal wat jy nog nie het nie, sal dit jou werkgids (working directory) glad nie verander nie.
+Dit sal bloot die data vir jou kry en jou toelaat om dit self saam te smelt (merge).
+Daar is egter 'n opdrag genaamd git pull wat in die meeste gevalle in wese 'n git fetch is, onmiddellik gevolg deur 'n git merge.
+As jy 'n tracking branch opgestel het soos in die vorige afdeling gedemonstreer, hetsy deur dit eksplisiet in te stel of deur dit vir jou te laat skep deur die clone of checkout opdragte, sal git pull kyk watter bediener en tak jou huidige tak naspeur, van daardie bediener afhaal (fetch) en dan probeer om daardie afgeleë tak (remote branch) in te smelt.
+
+
+
Afgeleë Takke Uitvee (Deleting Remote Branches)
+
+
+Veronderstel jy is klaar met 'n afgeleë tak — sê nou jy en jou medewerkers is klaar met 'n kenmerk (feature) en het dit in jou remote se master tak (of watter tak jou stabiele kodelyn ook al in is) saamgesmelt (merged).
+Jy kan 'n afgeleë tak uitvee deur die --delete opsie saam met git push te gebruik.
+As jy jou serverfix tak van die bediener wil uitvee, voer jy die volgende uit:
+
+
+
+
$ git push origin --delete serverfix
+To https://github.com/schacon/simplegit
+ - [deleted] serverfix
+
+
+
+
Al wat dit basies doen, is om die wyser (pointer) van die bediener af te verwyder.
+Die Git-bediener sal oor die algemeen die data daar hou vir 'n rukkie totdat 'n vullisverwyderingsproses (garbage collection) loop, so as dit per ongeluk uitgevee is, is dit dikwels maklik om te herstel.
+
+
Eenvoudige vertakking en saamsmelting (Basic Branching and Merging)
+
+
Kom ons stap deur 'n eenvoudige voorbeeld van vertakking (branching) en saamsmelting (merging) met 'n werkvloei (workflow) wat jy in die regte wêreld sal gebruik.
+Jy sal hierdie stappe volg:
+
+
+-
+
Werk aan 'n webwerf.
+
+-
+
Skep 'n tak (branch) vir 'n nuwe storie of taak waaraan jy werk.
+
+-
+
Doen bietjie werk in daardie tak.
+
+
+
+
Dan kry jy 'n oproep dat 'n ander probleem dadelik reggemaak moet word; jy moet 'n vinnige regstelling (hotfix) maak.
+Jy sal die volgende doen:
+
+
+-
+
Skakel (switch) oor na jou produksie-tak.
+
+-
+
Skep 'n tak om die hotfix by te voeg.
+
+-
+
Nadat dit getoets is, smelt (merge) die hotfix-tak saam en stuur (push) dit na produksie.
+
+-
+
Skakel terug na jou oorspronklike storie en gaan voort met jou werk.
+
+
+
+
Eenvoudige vertakking (Basic Branching)
+
+
+Eerstens, kom ons sê jy werk aan jou projek en het reeds 'n paar vasleggings (commits) op die master tak (branch) gemaak.
+
+
+
+
}}" alt="A simple commit history.">
+
+
Figure 18. 'n Eenvoudige vasleggingsgeskiedenis (commit history)
+
+
+
Jy het besluit dat jy gaan werk aan probleem #53 in watter stelsel jou maatskappy ook al gebruik om probleme te registreer.
+Om 'n tak (branch) te skep en dadelik soontoe oor te skakel (checkout), kan jy die git checkout opdrag met die -b opsie uitvoer:
+
+
+
+
$ git checkout -b iss53
+Switched to a new branch "iss53"
+
+
+
+
Dit is 'n kortpad vir:
+
+
+
+
$ git branch iss53
+$ git checkout iss53
+
+
+
+
+
}}" alt="Creating a new branch pointer.">
+
+
Figure 19. Skep van 'n nuwe tak-wyser (branch pointer)
+
+
+
Jy doen bietjie werk aan jou webwerf en doen 'n paar vasleggings (commits).
+Deur dit te doen beweeg die iss53 tak vorentoe, omdat jy dit uitgecheck (checked out) het (dit wil sê, jou HEAD wys daarna):
+
+
+
+
$ vim index.html
+$ git commit -a -m 'added a new footer [issue 53]'
+
+
+
+
+
}}" alt="The iss53 branch has moved forward with your work.">
+
+
Figure 20. Die iss53 tak het vorentoe beweeg met jou werk
+
+
+
Nou kry jy die oproep dat daar 'n probleem met die webwerf is, en jy moet dit dadelik regmaak.
+Met Git hoef jy nie die regstelling gelyktydig vry te stel (deploy) met die iss53 veranderings wat jy gemaak het nie, en jy hoef ook nie baie moeite te doen om daardie veranderings terug te rol (revert) voordat jy kan werk aan jou regstelling in produksie nie.
+Al wat jy hoef te doen is om terug te skakel (switch) na jou master tak.
+
+
+
Maar voordat jy dit doen, let op dat as jou werkgids (working directory) of voorbereidingsarea (staging area) veranderings bevat wat nog nie vasgelê (committed) is nie en konflik met die tak wat jy wil uitcheck, sal Git jou nie laat oorskakel nie.
+Dit is die beste om 'n skoon werkende toestand te hê wanneer jy tussen takke skakel.
+Daar is maniere om hierom te kom (naamlik wegbêre (stashing) en vasleggings-wysiging (commit amending)) wat ons later in }}">Bêre en Skoonmaak (Stashing and Cleaning) sal dek.
+Vir nou, laat ons aanneem dat jy alle veranderings vasgelê (committed) het, sodat jy kan oorskakel na jou master tak:
+
+
+
+
$ git checkout master
+Switched to branch 'master'
+
+
+
+
Hierna is jou projek se werkgids (working directory) presies soos dit was voordat jy aan probleem #53 begin werk het, en jy kan daarop konsentreer om jou hotfix te doen.
+Dit is 'n belangrike punt om te onthou: wanneer jy van takke verander, herstel Git jou werkgids om te lyk soos dit was toe jy laas op daardie tak vasgelê (committed) het.
+Dit voeg outomaties lêers by, verwyder dit en verander dit om seker te maak dat jou werkskopie presies lyk soos die tak gelyk het by jou laaste vaslegging.
+
+
+
Vervolgens moet jy 'n hotfix doen.
+Kom ons skep 'n hotfix tak om op te werk totdat dit voltooi is:
+
+
+
+
$ git checkout -b hotfix
+Switched to a new branch 'hotfix'
+$ vim index.html
+$ git commit -a -m 'fixed the broken email address'
+[hotfix 1fb7853] fixed the broken email address
+ 1 file changed, 2 insertions(+)
+
+
+
+
+
}}" alt="Hotfix branch based on master.">
+
+
Figure 21. Hotfix-tak gebaseer op master
+
+
+
+
Jy kan jou toetse laat hardloop, jouself verseker dat die hotfix is wat jy wil hê, en uiteindelik die hotfix tak saamsmelt (merge) met jou master-tak om dit na produksie uit te rol.
+Jy doen dit met die git merge opdrag:
+
+
+
+
$ git checkout master
+$ git merge hotfix
+Updating f42c576..3a0874c
+Fast-forward
+ index.html | 2 ++
+ 1 file changed, 2 insertions(+)
+
+
+
+
Jy sal die uitdrukking “Fast-forward” in daardie saamsmelting (merge) sien.
+Omdat die vaslegging (commit) C4 waarna die hotfix tak wat jy ingesmelt het, wys, direk voor die vaslegging C2 lê waarop jy jouself bevind, skuif Git bloot die wyser (pointer) vorentoe.
+Om dit anders te stel: as jy 'n vaslegging probeer saamsmelt (merge) met 'n vaslegging wat bereik kan word deur die geskiedenis van eersgenoemde te volg, vereenvoudig Git dinge deur die wyser vorentoe te skuif aangesien daar geen afwykende werk is om saam te smelt nie — dit word 'n “fast-forward” (vinnig-vorentoe) genoem.
+
+
+
Jou verandering is nou in die momentopname (snapshot) van die vaslegging (commit) waarna die master tak wys, en jy kan jou verandering uitrol (deploy).
+
+
+
+
}}" alt="master is fast-forwarded to hotfix.">
+
+
Figure 22. master word vinnig-vorentoe geskuif (fast-forwarded) na hotfix
+
+
+
+
Nadat jou super-belangrike regstelling uitgerol is, is jy gereed om terug te skakel (switch) na die werk wat jy gedoen het voordat jy onderbreek is.
+Eers gaan jy egter die hotfix tak uitvee, want jy het dit nie meer nodig nie — die master tak wys na dieselfde plek.
+Jy kan dit uitvee met die -d opsie op git branch:
+
+
+
+
$ git branch -d hotfix
+Deleted branch hotfix (3a0874c).
+
+
+
+
Nou kan jy terugskakel na jou werk-in-wording tak vir probleem #53 en voortgaan om daaraan te werk.
+
+
+
+
$ git checkout iss53
+Switched to branch "iss53"
+$ vim index.html
+$ git commit -a -m 'finished the new footer [issue 53]'
+[iss53 ad82d7a] finished the new footer [issue 53]
+1 file changed, 1 insertion(+)
+
+
+
+
+
}}" alt="Work continues on iss53.">
+
+
Figure 23. Werk gaan voort op iss53
+
+
+
+
Dit is belangrik om hier op te let dat die werk wat jy in die hotfix tak gedoen het, nie in die lêers in jou iss53 tak is nie.
+As jy dit moet intrek, kan jy die master tak by jou iss53 tak saamsmelt (merge) deur git merge master uit te voer, of jy kan wag om daardie veranderings te integreer totdat jy besluit om die iss53 tak later by master in te trek.
+
+
+
Eenvoudige saamsmelting (Basic Merging)
+
+
+Veronderstel jy het besluit jou probleem #53 werk is voltooi en gereed om by jou master tak saamgesmelt (merged) te word.
+Om dit te doen, sal jy jou iss53 tak saamsmelt op dieselfde manier as wat jy vroeër jou hotfix tak saamgesmelt het.
+Al wat jy hoef te doen is om na die tak oor te skakel (checkout) waarby jy wil saamsmelt, en dan die git merge opdrag uit te voer:
+
+
+
+
$ git checkout master
+Switched to branch 'master'
+$ git merge iss53
+Merge made by the 'recursive' strategy.
+index.html | 1 +
+1 file changed, 1 insertion(+)
+
+
+
+
Dit lyk 'n bietjie anders as die hotfix saamsmelting wat jy vroeër gedoen het.
+In hierdie geval het jou ontwikkelingsgeskiedenis vanaf 'n ouer punt afgewyk.
+Aangesien die vaslegging (commit) op die tak waarop jy is nie 'n direkte voorouer is van die tak wat jy insmelt nie, moet Git bietjie werk doen.
+In hierdie geval doen Git 'n eenvoudige drierigting-saamsmelting (three-way merge), wat die twee momentopnames (snapshots) gebruik waarna die tak-punte wys, asook die gemeenskaplike voorouer van daardie twee.
+
+
+
+
}}" alt="Three snapshots used in a typical merge.">
+
+
Figure 24. Drie momentopnames (snapshots) wat in 'n tipiese saamsmelting gebruik word
+
+
+
In plaas daarvan om die tak-wyser (branch pointer) net vorentoe te skuif, skep Git 'n nuwe momentopname wat die resultaat is van hierdie drierigting-saamsmelting, en skep outomaties 'n nuwe vaslegging (commit) wat daarna wys.
+Dit word na verwys as 'n saamsmeltingsvaslegging (merge commit), en is spesiaal in die sin dat dit meer as een ouer (parent) het.
+
+
+
+
}}" alt="A merge commit.">
+
+
Figure 25. 'n Saamsmeltingsvaslegging (merge commit)
+
+
+
Noudat jou werk saamgesmelt is, is daar nie meer 'n behoefte aan die iss53 tak nie.
+Jy kan die tak uitvee en dan die kwessie in jou probleem-opsporingstelsel (ticket-tracking system) handmatig sluit:
+
+
+
+
Eenvoudige saamsmeltingskonflikte (Basic Merge Conflicts)
+
+
+Af en toe verloop hierdie proses nie so glad nie.
+As jy dieselfde deel van dieselfde lêer verskillend verander het in die twee takke wat jy besig is om saam te smelt, sal Git nie in staat wees om dit skoon saam te smelt (merge) nie.
+As jou regstelling vir probleem #53 dieselfde deel van 'n lêer as die hotfix verander het, sal jy 'n saamsmeltingskonflik (merge conflict) kry wat min of meer so lyk:
+
+
+
+
$ git merge iss53
+Auto-merging index.html
+CONFLICT (content): Merge conflict in index.html
+Automatic merge failed; fix conflicts and then commit the result.
+
+
+
+
Git het nie outomaties 'n nuwe saamsmeltingsvaslegging (merge commit) geskep nie.
+Dit het die proses laat wag terwyl jy die konflik oplos.
+As jy enige tyd na 'n saamsmeltingskonflik wil sien watter lêers nog onsaamgesmelt (unmerged) is, kan jy git status uitvoer:
+
+
+
+
$ git status
+On branch master
+You have unmerged paths.
+ (fix conflicts and run "git commit")
+
+Unmerged paths:
+ (use "git add <file>..." to mark resolution)
+
+ both modified: index.html
+
+no changes added to commit (use "git add" and/or "git commit -a")
+
+
+
+
Enigiets wat saamsmeltingskonflikte (merge conflicts) het en nog nie opgelos is nie, word as onsaamgesmelt (unmerged) gelys.
+Git voeg standaard konflik-oplossingsmerkers by die lêers wat konflikte bevat, sodat jy hulle handmatig kan oopmaak en die konflikte kan oplos.
+Jou lêer bevat 'n afdeling wat min of meer so lyk:
+
+
+
+
<<<<<<< HEAD:index.html
+<div id="footer">contact : email.support@github.com</div>
+=======
+<div id="footer">
+ please contact us at support@github.com
+</div>
+>>>>>>> iss53:index.html
+
+
+
+
Dit beteken die weergawe in HEAD (jou master tak, want dit is wat jy uitgecheck het toe jy die saamsmelt-opdrag uitgevoer het) is die boonste deel van daardie blok (alles bo die =======), terwyl die weergawe in jou iss53 tak soos alles in die onderste deel lyk.
+Om die konflik op te los, moet jy óf een kant kies óf self die inhoud saamsmelt.
+Jy kan byvoorbeeld hierdie konflik oplos deur die hele blok met hierdie te vervang:
+
+
+
+
<div id="footer">
+please contact us at email.support@github.com
+</div>
+
+
+
+
Hierdie oplossing het 'n bietjie van elke afdeling in, en die <<<<<<<, =======, en >>>>>>> reëls is heeltemal verwyder.
+Nadat jy elkeen van hierdie afdelings in elke konflikterende lêer opgelos het, voer git add uit op elke lêer om dit as opgelos te merk.
+Die voorbereiding (staging) van die lêer merk dit as opgelos in Git.
+
+
+
As jy 'n grafiese hulpmiddel wil gebruik om hierdie kwessies op te los, kan jy git mergetool uitvoer, wat 'n toepaslike visuele saamsmelt-instrument aanvuur en jou deur die konflikte sal lei:
+
+
+
+
$ git mergetool
+
+This message is displayed because 'merge.tool' is not configured.
+See 'git mergetool --tool-help' or 'git help config' for more details.
+'git mergetool' will now attempt to use one of the following tools:
+opendiff kdiff3 tkdiff xxdiff meld tortoisemerge gvimdiff diffuse diffmerge ecmerge p4merge araxis bc3 codecompare vimdiff emerge
+Merging:
+index.html
+
+Normal merge conflict for 'index.html':
+ {local}: modified file
+ {remote}: modified file
+Hit return to start merge resolution tool (opendiff):
+
+
+
+
As jy 'n ander saamsmelt-instrument (merge tool) wil gebruik in plaas van die verstek een (Git het opendiff in hierdie geval gekies omdat die opdrag op 'n Mac uitgevoer is), kan jy al die ondersteunde gereedskap sien wat bo gelys word na “one of the following tools”.
+Tik net die naam in van die instrument wat jy verkies om te gebruik.
+
+
+
+
Nadat jy die saamsmelt-instrument toemaak, vra Git jou of die saamsmelting suksesvol was.
+As jy die skrip vertel dat dit was, berei (stage) dit die lêer vir jou voor om dit as opgelos te merk.
+Jy kan git status weer uitvoer om te verifieer dat al die konflikte opgelos is:
+
+
+
+
$ git status
+On branch master
+All conflicts fixed but you are still merging.
+ (use "git commit" to conclude merge)
+
+Changes to be committed:
+
+ modified: index.html
+
+
+
+
As jy tevrede is daarmee, en jy het geverifieer dat alles wat konflikte gehad het nou voorberei (staged) is, kan jy git commit tik om die saamsmeltingsvaslegging (merge commit) te voltooi.
+Die vasleggingsboodskap lyk by verstek (by default) min of meer so:
+
+
+
+
Merge branch 'iss53'
+
+Conflicts:
+ index.html
+#
+# It looks like you may be committing a merge.
+# If this is not correct, please remove the file
+# .git/MERGE_HEAD
+# and try again.
+
+
+# Please enter the commit message for your changes. Lines starting
+# with '#' will be ignored, and an empty message aborts the commit.
+# On branch master
+# All conflicts fixed but you are still merging.
+#
+# Changes to be committed:
+# modified: index.html
+#
+
+
+
+
Jy kan daardie boodskap verander met besonderhede oor hoe jy die konflik opgelos het as jy dink dit sal nuttig wees vir ander mense wat in die toekoms na hierdie saamsmelting kyk — hoekom jy gedoen het wat jy gedoen het, as dit nie vanselfsprekend is nie.
+
+
Herbasering (Rebasing)
+
+
+In Git is daar twee hoofmaniere om veranderings van een tak (branch) in 'n ander te integreer: die merge (saamsmelting) en die rebase (herbasering).
+In hierdie afdeling sal jy leer wat rebasing is, hoe om dit te doen, hoekom dit so 'n wonderlike instrument is, en in watter gevalle jy dit nie wil gebruik nie.
+
+
Die Eenvoudige Rebase (The Basic Rebase)
+
+
+
+
}}" alt="Simple divergent history">
+
+
Figure 35. Eenvoudige afgewykte geskiedenis (Simple divergent history)
+
+
+
Die maklikste manier om die takke te integreer, soos ons reeds gedek het, is die merge opdrag.
+Dit voer 'n drierigting-saamsmelting (three-way merge) uit tussen die twee laaste tak-momentopnames (branch snapshots) (C3 en C4) en die mees onlangse gemeenskaplike voorouer (common ancestor) van die twee (C2), en skep 'n nuwe momentopname (en vaslegging).
+
+
+
+
}}" alt="Merging to integrate diverged work history">
+
+
Figure 36. Saamsmelting (merging) om afgewykte werkgeskiedenis te integreer
+
+
+
Daar is egter 'n ander manier: jy kan die pleister (patch) van die verandering wat in C4 ingestel is, neem en dit weer bo-op C3 toepas (reapply).
+In Git word dit rebasing (herbasering) genoem.
+Met die rebase opdrag kan jy al die veranderings wat op een tak vasgelê (committed) is, neem en hulle op 'n ander tak herspeel (replay).
+
+
+
Vir hierdie voorbeeld sal jy die experiment tak uitcheck (checkout), en dit dan soos volg op die master tak rebase:
+
+
+
+
$ git checkout experiment
+$ git rebase master
+First, rewinding head to replay your work on top of it...
+Applying: added staged command
+
+
+
+
Hierdie operasie werk deur na die gemeenskaplike voorouer van die twee takke te gaan (die een waarop jy is en die een waarop jy rebase), die verskil (diff) te kry wat deur elke vaslegging (commit) van die huidige tak ingestel is, daardie diffs in tydelike lêers te stoor, die huidige tak terug te stel (reset) na dieselfde vaslegging as die tak waarop jy rebase, en uiteindelik elke verandering een vir een toe te pas.
+
+
+
+
}}" alt="Rebasing the change introduced in `C4` onto `C3`">
+
+
Figure 37. Rebase van die verandering ingestel in C4 bo-op C3
+
+
+
+
Op hierdie punt kan jy teruggaan na die master tak en 'n vinnig-vorentoe saamsmelting (fast-forward merge) doen.
+
+
+
+
$ git checkout master
+$ git merge experiment
+
+
+
+
+
}}" alt="Fast-forwarding the `master` branch">
+
+
Figure 38. Vinnig-vorentoe (fast-forwarding) van die master tak
+
+
+
Nou is die momentopname (snapshot) waarna C4' wys, presies dieselfde as dié waarna C5 in }}">die merge-voorbeeld gewys het.
+Daar is geen verskil in die eindproduk van die integrasie nie, maar rebasing sorg vir 'n skoner geskiedenis.
+As jy die log van 'n gerebasede tak ondersoek, lyk dit soos 'n lineêre geskiedenis: dit blyk asof al die werk in 'n reeks gebeur het, selfs al het dit oorspronklik in parallel gebeur.
+
+
+
Jy sal dit dikwels doen om seker te maak jou vasleggings (commits) pas skoon toe op 'n afgeleë tak (remote branch) — miskien in 'n projek waartoe jy probeer bydra, maar wat jy nie self bestuur (maintain) nie.
+In hierdie geval sal jy jou werk in 'n tak doen en dan jou werk op origin/master rebase wanneer jy gereed is om jou pleisters (patches) aan die hoofprojek voor te lê.
+Op dié manier hoef die instandhouer (maintainer) geen integrasiewerk te doen nie — net 'n fast-forward of 'n skoon toepassing (clean apply).
+
+
+
Let daarop dat die momentopname (snapshot) waarna die finale vaslegging wys waarmee jy eindig, hetsy dit die laaste van die gerebasede vasleggings is na 'n rebase, of die finale saamsmeltingsvaslegging (merge commit) na 'n merge, presies dieselfde momentopname is — dit is slegs die geskiedenis wat verskil.
+Rebasing speel veranderings van een werklyn op 'n ander oor in die volgorde waarin hulle ingestel is, terwyl merging die eindpunte neem en hulle saamsmelt.
+
+
+
Meer Interessante Rebases (More Interesting Rebases)
+
+
Jy kan ook jou rebase op iets anders as die rebase-teikentak laat afspeel.
+Neem 'n geskiedenis soos }}">'n Geskiedenis met 'n onderwerp-tak wat van 'n ander onderwerp-tak af vertak, byvoorbeeld.
+Jy het 'n onderwerp-tak (topic branch) genaamd server vertak om bietjie bedienerkant-funksionaliteit (server-side functionality) by jou projek te voeg, en 'n vaslegging gemaak.
+Toe het jy daarvan af vertak om die kliëntkant-veranderings (client) te maak en 'n paar keer vasgelê.
+Ten slotte het jy teruggegaan na jou server tak en nog 'n paar vasleggings gemaak.
+
+
+
+
}}" alt="A history with a topic branch off another topic branch">
+
+
Figure 39. 'n Geskiedenis met 'n onderwerp-tak wat van 'n ander onderwerp-tak af vertak
+
+
+
Veronderstel jy besluit dat jy jou kliëntkant-veranderings in jou hooflyn (mainline) wil saamsmelt vir 'n vrystelling (release), maar jy wil nog wag met die bedienerkant-veranderings totdat dit verder getoets is.
+Jy kan die veranderings op client neem wat nie op server is nie (C8 en C9) en hulle op jou master tak herspeel deur die --onto opsie van git rebase te gebruik:
+
+
+
+
$ git rebase --onto master server client
+
+
+
+
Dit sê basies: “Neem die client tak, vind uit wat die pleisters (patches) is vandat dit van die server tak afgewyk het, en herspeel hierdie pleisters in die client tak asof dit direk op die master tak gebaseer was.”
+Dit is 'n bietjie kompleks, maar die resultaat is nogal gaaf.
+
+
+
+
}}" alt="Rebasing a topic branch off another topic branch">
+
+
Figure 40. Rebasing van 'n onderwerp-tak vanaf 'n ander onderwerp-tak
+
+
+
+
+
$ git checkout master
+$ git merge client
+
+
+
+
+
}}" alt="Fast-forwarding your `master` branch to include the `client` branch changes">
+
+
Figure 41. Vinnig-vorentoe (fast-forwarding) van jou master tak om die client tak se veranderings in te sluit
+
+
+
Kom ons sê jy besluit om jou server tak ook in te trek (pull in).
+Jy kan die server tak op die master tak rebase sonder om dit eers uit te check, deur git rebase <basebranch> <topicbranch> uit te voer — wat die onderwerp-tak (in hierdie geval, server) vir jou uitcheck en dit op die basistak (master) herspeel:
+
+
+
+
$ git rebase master server
+
+
+
+
+
+
}}" alt="Rebasing your `server` branch on top of your `master` branch">
+
+
Figure 42. Rebasing van jou server tak bo-op jou master tak
+
+
+
Dan kan jy die basistak (master) vinnig-vorentoe stuur:
+
+
+
+
$ git checkout master
+$ git merge server
+
+
+
+
+
+
$ git branch -d client
+$ git branch -d server
+
+
+
+
+
}}" alt="Final commit history">
+
+
Figure 43. Finale vasleggingsgeskiedenis (Final commit history)
+
+
+
Die Gevare van Rebasing (The Perils of Rebasing)
+
+
+Aai, maar die vreugde van rebasing is nie sonder sy nadele nie, wat in 'n enkele reël opgesom kan word:
+
+
+
Moenie vasleggings (commits) rebase wat buite jou bewaarplek (repository) bestaan en waarop mense dalk hul werk gebaseer het nie.
+
+
+
As jy daardie riglyn volg, sal jy oukei wees.
+As jy dit nie doen nie, sal mense jou haat, en jy sal deur vriende en familie verag word.
+
+
+
Wanneer jy dinge rebase, laat vaar jy bestaande vasleggings en skep nuwes wat soortgelyk, maar tog verskillend is.
+As jy vasleggings êrens heen stuur (push) en ander trek (pull) hulle af en baseer hul werk daarop, en jy herskryf dan daardie vasleggings met git rebase en push hulle weer op, sal jou medewerkers hul werk weer moet saamsmelt (re-merge) en dinge sal morsig raak wanneer jy hul werk na joune probeer terugtrek.
+
+
+
Kom ons kyk na 'n voorbeeld van hoe rebasing van werk wat jy reeds publiek gemaak het, probleme kan veroorsaak.
+Veronderstel jy kloon vanaf 'n sentrale bediener en doen dan 'n bietjie werk daarvan af.
+Jou vasleggingsgeskiedenis lyk so:
+
+
+
+
}}" alt="Clone a repository, and base some work on it">
+
+
Figure 44. Kloon 'n bewaarplek, en baseer bietjie werk daarop
+
+
+
Nou doen iemand anders nog werk wat 'n merge insluit, en stuur (push) daardie werk na die sentrale bediener.
+Jy haal dit af (fetch) en smelt die nuwe afgeleë tak (remote branch) in jou werk in, wat jou geskiedenis so iets laat lyk:
+
+
+
+
}}" alt="Fetch more commits, and merge them into your work">
+
+
Figure 45. Haal meer vasleggings af (fetch), en smelt hulle by jou werk in (merge)
+
+
+
Vervolgens besluit die persoon wat die saamgesmelte werk gepush het, om terug te gaan en eerder hul werk te rebase; hulle doen 'n git push --force om die geskiedenis op die bediener te oorskryf.
+Jy haal (fetch) dan van daardie bediener af, wat die nuwe vasleggings aftrek.
+
+
+
+
}}" alt="Someone pushes rebased commits, abandoning commits you’ve based your work on">
+
+
Figure 46. Iemand push gerebasede vasleggings, en laat vaar vasleggings waarop jy jou werk gebaseer het
+
+
+
Nou is julle albei in die pekel.
+As jy 'n git pull doen, sal jy 'n saamsmeltingsvaslegging (merge commit) skep wat albei lyne van die geskiedenis insluit, en jou bewaarplek sal so lyk:
+
+
+
+
}}" alt="You merge in the same work again into a new merge commit">
+
+
Figure 47. Jy smelt dieselfde werk weer in 'n nuwe saamsmeltingsvaslegging (merge commit) in
+
+
+
As jy 'n git log uitvoer wanneer jou geskiedenis so lyk, sal jy twee vasleggings sien met dieselfde outeur, datum en boodskap, wat verwarrend sal wees.
+Verder, as jy hierdie geskiedenis weer na die bediener opstuur (push), sal jy al daardie gerebasede vasleggings weer aan die sentrale bediener bekendstel, wat mense nog verder kan verwar.
+Dit is redelik veilig om te aanvaar dat die ander ontwikkelaar nie C4 en C6 in die geskiedenis wil hê nie; dis hoekom hulle in die eerste plek gerebase het.
+
+
+
Rebase Wanneer Jy Rebase (Rebase When You Rebase)
+
+
As jy jou wel in 'n situasie soos hierdie bevind, het Git 'n bietjie verdere toorkuns wat jou dalk kan help.
+As iemand op jou span veranderings afdwing (force push) wat die werk oorskryf waarop jy jou werk gebaseer het, is jou uitdaging om uit te vind wat joune is en wat hulle herskryf het.
+
+
+
Dit blyk dat benewens die vaslegging SHA-1 kontrolesom, bereken Git ook 'n kontrolesom wat slegs gebaseer is op die pleister (patch) wat met die vaslegging ingestel is.
+Dit word 'n “patch-id” genoem.
+
+
+
As jy werk aftrek (pull) wat herskryf is en dit bo-op die nuwe vasleggings van jou vennoot rebase, kan Git dikwels suksesvol uitvind wat uniek joune is en dit weer bo-op die nuwe tak toepas.
+
+
+
+
+-
+
Bepaal watter werk uniek is aan ons tak (C2, C3, C4, C6, C7)
+
+-
+
Bepaal watter daarvan nie saamsmeltingsvasleggings (merge commits) is nie (C2, C3, C4)
+
+-
+
Bepaal watter nie in die teikentak herskryf is nie (slegs C2 en C3, aangesien C4 dieselfde pleister is as C4')
+
+-
+
Pas daardie vasleggings bo-op teamone/master toe
+
+
+
+
+
+
+
}}" alt="Rebase on top of force-pushed rebase work">
+
+
Figure 48. Rebase bo-op afgedwonge-opgestuurde (force-pushed) rebase werk
+
+
+
Hierdie werk slegs as C4 en C4' wat jou vennoot gemaak het, byna presies dieselfde pleister (patch) is.
+Andersins sal die rebase nie kan vasstel dat dit 'n duplikaat is nie en sal nog 'n C4-agtige pleister byvoeg (wat waarschijnlijk sal misluk om skoon toe te pas, aangesien die veranderings reeds ten minste gedeeltelik daar sal wees).
+
+
+
Jy kan dit ook vereenvoudig deur 'n git pull --rebase in plaas van 'n normale git pull uit te voer.
+Of jy kan dit in hierdie geval handmatig doen met 'n git fetch gevolg deur 'n git rebase teamone/master.
+
+
+
As jy git pull gebruik en --rebase die verstek (default) wil maak, kan jy die pull.rebase konfigurasie-waarde stel met iets soos git config --global pull.rebase true.
+
+
+
As jy altyd net vasleggings rebase wat nog nooit jou eie rekenaar verlaat het nie, sal jy heel oukei wees.
+As jy vasleggings rebase wat gepush is, maar waarop niemand anders vasleggings gebaseer het nie, sal jy ook oukei wees.
+As jy vasleggings rebase wat reeds publiek gepush is, en mense dalk hul werk op daardie vasleggings gebaseer het, dan is jy dalk op pad na 'n mate van frustrerende moeilikheid, asook die veragting van jou spangenote.
+
+
+
As jy of 'n vennoot dit wel op een of ander stadium nodig vind, maak seker almal weet om git pull --rebase uit te voer om te probeer om die pyn nadat dit gebeur het, 'n bietjie eenvoudiger te maak.
+
+
+
Rebase vs. Merge
+
+
+Noudat jy rebasing en merging in aksie gesien het, wonder jy dalk watter een beter is.
+Voordat ons dit kan beantwoord, kom ons tree 'n bietjie terug en praat oor wat geskiedenis beteken.
+
+
+
Een standpunt hieroor is dat jou bewaarplek (repository) se vasleggingsgeskiedenis 'n rekord is van wat werklik gebeur het.
+Dit is 'n historiese dokument, waardevol op sy eie, en daar behoort nie mee gepeuter te word nie.
+Uit hierdie hoek gesien, is die verandering van die vasleggingsgeskiedenis byna godslasterlik; jy lieg oor wat regtig gebeur het.
+Wat daarvan as daar 'n morsige reeks saamsmeltingsvasleggings (merge commits) was?
+Dit is hoe dit gebeur het, en die bewaarplek moet dit vir die nageslag bewaar.
+
+
+
Die teenoorgestelde standpunt is dat die vasleggingsgeskiedenis die storie is van hoe jou projek gemaak is.
+Jy sou nie die eerste konsep van 'n boek publiseer nie, so hoekom jou morsige werk wys?
+Wanneer jy aan 'n projek werk, mag jy dalk 'n rekord nodig hê van al jou misstappe en doodloopstrate, maar wanneer dit tyd is om jou werk aan die wêreld te wys, sal jy dalk 'n meer samehangende storie wil vertel van hoe jy van A na B gekom het.
+Mense in hierdie kamp gebruik instrumente soos rebase en filter-branch om hul vasleggings (commits) te herskryf voordat hulle in die hooftak (mainline branch) saamgesmelt (merged) word.
+Hulle gebruik gereedskap soos rebase en filter-branch, om die storie te vertel op 'n manier wat die beste is vir toekomstige lesers.
+
+
+
Nou, tot die vraag of saamsmelting (merging) of herbasering (rebasing) beter is: hopelik sal jy sien dat dit nie so eenvoudig is nie.
+Git is 'n kragtige instrument, en laat jou toe om baie dinge met en aan jou geskiedenis te doen, maar elke span en elke projek is verskillend.
+Noudat jy weet hoe albei hierdie dinge werk, is dit aan jou om te besluit watter een die beste vir jou spesifieke situasie is.
+
+
+
Jy kan die beste van albei wêrelde kry: rebase plaaslike (local) veranderings voordat jy push om jou werk skoon te maak, maar moenie ooit enigiets rebase wat jy iewers heen gepush het nie.
+
+
Summary
+
+
We’ve covered basic branching and merging in Git.
+You should feel comfortable creating and switching to new branches, switching between branches and merging local branches together.
+You should also be able to share your branches by pushing them to a shared server, working with others on shared branches and rebasing your branches before they are shared.
+Next, we’ll cover what you’ll need to run your own Git repository-hosting server.
+
Tak-bestuur (Branch Management)
+
+
+Noudat jy 'n paar takke (branches) geskep, saamgesmelt (merged), en uitgevee het, kom ons kyk na 'n paar tak-bestuursinstrumente (branch-management tools) wat handig te pas sal kom wanneer jy heeltyd takke begin gebruik.
+
+
Die git branch opdrag doen meer as net om takke te skep en uit te vee.
+As jy dit sonder enige argumente uitvoer, kry jy 'n eenvoudige lys van jou huidige takke:
+
+
+
$ git branch
+ iss53
+* master
+ testing
+
+
+
Let op die * karakter wat vooraan die master tak staan: dit dui die tak aan wat jy tans uitgecheck (checked out) het (dit wil sê, die tak waarna HEAD wys).
+Dit beteken dat as jy op hierdie punt vaslê (commit), sal die master tak vorentoe geskuif word met jou nuwe werk.
+Om die laaste vaslegging (commit) op elke tak te sien, kan jy git branch -v uitvoer:
+
+
+
$ git branch -v
+ iss53 93b412c Fix javascript issue
+* master 7a98805 Merge branch 'iss53'
+ testing 782fd34 Add scott to the author list in the readme
+
+
+
Die nuttige --merged en --no-merged opsies kan hierdie lys filtreer na takke wat jy reeds, of nog nie, saamgesmelt (merged) het met die tak waarop jy tans is nie.
+Om te sien watter takke reeds by jou huidige tak saamgesmelt is, kan jy git branch --merged uitvoer:
+
+
+
$ git branch --merged
+ iss53
+* master
+
+
+
Omdat jy vroeër reeds iss53 ingesmelt (merged) het, sien jy dit in jou lys.
+Takke op hierdie lys sonder die * vooraan is oor die algemeen veilig om uit te vee met git branch -d; jy het reeds hul werk in 'n ander tak geïnkorporeer, so jy gaan niks verloor nie.
+
+
Om al die takke te sien wat werk bevat wat jy nog nie saamgesmelt (merged) het nie, kan jy git branch --no-merged uitvoer:
+
+
+
$ git branch --no-merged
+ testing
+
+
+
Dit wys jou ander tak.
+Omdat dit werk bevat wat nog nie saamgesmelt (merged) is nie, sal 'n poging om dit met git branch -d uit te vee, misluk:
+
+
+
$ git branch -d testing
+error: The branch 'testing' is not fully merged.
+If you are sure you want to delete it, run 'git branch -D testing'.
+
+
+
As jy regtig die tak wil uitvee en daardie werk wil verloor, kan jy dit afdwing (force) met -D, soos die behulpsame boodskap uitwys.
+
+
+
+|
+ Tip
+ |
+
+
+ Die opsies hierbo beskryf, --merged en --no-merged, sal, indien 'n vaslegging (commit) of taknaam (branch name) nie as 'n argument gegee word nie, vir jou wys wat onderskeidelik by jou huidige tak saamgesmelt (merged) of nie saamgesmelt is nie.
+
+ Jy kan altyd 'n bykomende argument verskaf om na die saamsmeltings-status (merge state) met betrekking tot 'n ander tak te vra sonder om daardie ander tak eers uit te check (checkout), soos in, wat is nog nie in die master tak saamgesmelt nie?
+
+
+ $ git checkout testing
+$ git branch --no-merged master
+ topicA
+ featureB
+
+ |
+
+
+
+
'n Taknaam verander (Changing a branch name)
+
+
+
Veronderstel jy het 'n tak wat bad-branch-name genoem word en jy wil dit verander na corrected-branch-name, terwyl jy alle geskiedenis behou.
+Jy wil ook die taknaam op die afgeleë bediener (remote) soos GitHub, GitLab, of 'n ander bediener verander.
+Hoe doen jy dit?
+
+
+
Hernoem (rename) die tak plaaslik (locally) met die git branch --move opdrag:
+
+
+
+
$ git branch --move bad-branch-name corrected-branch-name
+
+
+
+
Dit vervang jou bad-branch-name met corrected-branch-name, maar hierdie verandering is vir eers net plaaslik (local).
+Om ander toe te laat om die gekorrigeerde tak op die afgeleë bediener (remote) te sien, stuur (push) dit op:
+
+
+
+
$ git push --set-upstream origin corrected-branch-name
+
+
+
+
Kom ons kyk nou kortliks na waar ons nou is:
+
+
+
+
$ git branch --all
+* corrected-branch-name
+ main
+ remotes/origin/bad-branch-name
+ remotes/origin/corrected-branch-name
+ remotes/origin/main
+
+
+
+
Let op dat jy op die corrected-branch-name tak is en dit op die afgeleë bediener (remote) beskikbaar is.
+Die tak met die slegte naam is egter ook nog daar teenwoordig, maar jy kan dit uitvee deur die volgende opdrag uit te voer:
+
+
+
+
$ git push origin --delete bad-branch-name
+
+
+
+
Nou is die slegte taknaam ten volle vervang met die gekorrigeerde taknaam.
+
+
+
Die master-tak se naam verander (Changing the master branch name)
+
+
+
+|
+ Warning
+ |
+
+
+ Om die naam van 'n tak soos master/main/mainline/default te verander, sal die integrasies, dienste, hulpmiddels (helper utilities) en bou/vrystelling-skrifte (build/release scripts) wat jou bewaarplek (repository) gebruik, breek.
+Maak seker dat jy met jou medewerkers konsulteer voordat jy dit doen.
+Maak ook seker dat jy 'n deeglike soektog deur jou bewaarplek (repo) doen en enige verwysings na die ou taknaam in jou kode en skrifte opdateer.
+ |
+
+
+
+
+
Hernoem jou plaaslike master tak na main met die volgende opdrag:
+
+
+
+
$ git branch --move master main
+
+
+
+
Daar is nie meer 'n plaaslike master tak nie, aangesien dit hernoem is na die main tak.
+
+
+
Om ander toe te laat om die nuwe main tak te sien, moet jy dit na die afgeleë bediener (remote) opstuur (push).
+Dit maak die hernoemde tak op die afgeleë bediener (remote) beskikbaar.
+
+
+
+
$ git push --set-upstream origin main
+
+
+
+
Nou eindig ons op met die volgende toestand:
+
+
+
+
$ git branch --all
+* main
+ remotes/origin/HEAD -> origin/master
+ remotes/origin/main
+ remotes/origin/master
+
+
+
+
Jou plaaslike master tak is weg, aangesien dit vervang is met die main tak.
+Die main tak is teenwoordig op die afgeleë bediener (remote).
+Die ou master tak is egter steeds teenwoordig op die afgeleë bediener.
+Ander medewerkers sal voortgaan om die master tak as die basis vir hul werk te gebruik, totdat jy verdere veranderings aanbring.
+
+
+
Nou het jy nog 'n paar take voor jou om die oorgang te voltooi:
+
+
+
+-
+
Enige projekte wat van hierdie een afhanklik is, sal hul kode en/of konfigurasie moet opdateer.
+
+-
+
Dateer enige toetsloper-konfigurasielêers (test-runner configuration files) op.
+
+-
+
Pas bou- en vrystelling-skrifte (build and release scripts) aan.
+
+-
+
Herlei (redirect) instellings op jou repo-gasheer (host) vir dinge soos die repo se verstektak (default branch), saamsmeltreëls (merge rules), en ander dinge wat by takname pas.
+
+-
+
Dateer verwysings na die ou tak in dokumentasie op.
+
+-
+
Maak enige "pull requests" toe, of smelt hulle saam (merge), wat die ou tak as teiken het.
+
+
+
+
+
Nadat jy al hierdie take gedoen het, en seker is dat die main tak presies soos die master tak presteer, kan jy die master tak uitvee:
+
+
+
+
$ git push origin --delete master
+
+
+
+
+Nearly every VCS has some form of branching support.
+Branching means you diverge from the main line of development and continue to do work without messing with that main line.
+In many VCS tools, this is a somewhat expensive process, often requiring you to create a new copy of your source code directory, which can take a long time for large projects.
Some people refer to Git’s branching model as its “killer feature,” and it certainly sets Git apart in the VCS community.
+Why is it so special?
+The way Git branches is incredibly lightweight, making branching operations nearly instantaneous, and switching back and forth between branches generally just as fast.
+Unlike many other VCSs, Git encourages workflows that branch and merge often, even multiple times in a day.
+Understanding and mastering this feature gives you a powerful and unique tool and can entirely change the way that you develop.
+Takke in 'n Neutedop (Branches in a Nutshell)
+
+
Om werklik te verstaan hoe Git vertakking (branching) hanteer, moet ons 'n tree teruggee en ondersoek hoe Git sy data stoor.
+
+
Soos jy dalk onthou uit }}">[what_is_git_section], stoor Git nie data as 'n reeks veranderingstelle (changesets) of verskille (differences) nie, maar eerder as 'n reeks momentopnames (snapshots).
+
+
Wanneer jy 'n vaslegging (commit) maak, stoor Git 'n vasleggingsobjek (commit object) wat 'n wyser (pointer) bevat na die momentopname van die inhoud wat jy voorberei (staged) het. Hierdie objek bevat ook die outeur se naam en e-posadres, die boodskap wat jy getik het, en wysers na die vaslegging of vasleggings wat direk voor hierdie vaslegging gekom het (sy ouer of ouers): nul ouers vir die aanvanklike vaslegging, een ouer vir 'n normale vaslegging, en veelvuldige ouers vir 'n vaslegging wat die resultaat is van 'n saamsmelting (merge) van twee of meer takke (branches).
+
+
Om dit te visualiseer, kom ons aanvaar jy het 'n gids (directory) wat drie lêers bevat, en jy berei hulle almal voor (stage) en lê dit vas (commit). Die voorbereiding (staging) van die lêers bereken 'n kontrolesom (checksum) vir elkeen (die SHA-1 huts (hash) wat ons in }}">[what_is_git_section] genoem het), stoor daardie weergawe van die lêer in die Git-bewaarplek (repository) (Git verwys na hulle as blobs), en voeg daardie kontrolesom by die voorbereidingsarea (staging area):
+
+
+
$ git add README test.rb LICENSE
+$ git commit -m 'Initial commit'
+
+
+
Wanneer jy die vaslegging skep deur git commit uit te voer, bereken Git die kontrolesom vir elke subgids (in hierdie geval, net die wortel-projekgids / root project directory) en stoor hulle as 'n boom-objek (tree object) in die Git-bewaarplek. Git skep dan 'n vasleggingsobjek (commit object) wat die metadata het, sowel as 'n wyser na die wortel-projekboom sodat dit daardie momentopname (snapshot) kan herskep wanneer nodig.
+
+
Jou Git-bewaarplek (repository) bevat nou vyf objekte: drie blobs (waarvan elkeen die inhoud van een van die drie lêers verteenwoordig), een boom (tree) wat die inhoud van die gids lys en spesifiseer watter lêername as watter blobs gestoor is, en een vaslegging (commit) met die wyser na daardie wortelboom en al die vasleggings-metadata.
+
+
+
}}" alt="A commit and its tree">
+
+
Figure 9. 'n Vaslegging (commit) en sy boom (tree)
+
+
As jy 'n paar veranderings maak en weer vaslê (commit), stoor die volgende vaslegging 'n wyser na die vaslegging wat direk voor dit gekom het.
+
+
+
}}" alt="Commits and their parents">
+
+
Figure 10. Vasleggings (commits) en hul ouers
+
+
'n Tak (branch) in Git is bloot 'n liggewig, beweegbare wyser na een van hierdie vasleggings (commits). Die verstektaknaam (default branch name) in Git is master. Soos jy begin om vasleggings te maak, word jy 'n master tak gegee wat na die laaste vaslegging wys wat jy gemaak het. Elke keer as jy vaslê (commit), skuif die master tak-wyser outomaties vorentoe.
+
+
+
+|
+ Note
+ |
+
+
+ Die “master” tak in Git is nie 'n spesiale tak nie.
+Dit is presies soos enige ander tak. Die enigste rede hoekom byna elke bewaarplek (repository) een het, is dat die git init opdrag dit by verstek (by default) skep en die meeste mense nie die moeite doen om dit te verander nie.
+ |
+
+
+
+
+
}}" alt="A branch and its commit history">
+
+
Figure 11. 'n Tak en sy vasleggingsgeskiedenis
+
+
'n Nuwe tak skep (Creating a New Branch)
+
+
+Wat gebeur wanneer jy 'n nuwe tak skep? Wel, deur dit te doen, word 'n nuwe wyser (pointer) geskep vir jou om rond te skuif. Kom ons sê jy wil 'n nuwe tak genaamd testing skep. Jy doen dit met die git branch opdrag:
+
+
+
+
Dit skep 'n nuwe wyser na dieselfde vaslegging (commit) waarop jy tans is.
+
+
+
+
}}" alt="Two branches pointing into the same series of commits">
+
+
Figure 12. Twee takke wat na dieselfde reeks vasleggings wys
+
+
+
Hoe weet Git op watter tak jy tans is? Dit hou 'n spesiale wyser genaamd HEAD. Let op dat dit baie verskil van die konsep van HEAD in ander VCS’e waaraan jy dalk gewoond is, soos Subversion of CVS. In Git is dit 'n wyser na die plaaslike tak (local branch) waarop jy tans is. In hierdie geval is jy steeds op master. Die git branch opdrag het slegs 'n nuwe tak geskep — dit het nie na daardie tak oorgeskakel (switched) nie.
+
+
+
+
}}" alt="HEAD pointing to a branch">
+
+
Figure 13. HEAD wat na 'n tak wys
+
+
+
Jy kan dit maklik sien deur 'n eenvoudige git log opdrag uit te voer wat vir jou wys waarna die tak-wysers (branch pointers) wys. Hierdie opsie word --decorate genoem.
+
+
+
+
$ git log --oneline --decorate
+f30ab (HEAD -> master, testing) Add feature #32 - ability to add new formats to the central interface
+34ac2 Fix bug #1328 - stack overflow under certain conditions
+98ca9 Initial commit
+
+
+
+
Jy kan die master en testing takke sien wat net daar langs die f30ab vaslegging (commit) is.
+
+
+
Oorskakel tussen takke (Switching Branches)
+
+
+Om oor te skakel (switch) na 'n bestaande tak, voer jy die git checkout opdrag uit. Kom ons skakel oor na die nuwe testing tak:
+
+
+
+
$ git checkout testing
+
+
+
+
Dit skuif HEAD om na die testing tak te wys.
+
+
+
+
}}" alt="HEAD points to the current branch">
+
+
Figure 14. HEAD wys na die huidige tak
+
+
+
Wat is die betekenis daarvan? Wel, kom ons doen nog 'n vaslegging (commit):
+
+
+
+
$ vim test.rb
+$ git commit -a -m 'Make a change'
+
+
+
+
+
}}" alt="The HEAD branch moves forward when a commit is made">
+
+
Figure 15. Die HEAD-tak skuif vorentoe wanneer 'n vaslegging gemaak word
+
+
+
Dit is interessant, want nou het jou testing tak vorentoe geskuif, maar jou master tak wys steeds na die vaslegging (commit) waarop jy was toe jy git checkout uitgevoer het om tussen takke te skakel. Kom ons skakel terug na die master tak:
+
+
+
+
+
+|
+ Note
+ |
+
+
+git log wys nie altyd al die takke nie
+
+ As jy nou dadelik git log sou uitvoer, mag jy dalk wonder waarheen die "testing" tak wat jy so pas geskep het, verdwyn het, aangesien dit nie in die afvoer sou verskyn nie.
+
+ Die tak het nie verdwyn nie; Git weet net nie dat jy in daardie tak belangstel nie en dit probeer vir jou wys waarin dit dink jy belangstel. Met ander woorde, by verstek sal git log slegs die vasleggingsgeskiedenis (commit history) wys wat direk onder die tak lê wat jy uitgecheck (checked out) het.
+
+ Om die vasleggingsgeskiedenis vir die verlangde tak te wys, moet jy dit eksplisiet spesifiseer: git log testing. Om al die takke te wys, voeg --all by jou git log opdrag.
+ |
+
+
+
+
+
+
}}" alt="HEAD moves when you checkout">
+
+
Figure 16. HEAD skuif wanneer jy 'n checkout doen
+
+
+
Daardie opdrag het twee dinge gedoen. Dit het die HEAD-wyser teruggestoot om na die master tak te wys, en dit het die lêers in jou werkgids (working directory) teruggerol (reverted) na die momentopname (snapshot) waarna master wys. Dit beteken ook dat die veranderings wat jy van hierdie punt af vorentoe maak, sal afwyk (diverge) van 'n ouer weergawe van die projek. Dit draai in wese die werk wat jy in jou testing tak gedoen het terug, sodat jy in 'n ander rigting kan gaan.
+
+
+
+
+|
+ Note
+ |
+
+ Oorskakeling van takke verander lêers in jou werkgids
+
+ Dit is belangrik om daarop te let dat wanneer jy tussen takke in Git skakel (switch), lêers in jou werkgids (working directory) sal verander.
+As jy na 'n ouer tak oorslaan, sal jou werkgids teruggerol (reverted) word om te lyk soos die laaste keer toe jy op daardie tak vasgelê (committed) het. As Git dit nie skoon kan doen nie, sal dit jou hoegenaamd nie laat oorskakel nie.
+ |
+
+
+
+
+
Kom ons maak 'n paar veranderings en lê weer vas (commit):
+
+
+
+
$ vim test.rb
+$ git commit -a -m 'Make other changes'
+
+
+
+
Nou het jou projekgeskiedenis afgewyk (diverged) (sien }}">Afgewykte geskiedenis (Divergent history)). Jy het 'n tak geskep en daarheen oorgeskakel, bietjie werk daarop gedoen, en toe teruggeskakel na jou hooftak (main branch) en ander werk gedoen. Albei daardie veranderings is geïsoleer in aparte takke: jy kan heen en weer skakel tussen die takke en hulle saamsmelt (merge) wanneer jy gereed is. En jy het dit alles gedoen met eenvoudige branch, checkout, en commit opdragte.
+
+
+
+
}}" alt="Divergent history">
+
+
Figure 17. Afgewykte geskiedenis (Divergent history)
+
+
+
Jy kan dit ook maklik met die git log opdrag sien. As jy git log --oneline --decorate --graph --all uitvoer, sal dit die geskiedenis van jou vasleggings (commits) uitdruk, en wys waar jou tak-wysers (branch pointers) is en hoe jou geskiedenis afgewyk het.
+
+
+
+
$ git log --oneline --decorate --graph --all
+* c2b9e (HEAD, master) Make other changes
+| * 87ab2 (testing) Make a change
+|/
+* f30ab Add feature #32 - ability to add new formats to the central interface
+* 34ac2 Fix bug #1328 - stack overflow under certain conditions
+* 98ca9 Initial commit of my project
+
+
+
+
Omdat 'n tak in Git eintlik 'n eenvoudige lêer is wat die 40-karakter SHA-1 kontrolesom (checksum) bevat van die vaslegging (commit) waarna dit wys, is takke goedkoop om te skep en te vernietig. Die skep van 'n nuwe tak is so vinnig en eenvoudig as om 41 grepe (bytes) na 'n lêer te skryf (40 karakters en 'n nuwelyn).
+
+
+
Dit staan in skerp kontras met die manier waarop die meeste ouer VCS-nutsmiddels takke skep, wat behels dat al die projek se lêers in 'n tweede gids gekopieer word. Dit kan 'n paar sekondes of selfs minute neem, afhangend van die grootte van die projek, terwyl die proses in Git altyd onmiddellik is. Omdat ons ook die ouers (parents) opneem wanneer ons vaslê (commit), word die vind van 'n behoorlike saamsmeltingsbasis (merge base) outomaties vir ons gedoen en is dit oor die algemeen baie maklik om te doen. Hierdie kenmerke help om ontwikkelaars aan te moedig om gereeld takke te skep en te gebruik.
+
+
+
Kom ons kyk hoekom jy dit behoort te doen.
+
+
+
+
+|
+ Note
+ |
+
+ Skep van 'n nuwe tak en gelyktydige oorskakeling daarnatoe
+
+ Dit is tipies om 'n nuwe tak te skep en terselfdertyd na daardie nuwe tak te wil oorskakel — dit kan in een operasie gedoen word met git checkout -b <newbranchname>.
+ |
+
+
+
+
+
+
+|
+ Note
+ |
+
+
+ Vanaf Git weergawe 2.23 en verder kan jy git switch in plaas van git checkout gebruik om:
+
+
+-
+
Oor te skakel na 'n bestaande tak: git switch testing-branch.
+
+-
+
'n Nuwe tak te skep en daarheen oor te skakel: git switch -c new-branch.
+Die -c vlag staan vir create, jy kan ook die volle vlag gebruik: --create.
+
+-
+
Terug te keer na jou vorige uitgecheckte (checked out) tak: git switch -.
+
+
+ |
+
+
+
+
Vertakkingswerkvloeie (Branching Workflows)
+
+
Noudat jy die basiese beginsels van vertakking (branching) en saamsmelting (merging) onder die knie het, wat kan of behoort jy daarmee te doen?
+In hierdie afdeling sal ons 'n paar algemene werkvloeie (workflows) dek wat deur hierdie liggewig vertakking moontlik gemaak word, sodat jy kan besluit of jy dit in jou eie ontwikkelingsiklus wil inkorporeer.
+
+
Langlopende Takke (Long-Running Branches)
+
+
+Omdat Git 'n eenvoudige drierigting-saamsmelting (three-way merge) gebruik, is dit oor die algemeen maklik om veelvuldige kere oor 'n lang tydperk van een tak na 'n ander te smelt (merge).
+Dit beteken jy kan verskeie takke hê wat altyd oop is en wat jy vir verskillende fases van jou ontwikkelingsiklus gebruik; jy kan gereeld van sommige van hulle na ander smelt.
+
+
+
Baie Git-ontwikkelaars het 'n werkvloei wat hierdie benadering omhels, soos om byvoorbeeld slegs kode wat heeltemal stabiel is in hul master tak te hê — moontlik net kode wat reeds vrygestel (released) is of sal word.
+Hulle het nog 'n parallelle tak genaamd develop of next waaruit hulle werk of wat hulle gebruik om stabiliteit te toets — dit is nie noodwendig altyd stabiel nie, maar wanneer dit in 'n stabiele toestand kom, kan dit by master saamgesmelt word.
+Dit word gebruik om onderwerp-takke (topic branches - kortlewende takke, soos jou vroeëre iss53 tak) in te trek (pull in) wanneer hulle gereed is, om seker te maak hulle slaag al die toetse en stel nie foute (bugs) in nie.
+
+
+
In werklikheid praat ons van wysers (pointers) wat op en af beweeg op die lyn van vasleggings (commits) wat jy besig is om te maak.
+Die stabiele takke is verder af in die lyn van jou vasleggingsgeskiedenis, en die heel nuutste (bleeding-edge) takke is verder op in die geskiedenis.
+
+
+
+
}}" alt="A linear view of progressive-stability branching">
+
+
Figure 26. 'n Lineêre siening van progressiewe-stabiliteit vertakking
+
+
+
Dit is oor die algemeen makliker om aan hulle te dink as werksilo’s, waar stelle vasleggings (commits) gradueer na 'n meer stabiele silo wanneer hulle ten volle getoets is.
+
+
+
+
}}" alt="A “silo” view of progressive-stability branching">
+
+
Figure 27. 'n “Silo” siening van progressiewe-stabiliteit vertakking
+
+
+
Jy kan aanhou om dit te doen vir verskeie vlakke van stabiliteit.
+Sommige groter projekte het ook 'n proposed of pu (proposed updates) tak wat takke geïntegreer het wat dalk nog nie gereed is om in die next of master tak in te gaan nie.
+Die idee is dat jou takke op verskillende vlakke van stabiliteit is; wanneer hulle 'n meer stabiele vlak bereik, word hulle in die tak bokant hulle saamgesmelt (merged).
+Weereens, dit is nie nodig om veelvuldige langlopende takke te hê nie, maar dit is dikwels nuttig, veral wanneer jy met baie groot of komplekse projekte te doen het.
+
+
+
Onderwerp-takke (Topic Branches)
+
+
+Onderwerp-takke is egter nuttig in projekte van enige grootte.
+'n Onderwerp-tak is 'n kortlewende tak wat jy skep en gebruik vir 'n enkele spesifieke kenmerk (feature) of verwante werk.
+Dit is iets wat jy waarskynlik nog nooit voorheen met 'n VCS gedoen het nie, want dit is oor die algemeen te duur om takke te skep en te smelt (merge).
+Maar in Git is dit algemeen om takke verskeie kere per dag te skep, daaraan te werk, saam te smelt en uit te vee.
+
+
+
Jy het dit in die laaste afdeling gesien met die iss53 en hotfix takke wat jy geskep het.
+Jy het 'n paar vasleggings (commits) op hulle gedoen en hulle uitgevee direk nadat jy hulle in jou hooftak (main branch) saamgesmelt het.
+Hierdie tegniek stel jou in staat om vinnig en heeltemal van konteks te verander — omdat jou werk in silo’s geskei is waar al die veranderings in daardie tak met daardie onderwerp te doen het, is dit makliker om te sien wat gebeur het tydens kodehersiening (code review) en dergelike dinge.
+Jy kan die veranderings daar hou vir minute, dae, of maande, en dit saamsmelt wanneer hulle gereed is, ongeag die volgorde waarin hulle geskep is of waaraan gewerk is.
+
+
+
Oorweeg 'n voorbeeld waar jy bietjie werk doen (op master), af vertak (branch off) vir 'n kwessie (iss91), 'n bietjie daaraan werk, 'n tweede tak af vertak om 'n ander manier te probeer om dieselfde ding te hanteer (iss91v2), teruggaan na jou master tak en 'n rukkie daar werk, en dan daarvandaan vertak om werk te doen wat jy nie seker is 'n goeie idee is nie (dumbidea tak).
+Jou vasleggingsgeskiedenis sal min of meer so lyk:
+
+
+
+
}}" alt="Multiple topic branches">
+
+
Figure 28. Veelvuldige onderwerp-takke (topic branches)
+
+
+
Sê nou jy besluit jy hou die beste van die tweede oplossing vir jou kwessie (iss91v2); en jy het die dumbidea tak vir jou medewerkers gewys, en dit blyk geniaal te wees.
+Jy kan die oorspronklike iss91 tak weggooi (wat veroorsaak dat jy vasleggings C5 en C6 verloor) en die ander twee saamsmelt (merge).
+Jou geskiedenis lyk dan so:
+
+
+
+
}}" alt="History after merging `dumbidea` and `iss91v2`">
+
+
Figure 29. Geskiedenis na die saamsmelting van dumbidea en iss91v2
+
+
+
+
Ons sal in meer detail ingaan oor die verskillende moontlike werkvloeie (workflows) vir jou Git-projek in }}">Distributed Git, so voordat jy besluit watter vertakkingskema jou volgende projek sal gebruik, maak seker dat jy daardie hoofstuk lees.
+
+
+
Dit is belangrik om te onthou wanneer jy al hierdie dinge doen, dat hierdie takke heeltemal plaaslik (local) is.
+Wanneer jy vertak en saamsmelt (branching and merging), word alles slegs in jou Git-bewaarplek (repository) gedoen — daar is geen kommunikasie met die bediener nie.
+
+
Die Refspec (Verwysingspesifikasie)
+
+
Regdeur hierdie boek het ons eenvoudige karterings (mappings) van afgeleë takke (remote branches) na plaaslike verwysings gebruik, maar dit kan meer kompleks wees.
+Veronderstel jy het saam met die laaste paar afdelings gevolg en 'n klein plaaslike Git-bewaarplek geskep, en wou nou 'n remote daarby voeg:
+
+
+
$ git remote add origin https://github.com/schacon/simplegit-progit
+
+
+
Die uitvoering van die bogenoemde opdrag voeg 'n afdeling by jou bewaarplek se .git/config-lêer, wat die naam van die remote (origin), die URL van die afgeleë bewaarplek, en die refspec (verwysingspesifikasie) wat vir fetching gebruik moet word, spesifiseer:
+
+
+
[remote "origin"]
+ url = https://github.com/schacon/simplegit-progit
+ fetch = +refs/heads/*:refs/remotes/origin/*
+
+
+
Die formaat van die refspec is eerstens 'n opsionele +, gevolg deur <src>:<dst>, waar <src> die patroon vir verwysings aan die afgeleë kant is en <dst> die plek is waar daardie verwysings plaaslik nagespoor sal word.
+Die + sê vir Git om die verwysing op te dateer selfs al is dit nie 'n vinnige-voorwaartse (fast-forward) nie.
+
+
In die verstekgeval wat outomaties geskryf word deur 'n git remote add origin opdrag, haal (fetches) Git al die verwysings onder refs/heads/ op die bediener af en skryf dit plaaslik na refs/remotes/origin/.
+Dus, as daar 'n master-tak op die bediener is, kan jy toegang verkry tot die log van daardie tak plaaslik via enige van die volgende:
+
+
+
$ git log origin/master
+$ git log remotes/origin/master
+$ git log refs/remotes/origin/master
+
+
+
Hulle is almal ekwivalent, want Git brei elkeen van hulle uit na refs/remotes/origin/master.
+
+
As jy eerder wil hê dat Git slegs die master-tak elke keer aftrek (pull down), en nie elke ander tak op die afgeleë bediener nie, kan jy die fetch-reël verander om slegs na daardie tak te verwys:
+
+
+
fetch = +refs/heads/master:refs/remotes/origin/master
+
+
+
Dit is net die verstek refspec vir git fetch vir daardie remote.
+As jy net 'n eenmalige fetch wil doen, kan jy die spesifieke refspec ook op die opdragreël spesifiseer.
+Om die master-tak op die remote plaaslik af te trek na origin/mymaster, kan jy uitvoer:
+
+
+
$ git fetch origin master:refs/remotes/origin/mymaster
+
+
+
Jy kan ook veelvuldige refspecs spesifiseer.
+Op die opdragreël kan jy verskeie takke as volg aftrek:
+
+
+
$ 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
+
+
+
In hierdie geval is die aftrek van die master-tak verwerp omdat dit nie as 'n vinnige-voorwaartse verwysing gelys was nie.
+Jy kan dit oorskryf deur die + voor die refspec te spesifiseer.
+
+
Jy kan ook veelvuldige refspecs vir fetching in jou konfigurasielêer spesifiseer.
+As jy altyd die master- en experiment-takke van die origin-remote wil fetch, voeg twee reëls by:
+
+
+
[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
+
+
+
Sedert Git 2.6.0 kan jy gedeeltelike patrone (partial globs) in die patroon gebruik om by veelvuldige takke te pas, so dit werk:
+
+
+
fetch = +refs/heads/qa*:refs/remotes/origin/qa*
+
+
+
Nog beter, jy kan naamruimtes (namespaces - of gidse) gebruik om dieselfde met meer struktuur te bereik.
+As jy 'n QA-span het wat 'n reeks takke push, en jy wil die master-tak en enige van die QA-span se takke kry, maar niks anders nie, kan jy 'n konfigurasie-afdeling soos hierdie gebruik:
+
+
+
[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/*
+
+
+
As jy 'n komplekse werkvloeiproses het waar 'n QA-span takke push, ontwikkelaars takke push, en integrasiespanne push en saamwerk op afgeleë takke, kan jy hulle maklik op hierdie manier in naamruimtes plaas.
+
+
Die Push van Refspecs
+
+
Dit is oulik dat jy naamruimte-verwysings op daardie manier kan fetch, maar hoe kry die QA-span hul takke in die eerste plek in 'n qa/ naamruimte?
+Jy bereik dit deur refspecs te gebruik om te push.
+
+
+
As die QA-span hul master-tak wil push na qa/master op die afgeleë bediener, kan hulle uitvoer:
+
+
+
+
$ git push origin master:refs/heads/qa/master
+
+
+
+
As hulle wil hê Git moet dit outomaties doen elke keer as hulle git push origin uitvoer, kan hulle 'n push-waarde by hul konfigurasielêer voeg:
+
+
+
+
[remote "origin"]
+ url = https://github.com/schacon/simplegit-progit
+ fetch = +refs/heads/*:refs/remotes/origin/*
+ push = refs/heads/master:refs/heads/qa/master
+
+
+
+
Weereens, dit sal veroorsaak dat 'n git push origin die plaaslike master-tak by verstek na die afgeleë qa/master-tak push.
+
+
+
+
Verwydering van Verwysings
+
+
Jy kan ook die refspec gebruik om verwysings vanaf die afgeleë bediener te verwyder deur iets soos hierdie uit te voer:
+
+
+
+
$ git push origin :topic
+
+
+
+
Omdat die refspec <src>:<dst> is, deur die <src>-gedeelte weg te laat, sê dit basies om die topic-tak op die remote niks te maak nie, wat dit uitvee.
+
+
+
Of jy kan die nuwer sintaksis gebruik (beskikbaar sedert Git v1.7.0):
+
+
+
+
$ git push origin --delete topic
+
+
+
Git Objekte (Git Objects)
+
+
Git is 'n inhoud-adresseerbare lêerstelsel (content-addressable filesystem).
+Wonderlik.
+Wat beteken dit?
+Dit beteken dat daar in die kern van Git 'n eenvoudige sleutel-waarde datastoor is.
+Wat dit beteken, is dat jy enige soort inhoud in 'n Git-bewaarplek kan plaas, waarvoor Git vir jou 'n unieke sleutel sal teruggee wat jy later kan gebruik om daardie inhoud te herwin.
+
+
As 'n demonstrasie, kom ons kyk na die loodgietersopdrag (plumbing command) git hash-object, wat 'n bietjie data neem, dit in jou .git/objects gids (die objekdatabasis) stoor, en vir jou die unieke sleutel teruggee wat nou na daardie data-objek verwys.
+
+
Eerstens inisialiseer jy 'n nuwe Git-bewaarplek en verifieer dat daar (soos te wagte) niks in die objects-gids is nie:
+
+
+
$ git init test
+Initialized empty Git repository in /tmp/test/.git/
+$ cd test
+$ find .git/objects
+.git/objects
+.git/objects/info
+.git/objects/pack
+$ find .git/objects -type f
+
+
+
Git het die objects-gids geïnisialiseer en pack- en info-subgidse daarin geskep, maar daar is geen gewone lêers nie.
+Kom ons gebruik nou git hash-object om 'n nuwe data-objek te skep en dit handmatig in jou nuwe Git-databasis te stoor:
+
+
+
$ echo 'test content' | git hash-object -w --stdin
+d670460b4b4aece5915caf5c68d12f560a9fe3e4
+
+
+
In sy eenvoudigste vorm sou git hash-object die inhoud wat jy daaraan gegee het neem en slegs die unieke sleutel teruggee wat gebruik sou word om dit in jou Git-databasis te stoor.
+Die -w opsie sê dan vir die opdrag om nie bloot die sleutel terug te gee nie, maar om daardie objek na die databasis te skryf.
+Laastens sê die --stdin opsie vir git hash-object om die inhoud wat verwerk moet word vanaf stdin te kry; anders sou die opdrag 'n lêernaam-argument aan die einde van die opdrag verwag wat die inhoud bevat wat gebruik moet word.
+
+
Die afvoer van die bogenoemde opdrag is 'n 40-karakter kontrolesomhuts (checksum hash).
+Dit is die SHA-1-huts — 'n kontrolesom van die inhoud wat jy stoor plus 'n kopstuk (header), waaroor jy binnekort meer sal leer.
+Nou kan jy sien hoe Git jou data gestoor het:
+
+
+
$ find .git/objects -type f
+.git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4
+
+
+
As jy weer jou objects-gids ondersoek, kan jy sien dat dit nou 'n lêer vir daardie nuwe inhoud bevat.
+Dit is hoe Git die inhoud aanvanklik stoor — as 'n enkele lêer per stuk inhoud, benoem met die SHA-1-kontrolesom van die inhoud en sy kopstuk.
+Die subgids word benoem met die eerste 2 karakters van die SHA-1, en die lêernaam is die oorblywende 38 karakters.
+
+
Sodra jy inhoud in jou objekdatabasis het, kan jy daardie inhoud ondersoek met die git cat-file opdrag.
+Hierdie opdrag is 'n soort Switserse weermagsmes vir die inspeksie van Git-objekte.
+Deur -p aan cat-file deur te gee, beveel dit die opdrag om eers die tipe inhoud uit te vind, en dit dan gepas te vertoon:
+
+
+
$ git cat-file -p d670460b4b4aece5915caf5c68d12f560a9fe3e4
+test content
+
+
+
Nou kan jy inhoud by Git voeg en dit weer uittrek.
+Jy kan dit ook met inhoud in lêers doen.
+Jy kan byvoorbeeld eenvoudige weergawebeheer op 'n lêer doen.
+Eerstens, skep 'n nuwe lêer en stoor die inhoud daarvan in jou databasis:
+
+
+
$ echo 'version 1' > test.txt
+$ git hash-object -w test.txt
+83baae61804e65cc73a7201a7252750c76066a30
+
+
+
Skryf dan 'n bietjie nuwe inhoud na die lêer, en stoor dit weer:
+
+
+
$ echo 'version 2' > test.txt
+$ git hash-object -w test.txt
+1f7a7a472abf3dd9643fd615f6da379c4acb3e3a
+
+
+
Jou objekdatabasis bevat nou beide weergawes van hierdie nuwe lêer (sowel as die eerste inhoud wat jy daar gestoor het):
+
+
+
$ find .git/objects -type f
+.git/objects/1f/7a7a472abf3dd9643fd615f6da379c4acb3e3a
+.git/objects/83/baae61804e65cc73a7201a7252750c76066a30
+.git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4
+
+
+
Op hierdie punt kan jy jou plaaslike kopie van daardie test.txt lêer uitvee, en dan Git gebruik om óf die eerste weergawe wat jy gestoor het uit die objekdatabasis te herwin:
+
+
+
$ git cat-file -p 83baae61804e65cc73a7201a7252750c76066a30 > test.txt
+$ cat test.txt
+version 1
+
+
+
of die tweede weergawe:
+
+
+
$ git cat-file -p 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a > test.txt
+$ cat test.txt
+version 2
+
+
+
Maar om die SHA-1-sleutel vir elke weergawe van jou lêer te onthou, is nie prakties nie; plus, jy stoor nie die lêernaam in jou stelsel nie — net die inhoud.
+Hierdie objektipe word 'n blob genoem.
+Jy kan Git laat sê wat die objektipe van enige objek in Git is, gegewe sy SHA-1-sleutel, met git cat-file -t:
+
+
+
$ git cat-file -t 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a
+blob
+
+
+
Boomobjekte (Tree Objects)
+
+
Die volgende tipe Git-objek wat ons sal ondersoek is die boom (tree), wat die probleem oplos om die lêernaam te stoor en jou ook toelaat om 'n groep lêers saam te stoor.
+Git stoor inhoud op 'n manier soortgelyk aan 'n UNIX-lêerstelsel, maar 'n bietjie vereenvoudig.
+Al die inhoud word as boom- en blob-objekte gestoor, met bome wat ooreenstem met UNIX-gidsinskrywings en blobs wat min of meer ooreenstem met inodes of lêerinhoud.
+'n Enkele boomobjek bevat een of meer inskrywings, waarvan elkeen die SHA-1-huts van 'n blob of subboom is met sy geassosieerde modus, tipe en lêernaam.
+Sê byvoorbeeld jy het 'n projek waar die mees onlangse boom so lyk:
+
+
+
+
$ git cat-file -p master^{tree}
+100644 blob a906cb2a4a904a152e80877d4088654daad0c859 README
+100644 blob 8f94139338f9404f26296befa88755fc2598c289 Rakefile
+040000 tree 99f1a6d12cb4b6f19c8655fca46c3ecf317074e0 lib
+
+
+
+
Die master^{tree} sintaksis spesifiseer die boomobjek waarna die laaste vaslegging op jou master-tak wys.
+Let op dat die lib-subgids nie 'n blob is nie, maar 'n wyser na 'n ander boom:
+
+
+
+
$ git cat-file -p 99f1a6d12cb4b6f19c8655fca46c3ecf317074e0
+100644 blob 47c6340d6459e05787f644c2447d2595f5d3a54b simplegit.rb
+
+
+
+
+
+|
+ Note
+ |
+
+
+ Afhangende van watter dop (shell) jy gebruik, mag jy foute teëkom wanneer jy die master^{tree} sintaksis gebruik.
+
+ In CMD op Windows word die ^ karakter gebruik vir "escaping", so jy moet dit verdubbel om dit te vermy: git cat-file -p master^^{tree}.
+Wanneer jy PowerShell gebruik, moet parameters wat {} karakters gebruik aangehaal (quoted) word om te verhoed dat die parameter verkeerd ontleed word: git cat-file -p 'master^{tree}'.
+
+ As jy ZSH gebruik, word die ^ karakter vir "globbing" gebruik, so jy moet die hele uitdrukking in aanhalingstekens plaas: git cat-file -p "master^{tree}".
+ |
+
+
+
+
+
Konseptueel lyk die data wat Git stoor min of meer so:
+
+
+
+
}}" alt="Simple version of the Git data model">
+
+
Figure 186. Eenvoudige weergawe van die Git-datamodel.
+
+
+
Jy kan redelik maklik jou eie boom skep.
+Git skep normaalweg 'n boom deur die toestand van jou voorbereidingsarea (staging area) of indeks te neem en 'n reeks boomobjekte daaruit te skryf.
+So, om 'n boomobjek te skep, moet jy eers 'n indeks opstel deur 'n paar lêers voor te berei.
+Om 'n indeks met 'n enkele inskrywing te skep — die eerste weergawe van jou test.txt-lêer — kan jy die loodgietersopdrag git update-index gebruik.
+Jy gebruik hierdie opdrag om die vroeëre weergawe van die test.txt-lêer kunsmatig by 'n nuwe voorbereidingsarea te voeg.
+Jy moet die --add opsie daaraan gee omdat die lêer nog nie in jou voorbereidingsarea bestaan nie (jy het nog nie eers 'n voorbereidingsarea opgestel nie) en --cacheinfo omdat die lêer wat jy byvoeg nie in jou gids is nie, maar in jou databasis.
+Dan spesifiseer jy die modus, SHA-1 en lêernaam:
+
+
+
+
$ git update-index --add --cacheinfo 100644 \
+ 83baae61804e65cc73a7201a7252750c76066a30 test.txt
+
+
+
+
In hierdie geval spesifiseer jy 'n modus van 100644, wat beteken dat dit 'n normale lêer is.
+Ander opsies is 100755, wat beteken dis 'n uitvoerbare lêer; en 120000, wat 'n simboliese skakel spesifiseer.
+Die modus is van normale UNIX-modusse afgeneem, maar is baie minder buigsaam — hierdie drie modusse is die enigste wat geldig is vir lêers (blobs) in Git (hoewel ander modusse vir gidse en submodules gebruik word).
+
+
+
Nou kan jy git write-tree gebruik om die voorbereidingsarea na 'n boomobjek uit te skryf.
+Geen -w opsie is nodig nie — deur hierdie opdrag te roep word 'n boomobjek outomaties geskep vanaf die toestand van die indeks as daardie boom nog nie bestaan nie:
+
+
+
+
$ git write-tree
+d8329fc1cc938780ffdd9f94e0d364e0ea74f579
+$ git cat-file -p d8329fc1cc938780ffdd9f94e0d364e0ea74f579
+100644 blob 83baae61804e65cc73a7201a7252750c76066a30 test.txt
+
+
+
+
Jy kan ook verifieer dat dit 'n boomobjek is deur dieselfde git cat-file opdrag te gebruik wat jy vroeër gesien het:
+
+
+
+
$ git cat-file -t d8329fc1cc938780ffdd9f94e0d364e0ea74f579
+tree
+
+
+
+
Jy sal nou 'n nuwe boom skep met die tweede weergawe van test.txt asook 'n nuwe lêer:
+
+
+
+
$ echo 'new file' > new.txt
+$ git update-index --cacheinfo 100644 \
+ 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a test.txt
+$ git update-index --add new.txt
+
+
+
+
Jou voorbereidingsarea het nou die nuwe weergawe van test.txt sowel as die nuwe lêer new.txt.
+Skryf daardie boom uit (wat die toestand van die voorbereidingsarea of indeks in 'n boomobjek aanteken) en kyk hoe dit lyk:
+
+
+
+
$ git write-tree
+0155eb4229851634a0f03eb265b69f5a2d56f341
+$ git cat-file -p 0155eb4229851634a0f03eb265b69f5a2d56f341
+100644 blob fa49b077972391ad58037050f2a75f74e3671e92 new.txt
+100644 blob 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a test.txt
+
+
+
+
Let op dat hierdie boom beide lêerinskrywings het en ook dat die test.txt SHA-1 die “version 2” SHA-1 van vroeër is (1f7a7a).
+Net vir die pret sal jy die eerste boom as 'n subgids by hierdie een voeg.
+Jy kan bome in jou voorbereidingsarea inlees deur git read-tree te roep.
+In hierdie geval kan jy 'n bestaande boom in jou voorbereidingsarea inlees as 'n subboom deur die --prefix opsie met hierdie opdrag te gebruik:
+
+
+
+
$ git read-tree --prefix=bak d8329fc1cc938780ffdd9f94e0d364e0ea74f579
+$ git write-tree
+3c4e9cd789d88d8d89c1073707c3585e41b0e614
+$ git cat-file -p 3c4e9cd789d88d8d89c1073707c3585e41b0e614
+040000 tree d8329fc1cc938780ffdd9f94e0d364e0ea74f579 bak
+100644 blob fa49b077972391ad58037050f2a75f74e3671e92 new.txt
+100644 blob 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a test.txt
+
+
+
+
As jy 'n werkgids sou skep vanaf die nuwe boom wat jy pas geskryf het, sou jy die twee lêers op die boonste vlak van die werkgids kry en 'n subgids genaamd bak wat die eerste weergawe van die test.txt lêer bevat.
+Jy kan dink aan die data wat Git vir hierdie strukture bevat asof dit so lyk:
+
+
+
+
}}" alt="The content structure of your current Git data">
+
+
Figure 187. Die inhoudstruktuur van jou huidige Git-data.
+
+
+
Vasleggingsobjekte (Commit Objects)
+
+
As jy al die bogenoemde gedoen het, het jy nou drie bome wat die verskillende momentopnames van jou projek verteenwoordig wat jy wil naspoor, maar die vroeëre probleem bly: jy moet al drie SHA-1-waardes onthou om die momentopnames te herroep.
+Jy het ook geen inligting oor wie die momentopnames gestoor het, wanneer dit gestoor is, of hoekom dit gestoor is nie.
+Dit is die basiese inligting wat die vasleggingsobjek vir jou stoor.
+
+
+
Om 'n vasleggingsobjek te skep, roep jy commit-tree en spesifiseer jy 'n enkele boom SHA-1 en watter vasleggingsobjekte, indien enige, dit direk voorafgegaan het.
+Begin met die eerste boom wat jy geskryf het:
+
+
+
+
$ echo 'First commit' | git commit-tree d8329f
+fdf4fc3344e67ab068f836878b6c4951e3b15f3d
+
+
+
+
+
+|
+ Note
+ |
+
+
+ Jy sal 'n ander hutswaarde kry as gevolg van verskillende skeppingstye en outeurdata.
+Bowendien, hoewel in beginsel enige vasleggingsobjek presies gereproduseer kan word gegewe daardie data, beteken historiese besonderhede van hierdie boek se samestelling dat die gedrukte vasleggingshutse moontlik nie ooreenstem met die gegewe vasleggings nie.
+Vervang vasleggings- en merkerhutse met jou eie kontrolesomme verder in hierdie hoofstuk.
+ |
+
+
+
+
+
Nou kan jy na jou nuwe vasleggingsobjek kyk met git cat-file:
+
+
+
+
$ git cat-file -p fdf4fc3
+tree d8329fc1cc938780ffdd9f94e0d364e0ea74f579
+author Scott Chacon <schacon@gmail.com> 1243040974 -0700
+committer Scott Chacon <schacon@gmail.com> 1243040974 -0700
+
+First commit
+
+
+
+
Die formaat vir 'n vasleggingsobjek is eenvoudig: dit spesifiseer die boonste-vlak boom vir die momentopname van die projek op daardie punt; die ouer-vasleggings indien enige (die vasleggingsobjek wat hierbo beskryf is, het geen ouers nie); die outeur/vaslêer (committer)-inligting (wat jou user.name en user.email konfigurasie-instellings en 'n tydstempel gebruik); 'n leë reël, en dan die vasleggingsboodskap.
+
+
+
Vervolgens sal jy die ander twee vasleggingsobjekte skryf, wat elkeen verwys na die vaslegging wat direk daarvoor gekom het:
+
+
+
+
$ echo 'Second commit' | git commit-tree 0155eb -p fdf4fc3
+cac0cab538b970a37ea1e769cbbde608743bc96d
+$ echo 'Third commit' | git commit-tree 3c4e9c -p cac0cab
+1a410efbd13591db07496601ebc7a059dd55cfe9
+
+
+
+
Elkeen van die drie vasleggingsobjekte wys na een van die drie momentopname-bome wat jy geskep het.
+Vreemd genoeg het jy nou 'n regte Git-geskiedenis wat jy kan bekyk met die git log-opdrag, as jy dit op die laaste vaslegging SHA-1 uitvoer:
+
+
+
+
$ git log --stat 1a410e
+commit 1a410efbd13591db07496601ebc7a059dd55cfe9
+Author: Scott Chacon <schacon@gmail.com>
+Date: Fri May 22 18:15:24 2009 -0700
+
+ Third commit
+
+ bak/test.txt | 1 +
+ 1 file changed, 1 insertion(+)
+
+commit cac0cab538b970a37ea1e769cbbde608743bc96d
+Author: Scott Chacon <schacon@gmail.com>
+Date: Fri May 22 18:14:29 2009 -0700
+
+ Second commit
+
+ new.txt | 1 +
+ test.txt | 2 +-
+ 2 files changed, 2 insertions(+), 1 deletion(-)
+
+commit fdf4fc3344e67ab068f836878b6c4951e3b15f3d
+Author: Scott Chacon <schacon@gmail.com>
+Date: Fri May 22 18:09:34 2009 -0700
+
+ First commit
+
+ test.txt | 1 +
+ 1 file changed, 1 insertion(+)
+
+
+
+
Verbluffend.
+Jy het pas die laevlak-operasies gedoen om 'n Git-geskiedenis op te bou sonder om enige van die voorvlak-opdragte (front end commands) te gebruik.
+Dit is in wese wat Git doen wanneer jy die git add en git commit opdragte uitvoer — dit stoor blobs vir die lêers wat verander het, werk die indeks by, skryf bome uit en skryf vasleggingsobjekte wat na die boonste-vlak bome verwys en die vasleggings wat onmiddellik voor hulle gekom het.
+Hierdie drie hoof Git-objekte — die blob, die boom en die vaslegging — word aanvanklik as aparte lêers in jou .git/objects gids gestoor.
+Hier is al die objekte in die voorbeeldgids nou, met kommentaar oor wat hulle stoor:
+
+
+
+
$ find .git/objects -type f
+.git/objects/01/55eb4229851634a0f03eb265b69f5a2d56f341 # tree 2
+.git/objects/1a/410efbd13591db07496601ebc7a059dd55cfe9 # commit 3
+.git/objects/1f/7a7a472abf3dd9643fd615f6da379c4acb3e3a # test.txt v2
+.git/objects/3c/4e9cd789d88d8d89c1073707c3585e41b0e614 # tree 3
+.git/objects/83/baae61804e65cc73a7201a7252750c76066a30 # test.txt v1
+.git/objects/ca/c0cab538b970a37ea1e769cbbde608743bc96d # commit 2
+.git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4 # 'test content'
+.git/objects/d8/329fc1cc938780ffdd9f94e0d364e0ea74f579 # tree 1
+.git/objects/fa/49b077972391ad58037050f2a75f74e3671e92 # new.txt
+.git/objects/fd/f4fc3344e67ab068f836878b6c4951e3b15f3d # commit 1
+
+
+
+
As jy al die interne wysers volg, kry jy 'n objekgrafiek wat min of meer so lyk:
+
+
+
+
}}" alt="All the reachable objects in your Git directory">
+
+
Figure 188. Al die bereikbare objekte in jou Git-gids.
+
+
+
Objekberging (Object Storage)
+
+
Ons het vroeër genoem dat daar 'n kopstuk (header) gestoor word saam met elke objek wat jy in jou Git-objekdatabasis vaslê.
+Kom ons neem 'n minuut om te kyk hoe Git sy objekte stoor.
+Jy sal sien hoe om 'n blob-objek te stoor — in hierdie geval die string “what is up, doc?” — interaktief in die Ruby-skriptaal.
+
+
+
Jy kan interaktiewe Ruby-modus met die irb-opdrag begin:
+
+
+
+
$ irb
+>> content = "what is up, doc?"
+=> "what is up, doc?"
+
+
+
+
Git konstrueer eers 'n kopstuk wat begin deur die tipe objek te identifiseer — in hierdie geval 'n blob.
+Aan daardie eerste deel van die kopstuk voeg Git 'n spasie by gevolg deur die grootte in grepe (bytes) van die inhoud, en voeg 'n finale nul-greep (null byte) by:
+
+
+
+
>> header = "blob #{content.bytesize}\0"
+=> "blob 16\u0000"
+
+
+
+
Git aaneenskakel die kopstuk en die oorspronklike inhoud en bereken dan die SHA-1 kontrolesom van daardie nuwe inhoud.
+Jy kan die SHA-1 waarde van 'n string in Ruby bereken deur die SHA1 digest-biblioteek met die require-opdrag in te sluit en dan Digest::SHA1.hexdigest() met die string te roep:
+
+
+
+
>> store = header + content
+=> "blob 16\u0000what is up, doc?"
+>> require 'digest/sha1'
+=> true
+>> sha1 = Digest::SHA1.hexdigest(store)
+=> "bd9dbf5aae1a3862dd1526723246b20206e5fc37"
+
+
+
+
Kom ons vergelyk dit met die afvoer van git hash-object.
+Hier gebruik ons echo -n om te voorkom dat 'n nuwe reël by die invoer gevoeg word.
+
+
+
+
$ echo -n "what is up, doc?" | git hash-object --stdin
+bd9dbf5aae1a3862dd1526723246b20206e5fc37
+
+
+
+
Git pers die nuwe inhoud saam met zlib, wat jy in Ruby kan doen met die zlib-biblioteek.
+Eerstens moet jy die biblioteek insluit (require) en dan Zlib::Deflate.deflate() op die inhoud uitvoer:
+
+
+
+
>> require 'zlib'
+=> true
+>> zlib_content = Zlib::Deflate.deflate(store)
+=> "x\x9CK\xCA\xC9OR04c(\xCFH,Q\xC8,V(-\xD0QH\xC9O\xB6\a\x00_\x1C\a\x9D"
+
+
+
+
Ten slotte sal jy jou zlib-saamgeperste inhoud na 'n objek op die skyf skryf.
+Jy sal die pad bepaal van die objek wat jy wil uitskryf (die eerste twee karakters van die SHA-1 waarde is die subgidsnaam, en die laaste 38 karakters is die lêernaam binne daardie gids).
+In Ruby kan jy die FileUtils.mkdir_p() funksie gebruik om die subgids te skep as dit nie bestaan nie.
+Maak dan die lêer oop met File.open() en skryf die voorheen zlib-saamgeperste inhoud uit na die lêer met 'n write()-roep op die resulterende lêerhandvatsel:
+
+
+
+
>> path = '.git/objects/' + sha1[0,2] + '/' + sha1[2,38]
+=> ".git/objects/bd/9dbf5aae1a3862dd1526723246b20206e5fc37"
+>> require 'fileutils'
+=> true
+>> FileUtils.mkdir_p(File.dirname(path))
+=> ".git/objects/bd"
+>> File.open(path, 'w') { |f| f.write zlib_content }
+=> 32
+
+
+
+
Kom ons gaan die inhoud van die objek na met behulp van git cat-file:
+
+
+
+
---
+$ git cat-file -p bd9dbf5aae1a3862dd1526723246b20206e5fc37
+what is up, doc?
+---
+
+
+
+
Dis dit – jy het 'n geldige Git blob-objek geskep.
+
+
+
Alle Git-objekte word op dieselfde manier gestoor, net met verskillende tipes – in plaas van die string 'blob', sal die kopstuk begin met 'commit' of 'tree'.
+Verder, hoewel die blob-inhoud byna enigiets kan wees, is die vaslegging- en boom-inhoud baie spesifiek geformateer.
+
+
Git-verwysings (Git References)
+
+
As jy daarin belangstel om die geskiedenis van jou bewaarplek te sien wat bereikbaar is vanaf vaslegging, sê maar, 1a410e, kan jy iets soos git log 1a410e uitvoer om daardie geskiedenis te vertoon, maar jy sal steeds moet onthou dat 1a410e die vaslegging is wat jy as die beginpunt vir daardie geskiedenis wil gebruik.
+In plaas daarvan sou dit makliker wees as jy 'n lêer het waarin jy daardie SHA-1-waarde onder 'n eenvoudige naam kan stoor, sodat jy daardie eenvoudige naam kan gebruik eerder as die rou SHA-1-waarde.
+
+
In Git word hierdie eenvoudige name “verwysings” (references) of “refs” genoem; jy kan die lêers wat daardie SHA-1-waardes bevat in die .git/refs-gids vind.
+In die huidige projek bevat hierdie gids geen lêers nie, maar dit bevat wel 'n eenvoudige struktuur:
+
+
+
$ find .git/refs
+.git/refs
+.git/refs/heads
+.git/refs/tags
+$ find .git/refs -type f
+
+
+
Om 'n nuwe verwysing te skep wat jou sal help onthou waar jou nuutste vaslegging is, kan jy tegnies iets so eenvoudig soos dit doen:
+
+
+
$ echo 1a410efbd13591db07496601ebc7a059dd55cfe9 > .git/refs/heads/master
+
+
+
Nou kan jy die kop-verwysing (head reference) wat jy pas geskep het in plaas van die SHA-1-waarde in jou Git-opdragte gebruik:
+
+
+
$ git log --pretty=oneline master
+1a410efbd13591db07496601ebc7a059dd55cfe9 Third commit
+cac0cab538b970a37ea1e769cbbde608743bc96d Second commit
+fdf4fc3344e67ab068f836878b6c4951e3b15f3d First commit
+
+
+
Jy word nie aangemoedig om die verwysingslêers direk te redigeer nie; in plaas daarvan verskaf Git die veiliger opdrag git update-ref om dit te doen as jy 'n verwysing wil opdateer:
+
+
+
$ git update-ref refs/heads/master 1a410efbd13591db07496601ebc7a059dd55cfe9
+
+
+
Dit is basies wat 'n tak (branch) in Git is: 'n eenvoudige wyser of verwysing na die kop van 'n lyn van werk.
+Om 'n tak terug by die tweede vaslegging te skep, kan jy dit doen:
+
+
+
$ git update-ref refs/heads/test cac0ca
+
+
+
Jou tak sal slegs werk van daardie vaslegging af ondertoe bevat:
+
+
+
$ git log --pretty=oneline test
+cac0cab538b970a37ea1e769cbbde608743bc96d Second commit
+fdf4fc3344e67ab068f836878b6c4951e3b15f3d First commit
+
+
+
Nou lyk jou Git-databasis konseptueel min of meer so:
+
+
+
}}" alt="Git directory objects with branch head references included">
+
+
Figure 189. Git-gids objekte met tak-kop-verwysings ingesluit
+
+
Wanneer jy opdragte soos git branch <tak> uitvoer, voer Git basies daardie update-ref-opdrag uit om die SHA-1 van die laaste vaslegging van die tak waarop jy is, by te voeg in watter nuwe verwysing jy ook al wil skep.
+
+
Die HEAD (The HEAD)
+
+
Die vraag is nou, wanneer jy git branch <tak> uitvoer, hoe weet Git wat die SHA-1 van die laaste vaslegging is?
+Die antwoord is die HEAD-lêer.
+
+
+
Gewoonlik is die HEAD-lêer 'n simboliese verwysing na die tak waarop jy tans is.
+Met simboliese verwysing bedoel ons dat, anders as 'n normale verwysing, dit 'n wyser na 'n ander verwysing bevat.
+
+
+
In sommige seldsame gevalle kan die HEAD-lêer egter die SHA-1-waarde van 'n Git-objek bevat.
+Dit gebeur wanneer jy 'n merker (tag), vaslegging, of afgeleë tak (remote branch) uittrek (checkout), wat jou bewaarplek in 'n "losgemaakte HEAD" (detached HEAD) toestand plaas.
+
+
+
As jy na die lêer kyk, sal jy normaalweg iets soos dit sien:
+
+
+
+
$ cat .git/HEAD
+ref: refs/heads/master
+
+
+
+
As jy git checkout test uitvoer, dateer Git die lêer op om so te lyk:
+
+
+
+
$ cat .git/HEAD
+ref: refs/heads/test
+
+
+
+
Wanneer jy git commit uitvoer, skep dit die vasleggingsobjek, wat die ouer van daardie vasleggingsobjek spesifiseer as watter SHA-1-waarde ook al die verwysing in HEAD na wys.
+
+
+
Jy kan ook hierdie lêer handmatig redigeer, maar weereens bestaan daar 'n veiliger opdrag om dit te doen: git symbolic-ref.
+Jy kan die waarde van jou HEAD via hierdie opdrag lees:
+
+
+
+
$ git symbolic-ref HEAD
+refs/heads/master
+
+
+
+
Jy kan ook die waarde van HEAD instel deur dieselfde opdrag te gebruik:
+
+
+
+
$ git symbolic-ref HEAD refs/heads/test
+$ cat .git/HEAD
+ref: refs/heads/test
+
+
+
+
Jy kan nie 'n simboliese verwysing buite die refs-styl instel nie:
+
+
+
+
$ git symbolic-ref HEAD test
+fatal: Refusing to point HEAD outside of refs/
+
+
+
+
+
+
Ons het pas klaar Git se drie hoof objektipe (blobs, trees (bome) en commits (vasleggings)) bespreek, maar daar is 'n vierde.
+Die merker-objek is baie soos 'n vasleggingsobjek — dit bevat 'n merker (tagger), 'n datum, 'n boodskap, en 'n wyser.
+Die hoofverskil is dat 'n merker-objek oor die algemeen na 'n vaslegging wys eerder as na 'n boom.
+Dit is soos 'n tak-verwysing, maar dit beweeg nooit nie — dit wys altyd na dieselfde vaslegging, maar gee dit 'n vriendeliker naam.
+
+
+
Soos bespreek in }}">Git Basics, is daar twee tipes merkers: geannoteer en liggewig.
+Jy kan 'n liggewig merker maak deur iets soos dit uit te voer:
+
+
+
+
$ git update-ref refs/tags/v1.0 cac0cab538b970a37ea1e769cbbde608743bc96d
+
+
+
+
Dit is al wat 'n liggewig merker is — 'n verwysing wat nooit beweeg nie.
+'n Geannoteerde merker is egter meer kompleks.
+As jy 'n geannoteerde merker skep, skep Git 'n merker-objek en skryf dan 'n verwysing om daarna te wys eerder as direk na die vaslegging.
+Jy kan dit sien deur 'n geannoteerde merker te skep (met behulp van die -a opsie):
+
+
+
+
$ git tag -a v1.1 1a410efbd13591db07496601ebc7a059dd55cfe9 -m 'Test tag'
+
+
+
+
Hier is die objek se SHA-1-waarde wat dit geskep het:
+
+
+
+
$ cat .git/refs/tags/v1.1
+9585191f37f7b0fb9444f35a9bf50de191beadc2
+
+
+
+
Voer nou git cat-file -p uit op daardie SHA-1-waarde:
+
+
+
+
$ git cat-file -p 9585191f37f7b0fb9444f35a9bf50de191beadc2
+object 1a410efbd13591db07496601ebc7a059dd55cfe9
+type commit
+tag v1.1
+tagger Scott Chacon <schacon@gmail.com> Sat May 23 16:48:58 2009 -0700
+
+Test tag
+
+
+
+
Let op dat die objek-inskrywing wys na die vaslegging SHA-1-waarde wat jy gemerk het.
+Let ook op dat dit nie na 'n vaslegging hoef te wys nie; jy kan enige Git-objek merk.
+In die Git-bronkode, byvoorbeeld, het die instandhouer hul GPG publieke sleutel as 'n blob-objek bygevoeg en dit dan gemerk.
+Jy kan die publieke sleutel besigtig deur dit in 'n kloon van die Git-bewaarplek uit te voer:
+
+
+
+
$ git cat-file blob junio-gpg-pub
+
+
+
+
Die Linux-kern-bewaarplek het ook 'n merker-objek wat nie na 'n vaslegging wys nie — die eerste merker wat geskep is, wys na die aanvanklike boom van die invoer van die bronkode.
+
+
+
Afgeleë Verwysings (Remotes)
+
+
Die derde tipe verwysing wat jy sal sien, is 'n afgeleë verwysing (remote reference).
+As jy 'n remote byvoeg en soontoe push, stoor Git die waarde wat jy laas na daardie remote gepush het vir elke tak in die refs/remotes-gids.
+Byvoorbeeld, jy kan 'n remote genaamd origin byvoeg en jou master-tak soontoe push:
+
+
+
+
$ git remote add origin git@github.com:schacon/simplegit-progit.git
+$ git push origin master
+Counting objects: 11, done.
+Compressing objects: 100% (5/5), done.
+Writing objects: 100% (7/7), 716 bytes, done.
+Total 7 (delta 2), reused 4 (delta 1)
+To git@github.com:schacon/simplegit-progit.git
+ a11bef0..ca82a6d master -> master
+
+
+
+
Dan kan jy sien wat die master-tak op die origin-remote was die laaste keer wat jy met die bediener gekommunikeer het, deur die refs/remotes/origin/master-lêer na te gaan:
+
+
+
+
$ cat .git/refs/remotes/origin/master
+ca82a6dff817ec66f44342007202690a93763949
+
+
+
+
Afgeleë verwysings verskil van takke (refs/heads verwysings) hoofsaaklik daarin dat hulle as leesalleen (read-only) beskou word.
+Jy kan 'n git checkout na een doen, maar Git sal nie simbolies HEAD na een verwys nie, so jy sal dit nooit met 'n commit-opdrag opdateer nie.
+Git bestuur hulle as boekmerke na die laaste bekende toestand van waar daardie takke op daardie bedieners was.
+
+
You may have skipped to this chapter from a much earlier chapter, or you may have gotten here after sequentially reading the entire book up to this point — in either case, this is where we’ll go over the inner workings and implementation of Git.
+We found that understanding this information was fundamentally important to appreciating how useful and powerful Git is, but others have argued to us that it can be confusing and unnecessarily complex for beginners.
+Thus, we’ve made this discussion the last chapter in the book so you could read it early or later in your learning process.
+We leave it up to you to decide.
Now that you’re here, let’s get started.
+First, if it isn’t yet clear, Git is fundamentally a content-addressable filesystem with a VCS user interface written on top of it.
+You’ll learn more about what this means in a bit.
In the early days of Git (mostly pre 1.5), the user interface was much more complex because it emphasized this filesystem rather than a polished VCS.
+In the last few years, the UI has been refined until it’s as clean and easy to use as any system out there; however, the stereotype lingers about the early Git UI that was complex and difficult to learn.
The content-addressable filesystem layer is amazingly cool, so we’ll cover that first in this chapter; then, you’ll learn about the transport mechanisms and the repository maintenance tasks that you may eventually have to deal with.
+Loodgieterswerk en Porselein (Plumbing and Porcelain)
+
+
Hierdie boek dek hoofsaaklik hoe om Git te gebruik met so 30 of wat subopdragte soos checkout, branch, remote, ensovoorts.
+Maar omdat Git aanvanklik 'n gereedskapstel vir 'n weergawebeheerstelsel was in plaas van 'n volledige gebruikersvriendelike WBS (VCS), het dit 'n aantal subopdragte wat laevlak-werk doen en ontwerp is om op 'n UNIX-manier aan mekaar gekoppel te word of vanuit skrippe geroep te word.
+Daar word oor die algemeen na hierdie opdragte verwys as Git se “loodgieters”-opdragte (“plumbing”), terwyl die meer gebruikersvriendelike opdragte “porselein”-opdragte (“porcelain”) genoem word.
+
+
Soos jy teen hierdie tyd sal opgemerk het, handel die eerste nege hoofstukke van hierdie boek byna uitsluitlik oor porselein-opdragte.
+Maar in hierdie hoofstuk sal jy meestal met die laervlak loodgieters-opdragte te doen kry, want hulle gee jou toegang tot die innerlike werking van Git, en help demonstreer hoe en hoekom Git doen wat hy doen.
+Baie van hierdie opdragte is nie bedoel om handmatig op die opdragreël gebruik te word nie, maar eerder om as boublokke vir nuwe hulpmiddels en pasgemaakte skrippe gebruik te word.
+
+
Wanneer jy git init in 'n nuwe of bestaande gids uitvoer, skep Git die .git-gids, wat is waar byna alles wat Git stoor en manipuleer, geleë is.
+As jy jou bewaarplek wil rugsteun of kloon, gee die kopiëring van hierdie enkele gids na 'n ander plek jou byna alles wat jy nodig het.
+Hierdie hele hoofstuk handel basies oor wat jy in hierdie gids kan sien.
+Hier is hoe 'n nuut-geïnisialiseerde .git-gids tipies lyk:
+
+
+
$ ls -F1
+config
+description
+HEAD
+hooks/
+info/
+objects/
+refs/
+
+
+
Afhangende van jou weergawe van Git, sal jy dalk bykomende inhoud daar sien, maar hierdie is 'n vars git init-bewaarplek — dit is wat jy by verstek sien.
+Die description-lêer word slegs deur die GitWeb-program gebruik, so moenie jou daaroor bekommer nie.
+Die config-lêer bevat jou projekspesifieke konfigurasie-opsies, en die info-gids hou 'n globale uitsluitingslêer (exclude file) vir geïgnoreerde patrone wat jy nie in 'n .gitignore-lêer wil naspoor nie.
+Die hooks-gids bevat jou kliënt- of bedienerkant haakskrippe (hook scripts), wat in detail in }}">Git-hake (Git Hooks) bespreek word.
+
+
Dit laat vier belangrike inskrywings oor: die HEAD en (nog te skep) index-lêers, en die objects- en refs-gidse.
+Dit is die kernonderdele van Git.
+Die objects-gids stoor al die inhoud vir jou databasis, die refs-gids stoor wysers na vasleggingsobjekte in daardie data (takke, merkers, remotes en meer), die HEAD-lêer wys na die tak wat jy tans uitgetrek (checked out) het, en die index-lêer is waar Git jou voorbereidingsarea (staging area) inligting stoor.
+Jy sal nou in detail na elk van hierdie afdelings kyk om te sien hoe Git werk.
+
Onderhoud en Dataherwinning
+
+
Soms moet jy dalk 'n bietjie skoonmaakwerk doen – 'n bewaarplek meer kompak maak, 'n ingevoerde bewaarplek skoonmaak, of verlore werk herwin.
+Hierdie afdeling sal sommige van hierdie scenario’s dek.
+
+
Onderhoud
+
+
Git voer af en toe outomaties 'n opdrag uit genaamd “auto gc”.
+Meestal doen hierdie opdrag niks nie.
+As daar egter te veel los objekte (objekte wat nie in 'n paklêer is nie) of te veel paklêers (packfiles) is, begin Git 'n volwaardige git gc-opdrag.
+Die “gc” staan vir vullisverwydering (garbage collect), en die opdrag doen 'n aantal dinge: dit versamel al die los objekte en plaas dit in paklêers, dit konsolideer paklêers in een groot paklêer, en dit verwyder objekte wat nie vanaf enige vaslegging bereikbaar is nie en 'n paar maande oud is.
+
+
+
Jy kan auto gc handmatig as volg uitvoer:
+
+
+
+
Weereens, dit doen oor die algemeen niks nie.
+Jy moet ongeveer 7 000 los objekte of meer as 50 paklêers hê sodat Git 'n ware gc-opdrag kan aanskakel.
+Jy kan hierdie limiete verander met onderskeidelik die gc.auto- en gc.autopacklimit-konfigurasie-instellings.
+
+
+
Die ander ding wat gc sal doen, is om jou verwysings (references) in 'n enkele lêer saam te pak.
+Gestel jou bewaarplek bevat die volgende takke en merkers:
+
+
+
+
$ find .git/refs -type f
+.git/refs/heads/experiment
+.git/refs/heads/master
+.git/refs/tags/v1.0
+.git/refs/tags/v1.1
+
+
+
+
As jy git gc uitvoer, sal jy nie meer hierdie lêers in die refs-gids hê nie.
+Git sal hulle ter wille van doeltreffendheid na 'n lêer genaamd .git/packed-refs skuif, wat so lyk:
+
+
+
+
$ cat .git/packed-refs
+# pack-refs with: peeled fully-peeled
+cac0cab538b970a37ea1e769cbbde608743bc96d refs/heads/experiment
+ab1afef80fac8e34258ff41fc1b867c702daa24b refs/heads/master
+cac0cab538b970a37ea1e769cbbde608743bc96d refs/tags/v1.0
+9585191f37f7b0fb9444f35a9bf50de191beadc2 refs/tags/v1.1
+^1a410efbd13591db07496601ebc7a059dd55cfe9
+
+
+
+
As jy 'n verwysing bywerk, wysig Git nie hierdie lêer nie, maar skryf eerder 'n nuwe lêer na refs/heads.
+Om die gepaste SHA-1 vir 'n gegewe verwysing te kry, kyk Git na daardie verwysing in die refs-gids en kyk dan na die packed-refs-lêer as 'n terugval.
+Dus, as jy nie 'n verwysing in die refs-gids kan vind nie, is dit waarskynlik in jou packed-refs-lêer.
+
+
+
Let op die laaste reël van die lêer, wat met 'n ^ begin.
+Dit beteken dat die merker direk daarbo 'n geannoteerde merker is en dat daardie reël die vaslegging is waarna die geannoteerde merker wys.
+
+
+
Dataherwinning
+
+
Op een of ander stadium in jou Git-reis mag jy dalk per ongeluk 'n vaslegging (commit) verloor.
+Oor die algemeen gebeur dit omdat jy 'n tak waarop werk gedoen is geforceerd uitvee, en dit blyk dat jy die tak tog wou hê; of jy doen 'n hard-reset op 'n tak, wat beteken jy laat vaar vasleggings waarvan jy iets wou hê.
+Gestel dit gebeur, hoe kan jy jou vasleggings terugkry?
+
+
+
Hier is 'n voorbeeld wat die master-tak in jou toetsbewaarplek na 'n ouer vaslegging hard-reset en dan die verlore vasleggings herwin.
+Eerstens, kom ons kyk waar jou bewaarplek op hierdie stadium is:
+
+
+
+
$ git log --pretty=oneline
+ab1afef80fac8e34258ff41fc1b867c702daa24b Modify repo.rb a bit
+484a59275031909e19aadb7c92262719cfcdf19a Create repo.rb
+1a410efbd13591db07496601ebc7a059dd55cfe9 Third commit
+cac0cab538b970a37ea1e769cbbde608743bc96d Second commit
+fdf4fc3344e67ab068f836878b6c4951e3b15f3d First commit
+
+
+
+
Skuif nou die master-tak terug na die middelste vaslegging:
+
+
+
+
$ git reset --hard 1a410efbd13591db07496601ebc7a059dd55cfe9
+HEAD is now at 1a410ef Third commit
+$ git log --pretty=oneline
+1a410efbd13591db07496601ebc7a059dd55cfe9 Third commit
+cac0cab538b970a37ea1e769cbbde608743bc96d Second commit
+fdf4fc3344e67ab068f836878b6c4951e3b15f3d First commit
+
+
+
+
Jy het in effek die boonste twee vasleggings verloor – jy het geen tak waarvandaan daardie vasleggings bereikbaar is nie.
+Jy moet die nuutste vaslegging SHA-1 vind en dan 'n tak byvoeg wat daarna wys.
+Die kuns is om daardie nuutste vaslegging SHA-1 te vind – dis nie asof jy dit gememoriseer het nie, reg?
+
+
+
Dikwels is die vinnigste manier om 'n hulpmiddel genaamd git reflog te gebruik.
+Terwyl jy werk, teken Git in stilte aan wat jou HEAD is elke keer as jy dit verander.
+Elke keer as jy vaslê of takke verander, word die verwysingslog (reflog) bygewerk.
+Die reflog word ook bygewerk deur die git update-ref-opdrag, wat nog 'n rede is om dit te gebruik in plaas daarvan om net die SHA-1-waarde na jou verwysingslêers te skryf, soos ons in }}">Git-verwysings (Git References) bespreek het.
+Jy kan enige tyd sien waar jy was deur git reflog uit te voer:
+
+
+
+
$ git reflog
+1a410ef HEAD@{0}: reset: moving to 1a410ef
+ab1afef HEAD@{1}: commit: Modify repo.rb a bit
+484a592 HEAD@{2}: commit: Create repo.rb
+
+
+
+
Hier kan ons die twee vasleggings sien wat ons uitgetrek (checked out) gehad het, maar daar is nie veel inligting hier nie.
+Om dieselfde inligting op 'n baie nuttiger manier te sien, kan ons git log -g uitvoer, wat jou 'n normale log-afvoer vir jou reflog sal gee.
+
+
+
+
$ git log -g
+commit 1a410efbd13591db07496601ebc7a059dd55cfe9
+Reflog: HEAD@{0} (Scott Chacon <schacon@gmail.com>)
+Reflog message: updating HEAD
+Author: Scott Chacon <schacon@gmail.com>
+Date: Fri May 22 18:22:37 2009 -0700
+
+ Third commit
+
+commit ab1afef80fac8e34258ff41fc1b867c702daa24b
+Reflog: HEAD@{1} (Scott Chacon <schacon@gmail.com>)
+Reflog message: updating HEAD
+Author: Scott Chacon <schacon@gmail.com>
+Date: Fri May 22 18:15:24 2009 -0700
+
+ Modify repo.rb a bit
+
+
+
+
Dit lyk of die onderste vaslegging die een is wat jy verloor het, sodat jy dit kan herwin deur 'n nuwe tak by daardie vaslegging te skep.
+Jy kan byvoorbeeld 'n tak genaamd recover-branch by daardie vaslegging (ab1afef) begin:
+
+
+
+
$ git branch recover-branch ab1afef
+$ git log --pretty=oneline recover-branch
+ab1afef80fac8e34258ff41fc1b867c702daa24b Modify repo.rb a bit
+484a59275031909e19aadb7c92262719cfcdf19a Create repo.rb
+1a410efbd13591db07496601ebc7a059dd55cfe9 Third commit
+cac0cab538b970a37ea1e769cbbde608743bc96d Second commit
+fdf4fc3344e67ab068f836878b6c4951e3b15f3d First commit
+
+
+
+
Koel – nou het jy 'n tak genaamd recover-branch wat is waar jou master-tak voorheen was, wat die eerste twee vasleggings weer bereikbaar maak.
+Vervolgens, gestel jou verlies was om een of ander rede nie in die reflog nie – jy kan dit simuleer deur recover-branch te verwyder en die reflog uit te vee.
+Nou is die eerste twee vasleggings deur niks bereikbaar nie:
+
+
+
+
$ git branch -D recover-branch
+$ rm -Rf .git/logs/
+
+
+
+
Omdat die reflog-data in die .git/logs/-gids gehou word, het jy in effek geen reflog nie.
+Hoe kan jy daardie vaslegging op hierdie stadium herwin?
+Een manier is om die git fsck-hulpmiddel te gebruik, wat jou databasis vir integriteit kontroleer.
+As jy dit met die --full opsie uitvoer, wys dit jou alle objekte waarna nie deur 'n ander objek gewys word nie:
+
+
+
+
$ git fsck --full
+Checking object directories: 100% (256/256), done.
+Checking objects: 100% (18/18), done.
+dangling blob d670460b4b4aece5915caf5c68d12f560a9fe3e4
+dangling commit ab1afef80fac8e34258ff41fc1b867c702daa24b
+dangling tree aea790b9a58f6cf6f2804eeac9f0abbe9631e4c9
+dangling blob 7108f7ecb345ee9d0084193f147cdad4d2998293
+
+
+
+
In hierdie geval kan jy jou ontbrekende vaslegging sien na die string “dangling commit”.
+Jy kan dit op dieselfde manier herwin deur 'n tak by te voeg wat na daardie SHA-1 wys.
+
+
+
Verwydering van Objekte
+
+
Daar is baie wonderlike dinge omtrent Git, maar een eienskap wat probleme kan veroorsaak, is die feit dat 'n git clone die hele geskiedenis van die projek aflaai, insluitend elke weergawe van elke lêer.
+Dit is reg as die hele ding bronkode is, want Git is hoogs geoptimaliseer om daardie data doeltreffend saam te pers.
+As iemand egter op enige stadium in die geskiedenis van jou projek 'n enkele enorme lêer bygevoeg het, sal elke kloon vir ewig gedwing word om daardie groot lêer af te laai, selfs al is dit in die heel volgende vaslegging uit die projek verwyder.
+Omdat dit vanuit die geskiedenis bereikbaar is, sal dit altyd daar wees.
+
+
+
Dit kan 'n yslike probleem wees wanneer jy Subversion- of Perforce-bewaarplekke in Git omskakel.
+Omdat jy nie die hele geskiedenis in daardie stelsels aflaai nie, dra hierdie tipe byvoeging min gevolge.
+As jy 'n invoer vanaf 'n ander stelsel gedoen het of andersins vind dat jou bewaarplek baie groter is as wat dit behoort te wees, is hier hoe jy groot objekte kan vind en verwyder.
+
+
+
Wees gewaarsku: hierdie tegniek is vernietigend vir jou vasleggingsgeskiedenis.
+Dit herskryf elke vasleggingsobjek sedert die vroegste boom (tree) wat jy moet verander om 'n grootlêerverwysing te verwyder.
+As jy dit onmiddellik na 'n invoer doen, voordat enigiemand begin het om werk op die vaslegging te baseer, is jy oukei – andersins moet jy alle bydraers in kennis stel dat hulle hul werk op jou nuwe vasleggings moet rebase.
+
+
+
Om te demonstreer, sal jy 'n groot lêer in jou toetsbewaarplek byvoeg, dit in die volgende vaslegging verwyder, dit vind, en dit permanent uit die bewaarplek verwyder.
+Eerstens, voeg 'n groot objek by jou geskiedenis:
+
+
+
+
$ curl -L https://www.kernel.org/pub/software/scm/git/git-2.1.0.tar.gz > git.tgz
+$ git add git.tgz
+$ git commit -m 'Add git tarball'
+[master 7b30847] Add git tarball
+ 1 file changed, 0 insertions(+), 0 deletions(-)
+ create mode 100644 git.tgz
+
+
+
+
Oeps – jy wou nie 'n massiewe tarball by jou projek voeg nie.
+Raak liewer daarvan ontslae:
+
+
+
+
$ git rm git.tgz
+rm 'git.tgz'
+$ git commit -m 'Oops - remove large tarball'
+[master dadf725] Oops - remove large tarball
+ 1 file changed, 0 insertions(+), 0 deletions(-)
+ delete mode 100644 git.tgz
+
+
+
+
Nou, voer gc op jou databasis uit en kyk hoeveel spasie jy gebruik:
+
+
+
+
$ git gc
+Counting objects: 17, done.
+Delta compression using up to 8 threads.
+Compressing objects: 100% (13/13), done.
+Writing objects: 100% (17/17), done.
+Total 17 (delta 1), reused 10 (delta 0)
+
+
+
+
Jy kan die count-objects-opdrag uitvoer om vinnig te sien hoeveel spasie jy gebruik:
+
+
+
+
$ git count-objects -v
+count: 7
+size: 32
+in-pack: 17
+packs: 1
+size-pack: 4868
+prune-packable: 0
+garbage: 0
+size-garbage: 0
+
+
+
+
Die size-pack-inskrywing is die grootte van jou paklêers in kilogrepe, so jy gebruik byna 5MB.
+Voor die laaste vaslegging het jy nader aan 2K gebruik – dit is duidelik dat die verwydering van die lêer uit die vorige vaslegging dit nie uit jou geskiedenis verwyder het nie.
+Elke keer as iemand hierdie bewaarplek kloon, sal hulle al 5MB moet kloon net om hierdie klein projekkie te kry, omdat jy per ongeluk 'n groot lêer bygevoeg het.
+Kom ons raak ontslae daarvan.
+
+
+
Eers moet jy dit vind.
+In hierdie geval weet jy reeds watter lêer dit is.
+Maar gestel jy het nie; hoe sou jy identifiseer watter lêer of lêers soveel spasie in beslag neem?
+As jy git gc uitvoer, is al die objekte in 'n paklêer; jy kan die groot objekte identifiseer deur nog 'n loodgietersopdrag (plumbing command) genaamd git verify-pack uit te voer en op die derde veld in die afvoer, wat lêergrootte is, te sorteer.
+Jy kan dit ook deur die tail-opdrag pyp, want jy is slegs in die laaste paar grootste lêers geïnteresseerd:
+
+
+
+
$ git verify-pack -v .git/objects/pack/pack-29…69.idx \
+ | sort -k 3 -n \
+ | tail -3
+dadf7258d699da2c8d89b09ef6670edb7d5f91b4 commit 229 159 12
+033b4468fa6b2a9547a70d88d1bbe8bf3f9ed0d5 blob 22044 5792 4977696
+82c99a3e86bb1267b236a4b6eff7868d97489af1 blob 4975916 4976258 1438
+
+
+
+
+
+
$ git rev-list --objects --all | grep 82c99a3
+82c99a3e86bb1267b236a4b6eff7868d97489af1 git.tgz
+
+
+
+
Nou moet jy hierdie lêer verwyder uit al die bome in jou verlede.
+Jy kan maklik sien watter vasleggings hierdie lêer gewysig het:
+
+
+
+
$ git log --oneline --branches -- git.tgz
+dadf725 Oops - remove large tarball
+7b30847 Add git tarball
+
+
+
+
Jy moet al die vasleggings stroomaf (downstream) vanaf 7b30847 herskryf om hierdie lêer ten volle uit jou Git-geskiedenis te verwyder.
+Om dit te doen, gebruik jy filter-branch, wat jy in }}">Herskryf van Geskiedenis (Rewriting History) gebruik het:
+
+
+
+
$ git filter-branch --index-filter \
+ 'git rm --ignore-unmatch --cached git.tgz' -- 7b30847^..
+Rewrite 7b30847d080183a1ab7d18fb202473b3096e9f34 (1/2)rm 'git.tgz'
+Rewrite dadf7258d699da2c8d89b09ef6670edb7d5f91b4 (2/2)
+Ref 'refs/heads/master' was rewritten
+
+
+
+
Die --index-filter-opsie is soortgelyk aan die --tree-filter-opsie wat in }}">Herskryf van Geskiedenis (Rewriting History) gebruik is, behalwe dat, in plaas daarvan om 'n opdrag deur te gee wat lêers wysig wat op die skyf uitgetrek is, jy elke keer jou voorbereidingsarea (staging area) of indeks wysig.
+
+
+
Eerder as om 'n spesifieke lêer te verwyder met iets soos rm lêer, moet jy dit verwyder met git rm --cached – jy moet dit uit die indeks verwyder, nie van die skyf af nie.
+Die rede om dit op hierdie manier te doen is spoed – aangesien Git nie elke hersiening op die skyf hoef uit te trek voordat jou filter uitgevoer word nie, kan die proses baie, baie vinniger wees.
+Jy kan dieselfde taak met --tree-filter verrig as jy wil.
+Die --ignore-unmatch-opsie vir git rm sê vir dit om nie 'n fout te gooi as die patroon wat jy probeer verwyder nie daar is nie.
+Uiteindelik vra jy filter-branch om jou geskiedenis slegs vanaf die 7b30847 vaslegging af op te herskryf, want jy weet dat dit is waar hierdie probleem begin het.
+Anders sal dit van die begin af begin en sal dit onnodig langer neem.
+
+
+
Jou geskiedenis bevat nie meer 'n verwysing na daardie lêer nie.
+Jou reflog en 'n nuwe stel verwysings wat Git bygevoeg het toe jy die filter-branch gedoen het onder .git/refs/original het egter nog wel, so jy moet dit verwyder en dan die databasis herpak.
+Jy moet ontslae raak van enigiets wat 'n wyser (pointer) na daardie ou vasleggings het voordat jy herpak:
+
+
+
+
$ rm -Rf .git/refs/original
+$ rm -Rf .git/logs/
+$ git gc
+Counting objects: 15, done.
+Delta compression using up to 8 threads.
+Compressing objects: 100% (11/11), done.
+Writing objects: 100% (15/15), done.
+Total 15 (delta 1), reused 12 (delta 0)
+
+
+
+
Kom ons kyk hoeveel spasie jy gespaar het.
+
+
+
+
$ git count-objects -v
+count: 11
+size: 4904
+in-pack: 15
+packs: 1
+size-pack: 8
+prune-packable: 0
+garbage: 0
+size-garbage: 0
+
+
+
+
Die gepakte bewaarplekgrootte is af tot 8K, wat baie beter as 5MB is.
+Jy kan van die grootte-waarde af sien dat die groot objek nog steeds in jou los objekte is, so dit is nie weg nie; maar dit sal nie oorgedra word tydens 'n push of daaropvolgende kloon nie, en dit is wat belangrik is.
+As jy regtig wou, kon jy die objek heeltemal verwyder deur git prune met die --expire opsie uit te voer:
+
+
+
+
$ git prune --expire now
+$ git count-objects -v
+count: 0
+size: 0
+in-pack: 15
+packs: 1
+size-pack: 8
+prune-packable: 0
+garbage: 0
+size-garbage: 0
+----```
+
+=== Omgewingsveranderlikes (Environment Variables)
+
+Git loop altyd binne 'n `bash` dop (shell), en gebruik 'n aantal dop-omgewingsveranderlikes om te bepaal hoe dit optree.
+Af en toe is dit handig om te weet wat dit is, en hoe hulle gebruik kan word om Git te laat optree soos jy dit wil hê.
+Hierdie is nie 'n volledige lys van al die omgewingsveranderlikes waaraan Git aandag gee nie, maar ons sal die nuttigste dek.
+
+==== Globale Gedrag (Global Behavior)
+
+Sommige van Git se algemene gedrag as 'n rekenaarprogram hang af van omgewingsveranderlikes.
+
+*`GIT_EXEC_PATH`* bepaal waar Git na sy subprogramme soek (soos `git-commit`, `git-diff`, en andere).
+Jy kan die huidige instelling nagaan deur `git --exec-path` uit te voer.
+
+*`HOME`* word gewoonlik nie as aanpasbaar beskou nie (te veel ander dinge hang daarvan af), maar dit is waar Git na die globale konfigurasielêer soek.
+As jy 'n werklik draagbare (portable) Git-installasie wil hê, kompleet met globale konfigurasie, kan jy `HOME` in die draagbare Git se dopprofiel (shell profile) oorskryf.
+
+*`PREFIX`* is soortgelyk, maar vir die stelselwye konfigurasie.
+Git soek na hierdie lêer by `$PREFIX/etc/gitconfig`.
+
+*`GIT_CONFIG_NOSYSTEM`*, as dit gestel is, deaktiveer die gebruik van die stelselwye konfigurasielêer.
+Dit is nuttig as jou stelselkonfigurasie met jou opdragte inmeng, maar jy nie toegang het om dit te verander of te verwyder nie.
+
+*`GIT_PAGER`* beheer die program wat gebruik word om multi-bladsy afvoer op die opdragreël te vertoon.
+As dit nie gestel is nie, sal `PAGER` as 'n terugvalopsie (fallback) gebruik word.
+
+*`GIT_EDITOR`* is die redigeerder wat Git sal aanskakel wanneer die gebruiker 'n bietjie teks moet redigeer (byvoorbeeld 'n vasleggingsboodskap).
+As dit nie gestel is nie, sal `EDITOR` gebruik word.
+
+==== Bewaarplekliggings (Repository Locations)
+
+Git gebruik verskeie omgewingsveranderlikes om te bepaal hoe dit met die huidige bewaarplek in wisselwerking tree.
+
+*`GIT_DIR`* is die ligging van die `.git` gids.
+As dit nie gespesifiseer is nie, loop Git op in die gidsboom totdat dit by `~` of `/` kom, en soek by elke stap na 'n `.git` gids.
+
+*`GIT_CEILING_DIRECTORIES`* beheer die gedrag van die soektog na 'n `.git` gids.
+As jy toegang verkry tot gidse wat stadig laai (soos dié op 'n banddryf, of oor 'n stadige netwerkverbinding), wil jy dalk hê dat Git vroeër ophou probeer as wat dit andersins sou, veral as Git opgeroep word wanneer jou dop-aanwysing (shell prompt) gebou word.
+
+*`GIT_WORK_TREE`* is die ligging van die wortel van die werkgids vir 'n nie-kaal (non-bare) bewaarplek.
+As `--git-dir` of `GIT_DIR` gespesifiseer is maar geeneen van `--work-tree`, `GIT_WORK_TREE` of `core.worktree` gespesifiseer is nie, word die huidige werkgids as die boonste vlak van jou werkboom (working tree) beskou.
+
+*`GIT_INDEX_FILE`* is die pad na die indekslêer (slegs nie-kaal bewaarplekke).
+
+*`GIT_OBJECT_DIRECTORY`* kan gebruik word om die ligging van die gids wat gewoonlik by `.git/objects` is, te spesifiseer.
+
+*`GIT_ALTERNATE_OBJECT_DIRECTORIES`* is 'n dubbelpunt-geskeide lys (geformateer soos `/dir/one:/dir/two:…`) wat vir Git vertel waar om vir objekte te kyk as hulle nie in `GIT_OBJECT_DIRECTORY` is nie.
+As jy toevallig baie projekte het met groot lêers wat presies dieselfde inhoud het, kan dit gebruik word om te vermy dat te veel kopieë daarvan gestoor word.
+
+==== Padspesifikasies (Pathspecs)
+
+'n "`Padspesifikasie`" ("`pathspec`") verwys na hoe jy paaie na dinge in Git spesifiseer, insluitend die gebruik van jokertekens (wildcards).
+Dit word gebruik in die `.gitignore` lêer, maar ook op die opdragreël (`git add *.c`).
+
+*`GIT_GLOB_PATHSPECS`* en *`GIT_NOGLOB_PATHSPECS`* beheer die verstekgedrag van jokertekens in padspesifikasies.
+As `GIT_GLOB_PATHSPECS` op 1 gestel is, tree jokertekenkarakters op as jokertekens (wat die verstek is); as `GIT_NOGLOB_PATHSPECS` op 1 gestel is, pas jokertekenkarakters net by hulself, wat beteken iets soos `\*.c` sou slegs pas by 'n lêer _genaamd_ "`\*.c`", eerder as enige lêer waarvan die naam op `.c` eindig.
+Jy kan dit in individuele gevalle oorskryf deur die padspesifikasie met `:(glob)` of `:(literal)` te begin, soos in `:(glob)\*.c`.
+
+*`GIT_LITERAL_PATHSPECS`* deaktiveer beide van die bogenoemde gedragte; geen jokertekenkarakters sal werk nie, en die oorskryf-voorvoegsels word ook gedeaktiveer.
+
+*`GIT_ICASE_PATHSPECS`* stel alle padspesifikasies in om op 'n kas-onsensitiewe (case-insensitive) manier te werk.
+
+==== Vaslegging (Committing)
+
+Die finale skepping van 'n Git-vasleggingsobjek word gewoonlik gedoen deur `git-commit-tree`, wat hierdie omgewingsveranderlikes as sy primêre bron van inligting gebruik, en val slegs terug op konfigurasiewaardes as hierdie nie teenwoordig is nie.
+
+*`GIT_AUTHOR_NAME`* is die mensleesbare naam in die "`author`" (outeur) veld.
+
+*`GIT_AUTHOR_EMAIL`* is die e-posadres vir die "`author`" veld.
+
+*`GIT_AUTHOR_DATE`* is die tydstempel wat vir die "`author`" veld gebruik word.
+
+*`GIT_COMMITTER_NAME`* stel die menslike naam vir die "`committer`" (vaslêer) veld.
+
+*`GIT_COMMITTER_EMAIL`* is die e-posadres vir die "`committer`" veld.
+
+*`GIT_COMMITTER_DATE`* word gebruik vir die tydstempel in die "`committer`" veld.
+
+*`EMAIL`* is die terugval-e-posadres ingeval die `user.email` konfigurasiewaarde nie gestel is nie.
+As _dit_ nie gestel is nie, val Git terug op die stelsel se gebruiker- en gasheername.
+
+==== Netwerke (Networking)
+
+Git gebruik die `curl` biblioteek om netwerkbedrywighede oor HTTP te doen, so *`GIT_CURL_VERBOSE`* sê vir Git om al die boodskappe wat deur daardie biblioteek gegenereer is, uit te straal.
+Dit is soortgelyk aan die uitvoer van `curl -v` op die opdragreël.
+
+*`GIT_SSL_NO_VERIFY`* sê vir Git om nie SSL-sertifikate te verifieer nie.
+Dit kan soms nodig wees as jy 'n self-ondertekende sertifikaat gebruik om Git-bewaarplekke oor HTTPS te bedien, of jy in die middel van die opstelling van 'n Git-bediener is, maar nog nie 'n volledige sertifikaat geïnstalleer het nie.
+
+As die datatempo van 'n HTTP-bewerking vir langer as *`GIT_HTTP_LOW_SPEED_TIME`* sekondes laer is as *`GIT_HTTP_LOW_SPEED_LIMIT`* grepe per sekonde, sal Git daardie bewerking staak.
+Hierdie waardes oorskryf die `http.lowSpeedLimit` en `http.lowSpeedTime` konfigurasiewaardes.
+
+*`GIT_HTTP_USER_AGENT`* stel die user-agent string wat Git gebruik wanneer hy oor HTTP kommunikeer.
+Die verstek is 'n waarde soos `git/2.0.0`.
+
+==== Diffing en Saamsmelting (Diffing and Merging)
+
+*`GIT_DIFF_OPTS`* is 'n bietjie van 'n wanbenaming.
+Die enigste geldige waardes is `-u<n>` of `--unified=<n>`, wat die aantal konteksreëls beheer wat in 'n `git diff` opdrag gewys word.
+
+*`GIT_EXTERNAL_DIFF`* word gebruik as 'n oorskrywing vir die `diff.external` konfigurasiewaarde.
+As dit gestel is, sal Git hierdie program oproep wanneer `git diff` opgeroep word.
+
+*`GIT_DIFF_PATH_COUNTER`* en *`GIT_DIFF_PATH_TOTAL`* is nuttig van binne die program gespesifiseer deur `GIT_EXTERNAL_DIFF` of `diff.external`.
+Die eerste verteenwoordig watter lêer in 'n reeks gediff word (beginnend by 1), en die tweede is die totale aantal lêers in die groep.
+
+*`GIT_MERGE_VERBOSITY`* beheer die afvoer vir die rekursiewe saamsmeltingstrategie.
+Die toegelate waardes is soos volg:
+
+* 0 voer niks uit nie, behalwe moontlik 'n enkele foutboodskap.
+* 1 wys slegs konflikte.
+* 2 wys ook lêerveranderings.
+* 3 wys wanneer lêers oorgeslaan word omdat dit nie verander het nie.
+* 4 wys alle paaie soos dit verwerk word.
+* 5 en hoër wys gedetailleerde ontfoutingsinligting (debugging information).
+
+Die verstekwaarde is 2.
+
+==== Ontfouting (Debugging)
+
+Wil jy _regtig_ weet waarmee Git besig is?
+Git het 'n redelik volledige stel spore (traces) ingebed, en al wat jy hoef te doen is om dit aan te skakel.
+Die moontlike waardes van hierdie veranderlikes is soos volg:
+
+* "`true`", "`1`", of "`2`" – die spoorkategorie word na stderr geskryf.
+* 'n Absolute pad wat met `/` begin – die spoorafvoer sal na daardie lêer geskryf word.
+
+*`GIT_TRACE`* beheer algemene spore, wat nie in enige spesifieke kategorie pas nie.
+Dit sluit die uitbreiding van aliassen en delegering na ander subprogramme in.
+
+[source,console]
+
+
+
+
$ GIT_TRACE=true git lga
+20:12:49.877982 git.c:554 trace: exec: 'git-lga'
+20:12:49.878369 run-command.c:341 trace: run_command: 'git-lga'
+20:12:49.879529 git.c:282 trace: alias expansion: lga ⇒ 'log' '--graph' '--pretty=oneline' '--abbrev-commit' '--decorate' '--all'
+20:12:49.879885 git.c:349 trace: built-in: git 'log' '--graph' '--pretty=oneline' '--abbrev-commit' '--decorate' '--all'
+20:12:49.899217 run-command.c:341 trace: run_command: 'less'
+20:12:49.899675 run-command.c:192 trace: exec: 'less'
+
+
+
+
*`GIT_TRACE_PACK_ACCESS`* beheer die opsporing van paklêer-toegang (packfile access).
+Die eerste veld is die paklêer wat verkry word, die tweede is die relatiewe verskuiwing (offset) binne daardie lêer:
+
+[source,console]
+
+
+
+
$ GIT_TRACE_PACK_ACCESS=true git status
+20:10:12.081397 sha1_file.c:2088 .git/objects/pack/pack-c3fa…291e.pack 12
+20:10:12.081886 sha1_file.c:2088 .git/objects/pack/pack-c3fa…291e.pack 34662
+20:10:12.082115 sha1_file.c:2088 .git/objects/pack/pack-c3fa…291e.pack 35175
+# […]
+20:10:12.087398 sha1_file.c:2088 .git/objects/pack/pack-e80e…e3d2.pack 56914983
+20:10:12.087419 sha1_file.c:2088 .git/objects/pack/pack-e80e…e3d2.pack 14303666
+On branch master
+Your branch is up-to-date with 'origin/master'.
+nothing to commit, working directory clean
+
+
+
+
*`GIT_TRACE_PACKET`* maak pakkievlak-opsporing (packet-level tracing) vir netwerkbedrywighede moontlik.
+
+[source,console]
+
+
+
+
$ GIT_TRACE_PACKET=true git ls-remote origin
+20:15:14.867043 pkt-line.c:46 packet: git< # service=git-upload-pack
+20:15:14.867071 pkt-line.c:46 packet: git< 0000
+20:15:14.867079 pkt-line.c:46 packet: git< 97b8860c071898d9e162678ea1035a8ced2f8b1f HEAD\0multi_ack thin-pack side-band side-band-64k ofs-delta shallow no-progress include-tag multi_ack_detailed no-done symref=HEAD:refs/heads/master agent=git/2.0.4
+20:15:14.867088 pkt-line.c:46 packet: git< 0f20ae29889d61f2e93ae00fd34f1cdb53285702 refs/heads/ab/add-interactive-show-diff-func-name
+20:15:14.867094 pkt-line.c:46 packet: git< 36dc827bc9d17f80ed4f326de21247a5d1341fbc refs/heads/ah/doc-gitk-config
+# […]
+
+
+
+
*`GIT_TRACE_PERFORMANCE`* beheer die aanteken van prestasiedata.
+Die afvoer wys hoe lank elke spesifieke `git` oproep neem.
+
+[source,console]
+
+
+
+
$ GIT_TRACE_PERFORMANCE=true git gc
+20:18:19.499676 trace.c:414 performance: 0.374835000 s: git command: 'git' 'pack-refs' '--all' '--prune'
+20:18:19.845585 trace.c:414 performance: 0.343020000 s: git command: 'git' 'reflog' 'expire' '--all'
+Counting objects: 170994, done.
+Delta compression using up to 8 threads.
+Compressing objects: 100% (43413/43413), done.
+Writing objects: 100% (170994/170994), done.
+Total 170994 (delta 126176), reused 170524 (delta 125706)
+20:18:23.567927 trace.c:414 performance: 3.715349000 s: git command: 'git' 'pack-objects' '--keep-true-parents' '--honor-pack-keep' '--non-empty' '--all' '--reflog' '--unpack-unreachable=2.weeks.ago' '--local' '--delta-base-offset' '.git/objects/pack/.tmp-49190-pack'
+20:18:23.584728 trace.c:414 performance: 0.000910000 s: git command: 'git' 'prune-packed'
+20:18:23.605218 trace.c:414 performance: 0.017972000 s: git command: 'git' 'update-server-info'
+20:18:23.606342 trace.c:414 performance: 3.756312000 s: git command: 'git' 'repack' '-d' '-l' '-A' '--unpack-unreachable=2.weeks.ago'
+Checking connectivity: 170994, done.
+20:18:25.225424 trace.c:414 performance: 1.616423000 s: git command: 'git' 'prune' '--expire' '2.weeks.ago'
+20:18:25.232403 trace.c:414 performance: 0.001051000 s: git command: 'git' 'rerere' 'gc'
+20:18:25.233159 trace.c:414 performance: 6.112217000 s: git command: 'git' 'gc'
+
+
+
+
*`GIT_TRACE_SETUP`* wys inligting oor wat Git ontdek oor die bewaarplek en omgewing waarmee hy interaksie het.
+
+[source,console]
+
+
+
+
$ GIT_TRACE_SETUP=true git status
+20:19:47.086765 trace.c:315 setup: git_dir: .git
+20:19:47.087184 trace.c:316 setup: worktree: /Users/ben/src/git
+20:19:47.087191 trace.c:317 setup: cwd: /Users/ben/src/git
+20:19:47.087194 trace.c:318 setup: prefix: (null)
+On branch master
+Your branch is up-to-date with 'origin/master'.
+nothing to commit, working directory clean
+
+
+
+
==== Diverse (Miscellaneous)
+
+*`GIT_SSH`*, indien gespesifiseer, is 'n program wat in plaas van `ssh` opgeroep word wanneer Git aan 'n SSH-gasheer probeer koppel.
+Dit word opgeroep as `$GIT_SSH [username@]host [-p <port>] <command>`.
+Let op dat dit nie die maklikste manier is om aan te pas hoe `ssh` opgeroep word nie; dit sal nie ekstra opdragreëlparameters ondersteun nie.
+Om ekstra opdragreëlparameters te ondersteun, kan jy *`GIT_SSH_COMMAND`* gebruik, 'n toedraaiskrip (wrapper script) skryf en `GIT_SSH` stel om daarna te wys, of die `~/.ssh/config` lêer gebruik.
+
+*`GIT_SSH_COMMAND`* stel die SSH-opdrag wat gebruik word wanneer Git aan 'n SSH-gasheer probeer koppel.
+Die opdrag word deur die dop geïnterpreteer, en ekstra opdragreëlargumente kan met `ssh` gebruik word, soos `GIT_SSH_COMMAND="ssh -i ~/.ssh/my_key" git clone git@example.com:my/repo`.
+
+*`GIT_ASKPASS`* is 'n oorskrywing (override) vir die `core.askpass` konfigurasiewaarde.
+Dit is die program wat opgeroep word wanneer Git die gebruiker vir aanmeldbewyse moet vra, wat 'n teksaanwysing as 'n opdragreëlargument kan verwag, en die antwoord op `stdout` behoort terug te gee (sien <<_credential_caching>> vir meer oor hierdie substelsel).
+
+*`GIT_NAMESPACE`* beheer toegang tot naamspasie-verwysings (namespaced refs), en is ekwivalent aan die `--namespace` vlag.
+Dit is meestal nuttig aan die bedienerkant, waar jy dalk veelvuldige vurke (forks) van 'n enkele bewaarplek in een bewaarplek wil stoor, en net die verwysings apart wil hou.
+
+*`GIT_FLUSH`* kan gebruik word om Git te dwing om nie-gebufferde I/O te gebruik wanneer dit inkrementeel na stdout skryf.
+'n Waarde van 1 veroorsaak dat Git meer gereeld spoel (flush), 'n waarde van 0 veroorsaak dat alle afvoer gebuffer word.
+Die verstekwaarde (as hierdie veranderlike nie gestel is nie) is om 'n gepaste bufferingskema te kies na gelang van die aktiwiteit en die afvoermodus.
+
+*`GIT_REFLOG_ACTION`* laat jou toe om die beskrywende teks te spesifiseer wat na die verwysingslog (reflog) geskryf word.
+Hier is 'n voorbeeld:
+
+[source,console]
+
+
+
+
$ GIT_REFLOG_ACTION="my action" git commit --allow-empty -m 'My message'
+[master 9e3d55a] My message
+$ git reflog -1
+9e3d55a HEAD@{0}: my action: My message
+
+
+
+
=== Summary
+
+At this point, you should have a pretty good understanding of what Git does in the background and, to some degree, how it's implemented.
+This chapter has covered a number of plumbing commands -- commands that are lower level and simpler than the porcelain commands you've learned about in the rest of the book.
+Understanding how Git works at a lower level should make it easier to understand why it's doing what it's doing and also to write your own tools and helper scripts to make your specific workflow work for you.
+
+Git as a content-addressable filesystem is a very powerful tool that you can easily use as more than just a VCS.
+We hope you can use your newfound knowledge of Git internals to implement your own cool application of this technology and feel more comfortable using Git in more advanced ways.
+
+
+[[A-git-in-other-environments]]
+[appendix]
+== Git in Other Environments
+
+If you read through the whole book, you've learned a lot about how to use Git at the command line.
+You can work with local files, connect your repository to others over a network, and work effectively with others.
+But the story doesn't end there; Git is usually used as part of a larger ecosystem, and the terminal isn't always the best way to work with it.
+Now we'll take a look at some of the other kinds of environments where Git can be useful, and how other applications (including yours) work alongside Git.
+
+== Grafiese Koppelvlakke (Graphical Interfaces)
+
+(((GUIs)))(((Grafiese hulpmiddels)))
+Git se natuurlike omgewing is in die terminaal.
+Nuwe kenmerke verskyn eerste daar, en slegs op die opdragreël (command line) is die volle krag van Git heeltemal tot jou beskikking.
+Maar gewone teks is nie die beste keuse vir alle take nie; soms is 'n visuele voorstelling wat jy nodig het, en sommige gebruikers is baie meer gemaklik met 'n wys-en-klik-koppelvlak.
+
+Dit is belangrik om daarop te let dat verskillende koppelvlakke vir verskillende werkvloeie (workflows) aangepas is.
+Sommige kliënte stel slegs 'n noukeurig uitgesoekte substel van Git-funksionaliteit bloot, ten einde 'n spesifieke manier van werk te ondersteun wat die outeur as effektief beskou.
+In hierdie lig gesien, kan nie een van hierdie hulpmiddels "`beter`" as enige van die ander genoem word nie; hulle is bloot meer geskik vir hul beoogde doel.
+Let ook daarop dat daar niks is wat hierdie grafiese kliënte kan doen wat die opdragreël-kliënt nie kan doen nie; die opdragreël is steeds waar jy die meeste krag en beheer sal hê wanneer jy met jou bewaarplekke werk.
+
+==== `gitk` en `git-gui`
+
+(((git opdragte, gitk)))(((git opdragte, gui)))(((gitk)))
+Wanneer jy Git installeer, kry jy ook sy visuele hulpmiddels, `gitk` en `git-gui`.
+
+`gitk` is 'n grafiese geskiedeniskyker (history viewer).
+Dink daaraan as 'n kragtige GUI-dop (shell) oor `git log` en `git grep`.
+Dit is die hulpmiddel om te gebruik wanneer jy probeer om iets te vind wat in die verlede gebeur het, of jou projek se geskiedenis wil visualiseer.
+
+Gitk is die maklikste om vanaf die opdragreël op te roep.
+Gaan net met `cd` na 'n Git-bewaarplek, en tik:
+
+[source,console]
+
+
+
+
$ gitk [git log options]
+
+
+
+
Gitk aanvaar baie opdragreëlopsies, waarvan die meeste na die onderliggende `git log` aksie deurgegee word.
+Waarskynlik een van die nuttigste is die `--all` vlag, wat vir `gitk` sê om vasleggings (commits) te wys wat vanaf _enige_ verwysing bereikbaar is, nie net HEAD nie.
+Gitk se koppelvlak lyk so:
+
+.Die `gitk` geskiedeniskyker
+image::images/gitk.png[The `gitk` history viewer]
+
+Aan die bokant is iets wat 'n bietjie soos die afvoer van `git log --graph` lyk; elke kolletjie verteenwoordig 'n vaslegging, die lyne verteenwoordig ouerverhoudings, en verwysings (refs) word as gekleurde boksies gewys.
+Die geel kolletjie verteenwoordig HEAD, en die rooi kolletjie verteenwoordig veranderings wat nog 'n vaslegging moet word.
+Aan die onderkant is 'n aansig van die gekose vaslegging; die kommentaar en pleister (patch) aan die linkerkant, en 'n opsommingsaansig aan die regterkant.
+Tussenin is 'n versameling kontroles wat gebruik word om deur die geskiedenis te soek.
+
+`git-gui`, aan die ander kant, is hoofsaaklik 'n hulpmiddel vir die samestelling (crafting) van vasleggings.
+Dit is ook die maklikste om vanaf die opdragreël op te roep:
+
+[source,console]
+
+
+
+
+
+
En dit lyk min of meer soos volg:
+
+.Die `git-gui` vasleggingshulpmiddel
+image::images/git-gui.png[The `git-gui` commit tool]
+
+Aan die linkerkant is die indeks; onvoorbereide (unstaged) veranderings is bo, voorbereide (staged) veranderings is onder.
+Jy kan hele lêers tussen die twee toestande skuif deur op hul ikone te klik, of jy kan 'n lêer kies om te besigtig deur op sy naam te klik.
+
+Regs bo is die verskilaansig (diff view), wat die veranderings vir die tans gekose lêer wys.
+Jy kan individuele stukke (hunks) of individuele reëls voorberei (stage) deur regs in hierdie area te klik.
+
+Regs onder is die boodskap- en aksie-area.
+Tik jou boodskap in die tekskassie en klik "`Commit`" om iets soortgelyks as `git commit` te doen.
+Jy kan ook kies om die laaste vaslegging te wysig (amend) deur die "`Amend`" radioknoppie te kies, wat die "`Staged Changes`" area sal opdateer met die inhoud van die laaste vaslegging.
+Dan kan jy bloot sommige veranderings voorberei of ongedaan maak, die vasleggingsboodskap verander, en weer "`Commit`" klik om die ou vaslegging met 'n nuwe een te vervang.
+
+`gitk` en `git-gui` is voorbeelde van taakgeoriënteerde hulpmiddels.
+Elkeen van hulle is aangepas vir 'n spesifieke doel (onderskeidelik die besigtiging van geskiedenis en die skep van vasleggings), en laat die kenmerke weg wat nie vir daardie taak nodig is nie.
+
+==== GitHub vir macOS en Windows
+
+(((GitHub vir macOS)))(((GitHub vir Windows)))
+GitHub het twee werkvloeigeoriënteerde Git-kliënte geskep: een vir Windows, en een vir macOS.
+Hierdie kliënte is 'n goeie voorbeeld van werkvloeigeoriënteerde hulpmiddels – eerder as om _al_ Git se funksionaliteit bloot te stel, fokus hulle eerder op 'n uitgesoekte stel algemeen gebruikte kenmerke wat goed saamwerk.
+Hulle lyk soos volg:
+
+.GitHub vir macOS
+image::images/github_mac.png[GitHub for macOS]
+
+.GitHub vir Windows
+image::images/github_win.png[GitHub for Windows]
+
+Hulle is ontwerp om baie dieselfde te lyk en te werk, so ons sal hulle as 'n enkele produk in hierdie hoofstuk hanteer.
+Ons gaan nie 'n gedetailleerde oorsig van hierdie hulpmiddels gee nie (hulle het hul eie dokumentasie), maar 'n vinnige toer deur die "`changes`" (veranderings) aansig (wat is waar jy die meeste van jou tyd sal spandeer) is gepas.
+
+* Aan die linkerkant is die lys van bewaarplekke wat die kliënt naspoor; jy kan 'n bewaarplek byvoeg (hetsy deur te kloon of plaaslik aan te heg) deur op die "`{plus}`" ikoon aan die bokant van hierdie area te klik.
+* In die middel is 'n vasleggingsinvoer-area, wat jou toelaat om 'n vasleggingsboodskap in te voer en te kies watter lêers ingesluit moet word. Op Windows word die vasleggingsgeskiedenis direk hieronder vertoon; op macOS is dit op 'n aparte oortjie.
+* Aan die regterkant is 'n verskilaansig (diff view), wat wys wat in jou werkgids verander het, of watter veranderings in die gekose vaslegging ingesluit was.
+* Die laaste ding om op te let, is die "`Sync`" (sinchroniseer) knoppie regs bo, wat die primêre manier is waarop jy oor die netwerk interaksie het.
+
+[NOTE]
+====
+Jy het nie 'n GitHub-rekening nodig om hierdie hulpmiddels te gebruik nie.
+Alhoewel hulle ontwerp is om GitHub se diens en aanbevole werkvloei uit te lig, sal hulle gelukkig met enige bewaarplek werk, en netwerkbedrywighede met enige Git-gasheer doen.
+====
+
+===== Installasie (Installation)
+
+GitHub vir Windows en macOS kan afgelaai word vanaf https://desktop.github.com/[^].
+Wanneer die toepassings vir die eerste keer oopgemaak word, lei hulle jou deur die eenmalige Git-opstelling, soos die konfigurasie van jou naam en e-posadres, en beide stel sinvolle verstekwaardes (sane defaults) op vir baie algemene konfigurasie-opsies, soos aanmeldbewys-kasgeheues (credential caches) en CRLF-gedrag.
+
+Beide is "`immergroen`" ("`evergreen`") – opdaterings word in die agtergrond afgelaai en geïnstalleer terwyl die toepassings oop is.
+Dit sluit nuttig 'n gebundelde weergawe van Git in, wat beteken jy sal waarskynlik nie hoef te bekommer om dit ooit weer handmatig op te dateer nie.
+Op Windows sluit die kliënt 'n kortpad in om PowerShell met Posh-git te loods, waaroor ons later in hierdie hoofstuk meer sal praat.
+
+Die volgende stap is om die hulpmiddel 'n paar bewaarplekke te gee om mee te werk.
+Die kliënt wys jou 'n lys van die bewaarplekke waartoe jy op GitHub toegang het, en kan hulle in een stap kloon.
+As jy reeds 'n plaaslike bewaarplek het, sleep net sy gids vanaf die Finder of Windows Explorer in die GitHub-kliëntvenster in, en dit sal by die lys bewaarplekke aan die linkerkant ingesluit word.
+
+===== Aanbevole Werkvloei (Recommended Workflow)
+
+Sodra dit geïnstalleer en gekonfigureer is, kan jy die GitHub-kliënt vir baie algemene Git-take gebruik.
+Die beoogde werkvloei vir hierdie hulpmiddel word soms die "`GitHub Flow`" genoem.
+Ons dek dit in meer detail in <<ch06-github_flow>>, maar die algemene idee is dat (a) jy na 'n tak sal vaslê, en (b) jy redelik gereeld met 'n afgeleë bewaarplek sal sinchroniseer.
+
+Takbestuur (Branch management) is een van die areas waar die twee hulpmiddels van mekaar verskil.
+Op macOS is daar 'n knoppie aan die bokant van die venster om 'n nuwe tak te skep:
+
+."Create Branch" (Skep Tak) knoppie op macOS
+image::images/branch_widget_mac.png[“Create Branch” button on macOS]
+
+Op Windows word dit gedoen deur die nuwe tak se naam in die tak-skakel-legstuk (branch-switching widget) te tik:
+
+.Die skep van 'n tak op Windows
+image::images/branch_widget_win.png[Creating a branch on Windows]
+
+Sodra jou tak geskep is, is dit redelik eenvoudig om nuwe vasleggings te maak.
+Maak 'n paar veranderings in jou werkgids, en wanneer jy oorskakel na die GitHub-kliëntvenster, sal dit jou wys watter lêers verander het.
+Voer 'n vasleggingsboodskap in, kies die lêers wat jy wil insluit, en klik die "`Commit`" knoppie (ctrl-enter of ⌘-enter).
+
+Die hoofmanier waarop jy interaksie het met ander bewaarplekke oor die netwerk, is deur die "`Sync`" (sinchroniseer) funksie.
+Git het intern aparte bewerkings vir push, fetch, merge en rebase, maar die GitHub-kliënte vou al hierdie in een meerstap-funksie ineen.
+Hier is wat gebeur as jy die Sync-knoppie klik:
+
+. `git pull --rebase`.
+ As dit misluk as gevolg van 'n saamsmeltingskonflik (merge conflict), val dit terug na `git pull --no-rebase`.
+. `git push`.
+
+Dit is die mees algemene volgorde van netwerkopdragte wanneer jy in hierdie styl werk, so om hulle in een opdrag saam te pers (squash) bespaar baie tyd.
+
+===== Opsomming (Summary)
+
+Hierdie hulpmiddels is uiters geskik vir die werkvloei waarvoor hulle ontwerp is.
+Ontwikkelaars en nie-ontwikkelaars gelyk kan binne minute aan 'n projek saamwerk, en baie van die beste praktyke vir hierdie soort werkvloei is in die hulpmiddels ingebou.
+As jou werkvloei egter verskil, of jy meer beheer wil hê oor hoe en wanneer netwerkbedrywighede gedoen word, beveel ons aan dat jy 'n ander kliënt of die opdragreël gebruik.
+
+==== Ander GUI's (Other GUIs)
+
+Daar is 'n aantal ander grafiese Git-kliënte, en hulle strek oor die hele spektrum, van gespesialiseerde enkeldoel-hulpmiddels tot by toepassings wat probeer om alles bloot te stel wat Git kan doen.
+Die amptelike Git-webwerf het 'n saamgestelde lys van die gewildste kliënte by https://git-scm.com/downloads/guis[^].
+'n Meer omvattende lys is beskikbaar op die Git-wiki-webwerf, by https://archive.kernel.org/oldwiki/git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools.html#Graphical_Interfaces[^].
+
+=== Git in Visual Studio
+
+(((Visual Studio)))
+Visual Studio has Git tooling built directly into the IDE, starting with Visual Studio 2019 version 16.8.
+
+The tooling supports the following Git functionality:
+
+* Create or clone a repository.
+* Open and browse history of a repository.
+* Create and checkout branches and tags.
+* Stash, stage, and commit changes.
+* Fetch, pull, push, or sync commits.
+* Merge and rebase branches.
+* Resolve merge conflicts.
+* View diffs.
+* ... and more!
+
+Read the https://learn.microsoft.com/en-us/visualstudio/version-control/[official documentation^] to learn more.
+
+
+=== Git in Visual Studio Code
+
+(((Visual Studio Code)))
+Visual Studio Code has Git support built in.
+You will need to have Git version 2.0.0 (or newer) installed.
+
+The main features are:
+
+* See the diff of the file you are editing in the gutter.
+* The Git Status Bar (lower left) shows the current branch, dirty indicators, incoming and outgoing commits.
+* You can do the most common git operations from within the editor:
+** Initialize a repository.
+** Clone a repository.
+** Create branches and tags.
+** Stage and commit changes.
+** Push/pull/sync with a remote branch.
+** Resolve merge conflicts.
+** View diffs.
+* With an extension, you can also handle GitHub Pull Requests:
+ https://marketplace.visualstudio.com/items?itemName=GitHub.vscode-pull-request-github[^].
+
+The official documentation can be found here: https://code.visualstudio.com/docs/sourcecontrol/overview[^].
+
+
+=== Git in IntelliJ / PyCharm / WebStorm / PhpStorm / RubyMine
+
+(((JetBrains)))
+JetBrains IDEs (such as IntelliJ IDEA, PyCharm, WebStorm, PhpStorm, RubyMine, and others) ship with a Git Integration plugin.
+It provides a dedicated view in the IDE to work with Git and GitHub Pull Requests.
+
+.Version Control ToolWindow in JetBrains IDEs
+image::images/jb.png[Version Control ToolWindow in JetBrains IDEs]
+
+The integration relies on the command-line Git client, and requires one to be installed.
+The official documentation is available at https://www.jetbrains.com/help/idea/using-git-integration.html[^].
+
+
+=== Git in Sublime Text
+
+(((Sublime Text)))
+From version 3.2 onwards, Sublime Text has Git integration in the editor.
+
+The features are:
+
+* The sidebar will show the `git status` of files and folders with a badge/icon.
+* Files and folders that are in your `.gitignore` file will be faded out in the sidebar.
+* In the status bar, you can see the current Git branch and how many modifications you have made.
+* All changes to a file are now visible via markers in the gutter.
+* You can use part of the Sublime Merge Git client functionality from within Sublime Text.
+ This requires that Sublime Merge is installed.
+ See: https://www.sublimemerge.com/[^].
+
+The official documentation for Sublime Text can be found here: https://www.sublimetext.com/docs/git_integration.html[^].
+
+
+=== Git in Bash
+
+(((bash)))(((oortjie-voltooiing, bash)))(((dop-aanwysings, bash)))
+As jy 'n Bash-gebruiker is, kan jy sommige van jou dop (shell) se kenmerke inspan om jou ervaring met Git baie vriendeliker te maak.
+Git kom eintlik met inproppe (plugins) vir verskeie doppe, maar dit is nie by verstek aangeskakel nie.
+
+Eerstens moet jy 'n kopie van die voltooiingslêer kry uit die bronkode van die Git-vrystelling wat jy gebruik.
+Gaan jou weergawe na deur `git version` in te tik, en gebruik dan `git checkout tags/vX.Y.Z`, waar `vX.Y.Z` ooreenstem met die weergawe van Git wat jy gebruik.
+Kopieer die `contrib/completion/git-completion.bash` lêer na 'n gerieflike plek, soos jou tuisgids (home directory), en voeg dit by jou `.bashrc`:
+
+[source,console]
+
+
+
+
+-
+
~/git-completion.bash
+
+
+
+
+
+
Sodra dit gedoen is, verander jou gids na 'n Git-bewaarplek en tik:
+
+[source,console]
+
+
+
+
+
+
…en Bash sal outomaties voltooi na `git checkout`.
+Dit werk met al Git se subopdragte, opdragreëlparameters, en afgeleë (remotes) en verwysingsname waar toepaslik.
+
+Dit is ook nuttig om jou aanwysing (prompt) aan te pas om inligting oor die huidige gids se Git-bewaarplek te wys.
+Dit kan so eenvoudig of kompleks wees as wat jy wil, maar daar is oor die algemeen 'n paar belangrike stukke inligting wat die meeste mense wil hê, soos die huidige tak en die status van die werkgids.
+Om dit by jou aanwysing te voeg, kopieer net die `contrib/completion/git-prompt.sh` lêer vanaf Git se bronbewaarplek na jou tuisgids, en voeg so iets by jou `.bashrc`:
+
+[source,console]
+
+
+
+
+-
+
~/git-prompt.sh
+export GIT_PS1_SHOWDIRTYSTATE=1
+export PS1='\w$(__git_ps1 " (%s)")\$ '
+
+
+
+
+
+
Die `\w` beteken druk die huidige werkgids, die `\$` druk die `$` gedeelte van die aanwysing, en `__git_ps1 " (%s)"` roep die funksie uit wat deur `git-prompt.sh` verskaf word met 'n formateringsargument.
+Nou sal jou bash-aanwysing so lyk wanneer jy enige plek binne 'n Git-beheerde projek is:
+
+.Gepasmaakte `bash` aanwysing
+image::images/git-bash.png[Gepasmaakte `bash` aanwysing]
+
+Beide hierdie skrippe kom met nuttige dokumentasie; kyk na die inhoud van `git-completion.bash` en `git-prompt.sh` vir meer inligting.
+
+=== Git in Zsh
+
+(((zsh)))(((oortjie-voltooiing, zsh)))(((dop-aanwysings, zsh)))
+Zsh kom ook met 'n oortjie-voltooiing (tab-completion) biblioteek vir Git.
+Om dit te gebruik, voer eenvoudig `autoload -Uz compinit && compinit` in jou `.zshrc` uit.
+Zsh se koppelvlak is ietwat kragtiger as dié van Bash:
+
+[source,console]
+
+
+
+
$ git che<tab>
+check-attr — vertoon gitattributes inligting
+check-ref-format — maak seker dat 'n verwysingsnaam goed gevorm is
+checkout — trek 'n tak of paaie na die werkboom uit (checkout)
+checkout-index — kopieer lêers van die indeks na die werkgids
+cherry — vind vasleggings wat nie stroomop ingesmelt is nie
+cherry-pick — pas veranderings toe wat deur sekere bestaande vasleggings ingestel is
+
+
+
+
Dubbelsinnige oortjie-voltooiings word nie net gelys nie; hulle het nuttige beskrywings, en jy kan grafies deur die lys navigeer deur herhaaldelik die oortjie-sleutel (tab) te druk.
+Dit werk met Git-opdragte, hul argumente, en name van dinge binne die bewaarplek (soos verwysings en remotes), sowel as lêername en al die ander dinge wat Zsh weet hoe om met oortjies te voltooi.
+
+Zsh kom met 'n raamwerk om inligting van weergawebeheerstelsels te kry, genaamd `vcs_info`.
+Om die taknaam by die aanwysing (prompt) aan die regterkant in te sluit, voeg hierdie reëls by jou `~/.zshrc` lêer:
+
+[source,console]
+
+
+
+
autoload -Uz vcs_info
+precmd_vcs_info() { vcs_info }
+precmd_functions+=( precmd_vcs_info )
+setopt prompt_subst
+RPROMPT='${vcs_info_msg_0_}'
+# PROMPT='${vcs_info_msg_0_}%# '
+zstyle ':vcs_info:git:*' formats '%b'
+
+
+
+
Dit lei tot 'n vertoning van die huidige tak aan die regterkant van die terminaalvenster, wanneer jou dop in 'n Git-bewaarplek is.
+Die linkerkant word natuurlik ook ondersteun; verwyder net die opmerkingsteken by die toewysing aan `PROMPT`.
+Dit lyk 'n bietjie soos volg:
+
+.Gepasmaakte `zsh` aanwysing
+image::images/zsh-prompt.png[Gepasmaakte `zsh` aanwysing]
+
+Vir meer inligting oor `vcs_info`, kyk na die dokumentasie in die `zshcontrib(1)` handleidingsbladsy (manual page), of aanlyn by https://zsh.sourceforge.io/Doc/Release/User-Contributions.html#Version-Control-Information[^].
+
+In plaas van `vcs_info`, verkies jy dalk die aanwysing-aanpassingskrip (prompt customization script) wat saam met Git kom, genaamd `git-prompt.sh`; kyk na https://github.com/git/git/blob/master/contrib/completion/git-prompt.sh[^] vir besonderhede.
+`git-prompt.sh` is versoenbaar met beide Bash en Zsh.
+
+Zsh is kragtig genoeg dat daar hele raamwerke is wat daaraan toegewy is om dit beter te maak.
+Een daarvan word "oh-my-zsh" genoem, en dit kan gevind word by https://github.com/ohmyzsh/ohmyzsh[^].
+oh-my-zsh se inpropstelsel kom met kragtige Git-oortjie-voltooiing, en dit het 'n verskeidenheid aanwysingstemas ("themes"), waarvan baie weergawebeheerdata vertoon.
+<<oh_my_zsh_git>> is net een voorbeeld van wat met hierdie stelsel gedoen kan word.
+
+[[oh_my_zsh_git]]
+.'n Voorbeeld van 'n oh-my-zsh tema
+image::images/zsh-oh-my.png['n Voorbeeld van 'n oh-my-zsh tema]
+
+[[_git_powershell]]
+=== Git in PowerShell
+
+(((PowerShell)))(((tab completion, PowerShell)))(((shell prompts, PowerShell)))
+(((posh-git)))
+The legacy command-line terminal on Windows (`cmd.exe`) isn't really capable of a customized Git experience, but if you're using PowerShell, you're in luck.
+This also works if you're running PowerShell Core on Linux or macOS.
+A package called posh-git (https://github.com/dahlbyk/posh-git[^]) provides powerful tab-completion facilities, as well as an enhanced prompt to help you stay on top of your repository status.
+It looks like this:
+
+.PowerShell with Posh-git
+image::images/posh-git.png[PowerShell with Posh-git]
+
+==== Installation
+
+===== Prerequisites (Windows only)
+
+Before you're able to run PowerShell scripts on your machine, you need to set your local `ExecutionPolicy` to `RemoteSigned` (basically, anything except `Undefined` and `Restricted`).
+If you choose `AllSigned` instead of `RemoteSigned`, also local scripts (your own) need to be digitally signed in order to be executed.
+With `RemoteSigned`, only scripts having the `ZoneIdentifier` set to `Internet` (were downloaded from the web) need to be signed, others not.
+If you're an administrator and want to set it for all users on that machine, use `-Scope LocalMachine`.
+If you're a normal user, without administrative rights, you can use `-Scope CurrentUser` to set it only for you.
+
+More about PowerShell Scopes: https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_scopes[^].
+
+More about PowerShell ExecutionPolicy: https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.security/set-executionpolicy[^].
+
+To set the value of `ExecutionPolicy` to `RemoteSigned` for all users use the next command:
+
+[source,powershell]
+
+
+
+
+
+
Set-ExecutionPolicy -Scope LocalMachine -ExecutionPolicy RemoteSigned -Force
+
+
+
+
+
===== PowerShell Gallery
+
+If you have at least PowerShell 5 or PowerShell 4 with PackageManagement installed, you can use the package manager to install posh-git for you.
+
+More information about PowerShell Gallery: https://learn.microsoft.com/en-us/powershell/scripting/gallery/overview[^].
+
+[source,powershell]
+
+
+
+
+
+
Install-Module posh-git -Scope CurrentUser -Force
+Install-Module posh-git -Scope CurrentUser -AllowPrerelease -Force # Newer beta version with PowerShell Core support
+
+
+
+
+
If you want to install posh-git for all users, use `-Scope AllUsers` instead and execute the command from an elevated PowerShell console.
+If the second command fails with an error like `Module 'PowerShellGet' was not installed by using Install-Module`, you'll need to run another command first:
+
+[source,powershell]
+
+
+
+
+
+
Install-Module PowerShellGet -Force -SkipPublisherCheck
+
+
+
+
+
Then you can go back and try again.
+This happens, because the modules that ship with Windows PowerShell are signed with a different publishment certificate.
+
+===== Update PowerShell Prompt
+
+To include Git information in your prompt, the posh-git module needs to be imported.
+To have posh-git imported every time PowerShell starts, execute the `Add-PoshGitToProfile` command which will add the import statement into your `$profile` script.
+This script is executed everytime you open a new PowerShell console.
+Keep in mind, that there are multiple `$profile` scripts.
+E.g. one for the console and a separate one for the ISE.
+
+[source,powershell]
+
+
+
+
+
+
Import-Module posh-git
+Add-PoshGitToProfile -AllHosts
+
+
+
+
+
===== From Source
+
+Just download a posh-git release from https://github.com/dahlbyk/posh-git/releases[^], and uncompress it.
+Then import the module using the full path to the `posh-git.psd1` file:
+
+[source,powershell]
+
+
+
+
+
+
Import-Module <path-to-uncompress-folder>\src\posh-git.psd1
+Add-PoshGitToProfile -AllHosts
+
+
+
+
+
This will add the proper line to your `profile.ps1` file, and posh-git will be active the next time you open PowerShell.
+
+For a description of the Git status summary information displayed in the prompt see: https://github.com/dahlbyk/posh-git/blob/master/README.md#git-status-summary-information[^]
+For more details on how to customize your posh-git prompt see: https://github.com/dahlbyk/posh-git/blob/master/README.md#customization-variables[^].
+
+
+=== Summary
+
+You've learned how to harness Git's power from inside the tools that you use during your everyday work, and also how to access Git repositories from your own programs.
+
+
+[[B-embedding-git-in-your-applications]]
+[appendix]
+== Embedding Git in your Applications
+
+If your application is for developers, chances are good that it could benefit from integration with source control.
+Even non-developer applications, such as document editors, could potentially benefit from version-control features, and Git's model works very well for many different scenarios.
+
+If you need to integrate Git with your application, you have essentially two options: spawn a shell and call the `git` command-line program, or embed a Git library into your application.
+Here we'll cover command-line integration and several of the most popular embeddable Git libraries.
+
+=== Command-line Git
+
+One option is to spawn a shell process and use the Git command-line tool to do the work.
+This has the benefit of being canonical, and all of Git's features are supported.
+This also happens to be fairly easy, as most runtime environments have a relatively simple facility for invoking a process with command-line arguments.
+However, this approach does have some downsides.
+
+One is that all the output is in plain text.
+This means that you'll have to parse Git's occasionally-changing output format to read progress and result information, which can be inefficient and error-prone.
+
+Another is the lack of error recovery.
+If a repository is corrupted somehow, or the user has a malformed configuration value, Git will simply refuse to perform many operations.
+
+Yet another is process management.
+Git requires you to maintain a shell environment on a separate process, which can add unwanted complexity.
+Trying to coordinate many of these processes (especially when potentially accessing the same repository from several processes) can be quite a challenge.
+
+
+=== Libgit2
+
+(((libgit2)))((("C")))
+Another option at your disposal is to use Libgit2.
+Libgit2 is a dependency-free implementation of Git, with a focus on having a nice API for use within other programs.
+You can find it at https://libgit2.org[^].
+
+First, let's take a look at what the C API looks like.
+Here's a whirlwind tour:
+
+[source,c]
+
+
+
+
git_repository *repo;
+int error = git_repository_open(&repo, "/path/to/repository");
+
+
+
git_object head_commit;
+error = git_revparse_single(&head_commit, repo, "HEAD^{commit}");
+git_commit *commit = (git_commit)head_commit;
+
+
+
printf("%s", git_commit_message(commit));
+const git_signature *author = git_commit_author(commit);
+printf("%s <%s>\n", author→name, author→email);
+const git_oid *tree_id = git_commit_tree_id(commit);
+
+
+
git_commit_free(commit);
+git_repository_free(repo);
+
+
+
+
The first couple of lines open a Git repository.
+The `git_repository` type represents a handle to a repository with a cache in memory.
+This is the simplest method, for when you know the exact path to a repository's working directory or `.git` folder.
+There's also the `git_repository_open_ext` which includes options for searching, `git_clone` and friends for making a local clone of a remote repository, and `git_repository_init` for creating an entirely new repository.
+
+The second chunk of code uses rev-parse syntax (see <<_branch_references>> for more on this) to get the commit that HEAD eventually points to.
+The type returned is a `git_object` pointer, which represents something that exists in the Git object database for a repository.
+`git_object` is actually a "`parent`" type for several different kinds of objects; the memory layout for each of the "`child`" types is the same as for `git_object`, so you can safely cast to the right one.
+In this case, `git_object_type(commit)` would return `GIT_OBJ_COMMIT`, so it's safe to cast to a `git_commit` pointer.
+
+The next chunk shows how to access the commit's properties.
+The last line here uses a `git_oid` type; this is Libgit2's representation for a SHA-1 hash.
+
+From this sample, a couple of patterns have started to emerge:
+
+* If you declare a pointer and pass a reference to it into a Libgit2 call, that call will probably return an integer error code.
+ A `0` value indicates success; anything less is an error.
+* If Libgit2 populates a pointer for you, you're responsible for freeing it.
+* If Libgit2 returns a `const` pointer from a call, you don't have to free it, but it will become invalid when the object it belongs to is freed.
+* Writing C is a bit painful.
+
+(((Ruby)))
+That last one means it isn't very probable that you'll be writing C when using Libgit2.
+Fortunately, there are a number of language-specific bindings available that make it fairly easy to work with Git repositories from your specific language and environment.
+Let's take a look at the above example written using the Ruby bindings for Libgit2, which are named Rugged, and can be found at https://github.com/libgit2/rugged[^].
+
+[source,ruby]
+
+
+
+
repo = Rugged::Repository.new('path/to/repository')
+commit = repo.head.target
+puts commit.message
+puts "{commit.author[:name]} <{commit.author[:email]}>"
+tree = commit.tree
+
+
+
+
As you can see, the code is much less cluttered.
+Firstly, Rugged uses exceptions; it can raise things like `ConfigError` or `ObjectError` to signal error conditions.
+Secondly, there's no explicit freeing of resources, since Ruby is garbage-collected.
+Let's take a look at a slightly more complicated example: crafting a commit from scratch
+
+[source,ruby]
+
+
+
+
blob_id = repo.write("Blob contents", :blob) # <1>
+
+
+
index = repo.index
+index.read_tree(repo.head.target.tree)
+index.add(:path ⇒ 'newfile.txt', :oid ⇒ blob_id) # <2>
+
+
+
sig = {
+ :email ⇒ "bob@example.com",
+ :name ⇒ "Bob User",
+ :time ⇒ Time.now,
+}
+
+
+
commit_id = Rugged::Commit.create(repo,
+ :tree ⇒ index.write_tree(repo), # <3>
+ :author ⇒ sig,
+ :committer ⇒ sig, # <4>
+ :message ⇒ "Add newfile.txt", # <5>
+ :parents ⇒ repo.empty? ? [] : [ repo.head.target ].compact, # <6>
+ :update_ref ⇒ 'HEAD', # <7>
+)
+commit = repo.lookup(commit_id) # <8>
+
+
+
+
<1> Create a new blob, which contains the contents of a new file.
+<2> Populate the index with the head commit's tree, and add the new file at the path `newfile.txt`.
+<3> This creates a new tree in the ODB, and uses it for the new commit.
+<4> We use the same signature for both the author and committer fields.
+<5> The commit message.
+<6> When creating a commit, you have to specify the new commit's parents.
+ This uses the tip of HEAD for the single parent.
+<7> Rugged (and Libgit2) can optionally update a reference when making a commit.
+<8> The return value is the SHA-1 hash of a new commit object, which you can then use to get a `Commit` object.
+
+The Ruby code is nice and clean, but since Libgit2 is doing the heavy lifting, this code will run pretty fast, too.
+If you're not a rubyist, we touch on some other bindings in <<_libgit2_bindings>>.
+
+==== Advanced Functionality
+
+Libgit2 has a couple of capabilities that are outside the scope of core Git.
+One example is pluggability: Libgit2 allows you to provide custom "`backends`" for several types of operation, so you can store things in a different way than stock Git does.
+Libgit2 allows custom backends for configuration, ref storage, and the object database, among other things.
+
+Let's take a look at how this works.
+The code below is borrowed from the set of backend examples provided by the Libgit2 team (which can be found at https://github.com/libgit2/libgit2-backends[^]).
+Here's how a custom backend for the object database is set up:
+
+[source,c]
+
+
+
+
git_odb *odb;
+int error = git_odb_new(&odb); // <1>
+
+
+
git_odb_backend my_backend;
+error = git_odb_backend_mine(&my_backend, /…*/); // <2>
+
+
+
error = git_odb_add_backend(odb, my_backend, 1); // <3>
+
+
+
git_repository *repo;
+error = git_repository_open(&repo, "some-path");
+error = git_repository_set_odb(repo, odb); // <4>
+
+
+
+
_Note that errors are captured, but not handled. We hope your code is better than ours._
+
+<1> Initialize an empty object database (ODB) "`frontend,`" which will act as a container for the "`backends`" which are the ones doing the real work.
+<2> Initialize a custom ODB backend.
+<3> Add the backend to the frontend.
+<4> Open a repository, and set it to use our ODB to look up objects.
+
+But what is this `git_odb_backend_mine` thing?
+Well, that's the constructor for your own ODB implementation, and you can do whatever you want in there, so long as you fill in the `git_odb_backend` structure properly.
+Here's what it _could_ look like:
+
+[source,c]
+
+
+
+
typedef struct {
+ git_odb_backend parent;
+
+
+
+
// Some other stuff
+ void *custom_context;
+} my_backend_struct;
+
+
+
+
int git_odb_backend_mine(git_odb_backend *backend_out, /…*/)
+{
+ my_backend_struct *backend;
+
+
+
+
backend = calloc(1, sizeof (my_backend_struct));
+
+
+
+
+
backend->custom_context = …;
+
+
+
+
+
backend->parent.read = &my_backend__read;
+backend->parent.read_prefix = &my_backend__read_prefix;
+backend->parent.read_header = &my_backend__read_header;
+// …
+
+
+
+
+
*backend_out = (git_odb_backend *) backend;
+
+
+
+
+
return GIT_SUCCESS;
+}
+
+
+
+
+
The subtlest constraint here is that ``my_backend_struct```'s first member must be a ``git_odb_backend`` structure; this ensures that the memory layout is what the Libgit2 code expects it to be.
+The rest of it is arbitrary; this structure can be as large or small as you need it to be.
+
+The initialization function allocates some memory for the structure, sets up the custom context, and then fills in the members of the `parent` structure that it supports.
+Take a look at the `include/git2/sys/odb_backend.h` file in the Libgit2 source for a complete set of call signatures; your particular use case will help determine which of these you'll want to support.
+
+[[_libgit2_bindings]]
+==== Other Bindings
+
+Libgit2 has bindings for many languages.
+Here we show a small example using a few of the more complete bindings packages as of this writing; libraries exist for many other languages, including C++, Go, Node.js, Erlang, and the JVM, all in various stages of maturity.
+The official collection of bindings can be found by browsing the repositories at https://github.com/libgit2[^].
+The code we'll write will return the commit message from the commit eventually pointed to by HEAD (sort of like `git log -1`).
+
+===== LibGit2Sharp
+
+(((.NET)))(((C#)))(((Mono)))
+If you're writing a .NET or Mono application, LibGit2Sharp (https://github.com/libgit2/libgit2sharp[^]) is what you're looking for.
+The bindings are written in C#, and great care has been taken to wrap the raw Libgit2 calls with native-feeling CLR APIs.
+Here's what our example program looks like:
+
+[source,csharp]
+
+
+
+
new Repository(@"C:\path\to\repo").Head.Tip.Message;
+
+
+
+
For desktop Windows applications, there's even a NuGet package that will help you get started quickly.
+
+===== objective-git
+
+(((Apple)))(((Objective-C)))(((Cocoa)))
+If your application is running on an Apple platform, you're likely using Objective-C as your implementation language.
+Objective-Git (https://github.com/libgit2/objective-git[^]) is the name of the Libgit2 bindings for that environment.
+The example program looks like this:
+
+[source,objc]
+
+
+
+
GTRepository *repo =
+ [[GTRepository alloc] initWithURL:[NSURL fileURLWithPath: @"/path/to/repo"] error:NULL];
+NSString *msg = [[[repo headReferenceWithError:NULL] resolvedTarget] message];
+
+
+
+
Objective-git is fully interoperable with Swift, so don't fear if you've left Objective-C behind.
+
+===== pygit2
+
+(((Python)))
+The bindings for Libgit2 in Python are called Pygit2, and can be found at https://www.pygit2.org[^].
+Our example program:
+
+[source,python]
+
+
+
+
pygit2.Repository("/path/to/repo") # open repository
+ .head # get the current branch
+ .peel(pygit2.Commit) # walk down to the commit
+ .message # read the message
+
+
+
+
==== Further Reading
+
+Of course, a full treatment of Libgit2's capabilities is outside the scope of this book.
+If you want more information on Libgit2 itself, there's API documentation at https://libgit2.github.com/libgit2[^], and a set of guides at https://libgit2.github.com/docs[^].
+For the other bindings, check the bundled README and tests; there are often small tutorials and pointers to further reading there.
+
+
+=== JGit
+
+(((jgit)))(((Java)))
+If you want to use Git from within a Java program, there is a fully featured Git library called JGit.
+JGit is a relatively full-featured implementation of Git written natively in Java, and is widely used in the Java community.
+The JGit project is under the Eclipse umbrella, and its home can be found at https://projects.eclipse.org/projects/technology.jgit[^].
+
+==== Getting Set Up
+
+There are a number of ways to connect your project with JGit and start writing code against it.
+Probably the easiest is to use Maven – the integration is accomplished by adding the following snippet to the `<dependencies>` tag in your `pom.xml` file:
+
+[source,xml]
+
+
+
+
<dependency>
+ <groupId>org.eclipse.jgit</groupId>
+ <artifactId>org.eclipse.jgit</artifactId>
+ <version>3.5.0.201409260305-r</version>
+</dependency>
+
+
+
+
The `version` will most likely have advanced by the time you read this; check https://mvnrepository.com/artifact/org.eclipse.jgit/org.eclipse.jgit[^] for updated repository information.
+Once this step is done, Maven will automatically acquire and use the JGit libraries that you'll need.
+
+If you would rather manage the binary dependencies yourself, pre-built JGit binaries are available from https://projects.eclipse.org/projects/technology.jgit/downloads[^].
+You can build them into your project by running a command like this:
+
+[source,console]
+
+
+
+
javac -cp .:org.eclipse.jgit-3.5.0.201409260305-r.jar App.java
+java -cp .:org.eclipse.jgit-3.5.0.201409260305-r.jar App
+
+
+
+
==== Plumbing
+
+JGit has two basic levels of API: plumbing and porcelain.
+The terminology for these comes from Git itself, and JGit is divided into roughly the same kinds of areas: porcelain APIs are a friendly front-end for common user-level actions (the sorts of things a normal user would use the Git command-line tool for), while the plumbing APIs are for interacting with low-level repository objects directly.
+
+The starting point for most JGit sessions is the `Repository` class, and the first thing you'll want to do is create an instance of it.
+For a filesystem-based repository (yes, JGit allows for other storage models), this is accomplished using `FileRepositoryBuilder`:
+
+[source,java]
+
+
+
+
Repository newlyCreatedRepo = FileRepositoryBuilder.create(
+ new File("/tmp/new_repo/.git"));
+newlyCreatedRepo.create();
+
+
+
Repository existingRepo = new FileRepositoryBuilder()
+ .setGitDir(new File("my_repo/.git"))
+ .build();
+
+
+
+
The builder has a fluent API for providing all the things it needs to find a Git repository, whether or not your program knows exactly where it's located.
+It can use environment variables (`.readEnvironment()`), start from a place in the working directory and search (`.setWorkTree(…).findGitDir()`), or just open a known `.git` directory as above.
+
+Once you have a `Repository` instance, you can do all sorts of things with it.
+Here's a quick sampling:
+
+[source,java]
+
+
+
+
Ref master = repo.getRef("master");
+
+
+
ObjectId masterTip = master.getObjectId();
+
+
+
ObjectId obj = repo.resolve("HEAD^{tree}");
+
+
+
ObjectLoader loader = repo.open(masterTip);
+loader.copyTo(System.out);
+
+
+
RefUpdate createBranch1 = repo.updateRef("refs/heads/branch1");
+createBranch1.setNewObjectId(masterTip);
+createBranch1.update();
+
+
+
RefUpdate deleteBranch1 = repo.updateRef("refs/heads/branch1");
+deleteBranch1.setForceUpdate(true);
+deleteBranch1.delete();
+
+
+
Config cfg = repo.getConfig();
+String name = cfg.getString("user", null, "name");
+
+
+
+
There's quite a bit going on here, so let's go through it one section at a time.
+
+The first line gets a pointer to the `master` reference.
+JGit automatically grabs the _actual_ `master` ref, which lives at `refs/heads/master`, and returns an object that lets you fetch information about the reference.
+You can get the name (`.getName()`), and either the target object of a direct reference (`.getObjectId()`) or the reference pointed to by a symbolic ref (`.getTarget()`).
+Ref objects are also used to represent tag refs and objects, so you can ask if the tag is "`peeled,`" meaning that it points to the final target of a (potentially long) string of tag objects.
+
+The second line gets the target of the `master` reference, which is returned as an ObjectId instance.
+ObjectId represents the SHA-1 hash of an object, which might or might not exist in Git's object database.
+The third line is similar, but shows how JGit handles the rev-parse syntax (for more on this, see <<_branch_references>>); you can pass any object specifier that Git understands, and JGit will return either a valid ObjectId for that object, or `null`.
+
+The next two lines show how to load the raw contents of an object.
+In this example, we call `ObjectLoader.copyTo()` to stream the contents of the object directly to stdout, but ObjectLoader also has methods to read the type and size of an object, as well as return it as a byte array.
+For large objects (where `.isLarge()` returns `true`), you can call `.openStream()` to get an InputStream-like object that can read the raw object data without pulling it all into memory at once.
+
+The next few lines show what it takes to create a new branch.
+We create a RefUpdate instance, configure some parameters, and call `.update()` to trigger the change.
+Directly following this is the code to delete that same branch.
+Note that `.setForceUpdate(true)` is required for this to work; otherwise the `.delete()` call will return `REJECTED`, and nothing will happen.
+
+The last example shows how to fetch the `user.name` value from the Git configuration files.
+This Config instance uses the repository we opened earlier for local configuration, but will automatically detect the global and system configuration files and read values from them as well.
+
+This is only a small sampling of the full plumbing API; there are many more methods and classes available.
+Also not shown here is the way JGit handles errors, which is through the use of exceptions.
+JGit APIs sometimes throw standard Java exceptions (such as `IOException`), but there are a host of JGit-specific exception types that are provided as well (such as `NoRemoteRepositoryException`, `CorruptObjectException`, and `NoMergeBaseException`).
+
+==== Porcelain
+
+The plumbing APIs are rather complete, but it can be cumbersome to string them together to achieve common goals, like adding a file to the index, or making a new commit.
+JGit provides a higher-level set of APIs to help out with this, and the entry point to these APIs is the `Git` class:
+
+[source,java]
+
+
+
+
Repository repo;
+Git git = new Git(repo);
+
+
+
+
The Git class has a nice set of high-level _builder_-style methods that can be used to construct some pretty complex behavior.
+Let's take a look at an example -- doing something like `git ls-remote`:
+
+[source,java]
+
+
+
+
CredentialsProvider cp = new UsernamePasswordCredentialsProvider("username", "p4ssw0rd");
+Collection<Ref> remoteRefs = git.lsRemote()
+ .setCredentialsProvider(cp)
+ .setRemote("origin")
+ .setTags(true)
+ .setHeads(false)
+ .call();
+for (Ref ref : remoteRefs) {
+ System.out.println(ref.getName() + " → " + ref.getObjectId().name());
+}
+
+
+
+
This is a common pattern with the Git class; the methods return a command object that lets you chain method calls to set parameters, which are executed when you call `.call()`.
+In this case, we're asking the `origin` remote for tags, but not heads.
+Also notice the use of a `CredentialsProvider` object for authentication.
+
+Many other commands are available through the Git class, including but not limited to `add`, `blame`, `commit`, `clean`, `push`, `rebase`, `revert`, and `reset`.
+
+==== Further Reading
+
+This is only a small sampling of JGit's full capabilities.
+If you're interested and want to learn more, here's where to look for information and inspiration:
+
+* The official JGit API documentation can be found at https://help.eclipse.org/latest/topic/org.eclipse.egit.doc/help/JGit/User_Guide/User-Guide.html[^].
+ These are standard Javadoc, so your favorite JVM IDE will be able to install them locally, as well.
+* The JGit Cookbook at https://github.com/centic9/jgit-cookbook[^] has many examples of how to do specific tasks with JGit.
+
+
+=== go-git
+
+(((go-git)))(((Go)))
+In case you want to integrate Git into a service written in Golang, there also is a pure Go library implementation.
+This implementation does not have any native dependencies and thus is not prone to manual memory management errors.
+It is also transparent for the standard Golang performance analysis tooling like CPU, Memory profilers, race detector, etc.
+
+go-git is focused on extensibility, compatibility and supports most of the plumbing APIs, which is documented at https://github.com/go-git/go-git/blob/master/COMPATIBILITY.md[^].
+
+Here is a basic example of using Go APIs:
+
+[source, go]
+
+
+
+
import "github.com/go-git/go-git/v5"
+
+
+
r, err := git.PlainClone("/tmp/foo", false, &git.CloneOptions{
+ URL: "https://github.com/go-git/go-git",
+ Progress: os.Stdout,
+})
+
+
+
+
As soon as you have a `Repository` instance, you can access information and perform mutations on it:
+
+[source, go]
+
+
+
+
+
commit, err := r.CommitObject(ref.Hash())
+
+
+
history, err := commit.History()
+
+
+
for _, c := range history {
+ fmt.Println(c)
+}
+
+
+
+
==== Advanced Functionality
+
+go-git has few notable advanced features, one of which is a pluggable storage system, which is similar to Libgit2 backends.
+The default implementation is in-memory storage, which is very fast.
+
+[source, go]
+
+
+
+
r, err := git.Clone(memory.NewStorage(), nil, &git.CloneOptions{
+ URL: "https://github.com/go-git/go-git",
+})
+
+
+
+
Pluggable storage provides many interesting options.
+For instance, https://github.com/go-git/go-git/tree/master/_examples/storage[^] allows you to store references, objects, and configuration in an Aerospike database.
+
+Another feature is a flexible filesystem abstraction.
+Using https://pkg.go.dev/github.com/go-git/go-billy/v5?tab=doc#Filesystem[^] it is easy to store all the files in different way i.e by packing all of them to a single archive on disk or by keeping them all in-memory.
+
+Another advanced use-case includes a fine-tunable HTTP client, such as the one found at https://github.com/go-git/go-git/blob/master/_examples/custom_http/main.go[^].
+
+[source, go]
+
+
+
+
customClient := &http.Client{
+ Transport: &http.Transport{ // accept any certificate (might be useful for testing)
+ TLSClientConfig: &tls.Config{InsecureSkipVerify: true},
+ },
+ Timeout: 15 * time.Second, // 15 second timeout
+ CheckRedirect: func(req *http.Request, via []*http.Request) error {
+ return http.ErrUseLastResponse // don’t follow redirect
+ },
+}
+
+
+
client.InstallProtocol("https", githttp.NewClient(customClient))
+
+
+
r, err := git.Clone(memory.NewStorage(), nil, &git.CloneOptions{URL: url})
+
+
+
+
==== Further Reading
+
+A full treatment of go-git's capabilities is outside the scope of this book.
+If you want more information on go-git, there's API documentation at https://pkg.go.dev/github.com/go-git/go-git/v5[^], and a set of usage examples at https://github.com/go-git/go-git/tree/master/_examples[^].
+
+
+=== Dulwich
+
+(((Dulwich)))(((Python)))
+There is also a pure-Python Git implementation - Dulwich.
+The project is hosted under https://www.dulwich.io/[^].
+It aims to provide an interface to Git repositories (both local and remote) that doesn't call out to Git directly but instead uses pure Python.
+It has an optional C extensions though, that significantly improve the performance.
+
+Dulwich follows Git design and separate two basic levels of API: plumbing and porcelain.
+
+Here is an example of using the lower level API to access the commit message of the last commit:
+
+[source, python]
+
+
+
+
from dulwich.repo import Repo
+r = Repo('.')
+r.head()
+# '57fbe010446356833a6ad1600059d80b1e731e15'
+
+
+
c = r[r.head()]
+c
+# <Commit 015fc1267258458901a94d228e39f0a378370466>
+
+
+
c.message
+# 'Add note about encoding.\n'
+
+
+
+
To print a commit log using high-level porcelain API, one can use:
+
+[source, python]
+
+
+
+
from dulwich import porcelain
+porcelain.log('.', max_entries=1)
+
+
+
#commit: 57fbe010446356833a6ad1600059d80b1e731e15
+#Author: Jelmer Vernooij <jelmer@jelmer.uk>
+#Date: Sat Apr 29 2017 23:57:34 +0000
+
+
+
+
==== Further Reading
+
+The API documentation, tutorial, and many examples of how to do specific tasks with Dulwich are available on the official website https://www.dulwich.io[^].
+
+
+
+[[C-git-commands]]
+[appendix]
+== Git Commands
+
+Throughout the book we have introduced dozens of Git commands and have tried hard to introduce them within something of a narrative, adding more commands to the story slowly.
+However, this leaves us with examples of usage of the commands somewhat scattered throughout the whole book.
+
+In this appendix, we'll go through all the Git commands we addressed throughout the book, grouped roughly by what they're used for.
+We'll talk about what each command very generally does and then point out where in the book you can find us having used it.
+
+[TIP]
+====
+You can abbreviate long options.
+For example, you can type in `git commit --a`, which acts as if you typed `git commit --amend`.
+This only works when the letters after `--` are unique for one option.
+Do use the full option when writing scripts.
+====
+
+=== Setup and Config
+
+There are two commands that are used quite a lot, from the first invocations of Git to common every day tweaking and referencing, the `config` and `help` commands.
+
+==== git config
+
+Git has a default way of doing hundreds of things.
+For a lot of these things, you can tell Git to default to doing them a different way, or set your preferences.
+This involves everything from telling Git what your name is to specific terminal color preferences or what editor you use.
+There are several files this command will read from and write to so you can set values globally or down to specific repositories.
+
+The `git config` command has been used in nearly every chapter of the book.
+
+In <<_first_time>> we used it to specify our name, email address and editor preference before we even got started using Git.
+
+In <<_git_aliases>> we showed how you could use it to create shorthand commands that expand to long option sequences so you don't have to type them every time.
+
+In <<_rebasing>> we used it to make `--rebase` the default when you run `git pull`.
+
+In <<_credential_caching>> we used it to set up a default store for your HTTP passwords.
+
+In <<_keyword_expansion>> we showed how to set up smudge and clean filters on content coming in and out of Git.
+
+Finally, basically the entirety of <<_git_config>> is dedicated to the command.
+
+[[ch_core_editor]]
+==== git config core.editor commands
+
+Accompanying the configuration instructions in <<_editor>>, many editors can be set as follows:
+
+.Exhaustive list of `core.editor` configuration commands
+[cols="1,2",options="header"]
+|==============================
+|Editor | Configuration command
+|Atom |`git config --global core.editor "atom --wait"`
+|BBEdit (macOS, with command line tools) |`git config --global core.editor "bbedit -w"`
+|Emacs |`git config --global core.editor emacs`
+|Gedit (Linux) |`git config --global core.editor "gedit --wait --new-window"`
+|Gvim (Windows 64-bit) |`git config --global core.editor "'C:\Program Files\Vim\vim72\gvim.exe' --nofork '%*'"` (Also see note below)
+|Helix |`git config --global core.editor "hx"`
+|Kate (Linux) |`git config --global core.editor "kate --block"`
+|nano |`git config --global core.editor "nano -w"`
+|Notepad (Windows 64-bit) |`git config core.editor notepad`
+|Notepad++ (Windows 64-bit) |`git config --global core.editor "'C:\Program Files\Notepad+\+\notepad++.exe' -multiInst -notabbar -nosession -noPlugin"` (Also see note below)
+|Scratch (Linux)|`git config --global core.editor "scratch-text-editor"`
+|Sublime Text (macOS) |`git config --global core.editor "/Applications/Sublime\ Text.app/Contents/SharedSupport/bin/subl --new-window --wait"`
+|Sublime Text (Windows 64-bit) |`git config --global core.editor "'C:\Program Files\Sublime Text 3\sublime_text.exe' -w"` (Also see note below)
+|TextEdit (macOS)|`git config --global core.editor "open --wait-apps --new -e"`
+|Textmate |`git config --global core.editor "mate -w"`
+|Textpad (Windows 64-bit) |`git config --global core.editor "'C:\Program Files\TextPad 5\TextPad.exe' -m"` (Also see note below)
+|UltraEdit (Windows 64-bit) | `git config --global core.editor Uedit32`
+|Vim |`git config --global core.editor "vim --nofork"`
+|Visual Studio Code |`git config --global core.editor "code --wait"`
+|VSCodium (Free/Libre Open Source Software Binaries of VSCode) | `git config --global core.editor "codium --wait"`
+|WordPad |`git config --global core.editor "'C:\Program Files\Windows NT\Accessories\wordpad.exe'"`
+|Xi | `git config --global core.editor "xi --wait"`
+|==============================
+
+[NOTE]
+====
+If you have a 32-bit editor on a Windows 64-bit system, the program will be installed in `C:\Program Files (x86)\` rather than `C:\Program Files\` as in the table above.
+====
+
+==== git help
+
+The `git help` command is used to show you all the documentation shipped with Git about any command.
+While we're giving a rough overview of most of the more popular ones in this appendix, for a full listing of all of the possible options and flags for every command, you can always run `git help <command>`.
+
+We introduced the `git help` command in <<_git_help>> and showed you how to use it to find more information about the `git shell` in <<_setting_up_server>>.
+
+=== Getting and Creating Projects
+
+There are two ways to get a Git repository.
+One is to copy it from an existing repository on the network or elsewhere and the other is to create a new one in an existing directory.
+
+==== git init
+
+To take a directory and turn it into a new Git repository so you can start version controlling it, you can simply run `git init`.
+
+We first introduce this in <<_getting_a_repo>>, where we show creating a brand new repository to start working with.
+
+We talk briefly about how you can change the default branch name from "`master`" in <<_remote_branches>>.
+
+We use this command to create an empty bare repository for a server in <<_bare_repo>>.
+
+Finally, we go through some of the details of what it actually does behind the scenes in <<_plumbing_porcelain>>.
+
+==== git clone
+
+The `git clone` command is actually something of a wrapper around several other commands.
+It creates a new directory, goes into it and runs `git init` to make it an empty Git repository, adds a remote (`git remote add`) to the URL that you pass it (by default named `origin`), runs a `git fetch` from that remote repository and then checks out the latest commit into your working directory with `git checkout`.
+
+The `git clone` command is used in dozens of places throughout the book, but we'll just list a few interesting places.
+
+It's basically introduced and explained in <<_git_cloning>>, where we go through a few examples.
+
+In <<_getting_git_on_a_server>> we look at using the `--bare` option to create a copy of a Git repository with no working directory.
+
+In <<_bundling>> we use it to unbundle a bundled Git repository.
+
+Finally, in <<_cloning_submodules>> we learn the `--recurse-submodules` option to make cloning a repository with submodules a little simpler.
+
+Though it's used in many other places through the book, these are the ones that are somewhat unique or where it is used in ways that are a little different.
+
+=== Basic Snapshotting
+
+For the basic workflow of staging content and committing it to your history, there are only a few basic commands.
+
+==== git add
+
+The `git add` command adds content from the working directory into the staging area (or "`index`") for the next commit.
+When the `git commit` command is run, by default it only looks at this staging area, so `git add` is used to craft what exactly you would like your next commit snapshot to look like.
+
+This command is an incredibly important command in Git and is mentioned or used dozens of times in this book.
+We'll quickly cover some of the unique uses that can be found.
+
+We first introduce and explain `git add` in detail in <<_tracking_files>>.
+
+We mention how to use it to resolve merge conflicts in <<_basic_merge_conflicts>>.
+
+We go over using it to interactively stage only specific parts of a modified file in <<_interactive_staging>>.
+
+Finally, we emulate it at a low level in <<_tree_objects>>, so you can get an idea of what it's doing behind the scenes.
+
+==== git status
+
+The `git status` command will show you the different states of files in your working directory and staging area.
+Which files are modified and unstaged and which are staged but not yet committed.
+In its normal form, it also will show you some basic hints on how to move files between these stages.
+
+We first cover `status` in <<_checking_status>>, both in its basic and simplified forms.
+While we use it throughout the book, pretty much everything you can do with the `git status` command is covered there.
+
+==== git diff
+
+The `git diff` command is used when you want to see differences between any two trees.
+This could be the difference between your working environment and your staging area (`git diff` by itself), between your staging area and your last commit (`git diff --staged`), or between two commits (`git diff master branchB`).
+
+We first look at the basic uses of `git diff` in <<_git_diff_staged>>, where we show how to see what changes are staged and which are not yet staged.
+
+We use it to look for possible whitespace issues before committing with the `--check` option in <<_commit_guidelines>>.
+
+We see how to check the differences between branches more effectively with the `git diff A...B` syntax in <<_what_is_introduced>>.
+
+We use it to filter out whitespace differences with `-b` and how to compare different stages of conflicted files with `--theirs`, `--ours` and `--base` in <<_advanced_merging>>.
+
+Finally, we use it to effectively compare submodule changes with `--submodule` in <<_starting_submodules>>.
+
+==== git difftool
+
+The `git difftool` command simply launches an external tool to show you the difference between two trees in case you want to use something other than the built in `git diff` command.
+
+We only briefly mention this in <<_git_diff_staged>>.
+
+==== git commit
+
+The `git commit` command takes all the file contents that have been staged with `git add` and records a new permanent snapshot in the database and then moves the branch pointer on the current branch up to it.
+
+We first cover the basics of committing in <<_committing_changes>>.
+There we also demonstrate how to use the `-a` flag to skip the `git add` step in daily workflows and how to use the `-m` flag to pass a commit message in on the command line instead of firing up an editor.
+
+In <<_undoing>> we cover using the `--amend` option to redo the most recent commit.
+
+In <<_git_branches_overview>>, we go into much more detail about what `git commit` does and why it does it like that.
+
+We looked at how to sign commits cryptographically with the `-S` flag in <<_signing_commits>>.
+
+Finally, we take a look at what the `git commit` command does in the background and how it's actually implemented in <<_git_commit_objects>>.
+
+==== git reset
+
+The `git reset` command is primarily used to undo things, as you can possibly tell by the verb.
+It moves around the `HEAD` pointer and optionally changes the `index` or staging area and can also optionally change the working directory if you use `--hard`.
+This final option makes it possible for this command to lose your work if used incorrectly, so make sure you understand it before using it.
+
+We first effectively cover the simplest use of `git reset` in <<_unstaging>>, where we use it to unstage a file we had run `git add` on.
+
+We then cover it in quite some detail in <<_git_reset>>, which is entirely devoted to explaining this command.
+
+We use `git reset --hard` to abort a merge in <<_abort_merge>>, where we also use `git merge --abort`, which is a bit of a wrapper for the `git reset` command.
+
+==== git rm
+
+The `git rm` command is used to remove files from the staging area and working directory for Git.
+It is similar to `git add` in that it stages a removal of a file for the next commit.
+
+We cover the `git rm` command in some detail in <<_removing_files>>, including recursively removing files and only removing files from the staging area but leaving them in the working directory with `--cached`.
+
+The only other differing use of `git rm` in the book is in <<_removing_objects>> where we briefly use and explain the `--ignore-unmatch` when running `git filter-branch`, which simply makes it not error out when the file we are trying to remove doesn't exist.
+This can be useful for scripting purposes.
+
+==== git mv
+
+The `git mv` command is a thin convenience command to move a file and then run `git add` on the new file and `git rm` on the old file.
+
+We only briefly mention this command in <<_git_mv>>.
+
+==== git clean
+
+The `git clean` command is used to remove unwanted files from your working directory.
+This could include removing temporary build artifacts or merge conflict files.
+
+We cover many of the options and scenarios in which you might used the clean command in <<_git_clean>>.
+
+=== Branching and Merging
+
+There are just a handful of commands that implement most of the branching and merging functionality in Git.
+
+==== git branch
+
+The `git branch` command is actually something of a branch management tool.
+It can list the branches you have, create a new branch, delete branches and rename branches.
+
+Most of <<ch03-git-branching>> is dedicated to the `branch` command and it's used throughout the entire chapter.
+We first introduce it in <<_create_new_branch>> and we go through most of its other features (listing and deleting) in <<_branch_management>>.
+
+In <<_tracking_branches>> we use the `git branch -u` option to set up a tracking branch.
+
+Finally, we go through some of what it does in the background in <<_git_refs>>.
+
+==== git checkout
+
+The `git checkout` command is used to switch branches and check content out into your working directory.
+
+We first encounter the command in <<_switching_branches>> along with the `git branch` command.
+
+We see how to use it to start tracking branches with the `--track` flag in <<_tracking_branches>>.
+
+We use it to reintroduce file conflicts with `--conflict=diff3` in <<_checking_out_conflicts>>.
+
+We go into closer detail on its relationship with `git reset` in <<_git_reset>>.
+
+Finally, we go into some implementation detail in <<ref_the_ref>>.
+
+==== git merge
+
+The `git merge` tool is used to merge one or more branches into the branch you have checked out.
+It will then advance the current branch to the result of the merge.
+
+The `git merge` command was first introduced in <<_basic_branching>>.
+Though it is used in various places in the book, there are very few variations of the `merge` command -- generally just `git merge <branch>` with the name of the single branch you want to merge in.
+
+We covered how to do a squashed merge (where Git merges the work but pretends like it's just a new commit without recording the history of the branch you're merging in) at the very end of <<_public_project>>.
+
+We went over a lot about the merge process and command, including the `-Xignore-space-change` command and the `--abort` flag to abort a problem merge in <<_advanced_merging>>.
+
+We learned how to verify signatures before merging if your project is using GPG signing in <<_signing_commits>>.
+
+Finally, we learned about Subtree merging in <<_subtree_merge>>.
+
+==== git mergetool
+
+The `git mergetool` command simply launches an external merge helper in case you have issues with a merge in Git.
+
+We mention it quickly in <<_basic_merge_conflicts>> and go into detail on how to implement your own external merge tool in <<_external_merge_tools>>.
+
+==== git log
+
+The `git log` command is used to show the reachable recorded history of a project from the most recent commit snapshot backwards.
+By default it will only show the history of the branch you're currently on, but can be given different or even multiple heads or branches from which to traverse.
+It is also often used to show differences between two or more branches at the commit level.
+
+This command is used in nearly every chapter of the book to demonstrate the history of a project.
+
+We introduce the command and cover it in some depth in <<_viewing_history>>.
+There we look at the `-p` and `--stat` option to get an idea of what was introduced in each commit and the `--pretty` and `--oneline` options to view the history more concisely, along with some simple date and author filtering options.
+
+In <<_create_new_branch>> we use it with the `--decorate` option to easily visualize where our branch pointers are located and we also use the `--graph` option to see what divergent histories look like.
+
+In <<_private_team>> and <<_commit_ranges>> we cover the `branchA..branchB` syntax to use the `git log` command to see what commits are unique to a branch relative to another branch.
+In <<_commit_ranges>> we go through this fairly extensively.
+
+In <<_merge_log>> and <<_triple_dot>> we cover using the `branchA...branchB` format and the `--left-right` syntax to see what is in one branch or the other but not in both.
+In <<_merge_log>> we also look at how to use the `--merge` option to help with merge conflict debugging as well as using the `--cc` option to look at merge commit conflicts in your history.
+
+In <<_git_reflog>> we use the `-g` option to view the Git reflog through this tool instead of doing branch traversal.
+
+In <<_searching>> we look at using the `-S` and `-L` options to do fairly sophisticated searches for something that happened historically in the code such as seeing the history of a function.
+
+In <<_signing_commits>> we see how to use `--show-signature` to add a validation string to each commit in the `git log` output based on if it was validly signed or not.
+
+==== git stash
+
+The `git stash` command is used to temporarily store uncommitted work in order to clean out your working directory without having to commit unfinished work on a branch.
+
+This is basically entirely covered in <<_git_stashing>>.
+
+==== git tag
+
+The `git tag` command is used to give a permanent bookmark to a specific point in the code history.
+Generally this is used for things like releases.
+
+This command is introduced and covered in detail in <<_git_tagging>> and we use it in practice in <<_tagging_releases>>.
+
+We also cover how to create a GPG signed tag with the `-s` flag and verify one with the `-v` flag in <<_signing>>.
+
+=== Sharing and Updating Projects
+
+There are not very many commands in Git that access the network, nearly all of the commands operate on the local database.
+When you are ready to share your work or pull changes from elsewhere, there are a handful of commands that deal with remote repositories.
+
+==== git fetch
+
+The `git fetch` command communicates with a remote repository and fetches down all the information that is in that repository that is not in your current one and stores it in your local database.
+
+We first look at this command in <<_fetching_and_pulling>> and we continue to see examples of its use in <<_remote_branches>>.
+
+We also use it in several of the examples in <<_contributing_project>>.
+
+We use it to fetch a single specific reference that is outside of the default space in <<_pr_refs>> and we see how to fetch from a bundle in <<_bundling>>.
+
+We set up highly custom refspecs in order to make `git fetch` do something a little different than the default in <<_refspec>>.
+
+==== git pull
+
+The `git pull` command is basically a combination of the `git fetch` and `git merge` commands, where Git will fetch from the remote you specify and then immediately try to merge it into the branch you're on.
+
+We introduce it quickly in <<_fetching_and_pulling>> and show how to see what it will merge if you run it in <<_inspecting_remote>>.
+
+We also see how to use it to help with rebasing difficulties in <<_rebase_rebase>>.
+
+We show how to use it with a URL to pull in changes in a one-off fashion in <<_checking_out_remotes>>.
+
+Finally, we very quickly mention that you can use the `--verify-signatures` option to it in order to verify that commits you are pulling have been GPG signed in <<_signing_commits>>.
+
+==== git push
+
+The `git push` command is used to communicate with another repository, calculate what your local database has that the remote one does not, and then pushes the difference into the other repository.
+It requires write access to the other repository and so normally is authenticated somehow.
+
+We first look at the `git push` command in <<_pushing_remotes>>.
+Here we cover the basics of pushing a branch to a remote repository.
+In <<_pushing_branches>> we go a little deeper into pushing specific branches and in <<_tracking_branches>> we see how to set up tracking branches to automatically push to.
+In <<_delete_branches>> we use the `--delete` flag to delete a branch on the server with `git push`.
+
+Throughout <<_contributing_project>> we see several examples of using `git push` to share work on branches through multiple remotes.
+
+We see how to use it to share tags that you have made with the `--tags` option in <<_sharing_tags>>.
+
+In <<_publishing_submodules>> we use the `--recurse-submodules` option to check that all of our submodules work has been published before pushing the superproject, which can be really helpful when using submodules.
+
+In <<_other_client_hooks>> we talk briefly about the `pre-push` hook, which is a script we can setup to run before a push completes to verify that it should be allowed to push.
+
+Finally, in <<_pushing_refspecs>> we look at pushing with a full refspec instead of the general shortcuts that are normally used.
+This can help you be very specific about what work you wish to share.
+
+==== git remote
+
+The `git remote` command is a management tool for your record of remote repositories.
+It allows you to save long URLs as short handles, such as "`origin`" so you don't have to type them out all the time.
+You can have several of these and the `git remote` command is used to add, change and delete them.
+
+This command is covered in detail in <<_remote_repos>>, including listing, adding, removing and renaming them.
+
+It is used in nearly every subsequent chapter in the book too, but always in the standard `git remote add <name> <url>` format.
+
+==== git archive
+
+The `git archive` command is used to create an archive file of a specific snapshot of the project.
+
+We use `git archive` to create a tarball of a project for sharing in <<_preparing_release>>.
+
+==== git submodule
+
+The `git submodule` command is used to manage external repositories within a normal repositories.
+This could be for libraries or other types of shared resources.
+The `submodule` command has several sub-commands (`add`, `update`, `sync`, etc) for managing these resources.
+
+This command is only mentioned and entirely covered in <<_git_submodules>>.
+
+=== Inspection and Comparison
+
+==== git show
+
+The `git show` command can show a Git object in a simple and human readable way.
+Normally you would use this to show the information about a tag or a commit.
+
+We first use it to show annotated tag information in <<_annotated_tags>>.
+
+Later we use it quite a bit in <<_revision_selection>> to show the commits that our various revision selections resolve to.
+
+One of the more interesting things we do with `git show` is in <<_manual_remerge>> to extract specific file contents of various stages during a merge conflict.
+
+==== git shortlog
+
+The `git shortlog` command is used to summarize the output of `git log`.
+It will take many of the same options that the `git log` command will but instead of listing out all of the commits it will present a summary of the commits grouped by author.
+
+We showed how to use it to create a nice changelog in <<_the_shortlog>>.
+
+==== git describe
+
+The `git describe` command is used to take anything that resolves to a commit and produces a string that is somewhat human-readable and will not change.
+It's a way to get a description of a commit that is as unambiguous as a commit SHA-1 but more understandable.
+
+We use `git describe` in <<_build_number>> and <<_preparing_release>> to get a string to name our release file after.
+
+=== Debugging
+
+Git has a couple of commands that are used to help debug an issue in your code.
+This ranges from figuring out where something was introduced to figuring out who introduced it.
+
+==== git bisect
+
+The `git bisect` tool is an incredibly helpful debugging tool used to find which specific commit was the first one to introduce a bug or problem by doing an automatic binary search.
+
+It is fully covered in <<_binary_search>> and is only mentioned in that section.
+
+==== git blame
+
+The `git blame` command annotates the lines of any file with which commit was the last one to introduce a change to each line of the file and what person authored that commit.
+This is helpful in order to find the person to ask for more information about a specific section of your code.
+
+It is covered in <<_file_annotation>> and is only mentioned in that section.
+
+==== git grep
+
+The `git grep` command can help you find any string or regular expression in any of the files in your source code, even older versions of your project.
+
+It is covered in <<_git_grep>> and is only mentioned in that section.
+
+=== Patching
+
+A few commands in Git are centered around the concept of thinking of commits in terms of the changes they introduce, as though the commit series is a series of patches.
+These commands help you manage your branches in this manner.
+
+==== git cherry-pick
+
+The `git cherry-pick` command is used to take the change introduced in a single Git commit and try to re-introduce it as a new commit on the branch you're currently on.
+This can be useful to only take one or two commits from a branch individually rather than merging in the branch which takes all the changes.
+
+Cherry picking is described and demonstrated in <<_rebase_cherry_pick>>.
+
+==== git rebase
+
+The `git rebase` command is basically an automated `cherry-pick`.
+It determines a series of commits and then cherry-picks them one by one in the same order somewhere else.
+
+Rebasing is covered in detail in <<_rebasing>>, including covering the collaborative issues involved with rebasing branches that are already public.
+
+We use it in practice during an example of splitting your history into two separate repositories in <<_replace>>, using the `--onto` flag as well.
+
+We go through running into a merge conflict during rebasing in <<ref_rerere>>.
+
+We also use it in an interactive scripting mode with the `-i` option in <<_changing_multiple>>.
+
+==== git revert
+
+The `git revert` command is essentially a reverse `git cherry-pick`.
+It creates a new commit that applies the exact opposite of the change introduced in the commit you're targeting, essentially undoing or reverting it.
+
+We use this in <<_reverse_commit>> to undo a merge commit.
+
+=== Email
+
+Many Git projects, including Git itself, are entirely maintained over mailing lists.
+Git has a number of tools built into it that help make this process easier, from generating patches you can easily email to applying those patches from an email box.
+
+==== git apply
+
+The `git apply` command applies a patch created with the `git diff` or even GNU diff command.
+It is similar to what the `patch` command might do with a few small differences.
+
+We demonstrate using it and the circumstances in which you might do so in <<_patches_from_email>>.
+
+==== git am
+
+The `git am` command is used to apply patches from an email inbox, specifically one that is mbox formatted.
+This is useful for receiving patches over email and applying them to your project easily.
+
+We covered usage and workflow around `git am` in <<_git_am>> including using the `--resolved`, `-i` and `-3` options.
+
+There are also a number of hooks you can use to help with the workflow around `git am` and they are all covered in <<_email_hooks>>.
+
+We also use it to apply patch formatted GitHub Pull Request changes in <<_email_notifications>>.
+
+==== git format-patch
+
+The `git format-patch` command is used to generate a series of patches in mbox format that you can use to send to a mailing list properly formatted.
+
+We go through an example of contributing to a project using the `git format-patch` tool in <<_project_over_email>>.
+
+==== git imap-send
+
+The `git imap-send` command uploads a mailbox generated with `git format-patch` into an IMAP drafts folder.
+
+We go through an example of contributing to a project by sending patches with the `git imap-send` tool in <<_project_over_email>>.
+
+==== git send-email
+
+The `git send-email` command is used to send patches that are generated with `git format-patch` over email.
+
+We go through an example of contributing to a project by sending patches with the `git send-email` tool in <<_project_over_email>>.
+
+==== git request-pull
+
+The `git request-pull` command is simply used to generate an example message body to email to someone.
+If you have a branch on a public server and want to let someone know how to integrate those changes without sending the patches over email, you can run this command and send the output to the person you want to pull the changes in.
+
+We demonstrate how to use `git request-pull` to generate a pull message in <<_public_project>>.
+
+=== External Systems
+
+Git comes with a few commands to integrate with other version control systems.
+
+==== git svn
+
+The `git svn` command is used to communicate with the Subversion version control system as a client.
+This means you can use Git to checkout from and commit to a Subversion server.
+
+This command is covered in depth in <<_git_svn>>.
+
+==== git fast-import
+
+For other version control systems or importing from nearly any format, you can use `git fast-import` to quickly map the other format to something Git can easily record.
+
+This command is covered in depth in <<_custom_importer>>.
+
+=== Administration
+
+If you're administering a Git repository or need to fix something in a big way, Git provides a number of administrative commands to help you out.
+
+==== git gc
+
+The `git gc` command runs "`garbage collection`" on your repository, removing unnecessary files in your database and packing up the remaining files into a more efficient format.
+
+This command normally runs in the background for you, though you can manually run it if you wish.
+We go over some examples of this in <<_git_gc>>.
+
+==== git fsck
+
+The `git fsck` command is used to check the internal database for problems or inconsistencies.
+
+We only quickly use this once in <<_data_recovery>> to search for dangling objects.
+
+==== git reflog
+
+The `git reflog` command goes through a log of where all the heads of your branches have been as you work to find commits you may have lost through rewriting histories.
+
+We cover this command mainly in <<_git_reflog>>, where we show normal usage to and how to use `git log -g` to view the same information with `git log` output.
+
+We also go through a practical example of recovering such a lost branch in <<_data_recovery>>.
+
+==== git filter-branch
+
+The `git filter-branch` command is used to rewrite loads of commits according to certain patterns, like removing a file everywhere or filtering the entire repository down to a single subdirectory for extracting a project.
+
+In <<_removing_file_every_commit>> we explain the command and explore several different options such as `--commit-filter`, `--subdirectory-filter` and `--tree-filter`.
+
+In <<_git_p4>> we use it to fix up imported external repositories.
+
+=== Plumbing Commands
+
+There were also quite a number of lower level plumbing commands that we encountered in the book.
+
+The first one we encounter is `ls-remote` in <<_pr_refs>> which we use to look at the raw references on the server.
+
+We use `ls-files` in <<_manual_remerge>>, <<ref_rerere>> and <<_the_index>> to take a more raw look at what your staging area looks like.
+
+We also mention `rev-parse` in <<_branch_references>> to take just about any string and turn it into an object SHA-1.
+
+However, most of the low level plumbing commands we cover are in <<ch10-git-internals>>, which is more or less what the chapter is focused on.
+We tried to avoid use of them throughout most of the rest of the book.
+
+
+
Oordragprotokolle (Transfer Protocols)
+
+
Git kan data tussen twee bewaarplekke op twee hoofmaniere oordra: die “dom” (dumb) protokol en die “slim” (smart) protokol.
+Hierdie afdeling sal vinnig dek hoe hierdie twee hoofprotokolle werk.
+
+
Die Dom Protokol (The Dumb Protocol)
+
+
As jy 'n bewaarplek opstel om leesalleen (read-only) oor HTTP bedien te word, is die dom protokol waarskynlik wat gebruik sal word.
+Hierdie protokol word “dom” genoem omdat dit geen Git-spesifieke kode aan die bedienerkant tydens die vervoerproses vereis nie; die aftrekproses (fetch process) is 'n reeks HTTP GET-versoeke, waar die kliënt die uitleg van die Git-bewaarplek op die bediener kan aanneem.
+
+
+
+
+|
+ Note
+ |
+
+
+ Die dom protokol word deesdae redelik selde gebruik.
+Dit is moeilik om te beveilig of privaat te maak, so die meeste Git-gashere (beide wolk-gebaseerde en op-perseel) sal weier om dit te gebruik.
+Dit word oor die algemeen aangeraai om die slim protokol te gebruik, wat ons 'n entjie verder bespreek.
+ |
+
+
+
+
+
Kom ons volg die http-fetch-proses vir die simplegit-biblioteek:
+
+
+
+
$ git clone http://server/simplegit-progit.git
+
+
+
+
Die eerste ding wat hierdie opdrag doen, is om die info/refs-lêer af te trek.
+Hierdie lêer word deur die update-server-info-opdrag geskryf, wat is hoekom jy dit as 'n post-receive-haak moet aktiveer sodat die HTTP-vervoer behoorlik kan werk:
+
+
+
+
=> GET info/refs
+ca82a6dff817ec66f44342007202690a93763949 refs/heads/master
+
+
+
+
Nou het jy 'n lys van die afgeleë verwysings (remote references) en SHA-1’s.
+Vervolgens soek jy wat die HEAD-verwysing is sodat jy weet wat om uit te trek (check out) wanneer jy klaar is:
+
+
+
+
=> GET HEAD
+ref: refs/heads/master
+
+
+
+
Jy moet die master-tak uittrek wanneer jy die proses voltooi het.
+Op hierdie punt is jy gereed om die stap-proses (walking process) te begin.
+Omdat jou beginpunt die ca82a6 vasleggingsobjek is wat jy in die info/refs-lêer gesien het, begin jy deur dit af te haal (fetch):
+
+
+
+
=> GET objects/ca/82a6dff817ec66f44342007202690a93763949
+(179 bytes of binary data)
+
+
+
+
Jy kry 'n objek terug – daardie objek is in los formaat op die bediener, en jy het dit oor 'n statiese HTTP GET-versoek afgehaal.
+Jy kan dit met zlib ontsaampers (uncompress), die kopstuk afstroop en na die vasleggingsinhoud kyk:
+
+
+
+
$ git cat-file -p ca82a6dff817ec66f44342007202690a93763949
+tree cfda3bf379e4f8dba8717dee55aab78aef7f4daf
+parent 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
+author Scott Chacon <schacon@gmail.com> 1205815931 -0700
+committer Scott Chacon <schacon@gmail.com> 1240030591 -0700
+
+Change version number
+
+
+
+
Vervolgens het jy nog twee objekte om te herwin – cfda3b, wat die boom van inhoud is waarna die vaslegging wat ons pas herwin het wys; en 085bb3, wat die ouer-vaslegging is:
+
+
+
+
=> GET objects/08/5bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
+(179 bytes of data)
+
+
+
+
Dit gee jou jou volgende vasleggingsobjek.
+Gryp die boom-objek:
+
+
+
+
=> GET objects/cf/da3bf379e4f8dba8717dee55aab78aef7f4daf
+(404 - Not Found)
+
+
+
+
Oeps – dit lyk of daardie boom-objek nie in los formaat op die bediener is nie, so jy kry 'n 404-reaksie terug.
+Daar is 'n paar redes hiervoor – die objek kan in 'n alternatiewe bewaarplek wees, of dit kan in 'n paklêer (packfile) in hierdie bewaarplek wees.
+Git kyk eers vir enige gelyste alternatiewe:
+
+
+
+
=> GET objects/info/http-alternates
+(empty file)
+
+
+
+
As dit terugkom met 'n lys van alternatiewe URL’e, kyk Git vir los lêers en paklêers daar – dit is 'n oulike meganisme vir projekte wat vurke (forks) van mekaar is om objekte op die skyf te deel.
+Aangesien geen alternatiewe in hierdie geval gelys is nie, moet jou objek egter in 'n paklêer wees.
+Om te sien watter paklêers op hierdie bediener beskikbaar is, moet jy die objects/info/packs-lêer kry, wat 'n lys daarvan bevat (ook gegenereer deur update-server-info):
+
+
+
+
=> GET objects/info/packs
+P pack-816a9b2334da9953e530f27bcac22082a9f5b835.pack
+
+
+
+
Daar is net een paklêer op die bediener, so jou objek is natuurlik daarin, maar jy sal die indekslêer nagaan om seker te maak.
+Dit is ook nuttig as jy veelvuldige paklêers op die bediener het, sodat jy kan sien watter paklêer die objek bevat wat jy benodig:
+
+
+
+
=> GET objects/pack/pack-816a9b2334da9953e530f27bcac22082a9f5b835.idx
+(4k of binary data)
+
+
+
+
Noudat jy die paklêer-indeks het, kan jy sien of jou objek daarin is – want die indeks lys die SHA-1’s van die objekte wat in die paklêer vervat is asook die beginpunte (offsets) na daardie objekte.
+Jou objek is daar, so gaan voort en kry die hele paklêer:
+
+
+
+
=> GET objects/pack/pack-816a9b2334da9953e530f27bcac22082a9f5b835.pack
+(13k of binary data)
+
+
+
+
Jy het jou boom-objek, so jy gaan voort om deur jou vasleggings te stap.
+Hulle is almal ook binne die paklêer wat jy pas afgelaai het, so jy hoef nie nog versoeke na jou bediener te rig nie.
+Git trek 'n werkkopie uit van die master-tak waarna gewys is deur die HEAD-verwysing wat jy aan die begin afgelaai het.
+
+
+
Die Slim Protokol (The Smart Protocol)
+
+
Die dom protokol is eenvoudig maar 'n bietjie ondoeltreffend, en dit kan nie die skryf van data van die kliënt na die bediener hanteer nie.
+Die slim protokol is 'n meer algemene metode om data oor te dra, maar dit vereis 'n proses aan die afgeleë kant wat intelligent is oor Git – dit kan plaaslike data lees, uitvind wat die kliënt het en benodig, en 'n pasgemaakte paklêer daarvoor genereer.
+Daar is twee stelle prosesse om data oor te dra: 'n paar vir die oplaai van data en 'n paar vir die aflaai van data.
+
+
+
Oplaai van Data (Uploading Data)
+
+
+Om data na 'n afgeleë proses op te laai, gebruik Git die send-pack en receive-pack prosesse.
+Die send-pack proses loop op die kliënt en koppel aan 'n receive-pack proses aan die afgeleë kant.
+
+
+
SSH
+
+
Sê byvoorbeeld jy voer git push origin master in jou projek uit, en origin word gedefinieer as 'n URL wat die SSH-protokol gebruik.
+Git skakel die send-pack proses aan, wat 'n verbinding oor SSH na jou bediener inisieer.
+Dit probeer 'n opdrag op die afgeleë bediener uitvoer via 'n SSH-roep wat min of meer so lyk:
+
+
+
+
$ ssh -x git@server "git-receive-pack 'simplegit-progit.git'"
+00a5ca82a6dff817ec66f4437202690a93763949 refs/heads/master□report-status \
+ delete-refs side-band-64k quiet ofs-delta \
+ agent=git/2:2.1.1+github-607-gfba4028 delete-refs
+0000
+
+
+
+
Die git-receive-pack-opdrag reageer onmiddellik met een reël vir elke verwysing wat dit tans het – in hierdie geval, net die master-tak en sy SHA-1.
+Die eerste reël bevat ook 'n lys van die bediener se vermoëns (hier, report-status, delete-refs, en 'n paar ander, insluitend die kliënt-identifiseerder).
+
+
+
Die data word in stukke (chunks) oorgedra.
+Elke stuk begin met 'n 4-karakter heksadesimale waarde wat spesifiseer hoe lank die stuk is (insluitend die 4 grepe van die lengte self).
+Stukke bevat gewoonlik 'n enkele reël data en 'n agtereenvolgende reëltoevoer (linefeed).
+Jou eerste stuk begin met 00a5, wat heksadesimaal vir 165 is, wat beteken dat die stuk 165 grepe lank is.
+Die volgende stuk is 0000, wat beteken die bediener is klaar met sy verwysingslys.
+
+
+
Noudat dit die bediener se toestand ken, bepaal jou send-pack-proses watter vasleggings dit het wat die bediener nie het nie.
+Vir elke verwysing wat hierdie push sal opdateer, vertel die send-pack-proses die receive-pack-proses daardie inligting.
+As jy byvoorbeeld die master-tak opdateer en 'n experiment-tak byvoeg, kan die send-pack-reaksie min of meer so lyk:
+
+
+
+
0076ca82a6dff817ec66f44342007202690a93763949 15027957951b64cf874c3557a0f3547bd83b3ff6 \
+ refs/heads/master report-status
+006c0000000000000000000000000000000000000000 cdfdb42577e2506715f8cfeacdbabc092bf63e8d \
+ refs/heads/experiment
+0000
+
+
+
+
Git stuur 'n reël vir elke verwysing wat jy opdateer met die reël se lengte, die ou SHA-1, die nuwe SHA-1, en die verwysing wat opgedateer word.
+Die eerste reël het ook die kliënt se vermoëns.
+Die SHA-1 waarde van slegs '0’e beteken dat niks voorheen daar was nie – omdat jy die experiment-verwysing byvoeg.
+As jy 'n verwysing sou uitvee, sou jy die teenoorgestelde sien: slegs '0’e aan die regterkant.
+
+
+
Vervolgens stuur die kliënt 'n paklêer van al die objekte wat die bediener nog nie het nie.
+Laastens reageer die bediener met 'n aanduiding van sukses (of mislukking):
+
+
+
+
+
HTTP(S)
+
+
Hierdie proses is grootliks dieselfde oor HTTP, alhoewel die handdruk (handshaking) 'n bietjie anders is.
+Die verbinding word met hierdie versoek begin:
+
+
+
+
=> GET http://server/simplegit-progit.git/info/refs?service=git-receive-pack
+001f# service=git-receive-pack
+00ab6c5f0e45abd7832bf23074a333f739977c9e8188 refs/heads/master□report-status \
+ delete-refs side-band-64k quiet ofs-delta \
+ agent=git/2:2.1.1~vmg-bitmaps-bugaloo-608-g116744e
+0000
+
+
+
+
Dit is die einde van die eerste kliënt-bediener-uitruiling.
+Die kliënt rig dan nog 'n versoek, hierdie keer 'n POST, met die data wat send-pack verskaf.
+
+
+
+
=> POST http://server/simplegit-progit.git/git-receive-pack
+
+
+
+
Die POST-versoek sluit die send-pack-afvoer en die paklêer as sy vrag (payload) in.
+Die bediener dui dan sukses of mislukking met sy HTTP-reaksie aan.
+
+
+
Hou in gedagte die HTTP-protokol kan hierdie data verder toedraai binne 'n gefragmenteerde oordragkodering (chunked transfer encoding).
+
+
+
+
+
Aflaai van Data (Downloading Data)
+
+
+Wanneer jy data aflaai, is die fetch-pack en upload-pack prosesse betrokke.
+Die kliënt inisieer 'n fetch-pack proses wat aan 'n upload-pack proses aan die afgeleë kant koppel om te onderhandel watter data oorgedra sal word.
+
+
+
SSH
+
+
As jy die fetch oor SSH doen, loop fetch-pack min of meer soos volg:
+
+
+
+
$ ssh -x git@server "git-upload-pack 'simplegit-progit.git'"
+
+
+
+
Nadat fetch-pack gekoppel het, stuur upload-pack iets soos dit terug:
+
+
+
+
00dfca82a6dff817ec66f44342007202690a93763949 HEAD□multi_ack thin-pack \
+ side-band side-band-64k ofs-delta shallow no-progress include-tag \
+ multi_ack_detailed symref=HEAD:refs/heads/master \
+ agent=git/2:2.1.1+github-607-gfba4028
+003fe2409a098dc3e53539a9028a94b6224db9d6a6b6 refs/heads/master
+0000
+
+
+
+
Dit is baie soortgelyk aan waarmee receive-pack reageer, maar die vermoëns verskil.
+Daarbenewens stuur dit terug waarna HEAD wys (symref=HEAD:refs/heads/master) sodat die kliënt weet wat om uit te trek as dit 'n kloon is.
+
+
+
Op hierdie stadium kyk die fetch-pack-proses na watter objekte dit het en reageer met die objekte wat dit benodig deur “want” te stuur en dan die SHA-1 wat dit wil hê.
+Dit stuur al die objekte wat dit reeds het met “have” en dan die SHA-1.
+Aan die einde van hierdie lys, skryf dit “done” om die upload-pack-proses te inisieer om die paklêer te begin stuur van die data wat dit benodig:
+
+
+
+
003cwant ca82a6dff817ec66f44342007202690a93763949 ofs-delta
+0032have 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
+0009done
+0000
+
+
+
+
+
HTTP(S)
+
+
Die handdruk vir 'n fetch-operasie neem twee HTTP-versoeke.
+Die eerste is 'n GET na dieselfde eindpunt wat in die dom protokol gebruik word:
+
+
+
+
=> GET $GIT_URL/info/refs?service=git-upload-pack
+001e# service=git-upload-pack
+00e7ca82a6dff817ec66f44342007202690a93763949 HEAD□multi_ack thin-pack \
+ side-band side-band-64k ofs-delta shallow no-progress include-tag \
+ multi_ack_detailed no-done symref=HEAD:refs/heads/master \
+ agent=git/2:2.1.1+github-607-gfba4028
+003fca82a6dff817ec66f44342007202690a93763949 refs/heads/master
+0000
+
+
+
+
Dit is baie soortgelyk aan die oproep van git-upload-pack oor 'n SSH-verbinding, maar die tweede uitruiling word as 'n aparte versoek uitgevoer:
+
+
+
+
=> POST $GIT_URL/git-upload-pack HTTP/1.0
+0032want 0a53e9ddeaddad63ad106860237bbf53411d11a7
+0032have 441b40d833fdfa93eb2908e52742248faf0ee993
+0000
+
+
+
+
Weereens, dit is dieselfde formaat as hierbo.
+Die antwoord op hierdie versoek dui op sukses of mislukking, en sluit die paklêer in.
+
+
+
+
+
Protokolle Opsomming (Protocols Summary)
+
+
Hierdie afdeling bevat 'n baie basiese oorsig van die oordragprotokolle.
+Die protokol sluit baie ander kenmerke in, soos multi_ack of side-band vermoëns, maar die dekking daarvan val buite die bestek van hierdie boek.
+Ons het probeer om vir jou 'n idee te gee van die algemene heen-en-weer tussen kliënt en bediener; as jy meer kennis as dit nodig het, sal jy waarskynlik na die Git-bronkode wil kyk.
+
+
Paklêers (Packfiles)
+
+
As jy al die instruksies in die voorbeeld van die vorige afdeling gevolg het, behoort jy nou 'n toets-Git-bewaarplek (repository) te hê met 11 objekte — vier blobs, drie bome (trees), drie vasleggings (commits), en een merker (tag):
+
+
+
$ find .git/objects -type f
+.git/objects/01/55eb4229851634a0f03eb265b69f5a2d56f341 # tree 2
+.git/objects/1a/410efbd13591db07496601ebc7a059dd55cfe9 # commit 3
+.git/objects/1f/7a7a472abf3dd9643fd615f6da379c4acb3e3a # test.txt v2
+.git/objects/3c/4e9cd789d88d8d89c1073707c3585e41b0e614 # tree 3
+.git/objects/83/baae61804e65cc73a7201a7252750c76066a30 # test.txt v1
+.git/objects/95/85191f37f7b0fb9444f35a9bf50de191beadc2 # tag
+.git/objects/ca/c0cab538b970a37ea1e769cbbde608743bc96d # commit 2
+.git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4 # 'test content'
+.git/objects/d8/329fc1cc938780ffdd9f94e0d364e0ea74f579 # tree 1
+.git/objects/fa/49b077972391ad58037050f2a75f74e3671e92 # new.txt
+.git/objects/fd/f4fc3344e67ab068f836878b6c4951e3b15f3d # commit 1
+
+
+
Git pers die inhoud van hierdie lêers saam met zlib, en jy stoor nie baie nie, so al hierdie lêers neem gesamentlik net 925 grepe (bytes) in beslag. Nou sal jy 'n bietjie meer lywige inhoud by die bewaarplek voeg om 'n interessante kenmerk van Git te demonstreer. Om dit te demonstreer, sal ons die repo.rb lêer van die Grit-biblioteek byvoeg — dit is 'n bronkodelêer van ongeveer 22K:
+
+
+
$ curl https://raw.githubusercontent.com/mojombo/grit/master/lib/grit/repo.rb > repo.rb
+$ git checkout master
+$ git add repo.rb
+$ git commit -m 'Create repo.rb'
+[master 484a592] Create repo.rb
+ 3 files changed, 709 insertions(+), 2 deletions(-)
+ delete mode 100644 bak/test.txt
+ create mode 100644 repo.rb
+ rewrite test.txt (100%)
+
+
+
As jy na die resulterende boom kyk, kan jy die SHA-1-waarde sien wat vir jou nuwe repo.rb blob-objek bereken is:
+
+
+
$ git cat-file -p master^{tree}
+100644 blob fa49b077972391ad58037050f2a75f74e3671e92 new.txt
+100644 blob 033b4468fa6b2a9547a70d88d1bbe8bf3f9ed0d5 repo.rb
+100644 blob e3f094f522629ae358806b17daf78246c27c007b test.txt
+
+
+
Jy kan dan git cat-file gebruik om te sien hoe groot daardie objek is:
+
+
+
$ git cat-file -s 033b4468fa6b2a9547a70d88d1bbe8bf3f9ed0d5
+22044
+
+
+
Op hierdie punt, verander daardie lêer 'n bietjie, en kyk wat gebeur:
+
+
+
$ echo '# testing' >> repo.rb
+$ git commit -am 'Modify repo.rb a bit'
+[master 2431da6] Modify repo.rb a bit
+ 1 file changed, 1 insertion(+)
+
+
+
Gaan die boom na wat deur daardie laaste vaslegging geskep is, en jy sal iets interessant sien:
+
+
+
$ git cat-file -p master^{tree}
+100644 blob fa49b077972391ad58037050f2a75f74e3671e92 new.txt
+100644 blob b042a60ef7dff760008df33cee372b945b6e884e repo.rb
+100644 blob e3f094f522629ae358806b17daf78246c27c007b test.txt
+
+
+
Die blob is nou 'n ander blob, wat beteken dat hoewel jy slegs 'n enkele reël aan die einde van 'n lêer met 400 reëls bygevoeg het, Git daardie nuwe inhoud as 'n heeltemal nuwe objek gestoor het:
+
+
+
$ git cat-file -s b042a60ef7dff760008df33cee372b945b6e884e
+22054
+
+
+
Jy het nou twee byna identiese 22K-objekte op jou skyf (elk saamgepers tot ongeveer 7K). Sou dit nie lekker wees as Git een van hulle volledig kon stoor nie, maar dan die tweede objek slegs as die verskil (delta) tussen hom en die eerste een?
+
+
Dit blyk dat dit wel kan. Die aanvanklike formaat waarin Git objekte op die skyf stoor, word 'n “los” (loose) objekformaat genoem. Soms pak Git egter verskeie van hierdie objekte in 'n enkele binêre lêer genaamd 'n “paklêer” (packfile) saam om spasie te bespaar en meer doeltreffend te wees. Git doen dit as jy te veel los objekte rondlê, as jy die git gc opdrag handmatig uitvoer, of as jy na 'n afgeleë bediener (remote server) push. Om te sien wat gebeur, kan jy Git handmatig vra om die objekte saam te pak deur die git gc opdrag uit te voer:
+
+
+
$ git gc
+Counting objects: 18, done.
+Delta compression using up to 8 threads.
+Compressing objects: 100% (14/14), done.
+Writing objects: 100% (18/18), done.
+Total 18 (delta 3), reused 0 (delta 0)
+
+
+
As jy in jou objects-gids kyk, sal jy sien dat die meeste van jou objekte weg is, en 'n nuwe paar lêers verskyn het:
+
+
+
$ find .git/objects -type f
+.git/objects/bd/9dbf5aae1a3862dd1526723246b20206e5fc37
+.git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4
+.git/objects/info/packs
+.git/objects/pack/pack-978e03944f5c581011e6998cd0e9e30000905586.idx
+.git/objects/pack/pack-978e03944f5c581011e6998cd0e9e30000905586.pack
+
+
+
Die objekte wat oorbly, is die blobs waarna geen vaslegging wys nie — in hierdie geval die “what is up, doc?” voorbeeld en die “test content” voorbeeld-blobs wat jy vroeër geskep het. Omdat jy hulle nooit by enige vasleggings gevoeg het nie, word hulle as hangend (dangling) beskou en word hulle nie in jou nuwe paklêer saamgepak nie.
+
+
Die ander lêers is jou nuwe paklêer en 'n indeks (index). Die paklêer is 'n enkele lêer wat die inhoud van al die objekte bevat wat van jou lêerstelsel verwyder is. Die indeks is 'n lêer wat relatiewe beginpunte (offsets) binne daardie paklêer bevat sodat jy vinnig na 'n spesifieke objek kan soek. Wat gaaf is, is dat hoewel die objekte op die skyf voordat jy die gc-opdrag uitgevoer het gesamentlik ongeveer 15K groot was, die nuwe paklêer slegs 7K is. Jy het jou skyfgebruik in die helfte gesny deur jou objekte op te pak.
+
+
Hoe doen Git dit? Wanneer Git objekte oppak, soek dit na lêers wat soortgelyke name en groottes het, en stoor slegs die delta’s van een weergawe van die lêer na die volgende. Jy kan in die paklêer kyk en sien wat Git gedoen het om spasie te bespaar. Die git verify-pack loodgietersopdrag (plumbing command) laat jou toe om te sien wat saamgepak is:
+
+
+
$ git verify-pack -v .git/objects/pack/pack-978e03944f5c581011e6998cd0e9e30000905586.idx
+2431da676938450a4d72e260db3bf7b0f587bbc1 commit 223 155 12
+69bcdaff5328278ab1c0812ce0e07fa7d26a96d7 commit 214 152 167
+80d02664cb23ed55b226516648c7ad5d0a3deb90 commit 214 145 319
+43168a18b7613d1281e5560855a83eb8fde3d687 commit 213 146 464
+092917823486a802e94d727c820a9024e14a1fc2 commit 214 146 610
+702470739ce72005e2edff522fde85d52a65df9b commit 165 118 756
+d368d0ac0678cbe6cce505be58126d3526706e54 tag 130 122 874
+fe879577cb8cffcdf25441725141e310dd7d239b tree 136 136 996
+d8329fc1cc938780ffdd9f94e0d364e0ea74f579 tree 36 46 1132
+deef2e1b793907545e50a2ea2ddb5ba6c58c4506 tree 136 136 1178
+d982c7cb2c2a972ee391a85da481fc1f9127a01d tree 6 17 1314 1 \
+ deef2e1b793907545e50a2ea2ddb5ba6c58c4506
+3c4e9cd789d88d8d89c1073707c3585e41b0e614 tree 8 19 1331 1 \
+ deef2e1b793907545e50a2ea2ddb5ba6c58c4506
+0155eb4229851634a0f03eb265b69f5a2d56f341 tree 71 76 1350
+83baae61804e65cc73a7201a7252750c76066a30 blob 10 19 1426
+fa49b077972391ad58037050f2a75f74e3671e92 blob 9 18 1445
+b042a60ef7dff760008df33cee372b945b6e884e blob 22054 5799 1463
+033b4468fa6b2a9547a70d88d1bbe8bf3f9ed0d5 blob 9 20 7262 1 \
+ b042a60ef7dff760008df33cee372b945b6e884e
+1f7a7a472abf3dd9643fd615f6da379c4acb3e3a blob 10 19 7282
+non delta: 15 objects
+chain length = 1: 3 objects
+.git/objects/pack/pack-978e03944f5c581011e6998cd0e9e30000905586.pack: ok
+
+
+
Hier verwys die 033b4 blob, wat as jy onthou die eerste weergawe van jou repo.rb lêer was, na die b042a blob, wat die tweede weergawe van die lêer was. Die derde kolom in die afvoer is die grootte van die objek in die paklêer, so jy kan sien dat b042a 22K van die lêer opneem, maar dat 033b4 slegs 9 grepe (bytes) in beslag neem. Wat ook interessant is, is dat die tweede weergawe van die lêer die een is wat ongeskonde (intact) gestoor word, terwyl die oorspronklike weergawe as 'n delta gestoor word — dit is omdat jy heel waarskynlik vinniger toegang tot die mees onlangse weergawe van die lêer sal benodig.
+
+
Die regtig lekker ding hiervan is dat dit enige tyd weer herpak kan word. Git sal af en toe jou databasis outomaties herpak, altyd in 'n poging om meer spasie te bespaar, maar jy kan dit ook enige tyd handmatig herpak deur git gc self uit te voer.
+
Bundeling (Bundling)
+
+
Alhoewel ons die algemene maniere gedek het om Git-data oor 'n netwerk oor te dra (HTTP, SSH, ens.), is daar eintlik nog een manier om dit te doen wat nie algemeen gebruik word nie, maar wat eintlik baie nuttig kan wees.
+
+
Git is in staat om sy data in 'n enkele lêer te “bundel”.
+Dit kan in verskeie scenario’s nuttig wees.
+Miskien is jou netwerk af en jy wil veranderings aan jou medewerkers stuur.
+Miskien werk jy iewers op 'n afgeleë plek en het om veiligheidsredes nie toegang tot die plaaslike netwerk nie.
+Miskien het jou draadlose/ethernet-kaart net gebreek.
+Miskien het jy op die oomblik nie toegang tot 'n gedeelde bediener nie, jy wil vir iemand opdaterings e-pos en jy wil nie 40 vasleggings (commits) via format-patch oordra nie.
+
+
Dit is waar die git bundle opdrag nuttig kan wees.
+Die bundle opdrag sal alles wat normaalweg met 'n git push opdrag oor die netwerk opgestuur sou word, in 'n binêre lêer verpak wat jy vir iemand kan e-pos of op 'n flitsstok (flash drive) kan sit, en dan in 'n ander bewaarplek kan ontbondel (unbundle).
+
+
Kom ons kyk na 'n eenvoudige voorbeeld.
+Sê nou jy het 'n bewaarplek met twee vasleggings:
+
+
+
$ git log
+commit 9a466c572fe88b195efd356c3f2bbeccdb504102
+Author: Scott Chacon <schacon@gmail.com>
+Date: Wed Mar 10 07:34:10 2010 -0800
+
+ Second commit
+
+commit b1ec3248f39900d2a406049d762aa68e9641be25
+Author: Scott Chacon <schacon@gmail.com>
+Date: Wed Mar 10 07:34:01 2010 -0800
+
+ First commit
+
+
+
As jy daardie bewaarplek vir iemand wil stuur en jy het nie toegang tot 'n bewaarplek om na te push nie, of eenvoudig nie een wil opstel nie, kan jy dit bundel met git bundle create.
+
+
+
$ git bundle create repo.bundle HEAD master
+Counting objects: 6, done.
+Delta compression using up to 2 threads.
+Compressing objects: 100% (2/2), done.
+Writing objects: 100% (6/6), 441 bytes, done.
+Total 6 (delta 0), reused 0 (delta 0)
+
+
+
Nou het jy 'n lêer genaamd repo.bundle wat al die data het wat nodig is om die bewaarplek se master tak te herskep.
+Met die bundle opdrag moet jy elke verwysing of spesifieke reeks vasleggings lys wat jy wil insluit.
+As jy van plan is dat dit iewers anders gekloon moet word, moet jy HEAD ook as 'n verwysing byvoeg, soos ons hier gedoen het.
+
+
Jy kan hierdie repo.bundle lêer vir iemand anders e-pos, of dit op 'n USB-skyf sit en dit oorstap.
+
+
Aan die ander kant, sê jy word hierdie repo.bundle lêer gestuur en wil aan die projek werk.
+Jy kan vanaf die binêre lêer in 'n gids kloon, baie soos jy van 'n URL af sou doen.
+
+
+
$ git clone repo.bundle repo
+Cloning into 'repo'...
+...
+$ cd repo
+$ git log --oneline
+9a466c5 Second commit
+b1ec324 First commit
+
+
+
As jy nie HEAD in die verwysings insluit nie, moet jy ook -b master spesifiseer of watter tak ook al ingesluit is, want anders sal dit nie weet watter tak om uit te check nie.
+
+
Kom ons sê nou jy doen drie vasleggings daarop en wil die nuwe vasleggings terugstuur via 'n bundel op 'n USB-stokkie of e-pos.
+
+
+
$ git log --oneline
+71b84da Last commit - second repo
+c99cf5b Fourth commit - second repo
+7011d3d Third commit - second repo
+9a466c5 Second commit
+b1ec324 First commit
+
+
+
Eerstens moet ons die reeks vasleggings bepaal wat ons in die bundel wil insluit.
+Anders as die netwerkprotokolle wat die minimum stel data wat oor die netwerk oorgedra moet word vir ons uitwerk, sal ons dit handmatig moet uitvind.
+Jy kan natuurlik net dieselfde ding doen en die hele bewaarplek bundel, wat sal werk, maar dit is beter om net die verskil te bundel - net die drie vasleggings wat ons pas plaaslik gemaak het.
+
+
Om dit te doen, sal jy die verskil moet bereken.
+Soos ons in }}">Vasleggingsreekse (Commit Ranges) beskryf het, kan jy 'n reeks vasleggings op verskeie maniere spesifiseer.
+Om die drie vasleggings te kry wat ons in ons master tak het wat nie in die tak was wat ons oorspronklik gekloon het nie, kan ons iets soos origin/master..master of master ^origin/master gebruik.
+Jy kan dit toets met die log opdrag.
+
+
+
$ git log --oneline master ^origin/master
+71b84da Last commit - second repo
+c99cf5b Fourth commit - second repo
+7011d3d Third commit - second repo
+
+
+
So noudat ons die lys van vasleggings het wat ons in die bundel wil insluit, kom ons bundel hulle.
+Ons doen dit met die git bundle create opdrag, wat dit 'n lêernaam gee wat ons wil hê ons bundel moet wees en die reeks vasleggings wat daarin moet gaan.
+
+
+
$ git bundle create commits.bundle master ^9a466c5
+Counting objects: 11, done.
+Delta compression using up to 2 threads.
+Compressing objects: 100% (3/3), done.
+Writing objects: 100% (9/9), 775 bytes, done.
+Total 9 (delta 0), reused 0 (delta 0)
+
+
+
Nou het ons 'n commits.bundle lêer in ons gids.
+As ons dit neem en dit na ons vennoot stuur, kan sy dit dan in die oorspronklike bewaarplek invoer, selfs al is daar intussen meer werk daar gedoen.
+
+
Wanneer sy die bundel kry, kan sy dit inspekteer om te sien wat dit bevat voordat sy dit in haar bewaarplek invoer.
+Die eerste opdrag is die bundle verify opdrag wat sal seker maak dat die lêer werklik 'n geldige Git-bundel is en dat jy al die nodige voorouers het om dit behoorlik te hersaamstel.
+
+
+
$ git bundle verify ../commits.bundle
+The bundle contains 1 ref
+71b84daaf49abed142a373b6e5c59a22dc6560dc refs/heads/master
+The bundle requires these 1 ref
+9a466c572fe88b195efd356c3f2bbeccdb504102 second commit
+../commits.bundle is okay
+
+
+
As die bundelaar 'n bundel geskep het van net die laaste twee vasleggings wat hulle gedoen het, eerder as al drie, sou die oorspronklike bewaarplek dit nie kon invoer nie, aangesien dit vereiste geskiedenis kort.
+Die verify opdrag sou in plaas daarvan so gelyk het:
+
+
+
$ git bundle verify ../commits-bad.bundle
+error: Repository lacks these prerequisite commits:
+error: 7011d3d8fc200abe0ad561c011c3852a4b7bbe95 Third commit - second repo
+
+
+
Ons eerste bundel is egter geldig, so ons kan vasleggings daaruit afhaal (fetch).
+As jy wil sien watter takke in die bundel is wat ingevoer kan word, is daar ook 'n opdrag om net die koppe (heads) te lys:
+
+
+
$ git bundle list-heads ../commits.bundle
+71b84daaf49abed142a373b6e5c59a22dc6560dc refs/heads/master
+
+
+
Die verify subopdrag sal jou ook die koppe (heads) vertel.
+Die punt is om te sien wat in gepull kan word, sodat jy die fetch of pull opdragte kan gebruik om vasleggings uit hierdie bundel in te voer.
+Hier sal ons die master tak van die bundel na 'n tak genaamd other-master in ons bewaarplek afhaal (fetch):
+
+
+
$ git fetch ../commits.bundle master:other-master
+From ../commits.bundle
+ * [new branch] master -> other-master
+
+
+
Nou kan ons sien dat ons die ingevoerde vasleggings op die other-master tak het asook enige vasleggings wat ons intussen in ons eie master tak gedoen het.
+
+
+
$ git log --oneline --decorate --graph --all
+* 8255d41 (HEAD, master) Third commit - first repo
+| * 71b84da (other-master) Last commit - second repo
+| * c99cf5b Fourth commit - second repo
+| * 7011d3d Third commit - second repo
+|/
+* 9a466c5 Second commit
+* b1ec324 First commit
+
+
+
Dus, git bundle kan regtig nuttig wees om te deel of netwerk-tipe bewerkings te doen wanneer jy nie die regte netwerk of gedeelde bewaarplek het om dit te doen nie.
+
Bêre en Skoonmaak (Stashing and Cleaning)
+
+
Dikwels, wanneer jy aan 'n deel van jou projek gewerk het, is dinge in 'n morsige toestand en wil jy vir 'n rukkie takke wissel om aan iets anders te werk.
+Die probleem is, jy wil nie 'n vaslegging (commit) van halfklaar werk doen net sodat jy later na hierdie punt kan terugkeer nie.
+Die antwoord op hierdie probleem is die git stash opdrag.
+
+
Om te bêre (stashing) neem die vuil toestand van jou werkgids — dit is jou gewysigde opgespoorde lêers en voorbereide (staged) veranderings — en stoor dit op 'n stapel van onvoltooide veranderings wat jy te eniger tyd weer kan toepas (selfs op 'n ander tak).
+
+
+
+|
+ Note
+ |
+
+ Migreer na git stash push
+
+
+ Vanaf laat Oktober 2017 was daar uitgebreide bespreking op die Git-poslys, waarin die opdrag git stash save uitgefaseer (deprecated) word ten gunste van die bestaande alternatief git stash push.
+Die hoofrede hiervoor is dat git stash push die opsie instel om geselekteerde padspesifikasies (pathspecs) te bêre, iets wat git stash save nie ondersteun nie.
+
+ git stash save gaan nie binnekort verdwyn nie, so moenie bekommerd wees dat dit skielik sal wegraak nie.
+Maar jy sal dalk wil begin oorskakel na die push alternatief vir die nuwe funksionaliteit.
+ |
+
+
+
+
Bêre van Jou Werk (Stashing Your Work)
+
+
Om stashing te demonstreer, sal jy in jou projek ingaan en aan 'n paar lêers begin werk en moontlik een van die veranderings voorberei (stage).
+As jy git status uitvoer, kan jy jou vuil toestand sien:
+
+
+
+
$ git status
+Changes to be committed:
+ (use "git reset HEAD <file>..." to unstage)
+
+ modified: index.html
+
+Changes not staged for commit:
+ (use "git add <file>..." to update what will be committed)
+ (use "git checkout -- <file>..." to discard changes in working directory)
+
+ modified: lib/simplegit.rb
+
+
+
+
Nou wil jy takke wissel, maar jy wil nog nie vaslê waaraan jy gewerk het nie, so jy sal die veranderings bêre.
+Om 'n nuwe stash op jou stapel te plaas (push), voer git stash of git stash push uit:
+
+
+
+
$ git stash
+Saved working directory and index state \
+ "WIP on master: 049d078 Create index file"
+HEAD is now at 049d078 Create index file
+(To restore them type "git stash apply")
+
+
+
+
Jy kan nou sien dat jou werkgids skoon is:
+
+
+
+
$ git status
+# On branch master
+nothing to commit, working directory clean
+
+
+
+
Op hierdie punt kan jy takke wissel en elders werk doen; jou veranderings word op jou stapel gestoor.
+Om te sien watter stashes jy gestoor het, kan jy git stash list gebruik:
+
+
+
+
$ git stash list
+stash@{0}: WIP on master: 049d078 Create index file
+stash@{1}: WIP on master: c264051 Revert "Add file_size"
+stash@{2}: WIP on master: 21d80a5 Add number to log
+
+
+
+
In hierdie geval is twee stashes voorheen gestoor, so jy het toegang tot drie verskillende gebêrede werke.
+Jy kan die een wat jy so pas gebêre het weer toepas deur die opdrag te gebruik wat in die hulpafvoer van die oorspronklike stash-opdrag gewys word: git stash apply.
+As jy een van die ouer stashes wil toepas, kan jy dit spesifiseer deur dit te benoem, soos volg: git stash apply stash@{2}.
+As jy nie 'n stash spesifiseer nie, neem Git die mees onlangse stash aan en probeer dit toepas:
+
+
+
+
$ git stash apply
+On branch master
+Changes not staged for commit:
+ (use "git add <file>..." to update what will be committed)
+ (use "git checkout -- <file>..." to discard changes in working directory)
+
+ modified: index.html
+ modified: lib/simplegit.rb
+
+no changes added to commit (use "git add" and/or "git commit -a")
+
+
+
+
Jy kan sien dat Git die lêers wat jy teruggerol het toe jy die stash gestoor het, weer wysig.
+In hierdie geval het jy 'n skoon werkgids gehad toe jy die stash probeer toepas het, en jy het probeer om dit toe te pas op dieselfde tak waarvan jy dit gestoor het.
+Om 'n skoon werkgids te hê en dit op dieselfde tak toe te pas, is nie nodig om 'n stash suksesvol toe te pas nie.
+Jy kan 'n stash op een tak stoor, later na 'n ander tak oorskakel, en probeer om die veranderings weer toe te pas.
+Jy kan ook gewysigde en onvasgelegde lêers in jou werkgids hê wanneer jy 'n stash toepas — Git gee jou saamsmeltingskonflikte as enigiets nie meer skoon toepas nie.
+
+
+
Die veranderings aan jou lêers is weer toegepas, maar die lêer wat jy vantevore voorberei (staged) het, is nie weer voorberei nie.
+Om dit te doen, moet jy die git stash apply opdrag met 'n --index opsie uitvoer om die opdrag te beveel om die voorbereide veranderings weer te probeer toepas.
+As jy dit in plaas daarvan uitgevoer het, sou jy terug by jou oorspronklike posisie gewees het:
+
+
+
+
$ git stash apply --index
+On branch master
+Changes to be committed:
+ (use "git reset HEAD <file>..." to unstage)
+
+ modified: index.html
+
+Changes not staged for commit:
+ (use "git add <file>..." to update what will be committed)
+ (use "git checkout -- <file>..." to discard changes in working directory)
+
+ modified: lib/simplegit.rb
+
+
+
+
Die apply opsie probeer slegs om die gebêrede werk toe te pas — jy behou dit steeds op jou stapel.
+Om dit te verwyder, kan jy git stash drop uitvoer met die naam van die stash om te verwyder:
+
+
+
+
$ git stash list
+stash@{0}: WIP on master: 049d078 Create index file
+stash@{1}: WIP on master: c264051 Revert "Add file_size"
+stash@{2}: WIP on master: 21d80a5 Add number to log
+$ git stash drop stash@{0}
+Dropped stash@{0} (364e91f3f268f0900bc3ee613f9f733e82aaed43)
+
+
+
+
Jy kan ook git stash pop uitvoer om die stash toe te pas en dit dan dadelik van jou stapel af te gooi (drop).
+
+
+
Kreatiewe Stashing (Creative Stashing)
+
+
Daar is 'n paar stash-variante wat ook nuttig kan wees.
+Die eerste opsie wat redelik gewild is, is die --keep-index opsie van die git stash opdrag.
+Dit sê vir Git om nie net alle voorbereide inhoud in te sluit by die stash wat geskep word nie, maar dit terselfdertyd in die indeks te laat.
+
+
+
+
$ git status -s
+M index.html
+ M lib/simplegit.rb
+
+$ git stash --keep-index
+Saved working directory and index state WIP on master: 1b65b17 added the index file
+HEAD is now at 1b65b17 added the index file
+
+$ git status -s
+M index.html
+
+
+
+
Nog 'n algemene ding wat jy dalk met stash wil doen, is om sowel die onopgespoorde (untracked) lêers as die opgespoordes te bêre.
+By verstek sal git stash slegs gewysigde en voorbereide opgespoorde lêers bêre.
+As jy --include-untracked of -u spesifiseer, sal Git onopgespoorde lêers insluit in die stash wat geskep word.
+Die insluiting van onopgespoorde lêers in die stash sal egter steeds nie eksplisiet geïgnoreerde lêers insluit nie; om addisioneel geïgnoreerde lêers in te sluit, gebruik --all (of net -a).
+
+
+
+
$ git status -s
+M index.html
+ M lib/simplegit.rb
+?? new-file.txt
+
+$ git stash -u
+Saved working directory and index state WIP on master: 1b65b17 added the index file
+HEAD is now at 1b65b17 added the index file
+
+$ git status -s
+$
+
+
+
+
Laastens, as jy die --patch vlag spesifiseer, sal Git nie alles wat gewysig is bêre nie, maar sal jou in plaas daarvan interaktief vra watter van die veranderings jy wil bêre en watter jy in jou werkgids wil hou.
+
+
+
+
$ git stash --patch
+diff --git a/lib/simplegit.rb b/lib/simplegit.rb
+index 66d332e..8bb5674 100644
+--- a/lib/simplegit.rb
++++ b/lib/simplegit.rb
+@@ -16,6 +16,10 @@ class SimpleGit
+ return `#{git_cmd} 2>&1`.chomp
+ end
+ end
++
++ def show(treeish = 'master')
++ command("git show #{treeish}")
++ end
+
+ end
+ test
+Stash this hunk [y,n,q,a,d,/,e,?]? y
+
+Saved working directory and index state WIP on master: 1b65b17 added the index file
+
+
+
+
Skep van 'n Tak vanuit 'n Stash (Creating a Branch from a Stash)
+
+
As jy 'n bietjie werk bêre, dit vir 'n rukkie daar laat, en voortgaan op die tak waaruit jy die werk gebêre het, kan jy 'n probleem hê om die werk weer toe te pas.
+As die toepassing (apply) 'n lêer probeer wysig wat jy sedertdien gewysig het, sal jy 'n saamsmeltingskonflik kry en dit moet probeer oplos.
+As jy 'n makliker manier wil hê om die gebêrede veranderings weer te toets, kan jy git stash branch <nuwe taknaam> uitvoer, wat vir jou 'n nuwe tak skep met jou gekose taknaam, die vaslegging uittrek waarop jy was toe jy jou werk gebêre het, jou werk daar weer toepas, en dan die stash afgooi as dit suksesvol toepas:
+
+
+
+
$ git stash branch testchanges
+M index.html
+M lib/simplegit.rb
+Switched to a new branch 'testchanges'
+On branch testchanges
+Changes to be committed:
+ (use "git reset HEAD <file>..." to unstage)
+
+ modified: index.html
+
+Changes not staged for commit:
+ (use "git add <file>..." to update what will be committed)
+ (use "git checkout -- <file>..." to discard changes in working directory)
+
+ modified: lib/simplegit.rb
+
+Dropped refs/stash@{0} (29d385a81d163dfd45a452a2ce816487a6b8b014)
+
+
+
+
Dit is 'n oulike kortpad om gebêrede werk maklik te herwin en daaraan in 'n nuwe tak te werk.
+
+
+
Skoonmaak van jou Werkgids (Cleaning your Working Directory)
+
+
Laastens wil jy dalk nie sekere werk of lêers in jou werkgids bêre nie, maar bloot daarvan ontslae raak; dit is waarvoor die git clean opdrag is.
+
+
+
Sommige algemene redes vir die skoonmaak van jou werkgids kan wees om rommel (cruft) te verwyder wat deur saamsmeltings of eksterne gereedskap gegenereer is, of om bou-artefakte te verwyder ten einde 'n skoon bou (clean build) te doen.
+
+
+
Jy sal redelik versigtig met hierdie opdrag wil wees, aangesien dit ontwerp is om lêers uit jou werkgids te verwyder wat nie opgespoor (tracked) word nie.
+As jy van plan verander, is daar dikwels geen manier om die inhoud van daardie lêers te herwin nie.
+'n Veiliger opsie is om git stash --all uit te voer om alles te verwyder, maar dit in 'n stash te stoor.
+
+
+
As ons aanneem jy wil wel rommel-lêers verwyder of jou werkgids skoonmaak, kan jy dit doen met git clean.
+Om al die onopgespoorde lêers in jou werkgids te verwyder, kan jy git clean -f -d uitvoer, wat enige lêers sowel as enige subgidse wat gevolglik leeg word, verwyder.
+Die -f beteken 'force' of “doen dit regtig,” en word vereis as die Git konfigurasieveranderlike clean.requireForce nie eksplisiet op vals (false) gestel is nie.
+
+
+
As jy ooit wil sien wat dit sou doen, kan jy die opdrag met die --dry-run (of -n) opsie uitvoer, wat beteken “doen 'n droë loop (dry run) en vertel my wat jy sou verwyder het”.
+
+
+
+
$ git clean -d -n
+Would remove test.o
+Would remove tmp/
+
+
+
+
By verstek sal die git clean opdrag slegs onopgespoorde lêers verwyder wat nie geïgnoreer word nie.
+Enige lêer wat ooreenstem met 'n patroon in jou .gitignore of ander ignoreer-lêers, sal nie verwyder word nie.
+As jy daardie lêers ook wil verwyder, byvoorbeeld om alle .o lêers wat van 'n bou gegenereer is te verwyder sodat jy 'n ten volle skoon bou kan doen, kan jy 'n -x by die clean opdrag voeg.
+
+
+
+
$ git status -s
+ M lib/simplegit.rb
+?? build.TMP
+?? tmp/
+
+$ git clean -n -d
+Would remove build.TMP
+Would remove tmp/
+
+$ git clean -n -d -x
+Would remove build.TMP
+Would remove test.o
+Would remove tmp/
+
+
+
+
As jy nie weet wat die git clean opdrag gaan doen nie, voer dit altyd eers met 'n -n uit om dubbel seker te maak voordat jy die -n na 'n -f verander en dit vir regtig doen.
+Die ander manier waarop jy versigtig kan wees oor die proses, is om dit met die -i of “interactive” vlag uit te voer.
+
+
+
Dit sal die clean opdrag in 'n interaktiewe modus uitvoer.
+
+
+
+
$ git clean -x -i
+Would remove the following items:
+ build.TMP test.o
+*** Commands ***
+ 1: clean 2: filter by pattern 3: select by numbers 4: ask each 5: quit
+ 6: help
+What now>
+
+
+
+
Op hierdie manier kan jy individueel deur elke lêer stap of patrone vir verwydering interaktief spesifiseer.
+
+
+
+
+|
+ Note
+ |
+
+
+ Daar is 'n eienaardige situasie waar jy dalk ekstra kragdadig moet wees wanneer jy Git vra om jou werkgids skoon te maak.
+As jy toevallig in 'n werkgids is waaronder jy ander Git-bewaarplekke gekopieer of gekloon het (miskien as submodules), sal selfs git clean -fd weier om daardie gidse uit te vee.
+In sulke gevalle moet jy 'n tweede -f opsie vir klem byvoeg.
+ |
+
+
+
+
Die Stoor van Aanmeldbewyse (Credential Storage)
+
+
+
+As jy die SSH-vervoer gebruik om aan remotes te koppel, is dit vir jou moontlik om 'n sleutel sonder 'n wagwoordfrase (passphrase) te hê, wat jou toelaat om veilig data oor te dra sonder om jou gebruikersnaam en wagwoord in te tik.
+Dit is egter nie moontlik met die HTTP-protokolle nie — elke verbinding benodig 'n gebruikersnaam en wagwoord.
+Dit raak selfs moeiliker vir stelsels met twee-faktor-verifikasie, waar die teken (token) wat jy vir 'n wagwoord gebruik ewekansig gegenereer en onuitspreekbaar is.
+
+
Gelukkig het Git 'n aanmeldbewysstelsel (credentials system) wat hiermee kan help.
+Git het 'n paar opsies wat standaard ingebou is:
+
+
+-
+
Die verstek (default) is om glad nie in die kas te stoor (cache) nie.
+Elke verbinding sal jou vir jou gebruikersnaam en wagwoord vra.
+
+-
+
Die “cache” (kas) modus hou aanmeldbewyse in die geheue vir 'n sekere tydperk.
+Geen van die wagwoorde word ooit op die skyf gestoor nie, en hulle word na 15 minute uit die kas verwyder.
+
+-
+
Die “store” (stoor) modus stoor die aanmeldbewyse in 'n gewone tekslêer op die skyf, en hulle verval nooit nie.
+Dit beteken dat totdat jy jou wagwoord vir die Git-gasheer verander, jy nooit weer jou aanmeldbewyse hoef in te tik nie.
+Die nadeel van hierdie benadering is dat jou wagwoorde onversleutel (cleartext) in 'n gewone lêer in jou tuisgids (home directory) gestoor word.
+
+-
+
As jy macOS gebruik, kom Git met 'n “osxkeychain” modus, wat aanmeldbewyse stoor in die veilige sleutelhouer (secure keychain) wat aan jou stelselrekening gekoppel is.
+Hierdie metode stoor die aanmeldbewyse op die skyf, en hulle verval nooit nie, maar hulle is geënkripteer met dieselfde stelsel wat HTTPS-sertifikate en Safari se outovoltooi-data stoor.
+
+-
+
As jy Windows gebruik, kan jy die Git Credential Manager kenmerk aktiveer wanneer jy Git for Windows installeer, of die nuutste GCM afsonderlik as 'n selfstandige diens installeer.
+Dit is soortgelyk aan die “osxkeychain” helper wat hierbo beskryf is, maar gebruik die Windows Credential Store om sensitiewe inligting te beheer.
+Dit kan ook aanmeldbewyse aan WSL1 of WSL2 verskaf.
+Sien GCM Install Instructions vir meer inligting.
+
+
+
+
Jy kan een van hierdie metodes kies deur 'n Git-konfigurasiewaarde in te stel:
+
+
+
$ git config --global credential.helper cache
+
+
+
Sommige van hierdie helpers het opsies.
+Die “store” helper kan 'n --file <path> argument neem, wat aanpas waar die gewone tekslêer gestoor word (die verstelling is ~/.git-credentials).
+Die “cache” helper aanvaar die --timeout <seconds> opsie, wat die tydsduur verander wat sy daemon aan die gang gehou word (die verstelling is “900”, of 15 minute).
+Hier is 'n voorbeeld van hoe jy die “store” helper met 'n pasgemaakte lêernaam sal konfigureer:
+
+
+
$ git config --global credential.helper 'store --file ~/.my-credentials'
+
+
+
Git laat jou selfs toe om verskeie helpers te konfigureer.
+Wanneer Git na aanmeldbewyse vir 'n spesifieke gasheer soek, sal dit hulle in volgorde navraag doen (query), en stop nadat die eerste antwoord verskaf is.
+Wanneer aanmeldbewyse gestoor word, sal Git die gebruikersnaam en wagwoord na al die helpers in die lys stuur, en hulle kan kies wat om daarmee te doen.
+Hier is hoe 'n .gitconfig sou lyk as jy 'n aanmeldbewyse-lêer op 'n geheuestokkie (thumb drive) gehad het, maar die geheuekas (in-memory cache) wou gebruik om tikwerk te bespaar as die aandrywer nie ingeprop is nie:
+
+
+
[credential]
+ helper = store --file /mnt/thumbdrive/.git-credentials
+ helper = cache --timeout 30000
+
+
+
Onder die Enjinkap (Under the Hood)
+
+
Hoe werk dit alles?
+Git se wortelopdrag (root command) vir die credential-helper-stelsel is git credential, wat 'n opdrag as 'n argument neem, en dan meer toevoer deur stdin ontvang.
+
+
+
Dit sal dalk makliker wees om met 'n voorbeeld te verstaan.
+Kom ons sê dat 'n credential helper gekonfigureer is, en die helper het aanmeldbewyse vir mygithost gestoor.
+Hier is 'n sessie wat die “fill” opdrag gebruik, wat geroep word wanneer Git probeer om aanmeldbewyse vir 'n gasheer te vind:
+
+
+
+
$ git credential fill (1)
+protocol=https (2)
+host=mygithost
+(3)
+protocol=https (4)
+host=mygithost
+username=bob
+password=s3cre7
+$ git credential fill (5)
+protocol=https
+host=unknownhost
+
+Username for 'https://unknownhost': bob
+Password for 'https://bob@unknownhost':
+protocol=https
+host=unknownhost
+username=bob
+password=s3cre7
+
+
+
+
+-
+
Hierdie is die opdragreël wat die interaksie inisieer.
+
+-
+
Git-credential wag dan vir toevoer op stdin.
+Ons verskaf dit van die dinge wat ons weet: die protokol en gasheernaam.
+
+-
+
'n Leë reël dui aan dat die toevoer voltooi is, en die aanmeldbewysstelsel moet antwoord met wat dit weet.
+
+-
+
Git-credential neem dan oor en skryf na stdout met die stukkies inligting wat dit gevind het.
+
+-
+
As aanmeldbewyse nie gevind word nie, vra Git die gebruiker vir die gebruikersnaam en wagwoord, en verskaf dit terug na die roepende stdout (hier is hulle aan dieselfde konsole gekoppel).
+
+
+
+
+
Die aanmeldbewysstelsel roep eintlik 'n program aan wat los staan van Git self; watter een en hoe hang af van die credential.helper konfigurasiewaarde.
+Daar is verskeie vorme wat dit kan aanneem:
+
+
+
+
+
+
+
+
+| Konfigurasiewaarde |
+Gedrag |
+
+
+
+
+foo
|
+Roep git-credential-foo aan |
+
+
+foo -a --opt=bcd
|
+Roep git-credential-foo -a --opt=bcd aan |
+
+
+/absolute/path/foo -xyz
|
+Roep /absolute/path/foo -xyz aan |
+
+
+!f() { echo "password=s3cre7"; }; f
|
+Kode na ! word in dop (shell) geëvalueer |
+
+
+
+
+
So die helpers wat hierbo beskryf is, word eintlik git-credential-cache, git-credential-store, ensovoorts genoem, en ons kan hulle konfigureer om opdragreël-argumente te neem.
+Die algemene vorm hiervoor is “git-credential-foo [args] <aksie>.”
+Die stdin/stdout-protokol is dieselfde as git-credential, maar hulle gebruik 'n effens ander stel aksies:
+
+
+
+-
+
get is 'n versoek vir 'n gebruikersnaam/wagwoord-paar.
+
+-
+
store is 'n versoek om 'n stel aanmeldbewyse in hierdie helper se geheue te stoor.
+
+-
+
erase verwyder die aanmeldbewyse vir die gegewe eienskappe uit hierdie helper se geheue.
+
+
+
+
+
Vir die store en erase aksies is geen reaksie nodig nie (Git ignoreer dit in elk geval).
+Vir die get aksie stel Git egter baie daarin belang wat die helper te sê het.
+As die helper niks nuttigs weet nie, kan dit bloot toemaak sonder afvoer, maar as dit wel weet, moet dit die verskafde inligting aanvul met die inligting wat dit gestoor het.
+Die afvoer word soos 'n reeks toekenningsverklarings (assignment statements) behandel; enigiets wat verskaf word, sal dit wat Git reeds weet vervang.
+
+
+
Hier is dieselfde voorbeeld as hierbo, maar ons slaan git-credential oor en gaan reguit na git-credential-store:
+
+
+
+
$ git credential-store --file ~/git.store store (1)
+protocol=https
+host=mygithost
+username=bob
+password=s3cre7
+$ git credential-store --file ~/git.store get (2)
+protocol=https
+host=mygithost
+
+username=bob (3)
+password=s3cre7
+
+
+
+
+-
+
Hier sê ons vir git-credential-store om sekere aanmeldbewyse te stoor: die gebruikersnaam “bob” en die wagwoord “s3cre7” moet gebruik word wanneer https://mygithost benader word.
+
+-
+
Nou gaan ons daardie aanmeldbewyse herwin (retrieve).
+Ons verskaf die dele van die verbinding wat ons reeds weet (https://mygithost), en 'n leë reël.
+
+-
+
git-credential-store antwoord met die gebruikersnaam en wagwoord wat ons hierbo gestoor het.
+
+
+
+
+
Hier is hoe die ~/git.store lêer lyk:
+
+
+
+
https://bob:s3cre7@mygithost
+
+
+
+
Dit is net 'n reeks reëls, wat elk 'n URL bevat wat met 'n aanmeldbewys versier is.
+Die osxkeychain en wincred helpers gebruik die inheemse formaat van hul eie agterliggende stoorplekke (backing stores), terwyl cache sy eie geheue-formaat (in-memory format) gebruik (wat geen ander proses kan lees nie).
+
+
+
'n Pasgemaakte Aanmeldbewyskas (A Custom Credential Cache)
+
+
Gegewe dat git-credential-store en vriende aparte programme van Git is, is dit nie 'n groot sprong om te besef dat enige program 'n Git credential helper kan wees nie.
+Die helpers wat deur Git verskaf word dek baie algemene gebruiksgevalle, maar nie almal nie.
+Byvoorbeeld, sê nou jou span het 'n paar aanmeldbewyse wat met die hele span gedeel word, miskien vir ontplooiing (deployment).
+Dit word in 'n gedeelde gids gestoor, maar jy wil dit nie na jou eie aanmeldbewysstoor kopieer nie, want dit verander dikwels.
+Geen van die bestaande helpers dek hierdie geval nie; kom ons kyk wat dit sal verg om ons eie te skryf.
+Daar is verskeie sleutelkenmerke wat hierdie program moet hê:
+
+
+
+-
+
Die enigste aksie waaraan ons aandag moet gee, is get; store en erase is skryfoperasies, so ons sal net skoon toemaak wanneer dit ontvang word.
+
+-
+
Die lêerformaat van die gedeelde aanmeldbewyslêer is dieselfde as wat deur git-credential-store gebruik word.
+
+-
+
Die ligging van daardie lêer is redelik standaard, maar ons moet die gebruiker toelaat om 'n pasgemaakte pad aan te gee net vir ingeval.
+
+
+
+
+
Weereens sal ons hierdie uitbreiding in Ruby skryf, maar enige taal sal werk solank Git die voltooide produk kan uitvoer.
+Hier is die volledige bronkode van ons nuwe credential helper:
+
+
+
+
#!/usr/bin/env ruby
+
+require 'optparse'
+
+path = File.expand_path '~/.git-credentials' # (1)
+OptionParser.new do |opts|
+ opts.banner = 'USAGE: git-credential-read-only [options] <action>'
+ opts.on('-f', '--file PATH', 'Specify path for backing store') do |argpath|
+ path = File.expand_path argpath
+ end
+end.parse!
+
+exit(0) unless ARGV[0].downcase == 'get' # (2)
+exit(0) unless File.exist? path
+
+known = {} # (3)
+while line = STDIN.gets
+ break if line.strip == ''
+ k,v = line.strip.split '=', 2
+ known[k] = v
+end
+
+File.readlines(path).each do |fileline| # (4)
+ prot,user,pass,host = fileline.scan(/^(.*?):\/\/(.*?):(.*?)@(.*)$/).first
+ if prot == known['protocol'] and host == known['host'] and user == known['username'] then
+ puts "protocol=#{prot}"
+ puts "host=#{host}"
+ puts "username=#{user}"
+ puts "password=#{pass}"
+ exit(0)
+ end
+end
+
+
+
+
+-
+
Hier ontleed (parse) ons die opdragreël-opsies, wat die gebruiker toelaat om die toevoerlêer te spesifiseer.
+Die verstelling is ~/.git-credentials.
+
+-
+
Hierdie program reageer slegs as die aksie get is en die agterliggende lêer bestaan.
+
+-
+
Hierdie lus (loop) lees vanaf stdin totdat die eerste leë reël bereik word.
+Die toevoer word in die known hutskrabbel (hash) gestoor vir latere verwysing.
+
+-
+
Hierdie lus lees die inhoud van die stoorlêer en soek na ooreenkomste (matches).
+As die protokol, gasheer en gebruikersnaam in known met hierdie reël ooreenstem, druk die program die resultate na stdout en sluit af.
+
+
+
+
+
Ons sal ons helper as git-credential-read-only stoor, dit iewers in ons PATH plaas en dit as uitvoerbaar (executable) merk.
+Hier is hoe 'n interaktiewe sessie lyk:
+
+
+
+
$ git credential-read-only --file=/mnt/shared/creds get
+protocol=https
+host=mygithost
+username=bob
+
+protocol=https
+host=mygithost
+username=bob
+password=s3cre7
+
+
+
+
Aangesien sy naam met “git-” begin, kan ons die eenvoudige sintaksis vir die konfigurasiewaarde gebruik:
+
+
+
+
$ git config --global credential.helper 'read-only --file /mnt/shared/creds'
+
+
+
+
Soos jy kan sien, is die uitbreiding van hierdie stelsel redelik eenvoudig, en kan dit 'n paar algemene probleme vir jou en jou span oplos.
+
+
Gevorderde Saamsmelting (Advanced Merging)
+
+
Saamsmelting (merging) in Git is tipies redelik maklik.
+Omdat Git dit maklik maak om 'n ander tak verskeie kere in te smelt, beteken dit dat jy 'n baie langlewende tak kan hê, maar jy kan dit op datum hou soos jy aangaan, en gereeld klein konflikte oplos in plaas daarvan om deur een enorme konflik aan die einde van die reeks verras te word.
+
+
Soms kom daar egter netelige konflikte voor.
+Anders as sommige ander weergawebeheerstelsels (version control systems), probeer Git nie te slim wees oor die oplossing van saamsmeltingskonflikte (merge conflicts) nie.
+Git se filosofie is om slim te wees oor die bepaling van wanneer 'n saamsmeltingsoplossing ondubbelsinnig is, maar as daar 'n konflik is, probeer dit nie slim wees om dit outomaties op te los nie.
+Daarom, as jy te lank wag om twee takke wat vinnig afwyk saam te smelt, kan jy 'n paar probleme ondervind.
+
+
In hierdie afdeling sal ons kyk na wat sommige van daardie probleme kan wees en watter gereedskap Git jou gee om hierdie meer netelige situasies te help hanteer.
+Ons sal ook sommige van die verskillende, nie-standaard tipes saamsmeltings wat jy kan doen dek, asook kyk hoe om saamsmeltings wat jy reeds gedoen het, ongedaan te maak.
+
+
Saamsmeltingskonflikte (Merge Conflicts)
+
+
+
Eerstens, as dit enigsins moontlik is, probeer seker maak dat jou werkgids (working directory) skoon is voordat jy 'n saamsmelting doen wat konflikte kan hê.
+As jy werk aan die gang het, lê dit óf vas (commit) na 'n tydelike tak óf bêre dit (stash).
+Dit sorg dat jy enigiets wat jy hier probeer, ongedaan kan maak (undo).
+As jy ongestoorde veranderings in jou werkgids het wanneer jy 'n saamsmelting probeer, kan sommige van hierdie wenke jou help om daardie werk te behou.
+
+
+
Kom ons stap deur 'n baie eenvoudige voorbeeld.
+Ons het 'n super eenvoudige Ruby-lêer wat 'hello world' druk.
+
+
+
+
#! /usr/bin/env ruby
+
+def hello
+ puts 'hello world'
+end
+
+hello()
+
+
+
+
In ons bewaarplek skep ons 'n nuwe tak genaamd whitespace en gaan voort om al die Unix-reëleindes (line endings) na DOS-reëleindes te verander, wat in wese elke reël van die lêer verander, maar net met witruimte (whitespace).
+Dan verander ons die reël “hello world” na “hello mundo”.
+
+
+
+
$ git checkout -b whitespace
+Switched to a new branch 'whitespace'
+
+$ unix2dos hello.rb
+unix2dos: converting file hello.rb to DOS format ...
+$ git commit -am 'Convert hello.rb to DOS'
+[whitespace 3270f76] Convert hello.rb to DOS
+ 1 file changed, 7 insertions(+), 7 deletions(-)
+
+$ vim hello.rb
+$ git diff -b
+diff --git a/hello.rb b/hello.rb
+index ac51efd..e85207e 100755
+--- a/hello.rb
++++ b/hello.rb
+@@ -1,7 +1,7 @@
+ #! /usr/bin/env ruby
+
+ def hello
+- puts 'hello world'
++ puts 'hello mundo'^M
+ end
+
+ hello()
+
+$ git commit -am 'Use Spanish instead of English'
+[whitespace 6d338d2] Use Spanish instead of English
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+
+
+
Nou skakel ons terug na ons master tak en voeg 'n bietjie dokumentasie vir die funksie by.
+
+
+
+
$ git checkout master
+Switched to branch 'master'
+
+$ vim hello.rb
+$ git diff
+diff --git a/hello.rb b/hello.rb
+index ac51efd..36c06c8 100755
+--- a/hello.rb
++++ b/hello.rb
+@@ -1,5 +1,6 @@
+ #! /usr/bin/env ruby
+
++# prints out a greeting
+ def hello
+ puts 'hello world'
+ end
+
+$ git commit -am 'Add comment documenting the function'
+[master bec6336] Add comment documenting the function
+ 1 file changed, 1 insertion(+)
+
+
+
+
Nou probeer ons ons whitespace tak insmelt en ons sal konflikte kry as gevolg van die witruimteveranderings.
+
+
+
+
$ git merge whitespace
+Auto-merging hello.rb
+CONFLICT (content): Merge conflict in hello.rb
+Automatic merge failed; fix conflicts and then commit the result.
+
+
+
+
Afbreek van 'n Saamsmelting (Aborting a Merge)
+
+
Ons het nou 'n paar opsies.
+Kom ons dek eers hoe om uit hierdie situasie te kom.
+As jy dalk nie konflikte verwag het nie en nog nie heeltemal die situasie wil hanteer nie, kan jy eenvoudig die saamsmelting ongedaan maak met git merge --abort.
+
+
+
+
$ git status -sb
+## master
+UU hello.rb
+
+$ git merge --abort
+
+$ git status -sb
+## master
+
+
+
+
Die git merge --abort opsie probeer terugkeer na jou toestand voor jy die saamsmelting geloop het.
+Die enigste gevalle waar dit dalk nie perfek sal kan doen nie, is as jy ongebêrede (unstashed), onvasgelegde (uncommitted) veranderings in jou werkgids gehad het toe jy dit uitgevoer het; andersins behoort dit goed te werk.
+
+
+
As jy om die een of ander rede net van voor af wil begin, kan jy ook git reset --hard HEAD uitvoer, en jou bewaarplek sal terug wees na die laaste vasgelegde toestand.
+Onthou dat enige onvasgelegde werk verlore sal gaan, so maak seker jy wil nie enige van jou veranderings hê nie.
+
+
+
+
Ignorering van Witruimte (Ignoring Whitespace)
+
+
In hierdie spesifieke geval is die konflikte witruimteverwante.
+Ons weet dit omdat die geval eenvoudig is, maar dit is ook redelik maklik om in werklike gevalle te sien wanneer daar na die konflik gekyk word, omdat elke reël aan die een kant verwyder word en aan die ander kant weer bygevoeg word.
+By verstek sien Git al hierdie reëls as gewysig, so dit kan nie die lêers saamsmelt nie.
+
+
+
Die verstek saamsmeltingstrategie kan egter argumente neem, en 'n paar daarvan gaan oor die behoorlike ignorering van witruimteveranderings.
+As jy sien dat jy baie witruimte-kwessies in 'n saamsmelting het, kan jy dit eenvoudig afbreek en dit weer doen, hierdie keer met -Xignore-all-space of -Xignore-space-change.
+Die eerste opsie ignoreer witruimte heeltemal wanneer reëls vergelyk word, die tweede beskou reekse van een of meer witruimtekarakters as ekwivalent.
+
+
+
+
$ git merge -Xignore-space-change whitespace
+Auto-merging hello.rb
+Merge made by the 'recursive' strategy.
+ hello.rb | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+
+
+
Aangesien die werklike lêerveranderings in hierdie geval nie botsend was nie, smelt alles net mooi saam sodra ons die witruimteveranderings ignoreer.
+
+
+
Dit is 'n lewensredder as jy iemand op jou span het wat daarvan hou om soms alles te herformateer van spasies na keepspasies (tabs) of andersom.
+
+
+
+
Handmatige Lêer Hersaamsmelting (Manual File Re-merging)
+
+
Alhoewel Git witruimte-voorbewerking redelik goed hanteer, is daar ander tipes veranderings wat Git dalk nie outomaties kan hanteer nie, maar skripbare regstellings is.
+As 'n voorbeeld, kom ons gee voor dat Git nie die witruimteverandering kon hanteer nie en ons dit per hand moes doen.
+
+
+
Wat ons regtig moet doen, is om die lêer wat ons probeer insmelt deur 'n dos2unix program te laat loop voordat ons die werklike lêersaamsmelting probeer.
+So hoe sou ons dit doen?
+
+
+
Eerstens kom ons in die saamsmeltingskonflik-toestand.
+Dan wil ons afskrifte kry van ons weergawe van die lêer, hul weergawe (van die tak wat ons insmelt) en die gemeenskaplike weergawe (vanwaar beide kante afgetak het).
+Dan wil ons óf hul kant óf ons kant regmaak en die saamsmelting weer net vir hierdie enkele lêer probeer.
+
+
+
Om die drie lêerweergawes te kry, is eintlik redelik maklik.
+Git stoor al hierdie weergawes in die indeks onder “stages” (stadia) wat elkeen nommers aan hulle gekoppel het.
+Stadium 1 is die gemeenskaplike voorouer, stadium 2 is jou weergawe en stadium 3 is van die MERGE_HEAD, die weergawe wat jy insmelt (“theirs”).
+
+
+
Jy kan 'n afskrif van elkeen van hierdie weergawes van die konflik-lêer onttrek met die git show opdrag en 'n spesiale sintaksis.
+
+
+
+
$ git show :1:hello.rb > hello.common.rb
+$ git show :2:hello.rb > hello.ours.rb
+$ git show :3:hello.rb > hello.theirs.rb
+
+
+
+
As jy 'n bietjie meer hardekern (hard core) wil raak, kan jy ook die ls-files -u loodgietersopdrag (plumbing command) gebruik om die werklike SHA-1’s van die Git-blobs vir elkeen van hierdie lêers te kry.
+
+
+
+
$ git ls-files -u
+100755 ac51efdc3df4f4fd328d1a02ad05331d8e2c9111 1 hello.rb
+100755 36c06c8752c78d2aff89571132f3bf7841a7b5c3 2 hello.rb
+100755 e85207e04dfdd5eb0a1e9febbc67fd837c44a1cd 3 hello.rb
+
+
+
+
Die :1:hello.rb is net 'n kortpad om daardie blob SHA-1 op te soek.
+
+
+
Noudat ons die inhoud van al drie stadia in ons werkgids het, kan ons hul eie (theirs) handmatig regmaak om die witruimtekwessie op te los en die lêer weer in te smelt (re-merge) met die min bekende git merge-file opdrag wat net dit doen.
+
+
+
+
$ dos2unix hello.theirs.rb
+dos2unix: converting file hello.theirs.rb to Unix format ...
+
+$ git merge-file -p \
+ hello.ours.rb hello.common.rb hello.theirs.rb > hello.rb
+
+$ git diff -b
+diff --cc hello.rb
+index 36c06c8,e85207e..0000000
+--- a/hello.rb
++++ b/hello.rb
+@@@ -1,8 -1,7 +1,8 @@@
+ #! /usr/bin/env ruby
+
+ +# prints out a greeting
+ def hello
+- puts 'hello world'
++ puts 'hello mundo'
+ end
+
+ hello()
+
+
+
+
Op hierdie punt het ons die lêer mooi saamgesmelt.
+Trouens, dit werk eintlik beter as die ignore-space-change opsie omdat dit eintlik die witruimteveranderings voor saamsmelting regmaak in plaas daarvan om dit bloot te ignoreer.
+In die ignore-space-change saamsmelting het ons eintlik met 'n paar reëls met DOS-reëleindes geëindig, wat dinge gemeng gemaak het.
+
+
+
As jy 'n idee wil kry voordat jy hierdie vaslegging finaliseer oor wat werklik tussen die een of ander kant verander het, kan jy git diff vra om te vergelyk wat in jou werkgids is wat jy op die punt staan om as resultaat van die saamsmelting vas te lê teen enige van hierdie stadia.
+Kom ons gaan deur hulle almal.
+
+
+
Om jou resultaat te vergelyk met wat jy in jou tak gehad het voor die saamsmelting, met ander woorde, om te sien wat die saamsmelting ingestel het, kan jy git diff --ours uitvoer:
+
+
+
+
$ git diff --ours
+* Unmerged path hello.rb
+diff --git a/hello.rb b/hello.rb
+index 36c06c8..44d0a25 100755
+--- a/hello.rb
++++ b/hello.rb
+@@ -2,7 +2,7 @@
+
+ # prints out a greeting
+ def hello
+- puts 'hello world'
++ puts 'hello mundo'
+ end
+
+ hello()
+
+
+
+
So hier kan ons maklik sien dat wat in ons tak gebeur het, dit wat ons werklik aan hierdie lêer instel met hierdie saamsmelting, is die verandering van daardie enkele reël.
+
+
+
As ons wil sien hoe die resultaat van die saamsmelting verskil het van wat aan hul kant was, kan jy git diff --theirs uitvoer.
+In hierdie en die volgende voorbeeld moet ons -b gebruik om die witruimte te verwyder, want ons vergelyk dit met wat in Git is, nie ons skoongemaakte hello.theirs.rb lêer nie.
+
+
+
+
$ git diff --theirs -b
+* Unmerged path hello.rb
+diff --git a/hello.rb b/hello.rb
+index e85207e..44d0a25 100755
+--- a/hello.rb
++++ b/hello.rb
+@@ -1,5 +1,6 @@
+ #! /usr/bin/env ruby
+
++# prints out a greeting
+ def hello
+ puts 'hello mundo'
+ end
+
+
+
+
Ten slotte kan jy sien hoe die lêer van albei kante af verander het met git diff --base.
+
+
+
+
$ git diff --base -b
+* Unmerged path hello.rb
+diff --git a/hello.rb b/hello.rb
+index ac51efd..44d0a25 100755
+--- a/hello.rb
++++ b/hello.rb
+@@ -1,7 +1,8 @@
+ #! /usr/bin/env ruby
+
++# prints out a greeting
+ def hello
+- puts 'hello world'
++ puts 'hello mundo'
+ end
+
+ hello()
+
+
+
+
Op hierdie punt kan ons die git clean opdrag gebruik om die ekstra lêers uit te vee wat ons geskep het om die handmatige saamsmelting te doen maar wat nie meer nodig is nie.
+
+
+
+
$ git clean -f
+Removing hello.common.rb
+Removing hello.ours.rb
+Removing hello.theirs.rb
+
+
+
+
+
Uitcheck van Konflikte (Checking Out Conflicts)
+
+
Miskien is ons om die een of ander rede nie tevrede met die oplossing op hierdie punt nie, of miskien het die handmatige redigering van een of albei kante steeds nie goed gewerk nie en benodig ons meer konteks.
+
+
+
Kom ons verander die voorbeeld effens.
+Vir hierdie voorbeeld het ons twee langlewende takke wat elkeen 'n paar vasleggings daarin het, maar wat 'n wettige inhoudskonflik skep wanneer dit saamgesmelt word.
+
+
+
+
$ git log --graph --oneline --decorate --all
+* f1270f7 (HEAD, master) Update README
+* 9af9d3b Create README
+* 694971d Update phrase to 'hola world'
+| * e3eb223 (mundo) Add more tests
+| * 7cff591 Create initial testing script
+| * c3ffff1 Change text to 'hello mundo'
+|/
+* b7dcc89 Initial hello world code
+
+
+
+
Ons het nou drie unieke vasleggings wat slegs op die master tak leef en drie ander wat op die mundo tak leef.
+As ons probeer om die mundo tak in te smelt, kry ons 'n konflik.
+
+
+
+
$ git merge mundo
+Auto-merging hello.rb
+CONFLICT (content): Merge conflict in hello.rb
+Automatic merge failed; fix conflicts and then commit the result.
+
+
+
+
Ons wil graag sien wat die saamsmeltingskonflik is.
+As ons die lêer oopmaak, sal ons so iets so sien:
+
+
+
+
#! /usr/bin/env ruby
+
+def hello
+<<<<<<< HEAD
+ puts 'hola world'
+=======
+ puts 'hello mundo'
+>>>>>>> mundo
+end
+
+hello()
+
+
+
+
Beide kante van die saamsmelting het inhoud by hierdie lêer bygevoeg, maar sommige van die vasleggings het die lêer in dieselfde plek gewysig wat hierdie konflik veroorsaak het.
+
+
+
Kom ons verken 'n paar instrumente wat jy nou tot jou beskikking het om te bepaal hoe hierdie konflik ontstaan het.
+Miskien is dit nie voor die hand liggend hoe presies jy hierdie konflik moet oplos nie.
+Jy benodig meer konteks.
+
+
+
Een nuttige instrument is git checkout met die --conflict opsie.
+Dit sal die lêer weer heruitcheck (re-checkout) en die saamsmeltingskonflikmerkers vervang.
+Dit kan nuttig wees as jy die merkers wil terugstel en weer probeer om dit op te los.
+
+
+
Jy kan --conflict óf diff3 óf merge (wat die verstek is) aangee.
+As jy dit diff3 gee, sal Git 'n effens ander weergawe van konflikmerkers gebruik, wat vir jou nie net die “ours” en “theirs” weergawes gee nie, maar ook die “base” weergawe inlyn om jou meer konteks te gee.
+
+
+
+
$ git checkout --conflict=diff3 hello.rb
+
+
+
+
Sodra ons dit uitvoer, sal die lêer in plaas daarvan so lyk:
+
+
+
+
#! /usr/bin/env ruby
+
+def hello
+<<<<<<< ours
+ puts 'hola world'
+||||||| base
+ puts 'hello world'
+=======
+ puts 'hello mundo'
+>>>>>>> theirs
+end
+
+hello()
+
+
+
+
As jy van hierdie formaat hou, kan jy dit as die verstek stel vir toekomstige saamsmeltingskonflikte deur die merge.conflictstyle instelling op diff3 te stel.
+
+
+
+
$ git config --global merge.conflictstyle diff3
+
+
+
+
Die git checkout opdrag kan ook --ours en --theirs opsies neem, wat 'n baie vinnige manier kan wees om net die een of die ander kant te kies sonder om dinge hoegenaamd saam te smelt.
+
+
+
Dit kan veral nuttig wees vir konflikte van binêre lêers waar jy eenvoudig een kant kan kies, of waar jy net sekere lêers van 'n ander tak wil insmelt — jy kan die saamsmelting doen en dan sekere lêers van die een of die ander kant uitcheck voor vaslegging.
+
+
+
+
Saamsmeltingslogboek (Merge Log)
+
+
Nog 'n nuttige instrument by die oplossing van saamsmeltingskonflikte is git log.
+Dit kan jou help om konteks te kry oor wat tot die konflikte kon bygedra het.
+Om 'n bietjie geskiedenis te hersien om te onthou hoekom twee lyne van ontwikkeling aan dieselfde area van kode geraak het, kan soms baie nuttig wees.
+
+
+
Om 'n volledige lys te kry van al die unieke vasleggings wat ingesluit was in enige tak betrokke by hierdie saamsmelting, kan ons die “driedubbelpunt” (triple dot) sintaksis gebruik wat ons geleer het in }}">Driedubbelpunt (Triple Dot).
+
+
+
+
$ git log --oneline --left-right HEAD...MERGE_HEAD
+< f1270f7 Update README
+< 9af9d3b Create README
+< 694971d Update phrase to 'hola world'
+> e3eb223 Add more tests
+> 7cff591 Create initial testing script
+> c3ffff1 Change text to 'hello mundo'
+
+
+
+
Dit is 'n mooi lys van die totale ses vasleggings wat betrokke was, sowel as op watter lyn van ontwikkeling elke vaslegging was.
+
+
+
Ons kan dit egter verder vereenvoudig om vir ons baie meer spesifieke konteks te gee.
+As ons die --merge opsie by git log voeg, sal dit net die vasleggings wys in enige kant van die saamsmelting wat 'n lêer raak wat tans in konflik is.
+
+
+
+
$ git log --oneline --left-right --merge
+< 694971d Update phrase to 'hola world'
+> c3ffff1 Change text to 'hello mundo'
+
+
+
+
As jy dit in plaas daarvan met die -p opsie uitvoer, kry jy net die diffs na die lêer wat uiteindelik in konflik was.
+Dit kan werklik nuttig wees om jou vinnig die konteks te gee wat jy nodig het om te help verstaan hoekom iets bots en hoe om dit intelligenter op te los.
+
+
+
+
+
+
Aangesien Git enige saamsmeltingsresultate voorberei (stages) wat suksesvol is, kry jy slegs wat tans nog in konflik is as jy git diff uitvoer terwyl jy in 'n botsende saamsmeltingstoestand is.
+Dit kan nuttig wees om te sien wat jy nog moet oplos.
+
+
+
Wanneer jy git diff direk na 'n saamsmeltingskonflik uitvoer, sal dit jou inligting gee in 'n taamlik unieke diff-afvoerformaat.
+
+
+
+
$ git diff
+diff --cc hello.rb
+index 0399cd5,59727f0..0000000
+--- a/hello.rb
++++ b/hello.rb
+@@@ -1,7 -1,7 +1,11 @@@
+ #! /usr/bin/env ruby
+
+ def hello
+++<<<<<<< HEAD
+ + puts 'hola world'
+++=======
++ puts 'hello mundo'
+++>>>>>>> mundo
+ end
+
+ hello()
+
+
+
+
Die formaat word “Combined Diff” genoem en gee vir jou twee kolomme data langs elke reël.
+Die eerste kolom wys jou of daardie reël verskil (bygevoeg of verwyder) tussen die “ours” tak en die lêer in jou werkgids, en die tweede kolom doen dieselfde tussen die “theirs” tak en jou werkgidskopie.
+
+
+
So in daardie voorbeeld kan jy sien dat die <<<<<<< en >>>>>>> reëls in die werkkopie is, maar nie in enige van die kante van die saamsmelting was nie.
+Dit maak sin, want die saamsmeltingsinstrument het dit daar ingedruk vir ons konteks, maar dit word van ons verwag om dit te verwyder.
+
+
+
As ons die konflik oplos en git diff weer uitvoer, sal ons dieselfde ding sien, maar dit is 'n bietjie nuttiger.
+
+
+
+
$ vim hello.rb
+$ git diff
+diff --cc hello.rb
+index 0399cd5,59727f0..0000000
+--- a/hello.rb
++++ b/hello.rb
+@@@ -1,7 -1,7 +1,7 @@@
+ #! /usr/bin/env ruby
+
+ def hello
+- puts 'hola world'
+ - puts 'hello mundo'
+++ puts 'hola mundo'
+ end
+
+ hello()
+
+
+
+
Dit wys ons dat “hola world” aan ons kant was maar nie in die werkkopie nie, dat “hello mundo” aan hul kant was maar nie in die werkkopie nie, en uiteindelik dat “hola mundo” nie aan enige kant was nie maar nou in die werkkopie is.
+Dit kan nuttig wees om te hersien voordat die resolusie vasgelê word.
+
+
+
Jy kan dit ook van die git log vir enige saamsmelting kry om te sien hoe iets na die tyd opgelos is.
+Git sal hierdie formaat uitvoer as jy git show op 'n saamsmeltingsvaslegging (merge commit) uitvoer, of as jy 'n --cc opsie by 'n git log -p voeg (wat by verstek slegs pleisters wys vir nie-saamsmeltingsvasleggings).
+
+
+
+
$ git log --cc -p -1
+commit 14f41939956d80b9e17bb8721354c33f8d5b5a79
+Merge: f1270f7 e3eb223
+Author: Scott Chacon <schacon@gmail.com>
+Date: Fri Sep 19 18:14:49 2014 +0200
+
+ Merge branch 'mundo'
+
+ Conflicts:
+ hello.rb
+
+diff --cc hello.rb
+index 0399cd5,59727f0..e1d0799
+--- a/hello.rb
++++ b/hello.rb
+@@@ -1,7 -1,7 +1,7 @@@
+ #! /usr/bin/env ruby
+
+ def hello
+- puts 'hola world'
+ - puts 'hello mundo'
+++ puts 'hola mundo'
+ end
+
+ hello()
+
+
+
+
+
Saamsmeltings Ongedaan Maak (Undoing Merges)
+
+
Noudat jy weet hoe om 'n saamsmeltingsvaslegging te skep, sal jy waarskynlik 'n paar per ongeluk maak.
+Een van die wonderlike dinge van werk met Git is dat dit oukei is om foute te maak, want dit is moontlik (en in baie gevalle maklik) om dit reg te maak.
+
+
+
Saamsmeltingsvasleggings is nie anders nie.
+Kom ons sê jy het werk op 'n onderwerp-tak (topic branch) begin, dit per ongeluk in master ingesmelt, en nou lyk jou vasleggingsgeskiedenis soos volg:
+
+
+
+
}}" alt="Accidental merge commit">
+
+
Figure 168. Accidental merge commit
+
+
+
Daar is twee maniere om hierdie probleem te benader, afhangende van wat jou gewenste uitkoms is.
+
+
+
Maak die verwysings reg (Fix the references)
+
+
As die ongewenste saamsmeltingsvaslegging slegs op jou plaaslike bewaarplek bestaan, is die maklikste en beste oplossing om die takke te skuif sodat hulle wys na waar jy wil hê hulle moet.
+In die meeste gevalle, as jy die foutiewe git merge opvolg met git reset --hard HEAD~, sal dit die takwysers herstel sodat hulle so lyk:
+
+
+
+
}}" alt="History after `git reset --hard HEAD~`">
+
+
Figure 169. History after git reset --hard HEAD~
+
+
+
+
Ons het vroeër in }}">Reset Ontmystifiseer (Reset Demystified) reset gedek, so dit behoort nie te moeilik te wees om uit te vind wat hier aangaan nie.
+Hier is 'n vinnige opknapping: reset --hard gaan gewoonlik deur drie stappe:
+
+
+
+-
+
Skuif die tak waarna HEAD wys.
+In hierdie geval wil ons master skuif na waar dit was voor die saamsmeltingsvaslegging (C6).
+
+-
+
Laat die indeks soos HEAD lyk.
+
+-
+
Laat die werkgids soos die indeks lyk.
+
+
+
+
+
Die nadeel van hierdie benadering is dat dit geskiedenis herskryf, wat problematies kan wees met 'n gedeelde bewaarplek.
+Gaan kyk na }}">Die Gevare van Rebasing (The Perils of Rebasing) vir meer inligting oor wat kan gebeur; die kort weergawe is dat as ander mense die vasleggings het wat jy herskryf, moet jy waarskynlik reset vermy.
+Hierdie benadering sal ook nie werk as enige ander vasleggings geskep is sedert die saamsmelting nie; om die verwysings te skuif sal daardie veranderings effektief verloor.
+
+
+
+
Draai die vaslegging om (Reverse the commit)
+
+
As die verskuiwing van die takwysers nie vir jou gaan werk nie, gee Git jou die opsie om 'n nuwe vaslegging te maak wat al die veranderings van 'n bestaande een ongedaan maak.
+Git noem hierdie aksie 'n “revert” (terugrol), en in hierdie spesifieke scenario sou jy dit so aanroep:
+
+
+
+
$ git revert -m 1 HEAD
+[master b1d8379] Revert "Merge branch 'topic'"
+
+
+
+
Die -m 1 vlag dui aan watter ouer die “hooflyn” (mainline) is en gehou moet word.
+Wanneer jy 'n saamsmelting na HEAD (git merge topic) aanroep, het die nuwe vaslegging twee ouers: die eerste een is HEAD (C6), en die tweede is die punt van die tak wat ingesmelt word (C4).
+In hierdie geval wil ons al die veranderings wat ingestel is deur ouer #2 in te smelt (C4) ongedaan maak, terwyl al die inhoud van ouer #1 (C6) behoue bly.
+
+
+
Die geskiedenis met die revert-vaslegging lyk soos volg:
+
+
+
+
}}" alt="History after `git revert -m 1`">
+
+
Figure 170. History after git revert -m 1
+
+
+
+
Die nuwe vaslegging ^M het presies dieselfde inhoud as C6, so as jy hiervandaan begin is dit asof die saamsmelting nooit gebeur het nie, behalwe dat die nou-ongesmelte vasleggings steeds in HEAD se geskiedenis is.
+Git sal verward wees as jy weer topic in master probeer insmelt:
+
+
+
+
$ git merge topic
+Already up-to-date.
+
+
+
+
Daar is niks in topic wat nie reeds vanaf master bereikbaar is nie.
+Wat erger is, is as jy werk by topic voeg en weer insmelt, sal Git slegs die veranderings sedert die ongedaan-gemaakte saamsmelting bring:
+
+
+
+
}}" alt="History with a bad merge">
+
+
Figure 171. History with a bad merge
+
+
+
Die beste manier om hierom te kom is om die oorspronklike saamsmelting on-terug-te-rol (un-revert), aangesien jy nou die veranderings wil inbring wat teruggerol (reverted out) was, en dan 'n nuwe saamsmeltingsvaslegging te skep:
+
+
+
+
$ git revert ^M
+[master 09f0126] Revert "Revert "Merge branch 'topic'""
+$ git merge topic
+
+
+
+
+
}}" alt="History after re-merging a reverted merge">
+
+
Figure 172. History after re-merging a reverted merge
+
+
+
In hierdie voorbeeld kanselleer M en ^M mekaar uit.
+^^M smelt effektief die veranderings van C3 en C4 in, en C8 smelt die veranderings van C7 in, so nou is topic ten volle ingesmelt.
+
+
+
+
Ander Tipes Saamsmeltings (Other Types of Merges)
+
+
Tot dusver het ons die normale saamsmelting van twee takke gedek, wat normaalweg hanteer word met wat die “rekursiewe” (recursive) strategie van saamsmelting genoem word.
+Daar is egter ander maniere om takke saam te smelt.
+Kom ons dek 'n paar van hulle vinnig.
+
+
+
Voorkeur vir Onse of Hulle S’n (Our or Theirs Preference)
+
+
Eerstens is daar nog 'n nuttige ding wat ons met die normale “rekursiewe” modus van saamsmelting kan doen.
+Ons het reeds die ignore-all-space en ignore-space-change opsies gesien wat met 'n -X deurgegee word, maar ons kan Git ook sê om die een of die ander kant te bevoordeel as dit 'n konflik sien.
+
+
+
By verstek, wanneer Git 'n konflik sien tussen twee takke wat saamgesmelt word, sal dit saamsmeltingskonflikmerkers in jou kode voeg en die lêer as botsend merk en jou dit laat oplos.
+As jy verkies dat Git bloot 'n spesifieke kant kies en die ander kant ignoreer in plaas daarvan om jou die konflik handmatig te laat oplos, kan jy vir die merge opdrag óf 'n -Xours óf -Xtheirs aangee.
+
+
+
As Git dit sien, sal dit nie konflikmerkers byvoeg nie.
+Enige verskille wat saamsmeltbaar is, sal dit saamsmelt.
+Enige verskille wat bots, sal dit bloot in die geheel die kant kies wat jy spesifiseer, insluitend binêre lêers.
+
+
+
As ons teruggaan na die “hello world” voorbeeld wat ons vroeër gebruik het, kan ons sien dat insmelting in ons tak konflikte veroorsaak.
+
+
+
+
$ git merge mundo
+Auto-merging hello.rb
+CONFLICT (content): Merge conflict in hello.rb
+Resolved 'hello.rb' using previous resolution.
+Automatic merge failed; fix conflicts and then commit the result.
+
+
+
+
As ons dit egter met -Xours of -Xtheirs uitvoer, gebeur dit nie.
+
+
+
+
$ git merge -Xours mundo
+Auto-merging hello.rb
+Merge made by the 'recursive' strategy.
+ hello.rb | 2 +-
+ test.sh | 2 ++
+ 2 files changed, 3 insertions(+), 1 deletion(-)
+ create mode 100644 test.sh
+
+
+
+
In daardie geval, in plaas daarvan om konflikmerkers in die lêer te kry met “hello mundo” aan die een kant en “hola world” aan die ander kant, sal dit bloot “hola world” kies.
+Alle ander nie-botsende veranderings in daardie tak word egter suksesvol ingesmelt.
+
+
+
Hierdie opsie kan ook deurgegee word na die git merge-file opdrag wat ons vroeër gesien het deur iets soos git merge-file --ours uit te voer vir individuele lêersaamsmeltings.
+
+
+
As jy so iets wil doen, maar nie eers wil hê Git moet probeer om veranderings van die ander kant af in te smelt nie, is daar 'n meer drakoniese opsie, wat die “ours” saamsmelting strategie is.
+Dit verskil van die “ours” rekursiewe saamsmelting opsie.
+
+
+
Dit sal basies 'n vals saamsmelting doen.
+Dit sal 'n nuwe saamsmeltingsvaslegging opneem met beide takke as ouers, maar dit sal nie eers na die tak kyk wat jy insmelt nie.
+Dit sal bloot die presiese kode in jou huidige tak as resultaat van die saamsmelting aanteken.
+
+
+
+
$ git merge -s ours mundo
+Merge made by the 'ours' strategy.
+$ git diff HEAD HEAD~
+$
+
+
+
+
Jy kan sien dat daar geen verskil is tussen die tak waarop ons was en die resultaat van die saamsmelting nie.
+
+
+
Dit kan dikwels nuttig wees om Git basies te mislei om te dink dat 'n tak reeds ingesmelt is wanneer jy later 'n saamsmelting doen.
+Byvoorbeeld, sê jy het van 'n release tak afgetak en werk daaraan gedoen wat jy op 'n stadium in jou master tak wil terugsmelt.
+Intussen moet 'n foutregstelling op master teruggeneem word (backported) na jou release tak.
+Jy kan die foutregstellingstak in die release tak insmelt en ook merge -s ours op dieselfde tak na jou master tak (selfs al is die foutregstelling reeds daar) sodat wanneer jy later die release tak weer insmelt, daar geen konflikte as gevolg van die foutregstelling sal wees nie.
+
+
+
+
Subboom-saamsmelting (Subtree Merging)
+
+
Die idee van 'n subboom-saamsmelting (subtree merge) is dat jy twee projekte het, en een van die projekte karteer na 'n subgids van die ander een.
+Wanneer jy 'n subboom-saamsmelting spesifiseer, is Git dikwels slim genoeg om uit te vind dat die een 'n subboom van die ander is en smelt dit dienooreenkomstig saam.
+
+
+
Ons sal deur 'n voorbeeld gaan waar ons 'n afsonderlike projek by 'n bestaande projek voeg en dan die kode van die tweede in 'n subgids van die eerste insmelt.
+
+
+
Eerstens sal ons die Rack-toepassing by ons projek voeg.
+Ons sal die Rack-projek as 'n afgeleë verwysing (remote reference) in ons eie projek byvoeg en dit dan in sy eie tak uittrek (checkout):
+
+
+
+
$ git remote add rack_remote https://github.com/rack/rack
+$ git fetch rack_remote --no-tags
+warning: no common commits
+remote: Counting objects: 3184, done.
+remote: Compressing objects: 100% (1465/1465), done.
+remote: Total 3184 (delta 1952), reused 2770 (delta 1675)
+Receiving objects: 100% (3184/3184), 677.42 KiB | 4 KiB/s, done.
+Resolving deltas: 100% (1952/1952), done.
+From https://github.com/rack/rack
+ * [new branch] build -> rack_remote/build
+ * [new branch] master -> rack_remote/master
+ * [new branch] rack-0.4 -> rack_remote/rack-0.4
+ * [new branch] rack-0.9 -> rack_remote/rack-0.9
+$ git checkout -b rack_branch rack_remote/master
+Branch rack_branch set up to track remote branch refs/remotes/rack_remote/master.
+Switched to a new branch "rack_branch"
+
+
+
+
Nou het ons die wortel (root) van die Rack-projek in ons rack_branch tak en ons eie projek in die master tak.
+As jy die een uittrek en dan die ander, kan jy sien dat hulle verskillende projekwortels het:
+
+
+
+
$ ls
+AUTHORS KNOWN-ISSUES Rakefile contrib lib
+COPYING README bin example test
+$ git checkout master
+Switched to branch "master"
+$ ls
+README
+
+
+
+
Hierdie is ietwat van 'n vreemde konsep.
+Nie al die takke in jou bewaarplek (repository) hoef eintlik takke van dieselfde projek te wees nie.
+Dit is nie algemeen nie, want dit is selde nuttig, maar dit is redelik maklik om takke te hê wat heeltemal verskillende geskiedenisse bevat.
+
+
+
In hierdie geval wil ons die Rack-projek in ons master projek intrek (pull) as 'n subgids.
+Ons kan dit in Git doen met git read-tree.
+Jy sal meer leer oor read-tree en sy vriende in }}">Git Internals, maar vir eers moet jy weet dat dit die wortelboom van een tak in jou huidige voorbereidingsarea (staging area) en werkgids inlees.
+Ons het pas teruggeskakel na jou master tak, en ons trek die rack_branch tak in die rack subgids van ons master tak van ons hoofprojek in:
+
+
+
+
$ git read-tree --prefix=rack/ -u rack_branch
+
+
+
+
Wanneer ons vaslê (commit), lyk dit asof ons al die Rack-lêers onder daardie subgids het — asof ons hulle vanuit 'n tarball ingekopieer het.
+Wat interessant raak, is dat ons redelik maklik veranderings van een van die takke na die ander kan insmelt.
+Dus, as die Rack-projek opdateer, kan ons stroomopwaartse (upstream) veranderings intrek deur na daardie tak oor te skakel en te pull:
+
+
+
+
$ git checkout rack_branch
+$ git pull
+
+
+
+
Dan kan ons daardie veranderings teruginsmelt in ons master tak.
+Om die veranderings in te trek en die vasleggingsboodskap vooraf in te vul, gebruik die --squash opsie, sowel as die rekursiewe saamsmeltingstrategie se -Xsubtree opsie.
+Die rekursiewe strategie is hier die verstek (default), maar ons sluit dit in vir duidelikheid.
+
+
+
+
$ git checkout master
+$ git merge --squash -s recursive -Xsubtree=rack rack_branch
+Squash commit -- not updating HEAD
+Automatic merge went well; stopped before committing as requested
+
+
+
+
Al die veranderings van die Rack-projek is ingesmelt en gereed om plaaslik vasgelê te word.
+Jy kan ook die teenoorgestelde doen — maak veranderings in die rack subgids van jou master tak en smelt dit dan later in jou rack_branch tak in om dit by die instandhouers in te dien of stroomopwaarts te push.
+
+
+
Dit gee ons 'n manier om 'n werkvloei te hê wat ietwat soortgelyk is aan die submodule-werkvloei sonder om submodules te gebruik (wat ons in }}">Submodules sal dek).
+Ons kan takke met ander verwante projekte in ons bewaarplek hou en dit af en toe as subbome in ons projek insmelt.
+Dit is op sommige maniere lekker, byvoorbeeld al die kode word op 'n enkele plek vasgelê.
+Dit het egter ander nadele deurdat dit 'n bietjie meer kompleks is en makliker is om foute te maak met die herintegrering van veranderings of deur per ongeluk 'n tak na 'n onverwante bewaarplek te push.
+
+
+
Nog 'n effens vreemde ding is dat om 'n verskil (diff) te kry tussen wat jy in jou rack subgids het en die kode in jou rack_branch tak — om te sien of jy hulle moet saamsmelt — kan jy nie die normale diff opdrag gebruik nie.
+In plaas daarvan moet jy git diff-tree uitvoer met die tak waarmee jy wil vergelyk:
+
+
+
+
$ git diff-tree -p rack_branch
+
+
+
+
Of, om dit wat in jou rack subgids is te vergelyk met wat die master tak op die bediener was die laaste keer wat jy afgelaai (fetched) het, kan jy die volgende uitvoer:
+
+
+
+
$ git diff-tree -p rack_remote/master
+
+
+
+
By now, you’ve learned most of the day-to-day commands and workflows that you need to manage or maintain a Git repository for your source code control.
+You’ve accomplished the basic tasks of tracking and committing files, and you’ve harnessed the power of the staging area and lightweight topic branching and merging.
Now you’ll explore a number of very powerful things that Git can do that you may not necessarily use on a day-to-day basis but that you may need at some point.
+Hersieningseleksie (Revision Selection)
+
+
Git laat jou toe om op 'n aantal maniere na 'n enkele vaslegging (commit), 'n stel vasleggings, of 'n reeks vasleggings te verwys.
+Hulle is nie noodwendig voor die hand liggend nie, maar dit is nuttig om dit te weet.
+
+
Enkel Hersienings (Single Revisions)
+
+
Jy kan natuurlik na enige enkele vaslegging verwys deur sy volle, 40-karakter SHA-1 huts (hash), maar daar is ook meer mensvriendelike maniere om na vasleggings te verwys.
+Hierdie afdeling skets die verskillende maniere waarop jy na enige vaslegging kan verwys.
+
+
+
Kort SHA-1 (Short SHA-1)
+
+
Git is slim genoeg om uit te vind na watter vaslegging jy verwys as jy die eerste paar karakters van die SHA-1 huts verskaf, solank daardie gedeeltelike huts ten minste vier karakters lank is en ondubbelsinnig is; dit wil sê, geen ander objek in die objekdatabasis kan 'n huts hê wat met dieselfde voorvoegsel (prefix) begin nie.
+
+
+
Byvoorbeeld, om 'n spesifieke vaslegging te ondersoek waar jy weet dat jy sekere funksionaliteit bygevoeg het, kan jy eers die git log opdrag uitvoer om die vaslegging op te spoor:
+
+
+
+
$ git log
+commit 734713bc047d87bf7eac9674765ae793478c50d3
+Author: Scott Chacon <schacon@gmail.com>
+Date: Fri Jan 2 18:32:33 2009 -0800
+
+ Fix refs handling, add gc auto, update tests
+
+commit d921970aadf03b3cf0e71becdaab3147ba71cdef
+Merge: 1c002dd... 35cfb2b...
+Author: Scott Chacon <schacon@gmail.com>
+Date: Thu Dec 11 15:08:43 2008 -0800
+
+ Merge commit 'phedders/rdocs'
+
+commit 1c002dd4b536e7479fe34593e72e6c6c1819e53b
+Author: Scott Chacon <schacon@gmail.com>
+Date: Thu Dec 11 14:58:32 2008 -0800
+
+ Add some blame and merge stuff
+
+
+
+
In hierdie geval, sê nou jy stel belang in die vaslegging waarvan die huts met 1c002dd… begin.
+Jy kan daardie vaslegging met enige van die volgende variasies van git show ondersoek (aannemende die korter weergawes is ondubbelsinnig):
+
+
+
+
$ git show 1c002dd4b536e7479fe34593e72e6c6c1819e53b
+$ git show 1c002dd4b536e7479f
+$ git show 1c002d
+
+
+
+
Git kan 'n kort, unieke afkorting vir jou SHA-1 waardes uitwerk.
+As jy --abbrev-commit na die git log opdrag aangee, sal die afvoer korter waardes gebruik maar dit uniek hou; dit gebruik by verstek sewe karakters maar maak dit langer indien nodig om die SHA-1 ondubbelsinnig te hou:
+
+
+
+
$ git log --abbrev-commit --pretty=oneline
+ca82a6d Change the version number
+085bb3b Remove unnecessary test code
+a11bef0 Initial commit
+
+
+
+
Oor die algemeen is agt tot tien karakters meer as genoeg om uniek binne 'n projek te wees.
+Byvoorbeeld, soos in Februarie 2019, het die Linux-kern (wat 'n redelike groot projek is) meer as 875 000 vasleggings en byna sewe miljoen objekte in sy objekdatabasis, met geen twee objekte waarvan die SHA-1’s in die eerste 12 karakters identies is nie.
+
+
+
+
+|
+ Note
+ |
+
+ 'N KORT NOTA OOR SHA-1
+
+ Baie mense raak op een of ander stadium bekommerd dat hulle, deur blote toeval, twee afsonderlike objekte in hul bewaarplek sal hê wat na dieselfde SHA-1 waarde huts.
+Wat dan?
+
+ As jy toevallig 'n objek vaslê wat na dieselfde SHA-1 waarde as 'n vorige verskillende objek in jou bewaarplek huts, sal Git die vorige objek wat reeds in jou Git-databasis is sien, aanneem dit was reeds geskryf en dit eenvoudig hergebruik.
+As jy daardie objek op 'n stadium weer probeer uittrek (check out), sal jy altyd die data van die eerste objek kry.
+
+ Jy moet egter bewus wees van hoe belaglik onwaarskynlik hierdie scenario is.
+Die SHA-1 opsomming (digest) is 20 grepe of 160 bisse.
+Die aantal ewekansig gehutste objekte wat nodig is om 'n 50% waarskynlikheid van 'n enkele botsing te verseker, is ongeveer 280 (die formule vir die bepaling van botsingswaarskynlikheid is p = (n(n-1)/2) * (1/2^160)).
+280 is 1.2 x 1024 of 1 miljoen miljard miljard.
+Dit is 1 200 keer die aantal sandkorrels op die aarde.
+
+ Hier is 'n voorbeeld om jou 'n idee te gee van wat dit sal neem om 'n SHA-1 botsing te kry.
+As al 6.5 miljard mense op aarde geprogrammeer het, en elke sekonde was elkeen besig om kode te produseer wat die ekwivalent was van die hele Linux-kern geskiedenis (6.5 miljoen Git objekte) en dit in een enorme Git bewaarplek in te push, sal dit ongeveer 2 jaar neem totdat daardie bewaarplek genoeg objekte bevat om 'n 50% waarskynlikheid van 'n enkele SHA-1 objek botsing te hê.
+'n Organiese SHA-1 botsing is dus minder waarskynlik as dat elke lid van jou programmeringspan op dieselfde aand in onverwante voorvalle deur wolwe aangeval en vermoor word.
+
+ As jy rekenaarkrag ter waarde van duisende rande daaraan wy, is dit moontlik om twee lêers met dieselfde huts te sintetiseer, soos in Februarie 2017 op https://shattered.io/ bewys is.
+Git beweeg daarna om SHA256 as die verstek huts-algoritme te gebruik, wat baie meer veerkragtig teen botsingsaanvalle is, en het kode in plek om hierdie aanval te help versag (hoewel dit nie heeltemal uitgeskakel kan word nie).
+ |
+
+
+
+
+
Takverwysings (Branch References)
+
+
Een eenvoudige manier om na 'n spesifieke vaslegging te verwys is as dit die vaslegging aan die punt van 'n tak is; in daardie geval kan jy eenvoudig die taknaam gebruik in enige Git-opdrag wat 'n verwysing na 'n vaslegging verwag.
+Byvoorbeeld, as jy die laaste vasleggingsobjek op 'n tak wil ondersoek, is die volgende opdragte ekwivalent, in die veronderstelling dat die topic1 tak na die vaslegging ca82a6d… wys:
+
+
+
+
$ git show ca82a6dff817ec66f44342007202690a93763949
+$ git show topic1
+
+
+
+
As jy wil sien na watter spesifieke SHA-1 'n tak wys, of as jy wil sien waarop enige van hierdie voorbeelde neerkom in terme van SHA-1’s, kan jy 'n Git loodgietersinstrument (plumbing tool) genaamd rev-parse gebruik.
+Jy kan }}">Git Internals bekyk vir meer inligting oor loodgietersinstrumente; basies, rev-parse bestaan vir laervlak bedrywighede en is nie ontwerp om in dag-tot-dag bedrywighede gebruik te word nie.
+Dit kan egter soms nuttig wees wanneer jy moet sien wat werklik aangaan.
+Hier kan jy rev-parse op jou tak uitvoer.
+
+
+
+
$ git rev-parse topic1
+ca82a6dff817ec66f44342007202690a93763949
+
+
+
+
RefLog Kortname (RefLog Shortnames)
+
+
Een van die dinge wat Git in die agtergrond doen terwyl jy werk, is om 'n “reflog” te hou — 'n logboek van waar jou HEAD en takverwysings die afgelope paar maande was.
+
+
+
Jy kan jou reflog sien deur git reflog te gebruik:
+
+
+
+
$ git reflog
+734713b HEAD@{0}: commit: Fix refs handling, add gc auto, update tests
+d921970 HEAD@{1}: merge phedders/rdocs: Merge made by the 'recursive' strategy.
+1c002dd HEAD@{2}: commit: Add some blame and merge stuff
+1c36188 HEAD@{3}: rebase -i (squash): updating HEAD
+95df984 HEAD@{4}: commit: # This is a combination of two commits.
+1c36188 HEAD@{5}: rebase -i (squash): updating HEAD
+7e05da5 HEAD@{6}: rebase -i (pick): updating HEAD
+
+
+
+
Elke keer as jou takpunt vir enige rede bygewerk word, stoor Git daardie inligting vir jou in hierdie tydelike geskiedenis.
+Jy kan jou reflog data gebruik om na ouer vasleggings ook te verwys.
+Byvoorbeeld, as jy die vyfde vorige waarde van die HEAD van jou bewaarplek wil sien, kan jy die @{5} verwysing gebruik wat jy in die reflog-afvoer sien:
+
+
+
+
Jy kan ook hierdie sintaksis gebruik om te sien waar 'n tak 'n sekere spesifieke tyd gelede was.
+Byvoorbeeld, om te sien waar jou master tak gister was, kan jy tik:
+
+
+
+
$ git show master@{yesterday}
+
+
+
+
Dit sal vir jou wys waar die punt van jou master tak gister was.
+Hierdie tegniek werk slegs vir data wat steeds in jou reflog is, so jy kan dit nie gebruik om vir vasleggings te soek wat ouer as 'n paar maande is nie.
+
+
+
Om reflog-inligting te sien wat soos die git log-afvoer geformateer is, kan jy git log -g uitvoer:
+
+
+
+
$ git log -g master
+commit 734713bc047d87bf7eac9674765ae793478c50d3
+Reflog: master@{0} (Scott Chacon <schacon@gmail.com>)
+Reflog message: commit: Fix refs handling, add gc auto, update tests
+Author: Scott Chacon <schacon@gmail.com>
+Date: Fri Jan 2 18:32:33 2009 -0800
+
+ Fix refs handling, add gc auto, update tests
+
+commit d921970aadf03b3cf0e71becdaab3147ba71cdef
+Reflog: master@{1} (Scott Chacon <schacon@gmail.com>)
+Reflog message: merge phedders/rdocs: Merge made by recursive.
+Author: Scott Chacon <schacon@gmail.com>
+Date: Thu Dec 11 15:08:43 2008 -0800
+
+ Merge commit 'phedders/rdocs'
+
+
+
+
Dit is belangrik om daarop te let dat reflog-inligting streng plaaslik is — dit is slegs 'n log van wat jy in jou bewaarplek gedoen het.
+Die verwysings sal nie dieselfde wees op iemand anders se kopie van die bewaarplek nie; ook, net nadat jy aanvanklik 'n bewaarplek gekloon het, sal jy 'n leë reflog hê, aangesien geen aktiwiteit nog in jou bewaarplek plaasgevind het nie.
+Deur git show HEAD@{2.months.ago} uit te voer, sal dit net die ooreenstemmende vaslegging wys as jy die projek ten minste twee maande gelede gekloon het — as jy dit enigsins meer onlangs as dit gekloon het, sal jy slegs jou eerste plaaslike vaslegging sien.
+
+
+
+
+|
+ Tip
+ |
+
+ Dink aan die reflog as Git se weergawe van dop-geskiedenis (shell history)
+
+ As jy 'n UNIX of Linux agtergrond het, kan jy aan die reflog dink as Git se weergawe van dop-geskiedenis, wat beklemtoon dat wat daar is, duidelik net vir jou en jou “sessie” relevant is, en niks te doen het met enigiemand anders wat dalk op dieselfde masjien werk nie.
+ |
+
+
+
+
+
+
+|
+ Note
+ |
+
+ Die ontsnapping van krulhakies in PowerShell
+
+ Wanneer jy PowerShell gebruik, is krulhakies soos { en } spesiale karakters en moet dit ontsnap word.
+Jy kan hulle ontsnap met 'n truteken (backtick) ` of die vasleggingsverwysing in aanhalingstekens plaas:
+
+
+ $ git show HEAD@{0} # sal NIE werk nie
+$ git show HEAD@`{0`} # OK
+$ git show "HEAD@{0}" # OK
+
+ |
+
+
+
+
+
Voorouer Verwysings (Ancestry References)
+
+
Die ander hoofmanier om 'n vaslegging te spesifiseer, is via sy voorouerskap.
+As jy 'n ^ (kappie/caret) aan die einde van 'n verwysing plaas, beskou Git dit as die ouer van daardie vaslegging.
+Gestel jy kyk na die geskiedenis van jou projek:
+
+
+
+
$ git log --pretty=format:'%h %s' --graph
+* 734713b Fix refs handling, add gc auto, update tests
+* d921970 Merge commit 'phedders/rdocs'
+|\
+| * 35cfb2b Some rdoc changes
+* | 1c002dd Add some blame and merge stuff
+|/
+* 1c36188 Ignore *.gem
+* 9b29157 Add open3_detach to gemspec file list
+
+
+
+
Dan kan jy die vorige vaslegging sien deur HEAD^ te spesifiseer, wat “die ouer van HEAD” beteken:
+
+
+
+
$ git show HEAD^
+commit d921970aadf03b3cf0e71becdaab3147ba71cdef
+Merge: 1c002dd... 35cfb2b...
+Author: Scott Chacon <schacon@gmail.com>
+Date: Thu Dec 11 15:08:43 2008 -0800
+
+ Merge commit 'phedders/rdocs'
+
+
+
+
+
+|
+ Note
+ |
+
+ Die ontsnapping van die kappie op Windows
+
+ Op Windows in cmd.exe is ^ 'n spesiale karakter en moet dit anders behandel word.
+Jy kan dit of verdubbel of die vasleggingsverwysing in aanhalingstekens plaas:
+
+
+ $ git show HEAD^ # sal NIE werk op Windows nie
+$ git show HEAD^^ # OK
+$ git show "HEAD^" # OK
+
+ |
+
+
+
+
+
Jy kan ook 'n nommer na die ^ spesifiseer om te identifiseer watter ouer jy wil hê; byvoorbeeld, d921970^2 beteken “die tweede ouer van d921970.”
+Hierdie sintaksis is slegs nuttig vir saamsmeltingsvasleggings (merge commits), wat meer as een ouer het — die eerste ouer van 'n saamsmeltingsvaslegging is vanaf die tak waarop jy was toe jy saamgesmelt het (dikwels master), terwyl die tweede ouer van 'n saamsmeltingsvaslegging vanaf die tak is wat ingesmelt is (sê nou, topic):
+
+
+
+
$ git show d921970^
+commit 1c002dd4b536e7479fe34593e72e6c6c1819e53b
+Author: Scott Chacon <schacon@gmail.com>
+Date: Thu Dec 11 14:58:32 2008 -0800
+
+ Add some blame and merge stuff
+
+$ git show d921970^2
+commit 35cfb2b795a55793d7cc56a6cc2060b4bb732548
+Author: Paul Hedderly <paul+git@mjr.org>
+Date: Wed Dec 10 22:22:03 2008 +0000
+
+ Some rdoc changes
+
+
+
+
Die ander belangrike voorouerspesifikasie is die ~ (tilde).
+Dit verwys ook na die eerste ouer, dus HEAD~ en HEAD^ is ekwivalent.
+Die verskil word duidelik wanneer jy 'n nommer spesifiseer.
+HEAD~2 beteken “die eerste ouer van die eerste ouer,” of “die grootouer” — dit loop deur die eerste ouers vir die aantal kere wat jy spesifiseer.
+Byvoorbeeld, in die geskiedenis wat vroeër gelys is, sou HEAD~3 wees:
+
+
+
+
$ git show HEAD~3
+commit 1c3618887afb5fbcbea25b7c013f4e2114448b8d
+Author: Tom Preston-Werner <tom@mojombo.com>
+Date: Fri Nov 7 13:47:59 2008 -0500
+
+ Ignore *.gem
+
+
+
+
Dit kan ook as HEAD~~~ geskryf word, wat weereens die eerste ouer van die eerste ouer van die eerste ouer is:
+
+
+
+
$ git show HEAD~~~
+commit 1c3618887afb5fbcbea25b7c013f4e2114448b8d
+Author: Tom Preston-Werner <tom@mojombo.com>
+Date: Fri Nov 7 13:47:59 2008 -0500
+
+ Ignore *.gem
+
+
+
+
Jy kan ook hierdie sintaksisse kombineer — jy kan die tweede ouer van die vorige verwysing kry (aannemende dat dit 'n saamsmeltingsvaslegging was) deur HEAD~3^2 te gebruik, ensovoorts.
+
+
+
Vasleggingsreekse (Commit Ranges)
+
+
Noudat jy individuele vasleggings kan spesifiseer, kom ons kyk hoe om reekse van vasleggings te spesifiseer.
+Dit is veral nuttig vir die bestuur van jou takke — as jy baie takke het, kan jy reekspesifikasies gebruik om vrae te beantwoord soos: “Watter werk is op hierdie tak wat ek nog nie in my hooftak ingesmelt het nie?”
+
+
+
Dubbelpunt (Double Dot)
+
+
Die mees algemene reeks-spesifikasie is die dubbelpunt-sintaksis.
+Dit vra basies vir Git om 'n reeks vasleggings op te los wat vanaf een vaslegging bereikbaar is, maar nie vanaf 'n ander bereikbaar is nie.
+Sê byvoorbeeld jy het 'n vasleggingsgeskiedenis wat soos }}">Voorbeeldgeskiedenis vir reeksseleksie lyk.
+
+
+
+
}}" alt="Example history for range selection">
+
+
Figure 149. Voorbeeldgeskiedenis vir reeksseleksie
+
+
+
Sê jy wil sien wat in jou experiment tak is wat nog nie in jou master tak ingesmelt is nie.
+Jy kan Git vra om vir jou 'n logboek te wys van net daardie vasleggings met master..experiment — dit beteken “alle vasleggings bereikbaar vanaf experiment wat nie bereikbaar is vanaf master nie.”
+Ter wille van beknoptheid en duidelikheid in hierdie voorbeelde, word die letters van die vasleggingsobjekte uit die diagram in die plek van die werklike log-afvoer gebruik in die volgorde wat dit sal vertoon:
+
+
+
+
$ git log master..experiment
+D
+C
+
+
+
+
As jy, aan die ander kant, die teenoorgestelde wil sien — alle vasleggings in master wat nie in experiment is nie — kan jy die takname omruil.
+experiment..master wys vir jou alles in master wat nie bereikbaar is vanaf experiment nie:
+
+
+
+
$ git log experiment..master
+F
+E
+
+
+
+
Dit is nuttig as jy die experiment tak op datum wil hou en 'n voorskou wil kry van wat jy op die punt is om in te smelt.
+Nog 'n algemene gebruik van hierdie sintaksis is om te sien wat jy op die punt is om na 'n remote te push:
+
+
+
+
$ git log origin/master..HEAD
+
+
+
+
Hierdie opdrag wys vir jou enige vasleggings in jou huidige tak wat nie in die master tak op jou origin remote is nie.
+As jy 'n git push uitvoer en jou huidige tak spoor (tracks) origin/master na, is die vasleggings wat deur git log origin/master..HEAD gelys word, die vasleggings wat na die bediener oorgedra sal word.
+Jy kan ook een kant van die sintaksis weglaat om Git te laat aanneem HEAD word bedoel.
+Byvoorbeeld, jy kan dieselfde resultate as in die vorige voorbeeld kry deur git log origin/master.. te tik — Git vervang HEAD as die een kant ontbreek.
+
+
+
+
Veelvuldige Punte (Multiple Points)
+
+
Die dubbelpunt-sintaksis is nuttig as 'n kortpad, maar miskien wil jy meer as twee takke spesifiseer om jou hersiening aan te dui, soos om te sien watter vasleggings in enige van verskeie takke is wat nie in die tak is waarop jy tans is nie.
+Git laat jou toe om dit te doen deur óf die ^ karakter óf --not te gebruik voor enige verwysing waarvan jy nie bereikbare vasleggings wil sien nie.
+Die volgende drie opdragte is dus ekwivalent:
+
+
+
+
$ git log refA..refB
+$ git log ^refA refB
+$ git log refB --not refA
+
+
+
+
Dit is handig want met hierdie sintaksis kan jy meer as twee verwysings in jou navraag spesifiseer, wat jy nie met die dubbelpunt-sintaksis kan doen nie.
+Byvoorbeeld, as jy alle vasleggings wil sien wat vanaf refA of refB bereikbaar is, maar nie vanaf refC nie, kan jy enige van die volgende gebruik:
+
+
+
+
$ git log refA refB ^refC
+$ git log refA refB --not refC
+
+
+
+
Dit sorg vir 'n baie kragtige hersieningsnavraagstelsel wat jou behoort te help om uit te vind wat in jou takke is.
+
+
+
+
Driedubbelpunt (Triple Dot)
+
+
Die laaste belangrike reeks-seleksie sintaksis is die driedubbelpunt-sintaksis, wat al die vasleggings spesifiseer wat bereikbaar is deur enigeen van twee verwysings, maar nie deur albei van hulle nie.
+Kyk terug na die voorbeeld vasleggingsgeskiedenis in }}">Voorbeeldgeskiedenis vir reeksseleksie.
+As jy wil sien wat in master of experiment is, maar nie enige algemene verwysings nie, kan jy uitvoer:
+
+
+
+
$ git log master...experiment
+F
+E
+D
+C
+
+
+
+
Weereens, dit gee jou normale log afvoer maar wys jou net die vasleggingsinligting vir daardie vier vasleggings, wat in die tradisionele vasleggingsdatumvolgorde verskyn.
+
+
+
'n Algemene skakelaar (switch) om in hierdie geval met die log opdrag te gebruik is --left-right, wat jou wys aan watter kant van die reeks elke vaslegging is.
+Dit help om die afvoer nuttiger te maak:
+
+
+
+
$ git log --left-right master...experiment
+< F
+< E
+> D
+> C
+
+
+
+
Met hierdie gereedskap kan jy Git baie makliker laat weet watter vaslegging of vasleggings jy wil inspekteer.
+
+
+
Herskryf van Geskiedenis (Rewriting History)
+
+
Baie keer, wanneer jy met Git werk, wil jy dalk jou plaaslike vasleggingsgeskiedenis (commit history) hersien.
+Een van die wonderlike dinge van Git is dat dit jou toelaat om besluite op die laaste moontlike oomblik te neem.
+Jy kan besluit watter lêers in watter vasleggings gaan net voor jy vaslê met behulp van die voorbereidingsarea (staging area), jy kan besluit dat jy nog nie aan iets wou werk nie met git stash, en jy kan vasleggings wat reeds plaasgevind het herskryf sodat dit lyk of hulle op 'n ander manier gebeur het.
+Dit kan insluit die verandering van die volgorde van die vasleggings, die verandering van boodskappe of wysiging van lêers in 'n vaslegging, die saampers (squashing) of opsplitsing van vasleggings, of die algehele verwydering van vasleggings — alles voordat jy jou werk met ander deel.
+
+
In hierdie afdeling sal jy sien hoe om hierdie take uit te voer sodat jy jou vasleggingsgeskiedenis kan laat lyk soos jy wil voordat jy dit met ander deel.
+
+
+
+|
+ Note
+ |
+
+ Moenie jou werk push totdat jy daarmee tevrede is nie
+
+ Een van die kardinale reëls van Git is dat, aangesien soveel werk plaaslik binne jou kloon is, jy 'n groot mate van vryheid het om jou geskiedenis plaaslik te herskryf.
+Sodra jy egter jou werk push, is dit 'n heeltemal ander storie, en jy moet gepushte werk as finaal beskou tensy jy goeie rede het om dit te verander.
+Kortom, jy moet vermy om jou werk te push totdat jy daarmee tevrede is en gereed is om dit met die res van die wêreld te deel.
+ |
+
+
+
+
Verandering van die Laaste Vaslegging (Changing the Last Commit)
+
+
Die verandering van jou mees onlangse vaslegging is waarskynlik die mees algemene herskrywing van geskiedenis wat jy sal doen.
+Jy sal dikwels twee basiese dinge aan jou laaste vaslegging wil doen: bloot die vasleggingsboodskap verander, of die werklike inhoud van die vaslegging verander deur lêers by te voeg, te verwyder en te wysig.
+
+
+
As jy bloot jou laaste vasleggingsboodskap wil verander, is dit maklik:
+
+
+
+
Die opdrag hierbo laai die vorige vasleggingsboodskap in 'n redigeerdersessie in, waar jy veranderings aan die boodskap kan maak, daardie veranderings kan stoor en kan afsluit.
+Wanneer jy die redigeerder stoor en toemaak, skryf die redigeerder 'n nuwe vaslegging wat daardie opgedateerde vasleggingsboodskap bevat en maak dit jou nuwe laaste vaslegging.
+
+
+
As jy, aan die ander kant, die werklike inhoud van jou laaste vaslegging wil verander, werk die proses basies op dieselfde manier — maak eers die veranderings wat jy dink jy vergeet het, berei daardie veranderings voor (stage), en die daaropvolgende git commit --amend vervang daardie laaste vaslegging met jou nuwe, verbeterde vaslegging.
+
+
+
Jy moet versigtig wees met hierdie tegniek, want amendering verander die SHA-1 van die vaslegging.
+Dit is soos 'n baie klein herbasering (rebase) — moenie jou laaste vaslegging amendeer as jy dit reeds gepush het nie.
+
+
+
+
+|
+ Tip
+ |
+
+ 'n Geamendeerde vaslegging benodig dalk (of dalk nie) 'n geamendeerde vasleggingsboodskap
+
+ Wanneer jy 'n vaslegging amendeer, het jy die geleentheid om beide die vasleggingsboodskap en die inhoud van die vaslegging te verander.
+As jy die inhoud van die vaslegging wesenlik amendeer, moet jy amper sekerlik die vasleggingsboodskap opdateer om daardie geamendeerde inhoud te weerspieël.
+
+ Aan die ander kant, as jou amendemente so triviaal is (soos die regmaak van 'n simpel tikfout of die byvoeging van 'n lêer wat jy vergeet het om voor te berei) dat die vroeëre vasleggingsboodskap net reg is, kan jy eenvoudig die veranderings maak, dit voorberei, en die onnodige redigeerdersessie heeltemal vermy met:
+
+
+ $ git commit --amend --no-edit
+
+ |
+
+
+
+
+
Verandering van Veelvuldige Vasleggingsboodskappe (Changing Multiple Commit Messages)
+
+
Om 'n vaslegging te verander wat verder terug in jou geskiedenis is, moet jy na meer komplekse gereedskap beweeg.
+Git het nie 'n wysig-geskiedenis-instrument nie, maar jy kan die rebase-instrument gebruik om 'n reeks vasleggings te rebase op die HEAD waarop hulle oorspronklik gebaseer was in plaas daarvan om dit na 'n ander een te skuif.
+Met die interaktiewe rebase-instrument kan jy dan na elke vaslegging wat jy wil verander stop en die boodskap verander, lêers byvoeg, of doen wat jy wil.
+Jy kan rebase interaktief uitvoer deur die -i opsie by git rebase te voeg.
+Jy moet aandui hoe ver terug jy vasleggings wil herskryf deur vir die opdrag te sê op watter vaslegging dit moet rebase.
+
+
+
Byvoorbeeld, as jy die laaste drie vasleggingsboodskappe wil verander, of enige van die vasleggingsboodskappe in daardie groep, verskaf jy as 'n argument aan git rebase -i die ouer van die laaste vaslegging wat jy wil redigeer, wat HEAD~2^ of HEAD~3 is.
+Dit mag makliker wees om die ~3 te onthou, want jy probeer die laaste drie vasleggings redigeer, maar hou in gedagte dat jy eintlik vier vasleggings gelede aandui, die ouer van die laaste vaslegging wat jy wil redigeer:
+
+
+
+
$ git rebase -i HEAD~3
+
+
+
+
Onthou weereens dat hierdie 'n rebase-opdrag is — elke vaslegging in die reeks HEAD~3..HEAD met 'n veranderde boodskap en al sy afstammelinge sal herskryf word.
+Moenie enige vaslegging insluit wat jy reeds na 'n sentrale bediener gepush het nie — as jy dit doen, sal dit ander ontwikkelaars verwar deur 'n alternatiewe weergawe van dieselfde verandering te verskaf.
+
+
+
Die uitvoering van hierdie opdrag gee jou 'n lys van vasleggings in jou teksredigeerder wat so iets soos dit lyk:
+
+
+
+
pick f7f3f6d Change my name a bit
+pick 310154e Update README formatting and add blame
+pick a5f4a0d Add cat-file
+
+# Rebase 710f0f8..a5f4a0d onto 710f0f8
+#
+# Commands:
+# p, pick <commit> = use commit
+# r, reword <commit> = use commit, but edit the commit message
+# e, edit <commit> = use commit, but stop for amending
+# s, squash <commit> = use commit, but meld into previous commit
+# f, fixup <commit> = like "squash", but discard this commit's log message
+# x, exec <command> = run command (the rest of the line) using shell
+# b, break = stop here (continue rebase later with 'git rebase --continue')
+# d, drop <commit> = remove commit
+# l, label <label> = label current HEAD with a name
+# t, reset <label> = reset HEAD to a label
+# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
+# . create a merge commit using the original merge commit's
+# . message (or the oneline, if no original merge commit was
+# . specified). Use -c <commit> to reword the commit message.
+#
+# These lines can be re-ordered; they are executed from top to bottom.
+#
+# If you remove a line here THAT COMMIT WILL BE LOST.
+#
+# However, if you remove everything, the rebase will be aborted.
+#
+# Note that empty commits are commented out
+
+
+
+
Dit is belangrik om op te let dat hierdie vasleggings gelys word in die teenoorgestelde volgorde as wat jy hulle normaalweg sien wanneer jy die log opdrag gebruik.
+As jy 'n log uitvoer, sien jy so iets:
+
+
+
+
$ git log --pretty=format:"%h %s" HEAD~3..HEAD
+a5f4a0d Add cat-file
+310154e Update README formatting and add blame
+f7f3f6d Change my name a bit
+
+
+
+
Let op die omgekeerde volgorde.
+Die interaktiewe rebase gee jou 'n skrip wat dit gaan uitvoer.
+Dit sal begin by die vaslegging wat jy op die opdragreël spesifiseer (HEAD~3) en die veranderings wat in elkeen van hierdie vasleggings ingestel is, van bo na onder herspeel.
+Dit lys die oudste boaan, eerder as die nuutste, want dit is die eerste een wat dit sal herspeel.
+
+
+
Jy moet die skrip redigeer sodat dit stop by die vaslegging wat jy wil redigeer.
+Om dit te doen, verander die woord “pick” na die woord “edit” vir elkeen van die vasleggings waarby jy wil hê die skrip moet stop.
+Byvoorbeeld, om slegs die derde vasleggingsboodskap te verander, verander jy die lêer om so te lyk:
+
+
+
+
edit f7f3f6d Change my name a bit
+pick 310154e Update README formatting and add blame
+pick a5f4a0d Add cat-file
+
+
+
+
Wanneer jy die redigeerder stoor en verlaat, spoel Git jou terug na die laaste vaslegging in daardie lys en laat jou op die opdragreël met die volgende boodskap:
+
+
+
+
$ git rebase -i HEAD~3
+Stopped at f7f3f6d... Change my name a bit
+You can amend the commit now, with
+
+ git commit --amend
+
+Once you're satisfied with your changes, run
+
+ git rebase --continue
+
+
+
+
Hierdie instruksies vertel jou presies wat om te doen.
+Tik:
+
+
+
+
Verander die vasleggingsboodskap en verlaat die redigeerder.
+Voer dan die volgende uit:
+
+
+
+
$ git rebase --continue
+
+
+
+
Hierdie opdrag sal die ander twee vasleggings outomaties toepas, en dan is jy klaar.
+As jy pick na edit verander op meer reëls, kan jy hierdie stappe herhaal vir elke vaslegging wat jy na edit verander.
+Elke keer sal Git stop, jou toelaat om die vaslegging te amendeer, en voortgaan wanneer jy klaar is.
+
+
+
Herordening van Vasleggings (Reordering Commits)
+
+
Jy kan ook interaktiewe rebases gebruik om vasleggings te herorden of heeltemal te verwyder.
+As jy die “Add cat-file” vaslegging wil verwyder en die volgorde waarin die ander twee vasleggings ingestel is wil verander, kan jy die rebase-skrip hiervan verander:
+
+
+
+
pick f7f3f6d Change my name a bit
+pick 310154e Update README formatting and add blame
+pick a5f4a0d Add cat-file
+
+
+
+
+
+
pick 310154e Update README formatting and add blame
+pick f7f3f6d Change my name a bit
+
+
+
+
Wanneer jy die redigeerder stoor en verlaat, spoel Git jou tak terug na die ouer van hierdie vasleggings, pas 310154e toe en dan f7f3f6d, en stop dan.
+Jy het effektief die volgorde van daardie vasleggings verander en die “Add cat-file” vaslegging heeltemal verwyder.
+
+
+
Saampersing van Vasleggings (Squashing Commits)
+
+
Dit is ook moontlik om 'n reeks vasleggings te neem en hulle te saampers (squash) tot 'n enkele vaslegging met die interaktiewe rebasing-instrument.
+Die skrip plaas nuttige instruksies in die rebase-boodskap:
+
+
+
+
#
+# Commands:
+# p, pick <commit> = use commit
+# r, reword <commit> = use commit, but edit the commit message
+# e, edit <commit> = use commit, but stop for amending
+# s, squash <commit> = use commit, but meld into previous commit
+# f, fixup <commit> = like "squash", but discard this commit's log message
+# x, exec <command> = run command (the rest of the line) using shell
+# b, break = stop here (continue rebase later with 'git rebase --continue')
+# d, drop <commit> = remove commit
+# l, label <label> = label current HEAD with a name
+# t, reset <label> = reset HEAD to a label
+# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
+# . create a merge commit using the original merge commit's
+# . message (or the oneline, if no original merge commit was
+# . specified). Use -c <commit> to reword the commit message.
+#
+# These lines can be re-ordered; they are executed from top to bottom.
+#
+# If you remove a line here THAT COMMIT WILL BE LOST.
+#
+# However, if you remove everything, the rebase will be aborted.
+#
+# Note that empty commits are commented out
+
+
+
+
As jy in plaas van “pick” of “edit”, “squash” spesifiseer, pas Git beide daardie verandering en die verandering direk daarvoor toe en laat jou die vasleggingsboodskappe saamsmelt.
+So, as jy 'n enkele vaslegging van hierdie drie vasleggings wil maak, laat jy die skrip so lyk:
+
+
+
+
pick f7f3f6d Change my name a bit
+squash 310154e Update README formatting and add blame
+squash a5f4a0d Add cat-file
+
+
+
+
Wanneer jy die redigeerder stoor en verlaat, pas Git al drie veranderings toe en plaas jou dan terug in die redigeerder om die drie vasleggingsboodskappe saam te smelt:
+
+
+
+
# This is a combination of 3 commits.
+# The first commit's message is:
+Change my name a bit
+
+# This is the 2nd commit message:
+
+Update README formatting and add blame
+
+# This is the 3rd commit message:
+
+Add cat-file
+
+
+
+
Wanneer jy dit stoor, het jy 'n enkele vaslegging wat die veranderings van al drie vorige vasleggings instel.
+
+
+
Opsplitsing van 'n Vaslegging (Splitting a Commit)
+
+
Die opsplitsing van 'n vaslegging maak 'n vaslegging ongedaan en berei dit dan gedeeltelik voor (stages) en lê dit vas soveel keer as wat jy met nuwe vasleggings wil eindig.
+Byvoorbeeld, veronderstel jy wil die middelste vaslegging van jou drie vasleggings opsplits.
+In plaas van “Update README formatting and add blame”, wil jy dit opdeel in twee vasleggings: “Update README formatting” vir die eerste, en “Add blame” vir die tweede.
+Jy kan dit doen in die rebase -i skrip deur die instruksie op die vaslegging wat jy wil opsplits na “edit” te verander:
+
+
+
+
pick f7f3f6d Change my name a bit
+edit 310154e Update README formatting and add blame
+pick a5f4a0d Add cat-file
+
+
+
+
Dan, wanneer die skrip jou na die opdragreël terugbring, stel jy (reset) daardie vaslegging terug, neem die veranderings wat teruggestel is, en skep veelvuldige vasleggings daaruit.
+Wanneer jy die redigeerder stoor en verlaat, spoel Git terug na die ouer van die eerste vaslegging in jou lys, pas die eerste vaslegging toe (f7f3f6d), pas die tweede toe (310154e), en plaas jou op die konsole.
+Daar kan jy 'n gemengde reset (mixed reset) van daardie vaslegging doen met git reset HEAD^, wat daardie vaslegging effektief ongedaan maak en die gewysigde lêers onvoorbereid (unstaged) laat.
+Nou kan jy lêers voorberei (stage) en vaslê totdat jy verskeie vasleggings het, en git rebase --continue uitvoer wanneer jy klaar is:
+
+
+
+
$ git reset HEAD^
+$ git add README
+$ git commit -m 'Update README formatting'
+$ git add lib/simplegit.rb
+$ git commit -m 'Add blame'
+$ git rebase --continue
+
+
+
+
Git pas die laaste vaslegging (a5f4a0d) in die skrip toe, en jou geskiedenis lyk soos volg:
+
+
+
+
$ git log -4 --pretty=format:"%h %s"
+1c002dd Add cat-file
+9b29157 Add blame
+35cfb2b Update README formatting
+f7f3f6d Change my name a bit
+
+
+
+
Dit verander die SHA-1’s van die drie mees onlangse vasleggings in jou lys, so maak seker dat geen veranderde vaslegging in daardie lys verskyn wat jy reeds na 'n gedeelde bewaarplek gepush het nie.
+Let op dat die laaste vaslegging (f7f3f6d) in die lys onveranderd is.
+Ten spyte daarvan dat hierdie vaslegging in die skrip gewys word, omdat dit as “pick” gemerk is en voor enige rebase-veranderings toegepas is, laat Git die vaslegging onveranderd.
+
+
+
Uitvee van 'n Vaslegging (Deleting a commit)
+
+
As jy ontslae wil raak van 'n vaslegging, kan jy dit uitvee met behulp van die rebase -i skrip.
+In die lys van vasleggings, plaas die woord “drop” voor die vaslegging wat jy wil uitvee (of vee net daardie reël uit die rebase-skrip uit):
+
+
+
+
pick 461cb2a This commit is OK
+drop 5aecc10 This commit is broken
+
+
+
+
As gevolg van die manier waarop Git vasleggingsobjekte bou, sal die uitvee of wysiging van 'n vaslegging veroorsaak dat al die vasleggings wat daarop volg, herskryf word.
+Hoe verder terug in jou bewaarplek se geskiedenis jy gaan, hoe meer vasleggings sal herskep moet word.
+Dit kan baie saamsmeltingskonflikte veroorsaak as jy baie vasleggings later in die ry het wat afhanklik is van die een wat jy so pas uitgevee het.
+
+
+
As jy halfpad deur so 'n rebase kom en besluit dit is nie 'n goeie idee nie, kan jy altyd stop.
+Tik git rebase --abort, en jou bewaarplek sal teruggestel word na die toestand waarin dit was voor jy die rebase begin het.
+
+
+
As jy 'n rebase voltooi en besluit dis nie wat jy wil hê nie, kan jy git reflog gebruik om 'n vroeëre weergawe van jou tak te herwin.
+Sien }}">Dataherwinning vir meer inligting oor die reflog opdrag.
+
+
+
+
+|
+ Note
+ |
+
+
+ Drew DeVault het 'n praktiese handleiding met oefeninge gemaak om te leer hoe om git rebase te gebruik.
+Jy kan dit vind by: https://git-rebase.io/
+ |
+
+
+
+
+
Die Kernopsie (The Nuclear Option): filter-branch
+
+
Daar is nog 'n geskiedenis-herskrywingsopsie wat jy kan gebruik as jy 'n groter aantal vasleggings op een of ander skripbare manier moet herskryf — byvoorbeeld, die globale verandering van jou e-posadres of die verwydering van 'n lêer uit elke vaslegging.
+Die opdrag is filter-branch, en dit kan groot dele van jou geskiedenis herskryf, so jy moet dit waarskynlik nie gebruik nie, tensy jou projek nog nie publiek is nie en ander mense nog nie werk gebaseer het op die vasleggings wat jy op die punt is om te herskryf nie.
+Dit kan egter baie nuttig wees.
+Jy sal 'n paar van die algemene gebruike leer sodat jy 'n idee kan kry van sommige van die dinge waartoe dit in staat is.
+
+
+
+
+|
+ Caution
+ |
+
+
+ git filter-branch het baie slaggate, en word nie meer aanbeveel as die manier om geskiedenis te herskryf nie.
+Oorweeg dit eerder om git-filter-repo te gebruik, wat 'n Python-skrip is wat 'n beter werk doen vir die meeste toepassings waar jy normaalweg na filter-branch sou wend.
+Sy dokumentasie en bronkode kan gevind word by https://github.com/newren/git-filter-repo.
+ |
+
+
+
+
+
Verwydering van 'n Lêer uit Elke Vaslegging (Removing a File from Every Commit)
+
+
Dit gebeur redelik algemeen.
+Iemand lê per ongeluk 'n groot binêre lêer vas met 'n onnadenkende git add ., en jy wil dit oral verwyder.
+Miskien het jy per ongeluk 'n lêer vasgelê wat 'n wagwoord bevat, en jy wil jou projek oopbron maak.
+filter-branch is die instrument wat jy waarskynlik wil gebruik om jou hele geskiedenis skoon te skrop.
+Om 'n lêer genaamd passwords.txt uit jou hele geskiedenis te verwyder, kan jy die --tree-filter opsie aan filter-branch gee:
+
+
+
+
$ git filter-branch --tree-filter 'rm -f passwords.txt' HEAD
+Rewrite 6b9b3cf04e7c5686a9cb838c3f36a8cb6a0fc2bd (21/21)
+Ref 'refs/heads/master' was rewritten
+
+
+
+
Die --tree-filter opsie voer die gespesifiseerde opdrag uit na elke uittrekking (checkout) van die projek en lê dan die resultate weer vas (recommits).
+In hierdie geval verwyder jy 'n lêer genaamd passwords.txt van elke momentopname, of dit bestaan of nie.
+As jy alle per abuis vasgelegde redigeerder-rugsteunlêers (editor backup files) wil verwyder, kan jy iets soos git filter-branch --tree-filter 'rm -f *~' HEAD uitvoer.
+
+
+
Jy sal in staat wees om te kyk hoe Git bome en vasleggings herskryf en dan die takwyser (branch pointer) aan die einde verskuif.
+Dit is oor die algemeen 'n goeie idee om dit in 'n toetstak te doen en dan jou master tak hard terug te stel (hard-reset) nadat jy vasgestel het dat die uitkoms dit is wat jy werklik wil hê.
+Om filter-branch op al jou takke uit te voer, kan jy --all na die opdrag aangee.
+
+
+
+
Maak van 'n Subgids die Nuwe Wortel (Making a Subdirectory the New Root)
+
+
Sê nou jy het 'n invoer vanaf 'n ander bronbeheerstelsel gedoen en het subgidse wat geen sin maak nie (trunk, tags, ensovoorts).
+As jy die trunk subgids die nuwe projekwortel vir elke vaslegging wil maak, kan filter-branch jou help om dit ook te doen:
+
+
+
+
$ git filter-branch --subdirectory-filter trunk HEAD
+Rewrite 856f0bf61e41a27326cdae8f09fe708d679f596f (12/12)
+Ref 'refs/heads/master' was rewritten
+
+
+
+
Nou is jou nuwe projekwortel dit wat elke keer in die trunk subgids was.
+Git sal ook outomaties vasleggings verwyder wat nie die subgids beïnvloed het nie.
+
+
+
+
Globale Verandering van E-posadresse (Changing Email Addresses Globally)
+
+
Nog 'n algemene geval is dat jy vergeet het om git config uit te voer om jou naam en e-posadres te stel voordat jy begin werk het, of dalk wil jy 'n projek by die werk oopbron maak en al jou werks-e-posadresse na jou persoonlike adres verander.
+In elk geval kan jy e-posadresse in veelvuldige vasleggings as 'n bondel met filter-branch verander.
+Jy moet versigtig wees om slegs die e-posadresse te verander wat joune is, so jy gebruik --commit-filter:
+
+
+
+
$ git filter-branch --commit-filter '
+ if [ "$GIT_AUTHOR_EMAIL" = "schacon@localhost" ];
+ then
+ GIT_AUTHOR_NAME="Scott Chacon";
+ GIT_AUTHOR_EMAIL="schacon@example.com";
+ git commit-tree "$@";
+ else
+ git commit-tree "$@";
+ fi' HEAD
+
+
+
+
Dit gaan deur en herskryf elke vaslegging om jou nuwe adres te hê.
+Omdat vasleggings die SHA-1 waardes van hul ouers bevat, verander hierdie opdrag elke vaslegging SHA-1 in jou geskiedenis, nie net dié wat die ooreenstemmende e-posadres het nie.
+
+
+
Interaktiewe Voorbereiding (Interactive Staging)
+
+
In hierdie afdeling sal jy kyk na 'n paar interaktiewe Git-opdragte wat jou kan help om jou vasleggings (commits) so saam te stel dat dit slegs sekere kombinasies en dele van lêers insluit.
+Hierdie gereedskap is nuttig as jy 'n aantal lêers omvattend wysig, en dan besluit dat jy wil hê daardie veranderings moet in verskeie gefokusde vasleggings verdeel word in plaas van een groot, morsige vaslegging.
+Op hierdie manier kan jy seker maak jou vasleggings is logies aparte veranderingsette (changesets) en kan maklik hersien word deur die ontwikkelaars wat saam met jou werk.
+
+
As jy git add met die -i of --interactive opsie uitvoer, gaan Git in 'n interaktiewe dop-modus (interactive shell mode) in, wat iets soos die volgende vertoon:
+
+
+
$ git add -i
+ staged unstaged path
+ 1: unchanged +0/-1 TODO
+ 2: unchanged +1/-1 index.html
+ 3: unchanged +5/-1 lib/simplegit.rb
+
+*** Commands ***
+ 1: [s]tatus 2: [u]pdate 3: [r]evert 4: [a]dd untracked
+ 5: [p]atch 6: [d]iff 7: [q]uit 8: [h]elp
+What now>
+
+
+
Jy kan sien dat hierdie opdrag vir jou 'n heel ander blik op jou voorbereidingsarea (staging area) wys as waaraan jy waarskynlik gewoond is — basies dieselfde inligting wat jy met git status kry, maar net 'n bietjie meer bondig en insiggewend.
+Dit lys die veranderings wat jy voorberei (staged) het aan die linkerkant, en onvoorbereide (unstaged) veranderings aan die regterkant.
+
+
Hierna volg 'n “Commands” afdeling, wat jou toelaat om 'n aantal dinge te doen soos die voorbereiding en ongedaan maak van voorbereiding (staging and unstaging) van lêers, die voorbereiding van dele van lêers, die byvoeging van onopgespoorde (untracked) lêers, en die vertoon van diffs van dit wat voorberei is.
+
+
Voorbereiding en Ontvoorbereiding van Lêers (Staging and Unstaging Files)
+
+
As jy u of 2 (vir update) by die What now> por (prompt) tik, word jy gevra watter lêers jy wil voorberei:
+
+
+
+
What now> u
+ staged unstaged path
+ 1: unchanged +0/-1 TODO
+ 2: unchanged +1/-1 index.html
+ 3: unchanged +5/-1 lib/simplegit.rb
+Update>>
+
+
+
+
Om die TODO en index.html lêers voor te berei, kan jy die nommers tik:
+
+
+
+
Update>> 1,2
+ staged unstaged path
+* 1: unchanged +0/-1 TODO
+* 2: unchanged +1/-1 index.html
+ 3: unchanged +5/-1 lib/simplegit.rb
+Update>>
+
+
+
+
Die * langs elke lêer beteken die lêer is gekies om voorberei te word.
+As jy Enter druk nadat jy niks by die Update>> por getik het nie, neem Git enigiets wat gekies is en berei dit vir jou voor:
+
+
+
+
Update>>
+updated 2 paths
+
+*** Commands ***
+ 1: [s]tatus 2: [u]pdate 3: [r]evert 4: [a]dd untracked
+ 5: [p]atch 6: [d]iff 7: [q]uit 8: [h]elp
+What now> s
+ staged unstaged path
+ 1: +0/-1 nothing TODO
+ 2: +1/-1 nothing index.html
+ 3: unchanged +5/-1 lib/simplegit.rb
+
+
+
+
Nou kan jy sien dat die TODO en index.html lêers voorberei (staged) is en die simplegit.rb lêer steeds onvoorbereid (unstaged) is.
+As jy die voorbereiding van die TODO lêer op hierdie stadium ongedaan wil maak (unstage), gebruik jy die r of 3 (vir revert) opsie:
+
+
+
+
*** Commands ***
+ 1: [s]tatus 2: [u]pdate 3: [r]evert 4: [a]dd untracked
+ 5: [p]atch 6: [d]iff 7: [q]uit 8: [h]elp
+What now> r
+ staged unstaged path
+ 1: +0/-1 nothing TODO
+ 2: +1/-1 nothing index.html
+ 3: unchanged +5/-1 lib/simplegit.rb
+Revert>> 1
+ staged unstaged path
+* 1: +0/-1 nothing TODO
+ 2: +1/-1 nothing index.html
+ 3: unchanged +5/-1 lib/simplegit.rb
+Revert>> [enter]
+reverted one path
+
+
+
+
As jy weer na jou Git-status kyk, kan jy sien dat jy die TODO lêer onvoorbereid (unstaged) gemaak het:
+
+
+
+
*** Commands ***
+ 1: [s]tatus 2: [u]pdate 3: [r]evert 4: [a]dd untracked
+ 5: [p]atch 6: [d]iff 7: [q]uit 8: [h]elp
+What now> s
+ staged unstaged path
+ 1: unchanged +0/-1 TODO
+ 2: +1/-1 nothing index.html
+ 3: unchanged +5/-1 lib/simplegit.rb
+
+
+
+
Om die diff te sien van wat jy voorberei het, kan jy die d of 6 (vir diff) opdrag gebruik.
+Dit wys vir jou 'n lys van jou voorbereide lêers, en jy kan dié kies waarvoor jy graag die voorbereide diff wil sien.
+Dit is baie soos om git diff --cached op die opdragreël te spesifiseer:
+
+
+
+
*** Commands ***
+ 1: [s]tatus 2: [u]pdate 3: [r]evert 4: [a]dd untracked
+ 5: [p]atch 6: [d]iff 7: [q]uit 8: [h]elp
+What now> d
+ staged unstaged path
+ 1: +1/-1 nothing index.html
+Review diff>> 1
+diff --git a/index.html b/index.html
+index 4d07108..4335f49 100644
+--- a/index.html
++++ b/index.html
+@@ -16,7 +16,7 @@ Date Finder
+
+ <p id="out">...</p>
+
+-<div id="footer">contact : support@github.com</div>
++<div id="footer">contact : email.support@github.com</div>
+
+ <script type="text/javascript">
+
+
+
+
Met hierdie basiese opdragte kan jy die interaktiewe byvoeg-modus (interactive add mode) gebruik om jou voorbereidingsarea 'n bietjie makliker te hanteer.
+
+
+
Voorbereiding van Pleisters (Staging Patches)
+
+
Dit is ook moontlik vir Git om sekere dele van lêers voor te berei en nie die res nie.
+Byvoorbeeld, as jy twee veranderings aan jou simplegit.rb lêer maak en een daarvan wil voorberei en nie die ander nie, is dit baie maklik om in Git te doen.
+Vanuit dieselfde interaktiewe por wat in die vorige afdeling verduidelik is, tik p of 5 (vir patch).
+Git sal jou vra watter lêers jy gedeeltelik wil voorberei; dan, vir elke afdeling van die gekose lêers, sal dit brokke (hunks) van die lêer-diff vertoon en vra of jy dit wil voorberei, een vir een:
+
+
+
+
diff --git a/lib/simplegit.rb b/lib/simplegit.rb
+index dd5ecc4..57399e0 100644
+--- a/lib/simplegit.rb
++++ b/lib/simplegit.rb
+@@ -22,7 +22,7 @@ class SimpleGit
+ end
+
+ def log(treeish = 'master')
+- command("git log -n 25 #{treeish}")
++ command("git log -n 30 #{treeish}")
+ end
+
+ def blame(path)
+Stage this hunk [y,n,a,d,/,j,J,g,e,?]?
+
+
+
+
Jy het baie opsies op hierdie stadium.
+Deur ? te tik, word 'n lys gewys van wat jy kan doen:
+
+
+
+
Stage this hunk [y,n,a,d,/,j,J,g,e,?]? ?
+y - stage this hunk
+n - do not stage this hunk
+a - stage this and all the remaining hunks in the file
+d - do not stage this hunk nor any of the remaining hunks in the file
+g - select a hunk to go to
+/ - search for a hunk matching the given regex
+j - leave this hunk undecided, see next undecided hunk
+J - leave this hunk undecided, see next hunk
+k - leave this hunk undecided, see previous undecided hunk
+K - leave this hunk undecided, see previous hunk
+s - split the current hunk into smaller hunks
+e - manually edit the current hunk
+? - print help
+
+
+
+
Oor die algemeen sal jy y of n tik as jy elke brok (hunk) wil voorberei, maar om almal in sekere lêers voor te berei of 'n besluit oor 'n brok tot later oor te slaan, kan ook nuttig wees.
+As jy een deel van die lêer voorberei en 'n ander deel onvoorbereid laat, sal jou status-afvoer soos volg lyk:
+
+
+
+
What now> 1
+ staged unstaged path
+ 1: unchanged +0/-1 TODO
+ 2: +1/-1 nothing index.html
+ 3: +1/-1 +4/-0 lib/simplegit.rb
+
+
+
+
Die status van die simplegit.rb lêer is interessant.
+Dit wys vir jou dat 'n paar reëls voorberei (staged) is en 'n paar onvoorbereid is.
+Jy het hierdie lêer gedeeltelik voorberei.
+Op hierdie punt kan jy die interaktiewe byvoegingskrip (interactive adding script) verlaat en git commit uitvoer om die gedeeltelik voorbereide lêers vas te lê.
+
+
+
Jy hoef ook nie in die interaktiewe byvoeg-modus te wees om die gedeeltelike lêer-voorbereiding te doen nie — jy kan dieselfde skrip begin deur git add -p of git add --patch op die opdragreël te gebruik.
+
+
+
Verder kan jy die pleistermodus (patch mode) gebruik om lêers gedeeltelik terug te stel met die git reset --patch opdrag, om dele van lêers uit te check met die git checkout --patch opdrag, en om dele van lêers te bêre met die git stash save --patch opdrag.
+Ons sal in meer besonderhede op elkeen hiervan ingaan soos ons by meer gevorderde gebruike van hierdie opdragte kom.
+
+
Ondertekening van Jou Werk (Signing Your Work)
+
+
Git is kriptografies veilig, maar dit is nie onfeilbaar nie.
+As jy werk van ander op die internet neem en wil verifieer dat vasleggings (commits) werklik van 'n betroubare bron afkomstig is, het Git 'n paar maniere om werk met behulp van GPG te onderteken en te verifieer.
+
+
GPG-Inleiding
+
+
Eerstens, as jy enigiets wil onderteken, moet jy GPG opstel en jou persoonlike sleutel installeer.
+
+
+
+
$ gpg --list-keys
+/Users/schacon/.gnupg/pubring.gpg
+---------------------------------
+pub 2048R/0A46826A 2014-06-04
+uid Scott Chacon (Git signing key) <schacon@gmail.com>
+sub 2048R/874529A9 2014-06-04
+
+
+
+
As jy nie 'n sleutel geïnstalleer het nie, kan jy een genereer met gpg --gen-key.
+
+
+
+
Sodra jy 'n privaatsleutel het om mee te onderteken, kan jy Git opstel om dit te gebruik deur die user.signingkey konfigurasie-instelling te stel.
+
+
+
+
$ git config --global user.signingkey 0A46826A
+
+
+
+
Nou sal Git by verstek jou sleutel gebruik om merkers (tags) en vasleggings te onderteken as jy wil.
+
+
+
+
+
As jy 'n GPG-privaatsleutel opgestel het, kan jy dit nou gebruik om nuwe merkers te onderteken.
+Al wat jy hoef te doen is om -s in plaas van -a te gebruik:
+
+
+
+
$ git tag -s v1.5 -m 'my signed 1.5 tag'
+
+You need a passphrase to unlock the secret key for
+user: "Ben Straub <ben@straub.cc>"
+2048-bit RSA key, ID 800430EB, created 2014-05-04
+
+
+
+
As jy git show op daardie merker uitvoer, kan jy sien dat jou GPG-handtekening daaraan gekoppel is:
+
+
+
+
$ git show v1.5
+tag v1.5
+Tagger: Ben Straub <ben@straub.cc>
+Date: Sat May 3 20:29:41 2014 -0700
+
+my signed 1.5 tag
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v1
+
+iQEcBAABAgAGBQJTZbQlAAoJEF0+sviABDDrZbQH/09PfE51KPVPlanr6q1v4/Ut
+LQxfojUWiLQdg2ESJItkcuweYg+kc3HCyFejeDIBw9dpXt00rY26p05qrpnG+85b
+hM1/PswpPLuBSr+oCIDj5GMC2r2iEKsfv2fJbNW8iWAXVLoWZRF8B0MfqX/YTMbm
+ecorc4iXzQu7tupRihslbNkfvfciMnSDeSvzCpWAHl7h8Wj6hhqePmLm9lAYqnKp
+8S5B/1SSQuEAjRZgI4IexpZoeKGVDptPHxLLS38fozsyi0QyDyzEgJxcJQVMXxVi
+RUysgqjcpT8+iQM1PblGfHR4XAhuOqN5Fx06PSaFZhqvWFezJ28/CLyX5q+oIVk=
+=EFTF
+-----END PGP SIGNATURE-----
+
+commit ca82a6dff817ec66f44342007202690a93763949
+Author: Scott Chacon <schacon@gee-mail.com>
+Date: Mon Mar 17 21:52:11 2008 -0700
+
+ Change version number
+
+
+
+
+
+
Om 'n ondertekende merker te verifieer, gebruik jy git tag -v <tag-name>.
+Hierdie opdrag gebruik GPG om die handtekening te verifieer.
+Jy benodig die ondertekenaar se publieke sleutel in jou sleutelring (keyring) sodat dit behoorlik kan werk:
+
+
+
+
$ git tag -v v1.4.2.1
+object 883653babd8ee7ea23e6a5c392bb739348b1eb61
+type commit
+tag v1.4.2.1
+tagger Junio C Hamano <junkio@cox.net> 1158138501 -0700
+
+GIT 1.4.2.1
+
+Minor fixes since 1.4.2, including git-mv and git-http with alternates.
+gpg: Signature made Wed Sep 13 02:08:25 2006 PDT using DSA key ID F3119B9A
+gpg: Good signature from "Junio C Hamano <junkio@cox.net>"
+gpg: aka "[jpeg image of size 1513]"
+Primary key fingerprint: 3565 2A26 2040 E066 C9A7 4A7D C0C6 D9A4 F311 9B9A
+
+
+
+
As jy nie die ondertekenaar se publieke sleutel het nie, kry jy in plaas daarvan so iets:
+
+
+
+
gpg: Signature made Wed Sep 13 02:08:25 2006 PDT using DSA key ID F3119B9A
+gpg: Can't check signature: public key not found
+error: could not verify the tag 'v1.4.2.1'
+
+
+
+
Ondertekening van Vasleggings (Signing Commits)
+
+
In meer onlangse weergawes van Git (v1.7.9 en later), kan jy nou ook individuele vasleggings onderteken.
+As jy daarin belangstel om vasleggings direk te onderteken in plaas van net die merkers, is al wat jy hoef te doen om 'n -S by jou git commit opdrag te voeg.
+
+
+
+
$ git commit -a -S -m 'Signed commit'
+
+You need a passphrase to unlock the secret key for
+user: "Scott Chacon (Git signing key) <schacon@gmail.com>"
+2048-bit RSA key, ID 0A46826A, created 2014-06-04
+
+[master 5c3386c] Signed commit
+ 4 files changed, 4 insertions(+), 24 deletions(-)
+ rewrite Rakefile (100%)
+ create mode 100644 lib/git.rb
+
+
+
+
Om hierdie handtekeninge te sien en te verifieer, is daar ook 'n --show-signature opsie vir git log.
+
+
+
+
$ git log --show-signature -1
+commit 5c3386cf54bba0a33a32da706aa52bc0155503c2
+gpg: Signature made Wed Jun 4 19:49:17 2014 PDT using RSA key ID 0A46826A
+gpg: Good signature from "Scott Chacon (Git signing key) <schacon@gmail.com>"
+Author: Scott Chacon <schacon@gmail.com>
+Date: Wed Jun 4 19:49:17 2014 -0700
+
+ Signed commit
+
+
+
+
Daarbenewens kan jy git log opstel om enige handtekeninge wat dit vind na te gaan en hulle in sy afvoer te lys met die %G? formaat.
+
+
+
+
$ git log --pretty="format:%h %G? %aN %s"
+
+5c3386c G Scott Chacon Signed commit
+ca82a6d N Scott Chacon Change the version number
+085bb3b N Scott Chacon Remove unnecessary test code
+a11bef0 N Scott Chacon Initial commit
+
+
+
+
Hier kan ons sien dat slegs die laaste vaslegging onderteken en geldig is, en dat die vorige vasleggings nie is nie.
+
+
+
In Git 1.8.3 en later, kan vir git merge en git pull gesê word om te inspekteer en te verwerp wanneer 'n vaslegging saamgesmelt word wat nie 'n betroubare GPG-handtekening dra nie met die --verify-signatures opdrag.
+
+
+
As jy hierdie opsie gebruik wanneer jy 'n tak saamsmelt (merge) en dit bevat vasleggings wat nie onderteken en geldig is nie, sal die saamsmelting nie werk nie.
+
+
+
+
$ git merge --verify-signatures non-verify
+fatal: Commit ab06180 does not have a GPG signature.
+
+
+
+
As die saamsmelting slegs geldige ondertekende vasleggings bevat, sal die merge opdrag jou al die handtekeninge wys wat hy nagegaan het en dan voortgaan met die saamsmelting.
+
+
+
+
$ git merge --verify-signatures signed-branch
+Commit 13ad65e has a good GPG signature by Scott Chacon (Git signing key) <schacon@gmail.com>
+Updating 5c3386c..13ad65e
+Fast-forward
+ README | 2 ++
+ 1 file changed, 2 insertions(+)
+
+
+
+
Jy kan ook die -S opsie met die git merge opdrag gebruik om die resulterende saamsmeltingsvaslegging self te onderteken.
+Die volgende voorbeeld verifieer beide dat elke vaslegging in die tak wat saamgesmelt moet word onderteken is, en onderteken boonop die resulterende saamsmeltingsvaslegging.
+
+
+
+
$ git merge --verify-signatures -S signed-branch
+Commit 13ad65e has a good GPG signature by Scott Chacon (Git signing key) <schacon@gmail.com>
+
+You need a passphrase to unlock the secret key for
+user: "Scott Chacon (Git signing key) <schacon@gmail.com>"
+2048-bit RSA key, ID 0A46826A, created 2014-06-04
+
+Merge made by the 'recursive' strategy.
+ README | 2 ++
+ 1 file changed, 2 insertions(+)
+
+
+
+
Almal Moet Onderteken (Everyone Must Sign)
+
+
Om merkers en vasleggings te onderteken is wonderlik, maar as jy besluit om dit in jou normale werkvloei te gebruik, sal jy moet seker maak dat almal in jou span verstaan hoe om dit te doen.
+Dit kan bereik word deur almal wat met die bewaarplek werk te vra om git config --local commit.gpgsign true uit te voer, om sodoende outomaties al hul vasleggings in die bewaarplek by verstek te laat onderteken.
+As jy dit nie doen nie, sal jy uiteindelik baie tyd daaraan bestee om mense te help uitvind hoe om hul vasleggings te herskryf met ondertekende weergawes.
+Maak seker dat jy GPG en die voordele van die ondertekening van dinge verstaan voordat jy dit as deel van jou standaard werkvloei aanneem.
+
+
Ontfouting met Git (Debugging with Git)
+
+
Benewens dat dit hoofsaaklik vir weergawebeheer is, bied Git ook 'n paar opdragte om jou te help om jou bronkodeprojekte te ontfout (debug).
+Omdat Git ontwerp is om byna enige tipe inhoud te hanteer, is hierdie instrumente redelik generies, maar hulle kan jou dikwels help om vir 'n fout (bug) of skuldige te jag wanneer dinge skeefloop.
+
+
Lêer-annotasie (File Annotation)
+
+
As jy 'n fout in jou kode opspoor en wil weet wanneer dit ingestel is en hoekom, is lêer-annotasie dikwels jou beste instrument.
+Dit wys jou watter vaslegging (commit) die laaste was om elke reël van enige lêer te wysig.
+So as jy sien dat 'n metode in jou kode foutief (buggy) is, kan jy die lêer annoteer met git blame om te bepaal watter vaslegging verantwoordelik was vir die instelling van daardie reël.
+
+
+
Die volgende voorbeeld gebruik git blame om te bepaal watter vaslegging en vaslêer (committer) verantwoordelik was vir reëls in die boonste vlak (top-level) Linux-kern Makefile en gebruik verder die -L opsie om die afvoer van die annotasie tot reëls 69 tot 82 van daardie lêer te beperk:
+
+
+
+
$ git blame -L 69,82 Makefile
+b8b0618cf6fab (Cheng Renquan 2009-05-26 16:03:07 +0800 69) ifeq ("$(origin V)", "command line")
+b8b0618cf6fab (Cheng Renquan 2009-05-26 16:03:07 +0800 70) KBUILD_VERBOSE = $(V)
+^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 71) endif
+^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 72) ifndef KBUILD_VERBOSE
+^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 73) KBUILD_VERBOSE = 0
+^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 74) endif
+^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 75)
+066b7ed955808 (Michal Marek 2014-07-04 14:29:30 +0200 76) ifeq ($(KBUILD_VERBOSE),1)
+066b7ed955808 (Michal Marek 2014-07-04 14:29:30 +0200 77) quiet =
+066b7ed955808 (Michal Marek 2014-07-04 14:29:30 +0200 78) Q =
+066b7ed955808 (Michal Marek 2014-07-04 14:29:30 +0200 79) else
+066b7ed955808 (Michal Marek 2014-07-04 14:29:30 +0200 80) quiet=quiet_
+066b7ed955808 (Michal Marek 2014-07-04 14:29:30 +0200 81) Q = @
+066b7ed955808 (Michal Marek 2014-07-04 14:29:30 +0200 82) endif
+
+
+
+
Let op dat die eerste veld die gedeeltelike SHA-1 is van die vaslegging wat daardie reël laas gewysig het.
+Die volgende twee velde is waardes onttrek uit daardie vaslegging — die outeurnaam en die outeursdatum van daardie vaslegging — sodat jy maklik kan sien wie daardie reël gewysig het en wanneer.
+Daarna kom die reëlnommer en die inhoud van die lêer.
+Let ook op die ^1da177e4c3f4 vasleggingsreëls, waar die ^ voorvoegsel reëls aandui wat in die bewaarplek se aanvanklike vaslegging ingestel is en sedertdien onveranderd gebly het.
+Dit is 'n bietjie verwarrend, want nou het jy al ten minste drie verskillende maniere gesien waarop Git die ^ gebruik om 'n vaslegging SHA-1 te wysig, maar dit is wat dit hier beteken.
+
+
+
Nog 'n oulike ding van Git is dat dit nie lêerhernoemings eksplisiet naspoor nie.
+Dit neem die momentopnames (snapshots) op en probeer dan uitvind wat implisiet hernoem is, na die tyd.
+Een van die interessante kenmerke hiervan is dat jy dit kan vra om ook allerhande kodebewegings uit te vind.
+As jy -C na git blame aangee, ontleed Git die lêer wat jy annoteer en probeer uitvind waar brokkies kode daarin oorspronklik vandaan kom as dit van iewers anders gekopieer is.
+Sê byvoorbeeld jy is besig om 'n lêer genaamd GITServerHandler.m in verskeie lêers te herstruktureer (refactor), waarvan een GITPackUpload.m is.
+Deur GITPackUpload.m te blame met die -C opsie, kan jy sien waar gedeeltes van die kode oorspronklik vandaan kom:
+
+
+
+
$ git blame -C -L 141,153 GITPackUpload.m
+f344f58d GITServerHandler.m (Scott 2009-01-04 141)
+f344f58d GITServerHandler.m (Scott 2009-01-04 142) - (void) gatherObjectShasFromC
+f344f58d GITServerHandler.m (Scott 2009-01-04 143) {
+70befddd GITServerHandler.m (Scott 2009-03-22 144) //NSLog(@"GATHER COMMI
+ad11ac80 GITPackUpload.m (Scott 2009-03-24 145)
+ad11ac80 GITPackUpload.m (Scott 2009-03-24 146) NSString *parentSha;
+ad11ac80 GITPackUpload.m (Scott 2009-03-24 147) GITCommit *commit = [g
+ad11ac80 GITPackUpload.m (Scott 2009-03-24 148)
+ad11ac80 GITPackUpload.m (Scott 2009-03-24 149) //NSLog(@"GATHER COMMI
+ad11ac80 GITPackUpload.m (Scott 2009-03-24 150)
+56ef2caf GITServerHandler.m (Scott 2009-01-05 151) if(commit) {
+56ef2caf GITServerHandler.m (Scott 2009-01-05 152) [refDict setOb
+56ef2caf GITServerHandler.m (Scott 2009-01-05 153)
+
+
+
+
Dit is regtig nuttig.
+Normaalweg kry jy as die oorspronklike vaslegging die vaslegging waar jy die kode oorgekopieer het, want dit is die eerste keer dat jy aan daardie reëls in hierdie lêer geraak het.
+Git vertel jou die oorspronklike vaslegging waar jy daardie reëls geskryf het, selfs al was dit in 'n ander lêer.
+
+
+
Binêre Soektog (Binary Search)
+
+
Die annotasie van 'n lêer help as jy weet waar die kwessie is om mee te begin.
+As jy nie weet wat breek nie, en daar was dosyne of honderde vasleggings sedert die laaste toestand waar jy weet die kode gewerk het, sal jy waarskynlik na git bisect wend vir hulp.
+Die bisect opdrag doen 'n binêre soektog deur jou vasleggingsgeskiedenis om jou te help om so vinnig as moontlik te identifiseer watter vaslegging 'n kwessie ingestel het.
+
+
+
Sê nou jy het pas 'n vrystelling (release) van jou kode na 'n produksie-omgewing gepush, jy kry foutverslae (bug reports) oor iets wat nie in jou ontwikkelingsomgewing gebeur het nie, en jy kan nie dink hoekom die kode dit doen nie.
+Jy gaan terug na jou kode, en dit blyk dat jy die kwessie kan reproduseer, maar jy kan nie uitvind wat verkeerd loop nie.
+Jy kan die kode halveer (bisect) om uit te vind.
+Eerstens voer jy git bisect start uit om dinge aan die gang te kry, en dan gebruik jy git bisect bad om vir die stelsel te sê dat die huidige vaslegging waarop jy is, gebreek is.
+Dan moet jy vir bisect sê wanneer die laaste bekende goeie toestand was, met behulp van git bisect good <good_commit>:
+
+
+
+
$ git bisect start
+$ git bisect bad
+$ git bisect good v1.0
+Bisecting: 6 revisions left to test after this
+[ecb6e1bc347ccecc5f9350d878ce677feb13d3b2] Error handling on repo
+
+
+
+
Git het uitgevind dat ongeveer 12 vasleggings gekom het tussen die vaslegging wat jy as die laaste goeie vaslegging (v1.0) gemerk het en die huidige slegte weergawe, en dit het die middelste een vir jou uitgetrek (checked out).
+Op hierdie punt kan jy jou toets uitvoer om te sien of die kwessie by hierdie vaslegging bestaan.
+As dit wel die geval is, dan is dit iewers voor hierdie middelste vaslegging ingestel; as dit nie is nie, dan is die probleem iewers ná die middelste vaslegging ingestel.
+Dit blyk daar is geen kwessie hier nie, en jy vertel Git dit deur git bisect good te tik en sit jou reis voort:
+
+
+
+
$ git bisect good
+Bisecting: 3 revisions left to test after this
+[b047b02ea83310a70fd603dc8cd7a6cd13d15c04] Secure this thing
+
+
+
+
Nou is jy op 'n ander vaslegging, halfpad tussen die een wat jy pas getoets het en jou slegte vaslegging.
+Jy voer jou toets weer uit en vind dat hierdie vaslegging gebreek is, so jy sê dit vir Git met git bisect bad:
+
+
+
+
$ git bisect bad
+Bisecting: 1 revisions left to test after this
+[f71ce38690acf49c1f3c9bea38e09d82a5ce6014] Drop exceptions table
+
+
+
+
Hierdie vaslegging is reg, en nou het Git al die inligting wat dit nodig het om te bepaal waar die kwessie ingestel is.
+Dit vertel jou die SHA-1 van die eerste slegte vaslegging en wys van die vasleggingsinligting en watter lêers in daardie vaslegging gewysig is sodat jy kan uitvind wat gebeur het wat moontlik hierdie fout ingestel het:
+
+
+
+
$ git bisect good
+b047b02ea83310a70fd603dc8cd7a6cd13d15c04 is first bad commit
+commit b047b02ea83310a70fd603dc8cd7a6cd13d15c04
+Author: PJ Hyett <pjhyett@example.com>
+Date: Tue Jan 27 14:48:32 2009 -0800
+
+ Secure this thing
+
+:040000 040000 40ee3e7821b895e52c1695092db9bdc4c61d1730
+f24d3c6ebcfc639b1a3814550e62d60b8e68a8e4 M config
+
+
+
+
Wanneer jy klaar is, moet jy git bisect reset uitvoer om jou HEAD terug te stel na waar jy was voor jy begin het, of jy sal in 'n vreemde toestand eindig:
+
+
+
+
Dit is 'n kragtige instrument wat jou kan help om honderde vasleggings in minute vir 'n ingestelde fout na te gaan.
+Trouens, as jy 'n skrip het wat 0 sal afsluit (exit) as die projek goed is of nie-0 as die projek sleg is, kan jy git bisect ten volle outomatiseer.
+Eerstens vertel jy dit weer die omvang (scope) van die halvering (bisect) deur die bekende slegte en goeie vasleggings te verskaf.
+Jy kan dit doen deur hulle met die bisect start opdrag te lys as jy wil, deur die bekende slegte vaslegging eerste en die bekende goeie vaslegging tweede te lys:
+
+
+
+
$ git bisect start HEAD v1.0
+$ git bisect run test-error.sh
+
+
+
+
Deur dit te doen, word test-error.sh outomaties op elke uitgetrekte (checked-out) vaslegging uitgevoer totdat Git die eerste gebreekte vaslegging vind.
+Jy kan ook iets soos make of make tests uitvoer, of wat jy ook al het wat geoutomatiseerde toetse vir jou uitvoer.
+
+
Rerere
+
+
Die git rerere funksionaliteit is 'n bietjie van 'n versteekte kenmerk.
+Die naam staan vir “reuse recorded resolution” (hergebruik opgeneemde resolusie) en, soos die naam aandui, laat dit jou toe om Git te vra om te onthou hoe jy 'n brok-konflik (hunk conflict) opgelos het sodat die volgende keer as dit dieselfde konflik sien, Git dit outomaties vir jou kan oplos.
+
+
Daar is 'n aantal scenario’s waarin hierdie funksionaliteit regtig handig kan wees.
+Een van die voorbeelde wat in die dokumentasie genoem word, is wanneer jy wil seker maak dat 'n langlewende onderwerp-tak (topic branch) uiteindelik skoon sal saamsmelt, maar jy wil nie 'n klomp intermediêre saamsmeltingsvasleggings (merge commits) hê wat jou vasleggingsgeskiedenis rommelig maak nie.
+Met rerere geaktiveer, kan jy af en toe 'n saamsmelting probeer, die konflikte oplos, en dan uit die saamsmelting onttrek.
+As jy dit deurlopend doen, behoort die finale saamsmelting maklik te wees omdat rerere net alles outomaties vir jou kan doen.
+
+
Dieselfde taktiek kan gebruik word as jy 'n tak gerebase wil hou sodat jy nie elke keer met dieselfde herbaseringskonflikte (rebasing conflicts) hoef te doen te kry as jy dit doen nie.
+Of as jy 'n tak wil neem wat jy saamgesmelt het en 'n klomp konflikte opgelos het en dan besluit om dit eerder te rebase — jy sal waarskynlik nie weer al dieselfde konflikte hoef te doen nie.
+
+
Nog 'n toepassing van rerere is waar jy af en toe 'n klomp ontwikkelende onderwerp-takke saamsmelt in 'n toetsbare kop (testable head), soos die Git-projek self dikwels doen.
+As die toetse misluk, kan jy die saamsmeltings terugspoel (rewind) en dit oordoen sonder die onderwerp-tak wat die toetse laat misluk het, sonder om weer die konflikte te moet heroplos.
+
+
Om rerere funksionaliteit te aktiveer, moet jy eenvoudig hierdie konfigurasie-instelling uitvoer:
+
+
+
$ git config --global rerere.enabled true
+
+
+
Jy kan dit ook aanskakel deur die .git/rr-cache gids in 'n spesifieke bewaarplek te skep, maar die konfigurasie-instelling is duideliker en aktiveer daardie kenmerk globaal vir jou.
+
+
Kom ons kyk nou na 'n eenvoudige voorbeeld, soortgelyk aan ons vorige een.
+Kom ons sê ons het 'n lêer genaamd hello.rb wat so lyk:
+
+
+
#! /usr/bin/env ruby
+
+def hello
+ puts 'hello world'
+end
+
+
+
In een tak verander ons die woord “hello” na “hola”, dan in 'n ander tak verander ons die “world” na “mundo”, net soos voorheen.
+
+
+
}}" alt="Two branches changing the same part of the same file differently">
+
+
Figure 173. Twee takke wat dieselfde deel van dieselfde lêer verskillend verander
+
+
Wanneer ons die twee takke saamsmelt, sal ons 'n saamsmeltingskonflik kry:
+
+
+
$ git merge i18n-world
+Auto-merging hello.rb
+CONFLICT (content): Merge conflict in hello.rb
+Recorded preimage for 'hello.rb'
+Automatic merge failed; fix conflicts and then commit the result.
+
+
+
Jy behoort die nuwe reël Recorded preimage for 'hello.rb' daarin op te merk.
+Andersins behoort dit presies soos 'n normale saamsmeltingskonflik te lyk.
+Op hierdie punt kan rerere vir ons 'n paar dinge vertel.
+Normaalweg sou jy dalk op hierdie punt git status uitvoer om te sien wat alles gebots het (conflicted):
+
+
+
$ git status
+# On branch master
+# Unmerged paths:
+# (use "git reset HEAD <file>..." to unstage)
+# (use "git add <file>..." to mark resolution)
+#
+# both modified: hello.rb
+#
+
+
+
git rerere sal jou egter ook vertel waarvoor dit die voor-saamsmelting toestand opgeneem het met git rerere status:
+
+
+
$ git rerere status
+hello.rb
+
+
+
En git rerere diff sal die huidige toestand van die resolusie wys — waarmee jy begin het om op te los en waarna jy dit opgelos het.
+
+
+
$ git rerere diff
+--- a/hello.rb
++++ b/hello.rb
+@@ -1,11 +1,11 @@
+ #! /usr/bin/env ruby
+
+ def hello
+-<<<<<<<
+- puts 'hello mundo'
+-=======
++<<<<<<< HEAD
+ puts 'hola world'
+->>>>>>>
++=======
++ puts 'hello mundo'
++>>>>>>> i18n-world
+ end
+
+
+
Ook (en dit is nie regtig verwant aan rerere nie), kan jy git ls-files -u gebruik om die botsende lêers en die voor-, linker- en regterweergawes te sien:
+
+
+
$ git ls-files -u
+100644 39804c942a9c1f2c03dc7c5ebcd7f3e3a6b97519 1 hello.rb
+100644 a440db6e8d1fd76ad438a49025a9ad9ce746f581 2 hello.rb
+100644 54336ba847c3758ab604876419607e9443848474 3 hello.rb
+
+
+
Nou kan jy dit oplos om net puts 'hola mundo' te wees en jy kan weer git rerere diff uitvoer om te sien wat rerere sal onthou:
+
+
+
$ git rerere diff
+--- a/hello.rb
++++ b/hello.rb
+@@ -1,11 +1,7 @@
+ #! /usr/bin/env ruby
+
+ def hello
+-<<<<<<<
+- puts 'hello mundo'
+-=======
+- puts 'hola world'
+->>>>>>>
++ puts 'hola mundo'
+ end
+
+
+
Dit sê dus basies, wanneer Git 'n brok-konflik in 'n hello.rb lêer sien wat “hello mundo” aan die een kant het en “hola world” aan die ander kant, sal dit dit na “hola mundo” oplos.
+
+
Nou kan ons dit as opgelos merk en vaslê:
+
+
+
$ git add hello.rb
+$ git commit
+Recorded resolution for 'hello.rb'.
+[master 68e16e5] Merge branch 'i18n'
+
+
+
Jy kan sien dat dit aandui "Recorded resolution for 'hello.rb'".
+
+
+
}}" alt="Recorded resolution for FILE">
+
+
Figure 174. Opgeneemde resolusie vir lêer
+
+
Kom ons maak nou daardie saamsmelting ongedaan en rebase dit in plaas daarvan bo-op ons master tak.
+Ons kan ons tak terugskuif deur git reset te gebruik, soos ons gesien het in }}">Reset Ontmystifiseer (Reset Demystified).
+
+
+
$ git reset --hard HEAD^
+HEAD is now at ad63f15 i18n the hello
+
+
+
Ons saamsmelting is ongedaan gemaak.
+Kom ons rebase nou die onderwerp-tak.
+
+
+
$ git checkout i18n-world
+Switched to branch 'i18n-world'
+
+$ git rebase master
+First, rewinding head to replay your work on top of it...
+Applying: i18n one word
+Using index info to reconstruct a base tree...
+Falling back to patching base and 3-way merge...
+Auto-merging hello.rb
+CONFLICT (content): Merge conflict in hello.rb
+Resolved 'hello.rb' using previous resolution.
+Failed to merge in the changes.
+Patch failed at 0001 i18n one word
+
+
+
Nou het ons dieselfde saamsmeltingskonflik gekry soos ons verwag het, maar kyk na die Resolved 'hello.rb' using previous resolution reël.
+As ons na die lêer kyk, sal ons sien dat dit reeds opgelos is, daar is geen saamsmeltingskonflikmerkers daarin nie.
+
+
+
#! /usr/bin/env ruby
+
+def hello
+ puts 'hola mundo'
+end
+
+
+
Ook sal git diff jou wys hoe dit outomaties heropgelos (re-resolved) is:
+
+
+
$ git diff
+diff --cc hello.rb
+index a440db6,54336ba..0000000
+--- a/hello.rb
++++ b/hello.rb
+@@@ -1,7 -1,7 +1,7 @@@
+ #! /usr/bin/env ruby
+
+ def hello
+- puts 'hola world'
+ - puts 'hello mundo'
+++ puts 'hola mundo'
+ end
+
+
+
+
}}" alt="Automatically resolved merge conflict using previous resolution">
+
+
Figure 175. Outomaties opgeloste saamsmeltingskonflik met behulp van vorige resolusie
+
+
Jy kan ook die botsende lêertoestand herskep met git checkout:
+
+
+
$ git checkout --conflict=merge hello.rb
+$ cat hello.rb
+#! /usr/bin/env ruby
+
+def hello
+<<<<<<< ours
+ puts 'hola world'
+=======
+ puts 'hello mundo'
+>>>>>>> theirs
+end
+
+
+
+
$ git rerere
+Resolved 'hello.rb' using previous resolution.
+$ cat hello.rb
+#! /usr/bin/env ruby
+
+def hello
+ puts 'hola mundo'
+end
+
+
+
Ons het die lêer outomaties heropgelos deur gebruik te maak van die rerere gekaste (cached) resolusie.
+Jy kan nou byvoeg en voortgaan met die rebase om dit te voltooi.
+
+
+
$ git add hello.rb
+$ git rebase --continue
+Applying: i18n one word
+
+
+
So, as jy baie hersaamsmeltings doen, of 'n onderwerp-tak op datum wil hou met jou master tak sonder 'n magdom saamsmeltings, of jy dikwels rebase, kan jy rerere aanskakel om jou lewe 'n bietjie makliker te maak.
+
Reset Ontmystifiseer (Reset Demystified)
+
+
Voordat ons aanbeweeg na meer gespesialiseerde gereedskap, kom ons gesels eers oor die Git reset en checkout opdragte.
+Hierdie opdragte is twee van die mees verwarrende dele van Git wanneer jy hulle vir die eerste keer teëkom.
+Hulle doen so baie dinge dat dit hopeloos lyk om hulle werklik te verstaan en behoorlik aan te wend.
+Hiervoor beveel ons 'n eenvoudige metafoor aan.
+
+
Die Drie Bome (The Three Trees)
+
+
'n Makliker manier om oor reset en checkout te dink, is deur die raamwerk van Git as 'n inhoudsbestuurder van drie verskillende bome.
+Deur “boom” (“tree”) hier, bedoel ons regtig “versameling van lêers”, nie spesifiek die datastruktuur nie.
+(Daar is 'n paar gevalle waar die indeks (index) nie presies soos 'n boom optree nie, maar vir ons doeleindes is dit makliker om vir eers so daaroor te dink.)
+
+
+
Git as 'n stelsel bestuur en manipuleer drie bome in sy normale werking:
+
+
+
+
+
+
+
+
+| Boom (Tree) |
+Rol (Role) |
+
+
+
+
+HEAD |
+Laaste vaslegging momentopname (commit snapshot), volgende ouer |
+
+
+Indeks (Index) |
+Voorgestelde volgende vaslegging momentopname |
+
+
+Werkgids (Working Directory) |
+Sandput (Sandbox) |
+
+
+
+
+
Die HEAD (The HEAD)
+
+
HEAD is die wyser na die huidige tak-verwysing (branch reference), wat op sy beurt 'n wyser is na die laaste vaslegging gemaak op daardie tak.
+Dit beteken HEAD sal die ouer wees van die volgende vaslegging wat geskep word.
+Dit is oor die algemeen die eenvoudigste om aan HEAD te dink as die momentopname (snapshot) van jou laaste vaslegging op daardie tak.
+
+
+
Trouens, dit is redelik maklik om te sien hoe daardie momentopname lyk.
+Hier is 'n voorbeeld van hoe om die werklike gidslys en SHA-1-kontrolesomme vir elke lêer in die HEAD-momentopname te kry:
+
+
+
+
$ git cat-file -p HEAD
+tree cfda3bf379e4f8dba8717dee55aab78aef7f4daf
+author Scott Chacon 1301511835 -0700
+committer Scott Chacon 1301511835 -0700
+
+initial commit
+
+$ git ls-tree -r HEAD
+100644 blob a906cb2a4a904a152... README
+100644 blob 8f94139338f9404f2... Rakefile
+040000 tree 99f1a6d12cb4b6f19... lib
+
+
+
+
Die Git cat-file en ls-tree opdragte is “loodgieterswerk” (“plumbing”) opdragte wat vir laervlak dinge gebruik word en nie regtig in dag-tot-dag werk gebruik word nie, maar hulle help ons om te sien wat hier aangaan.
+
+
+
+
Die Indeks (The Index)
+
+
Die indeks is jou voorgestelde volgende vaslegging.
+Ons het ook na hierdie konsep verwys as Git se “Voorbereidingsarea” (“Staging Area”) aangesien dit is waarna Git kyk wanneer jy git commit uitvoer.
+
+
+
Git vul hierdie indeks met 'n lys van al die lêerinhoude wat die laaste keer in jou werkgids uitgetrek is (checked out) en hoe hulle gelyk het toe hulle oorspronklik uitgetrek is.
+Jy vervang dan sommige van daardie lêers met nuwe weergawes daarvan, en git commit omskep dit in die boom vir 'n nuwe vaslegging.
+
+
+
+
$ git ls-files -s
+100644 a906cb2a4a904a152e80877d4088654daad0c859 0 README
+100644 8f94139338f9404f26296befa88755fc2598c289 0 Rakefile
+100644 47c6340d6459e05787f644c2447d2595f5d3a54b 0 lib/simplegit.rb
+
+
+
+
Weereens, hier gebruik ons git ls-files, wat meer 'n agter-die-skerms opdrag is wat vir jou wys hoe jou indeks tans lyk.
+
+
+
Die indeks is nie tegnies 'n boomstruktuur nie — dit is eintlik as 'n platgemaakte manifes geïmplementeer — maar vir ons doeleindes is dit goed genoeg.
+
+
+
+
Die Werkgids (The Working Directory)
+
+
Laastens het jy jou werkgids (working directory, ook dikwels verwys na as die “working tree”).
+Die ander twee bome stoor hul inhoud op 'n doeltreffende maar ongerieflike manier binne die .git gids.
+Die werkgids pak dit uit in werklike lêers, wat dit vir jou baie makliker maak om dit te redigeer.
+Dink aan die werkgids as 'n sandput, waar jy veranderings kan uitprobeer voordat jy dit in jou voorbereidingsarea (indeks) en dan in die geskiedenis vaslê.
+
+
+
+
$ tree
+.
+├── README
+├── Rakefile
+└── lib
+ └── simplegit.rb
+
+1 directory, 3 files
+
+
+
+
+
Die Werkvloei (The Workflow)
+
+
Git se tipiese werkvloei is om momentopnames van jou projek in agtereenvolgens beter toestande op te neem deur hierdie drie bome te manipuleer.
+
+
+
+
}}" alt="Git’s typical workflow">
+
+
Figure 150. Git se tipiese werkvloei
+
+
+
Kom ons visualiseer hierdie proses: sê nou jy gaan na 'n nuwe gids met 'n enkele lêer daarin.
+Ons sal dit v1 van die lêer noem, en ons sal dit in blou aandui.
+Nou voer ons git init uit, wat 'n Git-bewaarplek sal skep met 'n HEAD-verwysing wat na die ongebore master tak wys.
+
+
+
+
}}" alt="Newly-initialized Git repository with unstaged file in the working directory">
+
+
Figure 151. Nuut-geïnisialiseerde Git-bewaarplek met onvoorbereide (unstaged) lêer in die werkgids
+
+
+
Op hierdie punt het slegs die werkgidsboom enige inhoud.
+
+
+
Nou wil ons hierdie lêer vaslê, so ons gebruik git add om inhoud in die werkgids te neem en dit na die indeks te kopieer.
+
+
+
+
}}" alt="File is copied to index on `git add`">
+
+
Figure 152. Lêer word na indeks gekopieer met git add
+
+
+
+
Dan voer ons git commit uit, wat die inhoud van die indeks neem en dit as 'n permanente momentopname stoor, 'n vasleggingsobjek skep wat na daardie momentopname wys, en master opdateer om na daardie vaslegging te wys.
+
+
+
+
}}" alt="The `git commit` step">
+
+
Figure 153. Die git commit stap
+
+
+
As ons git status uitvoer, sal ons geen veranderings sien nie, want al drie bome is dieselfde.
+
+
+
Nou wil ons 'n verandering aan daardie lêer maak en dit vaslê.
+Ons sal deur dieselfde proses gaan; eers verander ons die lêer in ons werkgids.
+Kom ons noem dit v2 van die lêer, en dui dit in rooi aan.
+
+
+
+
}}" alt="Git repository with changed file in the working directory">
+
+
Figure 154. Git-bewaarplek met gewysigde lêer in die werkgids
+
+
+
As ons git status dadelik uitvoer, sal ons die lêer in rooi sien as “Changes not staged for commit”, omdat daardie inskrywing verskil tussen die indeks en die werkgids.
+Volgende voer ons git add daarop uit om dit in ons indeks voor te berei (stage).
+
+
+
+
}}" alt="Staging change to index">
+
+
Figure 155. Voorbereiding (Staging) van verandering in indeks
+
+
+
Op hierdie punt, as ons git status uitvoer, sal ons die lêer in groen sien onder “Changes to be committed” omdat die indeks en HEAD verskil — dit wil sê, ons voorgestelde volgende vaslegging verskil nou van ons laaste vaslegging.
+Laastens voer ons git commit uit om die vaslegging te finaliseer.
+
+
+
+
}}" alt="The `git commit` step with changed file">
+
+
Figure 156. Die git commit stap met gewysigde lêer
+
+
+
Nou sal git status ons geen afvoer gee nie, want al drie bome is weer dieselfde.
+
+
+
Die omskakeling van takke of die kloning van 'n bewaarplek gaan deur 'n soortgelyke proses.
+Wanneer jy 'n tak uitcheck, verander dit HEAD om na die nuwe tak-verwysing (ref) te wys, vul jou indeks met die momentopname van daardie vaslegging, kopieer dan die inhoud van die indeks na jou werkgids.
+
+
+
Die Rol van Reset (The Role of Reset)
+
+
Die reset opdrag maak meer sin wanneer dit in hierdie konteks beskou word.
+
+
+
Vir die doeleindes van hierdie voorbeelde, kom ons sê ons het file.txt weer gewysig en dit 'n derde keer vasgelê.
+So nou lyk ons geskiedenis so:
+
+
+
+
}}" alt="Git repository with three commits">
+
+
Figure 157. Git-bewaarplek met drie vasleggings
+
+
+
Kom ons stap nou presies deur wat reset doen wanneer jy dit aanroep.
+Dit manipuleer direk hierdie drie bome op 'n eenvoudige en voorspelbare manier.
+Dit doen tot drie basiese bewerkings.
+
+
+
Stap 1: Skuif HEAD (Move HEAD)
+
+
Die eerste ding wat reset sal doen, is om dit waarna HEAD wys, te skuif.
+Dit is nie dieselfde as om HEAD self te verander nie (wat is wat checkout doen); reset skuif die tak waarna HEAD wys.
+Dit beteken as HEAD op die master tak gestel is (m.a.w. jy is tans op die master tak), sal die uitvoering van git reset 9e5e6a4 begin deur te maak dat master na 9e5e6a4 wys.
+
+
+
+
}}" alt="Soft reset">
+
+
Figure 158. Sagte reset (Soft reset)
+
+
+
Maak nie saak watter vorm van reset jy met 'n vaslegging aanroep nie, dit is die eerste ding wat dit altyd sal probeer doen.
+Met reset --soft, sal dit bloot daar stop.
+
+
+
Neem nou 'n oomblik om na daardie diagram te kyk en te besef wat gebeur het: dit het basies die laaste git commit opdrag ongedaan gemaak.
+Wanneer jy git commit uitvoer, skep Git 'n nuwe vaslegging en skuif die tak waarna HEAD wys op na dit.
+Wanneer jy terug reset na HEAD~ (die ouer van HEAD), skuif jy die tak terug na waar dit was, sonder om die indeks of werkgids te verander.
+Jy kan nou die indeks opdateer en weer git commit uitvoer om te bereik wat git commit --amend sou gedoen het (sien }}">Verandering van die Laaste Vaslegging (Changing the Last Commit)).
+
+
+
+
Stap 2: Opdatering van die Indeks (Updating the Index - --mixed)
+
+
Let op dat as jy nou git status uitvoer, sal jy die verskil in groen sien tussen die indeks en wat die nuwe HEAD is.
+
+
+
Die volgende ding wat reset sal doen, is om die indeks op te dateer met die inhoud van watter momentopname HEAD nou ook al na wys.
+
+
+
+
}}" alt="Mixed reset">
+
+
Figure 159. Gemengde reset (Mixed reset)
+
+
+
As jy die --mixed opsie spesifiseer, sal reset op hierdie punt stop.
+Dit is ook die verstelling, so as jy hoegenaamd geen opsie spesifiseer nie (net git reset HEAD~ in hierdie geval), is dit waar die opdrag sal stop.
+
+
+
Neem nou nog 'n oomblik om na daardie diagram te kyk en te besef wat gebeur het: dit het steeds jou laaste commit ongedaan gemaak, maar het ook alles onvoorbereid (unstaged) gemaak.
+Jy het teruggerol (rolled back) na voor jy al jou git add en git commit opdragte uitgevoer het.
+
+
+
+
Stap 3: Opdatering van die Werkgids (Updating the Working Directory - --hard)
+
+
Die derde ding wat reset sal doen, is om te maak dat die werkgids soos die indeks lyk.
+As jy die --hard opsie gebruik, sal dit voortgaan na hierdie stadium.
+
+
+
+
}}" alt="Hard reset">
+
+
Figure 160. Harde reset (Hard reset)
+
+
+
So kom ons dink oor wat nou net gebeur het.
+Jy het jou laaste vaslegging, die git add en git commit opdragte ongedaan gemaak, en al die werk wat jy in jou werkgids gedoen het.
+
+
+
Dit is belangrik om op te let dat hierdie vlag (--hard) die enigste manier is om die reset opdrag gevaarlik te maak, en een van die baie min gevalle waar Git werklik data sal vernietig.
+Enige ander aanroeping van reset kan redelik maklik ongedaan gemaak word, maar die --hard opsie kan nie, aangesien dit lêers in die werkgids met geweld oorskryf.
+In hierdie spesifieke geval het ons steeds die v3 weergawe van ons lêer in 'n vaslegging in ons Git-databasis, en ons kan dit terugkry deur na ons reflog te kyk, maar as ons dit nie vasgelê het nie, sou Git steeds die lêer oorskryf het en dit onherwinbaar wees.
+
+
+
+
Opsomming (Recap)
+
+
Die reset opdrag oorskryf hierdie drie bome in 'n spesifieke volgorde, en stop wanneer jy sê dit moet:
+
+
+
+-
+
Skuif die tak waarna HEAD wys (stop hier as --soft).
+
+-
+
Maak die indeks soos HEAD lyk (stop hier behalwe as --hard).
+
+-
+
Maak die werkgids soos die indeks lyk.
+
+
+
+
+
+
Reset Met 'n Pad (Reset With a Path)
+
+
Dit dek die gedrag van reset in sy basiese vorm, maar jy kan dit ook voorsien van 'n pad (path) om op op te tree.
+As jy 'n pad spesifiseer, sal reset stap 1 oorslaan, en die res van sy aksies beperk tot 'n spesifieke lêer of stel lêers.
+Dit maak eintlik 'n bietjie sin — HEAD is net 'n wyser, en jy kan nie na 'n deel van een vaslegging en 'n deel van 'n ander wys nie.
+Maar die indeks en werkgids kan gedeeltelik opgedateer word, so reset gaan voort met stappe 2 en 3.
+
+
+
So, neem aan ons voer git reset file.txt uit.
+Hierdie vorm (aangesien jy nie 'n vaslegging SHA-1 of tak gespesifiseer het nie, en jy nie --soft of --hard gespesifiseer het nie) is 'n kortskrif vir git reset --mixed HEAD file.txt, wat sal:
+
+
+
+-
+
Die tak waarna HEAD wys skuif (oorgeslaan).
+
+-
+
Die indeks soos HEAD laat lyk (stop hier).
+
+
+
+
+
So dit kopieer in wese net file.txt van HEAD na die indeks.
+
+
+
+
}}" alt="Mixed reset with a path">
+
+
Figure 161. Gemengde reset met 'n pad
+
+
+
Dit het die praktiese effek om die lêer onvoorbereid (unstaging) te maak.
+As ons na die diagram vir daardie opdrag kyk en dink oor wat git add doen, is hulle presies die teenoorgesteldes.
+
+
+
+
}}" alt="Staging file to index">
+
+
Figure 162. Voorbereiding (Staging) van lêer na indeks
+
+
+
+
Ons kon net so maklik Git nie laat aanneem het ons bedoel “trek die data van HEAD af” deur 'n spesifieke vaslegging te spesifiseer om daardie lêerweergawe van af te trek (pull).
+Ons sou net iets soos git reset eb43bf file.txt uitvoer.
+
+
+
+
}}" alt="Soft reset with a path to a specific commit">
+
+
Figure 163. Sagte reset met 'n pad na 'n spesifieke vaslegging
+
+
+
Dit doen effektief dieselfde ding asof ons die inhoud van die lêer teruggerol (reverted) het na v1 in die werkgids, git add daarop uitgevoer het, en dit dan weer teruggerol het na v3 (sonder om eintlik deur al daardie stappe te gaan).
+As ons nou git commit uitvoer, sal dit 'n verandering opneem wat daardie lêer terugrol na v1, al het ons dit nooit regtig weer in ons werkgids gehad nie.
+
+
+
Dit is ook interessant om op te let dat, net soos git add, sal die reset opdrag 'n --patch opsie aanvaar om inhoud onvoorbereid (unstage) te maak op 'n brok-vir-brok (hunk-by-hunk) basis.
+Jy kan dus selektief inhoud onvoorbereid maak of terugrol.
+
+
+
Saampersing (Squashing)
+
+
Kom ons kyk hoe om iets interessants met hierdie nuutgevonde krag te doen — die saampers (squashing) van vasleggings.
+
+
+
Sê jy het 'n reeks vasleggings met boodskappe soos “oops.”, “WIP” en “forgot this file”.
+Jy kan reset gebruik om hulle vinnig en maklik in 'n enkele vaslegging saam te pers wat jou baie slim laat lyk.
+}}">Saampersing van Vasleggings (Squashing Commits) wys 'n ander manier om dit te doen, maar in hierdie voorbeeld is dit makliker om reset te gebruik.
+
+
+
Kom ons sê jy het 'n projek waar die eerste vaslegging een lêer het, die tweede vaslegging 'n nuwe lêer bygevoeg het en die eerste verander het, en die derde vaslegging die eerste lêer weer verander het.
+Die tweede vaslegging was werk in proses en jy wil dit saampers.
+
+
+
+
}}" alt="Git repository">
+
+
Figure 164. Git-bewaarplek
+
+
+
Jy kan git reset --soft HEAD~2 uitvoer om die HEAD-tak terug te skuif na 'n ouer vaslegging (die mees onlangse vaslegging wat jy wil behou):
+
+
+
+
}}" alt="Moving HEAD with soft reset">
+
+
Figure 165. Verskuiwing van HEAD met sagte reset
+
+
+
En voer dan eenvoudig git commit weer uit:
+
+
+
+
}}" alt="Git repository with squashed commit">
+
+
Figure 166. Git-bewaarplek met saamgeperste (squashed) vaslegging
+
+
+
Nou kan jy sien dat jou bereikbare geskiedenis, die geskiedenis wat jy sou opstuur (push), nou lyk asof jy een vaslegging gehad het met file-a.txt v1, dan 'n tweede wat beide file-a.txt verander het na v3 en file-b.txt bygevoeg het.
+Die vaslegging met die v2 weergawe van die lêer is nie meer in die geskiedenis nie.
+
+
+
Check It Out
+
+
Laastens mag jy wonder wat die verskil tussen checkout en reset is.
+Soos reset, manipuleer checkout die drie bome, en dit is 'n bietjie anders afhangende van of jy die opdrag 'n lêerpad (file path) gee of nie.
+
+
+
Sonder Paaie (Without Paths)
+
+
Die uitvoering van git checkout [branch] is redelik soortgelyk aan die uitvoering van git reset --hard [branch] in die sin dat dit al drie bome vir jou opdateer om soos [branch] te lyk, maar daar is twee belangrike verskille.
+
+
+
Eerstens, anders as reset --hard, is checkout werkgids-veilig (working-directory safe); dit sal kyk om seker te maak dit wis nie lêers weg wat veranderings aan hulle het nie.
+Eintlik is dit 'n bietjie slimmer as dit — dit probeer om 'n triviale saamsmelting in die werkgids te doen, sodat al die lêers wat jy nie verander het nie, opgedateer sal word.
+reset --hard, aan die ander kant, sal eenvoudig alles oorkruis vervang sonder om te kyk.
+
+
+
Die tweede belangrike verskil is hoe checkout HEAD opdateer.
+Waar reset die tak sal skuif waarna HEAD wys, sal checkout HEAD self skuif om na 'n ander tak te wys.
+
+
+
Byvoorbeeld, sê ons het master en develop takke wat na verskillende vasleggings wys, en ons is tans op develop (so HEAD wys daarna).
+As ons git reset master uitvoer, sal develop self nou na dieselfde vaslegging wys as wat master doen.
+As ons in plaas daarvan git checkout master uitvoer, beweeg develop nie, HEAD self doen.
+HEAD sal nou na master wys.
+
+
+
So, in beide gevalle verskuif ons HEAD om na vaslegging A te wys, maar hoe ons dit doen is baie verskillend.
+reset sal die tak waarna HEAD wys skuif, checkout skuif HEAD self.
+
+
+
+
}}" alt="`git checkout` and `git reset`">
+
+
Figure 167. git checkout en git reset
+
+
+
+
+
Met Paaie (With Paths)
+
+
Die ander manier om checkout uit te voer, is met 'n lêerpad (file path), wat, soos reset, nie HEAD skuif nie.
+Dit is net soos git reset [branch] file in die sin dat dit die indeks met daardie lêer by daardie vaslegging opdateer, maar dit oorskryf ook die lêer in die werkgids.
+Dit sou presies wees soos git reset --hard [branch] file (as reset jou dit sou toelaat om dit uit te voer) — dit is nie werkgids-veilig nie, en dit skuif nie HEAD nie.
+
+
+
Ook, soos git reset en git add, sal checkout 'n --patch opsie aanvaar om jou toe te laat om lêerinhoud selektief terug te rol (revert) op 'n brok-vir-brok (hunk-by-hunk) basis.
+
+
+
+
Opsomming (Summary)
+
+
Hopelik verstaan jy nou en voel jy gemakliker met die reset opdrag, maar is waarskynlik steeds 'n bietjie verward oor hoe presies dit verskil van checkout en sou moontlik nie al die reëls van die verskillende oproepings (invocations) kon onthou nie.
+
+
+
Hier is 'n spiekbriefie vir watter opdragte watter bome beïnvloed.
+Die “HEAD” kolom lees “REF” as daardie opdrag die verwysing (tak) skuif waarna HEAD wys, en “HEAD” as dit HEAD self skuif.
+Gee veral aandag aan die 'WD Safe?' (Werkgids Veilig?) kolom — as dit sê NO, dink 'n oomblik na voordat jy daardie opdrag uitvoer.
+
+
+
+
+
+
+
+
+
+
+
+ |
+HEAD |
+Indeks |
+Werkgids |
+WD Veilig? |
+
+
+
+
+Vasleggingsvlak (Commit Level) |
+ |
+ |
+ |
+ |
+
+
+reset --soft [commit]
|
+REF |
+NO |
+NO |
+YES |
+
+
+reset [commit]
|
+REF |
+YES |
+NO |
+YES |
+
+
+reset --hard [commit]
|
+REF |
+YES |
+YES |
+NO |
+
+
+checkout <commit>
|
+HEAD |
+YES |
+YES |
+YES |
+
+
+Lêervlak (File Level) |
+ |
+ |
+ |
+ |
+
+
+reset [commit] <paths>
|
+NO |
+YES |
+NO |
+YES |
+
+
+checkout [commit] <paths>
|
+NO |
+YES |
+YES |
+NO |
+
+
+
+
Soek (Searching)
+
+
Met byna enige grootte kodebasis, sal jy dikwels moet vind waar 'n funksie geroep of gedefinieer word, of die geskiedenis van 'n metode moet vertoon.
+Git bied 'n paar nuttige instrumente om vinnig en maklik deur die kode en vasleggings (commits) wat in sy databasis gestoor is, te soek.
+Ons sal deur 'n paar van hulle gaan.
+
+
Git Grep
+
+
Git kom met 'n opdrag genaamd grep wat jou toelaat om maklik deur enige vasgelegde boom (committed tree), die werkgids (working directory), of selfs die indeks te soek vir 'n string of gereelde uitdrukking (regular expression).
+Vir die voorbeelde wat volg, sal ons deur die bronkode vir Git self soek.
+
+
+
By verstek sal git grep deur die lêers in jou werkgids soek.
+As 'n eerste variasie kan jy óf die -n óf --line-number opsies gebruik om die reëlnommers te druk waar Git ooreenkomste gevind het:
+
+
+
+
$ git grep -n gmtime_r
+compat/gmtime.c:3:#undef gmtime_r
+compat/gmtime.c:8: return git_gmtime_r(timep, &result);
+compat/gmtime.c:11:struct tm *git_gmtime_r(const time_t *timep, struct tm *result)
+compat/gmtime.c:16: ret = gmtime_r(timep, result);
+compat/mingw.c:826:struct tm *gmtime_r(const time_t *timep, struct tm *result)
+compat/mingw.h:206:struct tm *gmtime_r(const time_t *timep, struct tm *result);
+date.c:482: if (gmtime_r(&now, &now_tm))
+date.c:545: if (gmtime_r(&time, tm)) {
+date.c:758: /* gmtime_r() in match_digit() may have clobbered it */
+git-compat-util.h:1138:struct tm *git_gmtime_r(const time_t *, struct tm *);
+git-compat-util.h:1140:#define gmtime_r git_gmtime_r
+
+
+
+
Benewens die basiese soektog wat hierbo gewys word, ondersteun git grep 'n oormaat van ander interessante opsies.
+
+
+
Byvoorbeeld, in plaas daarvan om al die ooreenkomste te druk, kan jy git grep vra om die afvoer op te som deur slegs te wys watter lêers die soekstring bevat het en hoeveel ooreenkomste daar in elke lêer was met die -c of --count opsie:
+
+
+
+
$ git grep --count gmtime_r
+compat/gmtime.c:4
+compat/mingw.c:1
+compat/mingw.h:1
+date.c:3
+git-compat-util.h:2
+
+
+
+
As jy belangstel in die konteks van 'n soekstring, kan jy die insluitende metode of funksie vir elke ooreenstemmende string vertoon met óf die -p óf --show-function opsies:
+
+
+
+
$ git grep -p gmtime_r *.c
+date.c=static int match_multi_number(timestamp_t num, char c, const char *date,
+date.c: if (gmtime_r(&now, &now_tm))
+date.c=static int match_digit(const char *date, struct tm *tm, int *offset, int *tm_gmt)
+date.c: if (gmtime_r(&time, tm)) {
+date.c=int parse_date_basic(const char *date, timestamp_t *timestamp, int *offset)
+date.c: /* gmtime_r() in match_digit() may have clobbered it */
+
+
+
+
Soos jy kan sien, word die gmtime_r roetine geroep vanaf beide die match_multi_number en match_digit funksies in die date.c lêer (die derde ooreenkoms wat vertoon word, verteenwoordig bloot die string wat in 'n opmerking verskyn).
+
+
+
Jy kan ook na komplekse kombinasies van stringe soek met die --and vlag, wat verseker dat veelvuldige ooreenkomste in dieselfde reël teks moet voorkom.
+Kom ons soek byvoorbeeld na enige reëls wat 'n konstante definieer waarvan die naam enigeen van die substringe “LINK” of “BUF_MAX” bevat, spesifiek in 'n ouer weergawe van die Git-kodebasis wat deur die merker (tag) v1.8.0 verteenwoordig word (ons sal die --break en --heading opsies bygooi wat help om die afvoer in 'n meer leesbare formaat op te deel):
+
+
+
+
$ git grep --break --heading \
+ -n -e '#define' --and \( -e LINK -e BUF_MAX \) v1.8.0
+v1.8.0:builtin/index-pack.c
+62:#define FLAG_LINK (1u<<20)
+
+v1.8.0:cache.h
+73:#define S_IFGITLINK 0160000
+74:#define S_ISGITLINK(m) (((m) & S_IFMT) == S_IFGITLINK)
+
+v1.8.0:environment.c
+54:#define OBJECT_CREATION_MODE OBJECT_CREATION_USES_HARDLINKS
+
+v1.8.0:strbuf.c
+326:#define STRBUF_MAXLINK (2*PATH_MAX)
+
+v1.8.0:symlinks.c
+53:#define FL_SYMLINK (1 << 2)
+
+v1.8.0:zlib.c
+30:/* #define ZLIB_BUF_MAX ((uInt)-1) */
+31:#define ZLIB_BUF_MAX ((uInt) 1024 * 1024 * 1024) /* 1GB */
+
+
+
+
Die git grep opdrag het 'n paar voordele bo normale soekopdragte soos grep en ack.
+Die eerste is dat dit regtig vinnig is, die tweede is dat jy deur enige boom in Git kan soek, nie net die werkgids nie.
+Soos ons in die bostaande voorbeeld gesien het, het ons gesoek na terme in 'n ouer weergawe van die Git-bronkode, nie die weergawe wat tans uitgetrek (checked out) was nie.
+
+
+
Git Log Soek (Git Log Searching)
+
+
Miskien soek jy nie waar 'n term bestaan nie, maar wanneer dit bestaan het of ingestel is.
+Die git log opdrag het 'n aantal kragtige instrumente om spesifieke vasleggings te vind deur die inhoud van hul boodskappe of selfs die inhoud van die diff wat hulle instel.
+
+
+
As ons byvoorbeeld wil uitvind wanneer die ZLIB_BUF_MAX konstante oorspronklik ingestel is, kan ons die -S opsie gebruik (in die omgangstaal verwys na as die Git “piksteel” of “pickaxe” opsie) om vir Git te sê om vir ons slegs daardie vasleggings te wys wat die aantal voorkomste van daardie string verander het.
+
+
+
+
$ git log -S ZLIB_BUF_MAX --oneline
+e01503b zlib: allow feeding more than 4GB in one go
+ef49a7a zlib: zlib can only process 4GB at a time
+
+
+
+
As ons na die diff van daardie vasleggings kyk, kan ons sien dat in ef49a7a die konstante ingestel is en in e01503b is dit gewysig.
+
+
+
As jy meer spesifiek moet wees, kan jy 'n gereelde uitdrukking (regular expression) verskaf om na te soek met die -G opsie.
+
+
+
Reël-log Soek (Line Log Search)
+
+
Nog 'n redelik gevorderde logsoektog wat kranksinnig nuttig is, is die reëlgeskiedenis-soektog.
+Voer eenvoudig git log uit met die -L opsie, en dit sal vir jou die geskiedenis van 'n funksie of reël kode in jou kodebasis wys.
+
+
+
Byvoorbeeld, as ons elke verandering wat aan die funksie git_deflate_bound in die zlib.c lêer gemaak is wil sien, kan ons git log -L :git_deflate_bound:zlib.c uitvoer.
+Dit sal probeer uitvind wat die grense van daardie funksie is en dan deur die geskiedenis kyk en vir ons elke verandering wys wat aan die funksie gemaak is as 'n reeks pleisters (patches) terug tot toe die funksie vir die eerste keer geskep is.
+
+
+
+
$ git log -L :git_deflate_bound:zlib.c
+commit ef49a7a0126d64359c974b4b3b71d7ad42ee3bca
+Author: Junio C Hamano <gitster@pobox.com>
+Date: Fri Jun 10 11:52:15 2011 -0700
+
+ zlib: zlib can only process 4GB at a time
+
+diff --git a/zlib.c b/zlib.c
+--- a/zlib.c
++++ b/zlib.c
+@@ -85,5 +130,5 @@
+-unsigned long git_deflate_bound(z_streamp strm, unsigned long size)
++unsigned long git_deflate_bound(git_zstream *strm, unsigned long size)
+ {
+- return deflateBound(strm, size);
++ return deflateBound(&strm->z, size);
+ }
+
+
+commit 225a6f1068f71723a910e8565db4e252b3ca21fa
+Author: Junio C Hamano <gitster@pobox.com>
+Date: Fri Jun 10 11:18:17 2011 -0700
+
+ zlib: wrap deflateBound() too
+
+diff --git a/zlib.c b/zlib.c
+--- a/zlib.c
++++ b/zlib.c
+@@ -81,0 +85,5 @@
++unsigned long git_deflate_bound(z_streamp strm, unsigned long size)
++{
++ return deflateBound(strm, size);
++}
++
+
+
+
+
As Git nie kan uitvind hoe om 'n funksie of metode in jou programmeertaal te pas nie, kan jy dit ook voorsien van 'n gereelde uitdrukking (of regex).
+Byvoorbeeld, dit sou dieselfde ding gedoen het as die voorbeeld hierbo: git log -L '/unsigned long git_deflate_bound/',/^}/:zlib.c.
+Jy kan dit ook 'n reeks reëls of 'n enkele reëlnommer gee en jy sal dieselfde soort afvoer kry.
+
+
+
Submodules
+
+
Dit gebeur dikwels dat terwyl jy aan een projek werk, jy 'n ander projek daaruit moet gebruik.
+Miskien is dit 'n biblioteek wat 'n derde party ontwikkel het of wat jy afsonderlik ontwikkel en in veelvuldige ouerprojekte gebruik.
+'n Algemene probleem ontstaan in hierdie scenario’s: jy wil die twee projekte as afsonderlik kan hanteer, maar tog die een vanuit die ander kan gebruik.
+
+
Hier is 'n voorbeeld.
+Sê nou jy ontwikkel 'n webwerf en skep Atom-voere.
+In plaas daarvan om jou eie Atom-genererende kode te skryf, besluit jy om 'n biblioteek te gebruik.
+Jy sal waarskynlik hierdie kode moet insluit vanaf 'n gedeelde biblioteek soos 'n CPAN-installasie of Ruby-gem, of die bronkode in jou eie projekboom kopieer.
+Die probleem met die insluiting van die biblioteek is dat dit moeilik is om die biblioteek op enige manier aan te pas en dikwels moeiliker om dit te ontplooi (deploy), aangesien jy moet seker maak dat elke kliënt daardie biblioteek beskikbaar het.
+Die probleem met die kopiëring van die kode in jou eie projek, is dat enige pasgemaakte veranderings wat jy maak moeilik is om in te smelt wanneer stroomopwaartse veranderings beskikbaar word.
+
+
Git pak hierdie probleem aan met behulp van submodules.
+Submodules laat jou toe om 'n Git-bewaarplek (repository) as 'n subgids van 'n ander Git-bewaarplek te hou.
+Dit laat jou toe om 'n ander bewaarplek in jou projek te kloon en jou vasleggings (commits) afsonderlik te hou.
+
+
Om met Submodules te Begin
+
+
Ons sal stap vir stap deur die ontwikkeling van 'n eenvoudige projek gaan wat in 'n hoofprojek en 'n paar subprojekte opgedeel is.
+
+
+
Kom ons begin deur 'n bestaande Git-bewaarplek as 'n submodule by te voeg van die bewaarplek waaraan ons werk.
+Om 'n nuwe submodule by te voeg, gebruik jy die git submodule add opdrag met die absolute of relatiewe URL van die projek wat jy wil begin naspoor.
+In hierdie voorbeeld sal ons 'n biblioteek genaamd “DbConnector” byvoeg.
+
+
+
+
$ git submodule add https://github.com/chaconinc/DbConnector
+Cloning into 'DbConnector'...
+remote: Counting objects: 11, done.
+remote: Compressing objects: 100% (10/10), done.
+remote: Total 11 (delta 0), reused 11 (delta 0)
+Unpacking objects: 100% (11/11), done.
+Checking connectivity... done.
+
+
+
+
By verstek sal submodules die subprojek byvoeg in 'n gids met dieselfde naam as die bewaarplek, in hierdie geval “DbConnector”.
+Jy kan 'n ander pad aan die einde van die opdrag byvoeg as jy wil hê dit moet iewers anders heengaan.
+
+
+
As jy git status op hierdie punt uitvoer, sal jy 'n paar dinge opmerk.
+
+
+
+
$ git status
+On branch master
+Your branch is up-to-date with 'origin/master'.
+
+Changes to be committed:
+ (use "git reset HEAD <file>..." to unstage)
+
+ new file: .gitmodules
+ new file: DbConnector
+
+
+
+
Eerstens behoort jy die nuwe .gitmodules lêer op te merk.
+Dit is 'n konfigurasielêer wat die kartering (mapping) stoor tussen die projek se URL en die plaaslike subgids waarin jy dit ingetrek het:
+
+
+
+
[submodule "DbConnector"]
+ path = DbConnector
+ url = https://github.com/chaconinc/DbConnector
+
+
+
+
As jy veelvuldige submodules het, sal jy veelvuldige inskrywings in hierdie lêer hê.
+Dit is belangrik om op te let dat hierdie lêer onder weergawebeheer is saam met jou ander lêers, soos jou .gitignore lêer.
+Dit word met die res van jou projek opgestuur en ingetrek (pushed and pulled).
+Dit is hoe ander mense wat hierdie projek kloon, weet waar om die submoduleprojekte vandaan te kry.
+
+
+
+
+|
+ Note
+ |
+
+
+ Aangesien die URL in die .gitmodules-lêer is waarvandaan ander mense eers sal probeer kloon/afhaal, maak seker dat jy 'n URL gebruik waartoe hulle toegang het indien moontlik.
+Byvoorbeeld, as jy 'n ander URL gebruik om na te push as waarvandaan ander sou pull, gebruik die een waartoe ander toegang het.
+Jy kan hierdie waarde plaaslik oorskryf met git config submodule.DbConnector.url PRIVATE_URL vir jou eie gebruik.
+Waar van toepassing, kan 'n relatiewe URL nuttig wees.
+ |
+
+
+
+
+
Die ander lys in die git status afvoer is die projekvouerinskrywing.
+As jy git diff daarop uitvoer, sien jy iets interessant:
+
+
+
+
$ git diff --cached DbConnector
+diff --git a/DbConnector b/DbConnector
+new file mode 160000
+index 0000000..c3f01dc
+--- /dev/null
++++ b/DbConnector
+@@ -0,0 +1 @@
++Subproject commit c3f01dc8862123d317dd46284b05b6892c7b29bc
+
+
+
+
Alhoewel DbConnector 'n subgids in jou werkgids is, sien Git dit as 'n submodule en spoor nie sy inhoud na as jy nie in daardie gids is nie.
+In plaas daarvan sien Git dit as 'n spesifieke vaslegging van daardie bewaarplek.
+
+
+
As jy 'n effens mooier diff-afvoer wil hê, kan jy die --submodule opsie aan git diff deurgee.
+
+
+
+
$ git diff --cached --submodule
+diff --git a/.gitmodules b/.gitmodules
+new file mode 100644
+index 0000000..71fc376
+--- /dev/null
++++ b/.gitmodules
+@@ -0,0 +1,3 @@
++[submodule "DbConnector"]
++ path = DbConnector
++ url = https://github.com/chaconinc/DbConnector
+Submodule DbConnector 0000000...c3f01dc (new submodule)
+
+
+
+
Wanneer jy vaslê (commit), sien jy iets soos dit:
+
+
+
+
$ git commit -am 'Add DbConnector module'
+[master fb9093c] Add DbConnector module
+ 2 files changed, 4 insertions(+)
+ create mode 100644 .gitmodules
+ create mode 160000 DbConnector
+
+
+
+
Let op die 160000 modus vir die DbConnector inskrywing.
+Dit is 'n spesiale modus in Git wat basies beteken dat jy 'n vaslegging aanteken as 'n gidsinskrywing in plaas van 'n subgids of 'n lêer.
+
+
+
Laastens, push hierdie veranderings:
+
+
+
+
$ git push origin master
+
+
+
+
Kloning van 'n Projek met Submodules
+
+
Hier sal ons 'n projek kloon wat 'n submodule in het.
+Wanneer jy so 'n projek kloon, kry jy by verstek die gidse wat submodules bevat, maar nog geen van die lêers binne-in hulle nie:
+
+
+
+
$ git clone https://github.com/chaconinc/MainProject
+Cloning into 'MainProject'...
+remote: Counting objects: 14, done.
+remote: Compressing objects: 100% (13/13), done.
+remote: Total 14 (delta 1), reused 13 (delta 0)
+Unpacking objects: 100% (14/14), done.
+Checking connectivity... done.
+$ cd MainProject
+$ ls -la
+total 16
+drwxr-xr-x 9 schacon staff 306 Sep 17 15:21 .
+drwxr-xr-x 7 schacon staff 238 Sep 17 15:21 ..
+drwxr-xr-x 13 schacon staff 442 Sep 17 15:21 .git
+-rw-r--r-- 1 schacon staff 92 Sep 17 15:21 .gitmodules
+drwxr-xr-x 2 schacon staff 68 Sep 17 15:21 DbConnector
+-rw-r--r-- 1 schacon staff 756 Sep 17 15:21 Makefile
+drwxr-xr-x 3 schacon staff 102 Sep 17 15:21 includes
+drwxr-xr-x 4 schacon staff 136 Sep 17 15:21 scripts
+drwxr-xr-x 4 schacon staff 136 Sep 17 15:21 src
+$ cd DbConnector/
+$ ls
+$
+
+
+
+
Die DbConnector gids is daar, maar leeg.
+Jy moet twee opdragte vanaf die hoofprojek uitvoer: git submodule init om jou plaaslike konfigurasielêer te inisialiseer, en git submodule update om al die data van daardie projek af te haal en die toepaslike vaslegging uit te check wat in jou superprojek gelys is:
+
+
+
+
$ git submodule init
+Submodule 'DbConnector' (https://github.com/chaconinc/DbConnector) registered for path 'DbConnector'
+$ git submodule update
+Cloning into 'DbConnector'...
+remote: Counting objects: 11, done.
+remote: Compressing objects: 100% (10/10), done.
+remote: Total 11 (delta 0), reused 11 (delta 0)
+Unpacking objects: 100% (11/11), done.
+Checking connectivity... done.
+Submodule path 'DbConnector': checked out 'c3f01dc8862123d317dd46284b05b6892c7b29bc'
+
+
+
+
Nou is jou DbConnector subgids op die presiese toestand as wat dit was toe jy vroeër vasgelê het.
+
+
+
Daar is egter 'n ander manier om dit te doen wat 'n bietjie makliker is.
+As jy --recurse-submodules by die git clone opdrag voeg, sal dit outomaties elke submodule in die bewaarplek inisialiseer en opdateer, insluitend geneste submodules as enige van die submodules in die bewaarplek self submodules het.
+
+
+
+
$ git clone --recurse-submodules https://github.com/chaconinc/MainProject
+Cloning into 'MainProject'...
+remote: Counting objects: 14, done.
+remote: Compressing objects: 100% (13/13), done.
+remote: Total 14 (delta 1), reused 13 (delta 0)
+Unpacking objects: 100% (14/14), done.
+Checking connectivity... done.
+Submodule 'DbConnector' (https://github.com/chaconinc/DbConnector) registered for path 'DbConnector'
+Cloning into 'DbConnector'...
+remote: Counting objects: 11, done.
+remote: Compressing objects: 100% (10/10), done.
+remote: Total 11 (delta 0), reused 11 (delta 0)
+Unpacking objects: 100% (11/11), done.
+Checking connectivity... done.
+Submodule path 'DbConnector': checked out 'c3f01dc8862123d317dd46284b05b6892c7b29bc'
+
+
+
+
As jy reeds die projek gekloon het en --recurse-submodules vergeet het, kan jy die git submodule init en git submodule update stappe kombineer deur git submodule update --init uit te voer.
+Om ook enige geneste submodules te inisialiseer, af te haal en uit te check, kan jy die onfeilbare git submodule update --init --recursive gebruik.
+
+
+
Werk aan 'n Projek met Submodules
+
+
Nou het ons 'n kopie van 'n projek met submodules daarin en sal met ons spanmaats saamwerk op beide die hoofprojek en die submoduleprojek.
+
+
+
Intrek van Stroomopwaartse Veranderings vanaf die Submodule-remote
+
+
Die eenvoudigste model vir die gebruik van submodules in 'n projek sal wees as jy net 'n subprojek verbruik en van tyd tot tyd opdaterings daaruit wil kry, maar nie regtig iets in jou checkout wysig nie.
+Kom ons stap deur 'n eenvoudige voorbeeld daarvan.
+
+
+
As jy wil kyk vir nuwe werk in 'n submodule, kan jy in die gids ingaan en git fetch uitvoer en git merge op die stroomopwaartse tak doen om die plaaslike kode by te werk.
+
+
+
+
$ git fetch
+From https://github.com/chaconinc/DbConnector
+ c3f01dc..d0354fc master -> origin/master
+$ git merge origin/master
+Updating c3f01dc..d0354fc
+Fast-forward
+ scripts/connect.sh | 1 +
+ src/db.c | 1 +
+ 2 files changed, 2 insertions(+)
+
+
+
+
Nou as jy teruggaan na die hoofprojek en git diff --submodule uitvoer, kan jy sien dat die submodule opgedateer is en 'n lys kry van vasleggings wat daaraan bygevoeg is.
+As jy nie --submodule elke keer as jy git diff uitvoer wil intik nie, kan jy dit as die verstekformaat stel deur die diff.submodule konfigurasiewaarde op “log” te stel.
+
+
+
+
$ git config --global diff.submodule log
+$ git diff
+Submodule DbConnector c3f01dc..d0354fc:
+ > more efficient db routine
+ > better connection routine
+
+
+
+
As jy op hierdie punt vaslê, sal jy die submodule sluit (lock) sodat dit die nuwe kode het wanneer ander mense opdateer.
+
+
+
Daar is ook 'n makliker manier om dit te doen, as jy verkies om nie met die hand af te haal en te smelt in die subgids nie.
+As jy git submodule update --remote uitvoer, sal Git in jou submodules ingaan en namens jou afhaal en opdateer.
+
+
+
+
$ git submodule update --remote DbConnector
+remote: Counting objects: 4, done.
+remote: Compressing objects: 100% (2/2), done.
+remote: Total 4 (delta 2), reused 4 (delta 2)
+Unpacking objects: 100% (4/4), done.
+From https://github.com/chaconinc/DbConnector
+ 3f19983..d0354fc master -> origin/master
+Submodule path 'DbConnector': checked out 'd0354fc054692d3906c85c3af05ddce39a1c0644'
+
+
+
+
Hierdie opdrag sal by verstek aanneem dat jy die checkout wil opdateer na die verstektak van die afgeleë submodule-bewaarplek (die een waarna HEAD op die remote wys).
+Jy kan dit egter stel op iets anders as jy wil.
+Byvoorbeeld, as jy wil hê die DbConnector submodule moet daardie bewaarplek se “stable” tak naspoor, kan jy dit stel in óf jou .gitmodules lêer (sodat almal anders dit ook naspoor), óf net in jou plaaslike .git/config lêer.
+Kom ons stel dit in die .gitmodules lêer:
+
+
+
+
$ git config -f .gitmodules submodule.DbConnector.branch stable
+
+$ git submodule update --remote
+remote: Counting objects: 4, done.
+remote: Compressing objects: 100% (2/2), done.
+remote: Total 4 (delta 2), reused 4 (delta 2)
+Unpacking objects: 100% (4/4), done.
+From https://github.com/chaconinc/DbConnector
+ 27cf5d3..c87d55d stable -> origin/stable
+Submodule path 'DbConnector': checked out 'c87d55d4c6d4b05ee34fbc8cb6f7bf4585ae6687'
+
+
+
+
As jy die -f .gitmodules weglaat sal dit net die verandering vir jou maak, maar dit maak waarskynlik meer sin om daardie inligting saam met die bewaarplek te spoor sodat almal dit ook doen.
+
+
+
Wanneer ons op hierdie punt git status uitvoer, sal Git vir ons wys dat ons “new commits” (nuwe vasleggings) op die submodule het.
+
+
+
+
$ git status
+On branch master
+Your branch is up-to-date with 'origin/master'.
+
+Changes not staged for commit:
+ (use "git add <file>..." to update what will be committed)
+ (use "git checkout -- <file>..." to discard changes in working directory)
+
+ modified: .gitmodules
+ modified: DbConnector (new commits)
+
+no changes added to commit (use "git add" and/or "git commit -a")
+
+
+
+
As jy die konfigurasie-instelling status.submodulesummary stel, sal Git ook vir jou 'n kort opsomming van veranderings aan jou submodules wys:
+
+
+
+
$ git config status.submodulesummary 1
+
+$ git status
+On branch master
+Your branch is up-to-date with 'origin/master'.
+
+Changes not staged for commit:
+ (use "git add <file>..." to update what will be committed)
+ (use "git checkout -- <file>..." to discard changes in working directory)
+
+ modified: .gitmodules
+ modified: DbConnector (new commits)
+
+Submodules changed but not updated:
+
+* DbConnector c3f01dc...c87d55d (4):
+ > catch non-null terminated lines
+
+
+
+
As jy op hierdie oomblik git diff uitvoer, kan ons sien dat ons beide ons .gitmodules lêer gewysig het en ook dat daar 'n aantal vasleggings is wat ons ingetrek het en gereed is om na ons submodule-projek vas te lê.
+
+
+
+
$ git diff
+diff --git a/.gitmodules b/.gitmodules
+index 6fc0b3d..fd1cc29 100644
+--- a/.gitmodules
++++ b/.gitmodules
+@@ -1,3 +1,4 @@
+ [submodule "DbConnector"]
+ path = DbConnector
+ url = https://github.com/chaconinc/DbConnector
++ branch = stable
+ Submodule DbConnector c3f01dc..c87d55d:
+ > catch non-null terminated lines
+ > more robust error handling
+ > more efficient db routine
+ > better connection routine
+
+
+
+
Dit is nogal oulik aangesien ons regtig die log van vasleggings kan sien wat ons op die punt is om na ons submodule vas te lê.
+Sodra dit vasgelê is, kan jy hierdie inligting ook agterna sien wanneer jy git log -p uitvoer.
+
+
+
+
$ git log -p --submodule
+commit 0a24cfc121a8a3c118e0105ae4ae4c00281cf7ae
+Author: Scott Chacon <schacon@gmail.com>
+Date: Wed Sep 17 16:37:02 2014 +0200
+
+ updating DbConnector for bug fixes
+
+diff --git a/.gitmodules b/.gitmodules
+index 6fc0b3d..fd1cc29 100644
+--- a/.gitmodules
++++ b/.gitmodules
+@@ -1,3 +1,4 @@
+ [submodule "DbConnector"]
+ path = DbConnector
+ url = https://github.com/chaconinc/DbConnector
++ branch = stable
+Submodule DbConnector c3f01dc..c87d55d:
+ > catch non-null terminated lines
+ > more robust error handling
+ > more efficient db routine
+ > better connection routine
+
+
+
+
Git sal by verstek probeer om al jou submodules op te dateer wanneer jy git submodule update --remote uitvoer.
+As jy baie daarvan het, sal jy dalk die naam wil deurgee van slegs die submodule wat jy wil probeer opdateer.
+
+
+
+
Intrek van Stroomopwaartse Veranderings vanaf die Projek-remote
+
+
Kom ons plaas ons nou in die skoene van jou medewerker, wat hul eie plaaslike kloon van die MainProject-bewaarplek het.
+Om bloot git pull uit te voer om jou nuut-vasgelegde veranderings te kry, is nie genoeg nie:
+
+
+
+
$ git pull
+From https://github.com/chaconinc/MainProject
+ fb9093c..0a24cfc master -> origin/master
+Fetching submodule DbConnector
+From https://github.com/chaconinc/DbConnector
+ c3f01dc..c87d55d stable -> origin/stable
+Updating fb9093c..0a24cfc
+Fast-forward
+ .gitmodules | 2 +-
+ DbConnector | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+$ git status
+ On branch master
+Your branch is up-to-date with 'origin/master'.
+Changes not staged for commit:
+ (use "git add <file>..." to update what will be committed)
+ (use "git checkout -- <file>..." to discard changes in working directory)
+
+ modified: DbConnector (new commits)
+
+Submodules changed but not updated:
+
+* DbConnector c87d55d...c3f01dc (4):
+ < catch non-null terminated lines
+ < more robust error handling
+ < more efficient db routine
+ < better connection routine
+
+no changes added to commit (use "git add" and/or "git commit -a")
+
+
+
+
By verstek haal die git pull opdrag rekursief submoduleveranderings af (fetch), soos ons in die afvoer van die eerste opdrag hierbo kan sien.
+Dit dateer egter nie die submodules op nie.
+Dit word getoon deur die afvoer van die git status opdrag, wat wys dat die submodule “modified” is, en “new commits” het.
+Wat meer is, die hakies wat die nuwe vasleggings wys, wys na links (<), wat aandui dat hierdie vasleggings in MainProject opgeteken is, maar nie teenwoordig is in die plaaslike DbConnector checkout nie.
+Om die opdatering te finaliseer, moet jy git submodule update uitvoer:
+
+
+
+
$ git submodule update --init --recursive
+Submodule path 'vendor/plugins/demo': checked out '48679c6302815f6c76f1fe30625d795d9e55fc56'
+
+$ git status
+ On branch master
+Your branch is up-to-date with 'origin/master'.
+nothing to commit, working tree clean
+
+
+
+
Let daarop dat jy om aan die veilige kant te wees, git submodule update met die --init vlag moet uitvoer vir ingeval die MainProject-vasleggings wat jy so pas ingetrek het nuwe submodules bygevoeg het, en met die --recursive vlag indien enige submodules geneste submodules het.
+
+
+
As jy hierdie proses wil outomatiseer, kan jy die --recurse-submodules vlag by die git pull opdrag voeg (sedert Git 2.14).
+Dit sal Git git submodule update dadelik ná die pull laat uitvoer en die submodules in die regte toestand plaas.
+Boonop, as jy wil hê dat Git altyd moet intrek met --recurse-submodules, kan jy die konfigurasie-opsie submodule.recurse stel na true (dit werk vir git pull sedert Git 2.15).
+Hierdie opsie sal maak dat Git die --recurse-submodules vlag gebruik vir alle opdragte wat dit ondersteun (behalwe clone).
+
+
+
Daar is 'n spesiale situasie wat kan gebeur wanneer superprojekopdaterings ingetrek word: dit kan wees dat die stroomopwaartse bewaarplek die URL van die submodule in die .gitmodules lêer in een van die vasleggings wat jy intrek verander het.
+Dit kan byvoorbeeld gebeur as die submoduleprojek sy gasheerplatform verander.
+In daardie geval is dit moontlik dat git pull --recurse-submodules, of git submodule update, misluk as die superprojek verwys na 'n submodule-vaslegging wat nie gevind word in die submodule se remote soos plaaslik in jou bewaarplek opgestel is nie.
+Om hierdie situasie reg te stel, word die git submodule sync opdrag benodig:
+
+
+
+
# kopieer die nuwe URL na jou plaaslike konfigurasie
+$ git submodule sync --recursive
+# dateer die submodule op vanaf die nuwe URL
+$ git submodule update --init --recursive
+
+
+
+
+
Werk aan 'n Submodule
+
+
Dit is hoogs waarskynlik dat as jy submodules gebruik, jy dit doen omdat jy regtig aan die kode in die submodule wil werk terwyl jy aan die kode in die hoofprojek (of oor verskeie submodules heen) werk.
+Andersins sou jy waarskynlik eerder 'n eenvoudiger afhanklikheidsbestuurstelsel (dependency management system soos Maven of Rubygems) gebruik het.
+
+
+
Kom ons gaan nou deur 'n voorbeeld waar ons gelyktydig veranderings aan die submodule asook aan die hoofprojek maak, en daardie veranderings terselfdertyd vaslê en publiseer.
+
+
+
Tot dusver, wanneer ons die git submodule update opdrag uitgevoer het om veranderings van die submodule-bewaarplekke te haal, het Git die veranderings gekry en die lêers in die subgids opgedateer, maar sal die sub-bewaarplek agterlaat in 'n sogenaamde “detached HEAD” toestand.
+Dit beteken dat daar geen plaaslike werktak (soos master byvoorbeeld) is wat veranderings naspoor nie.
+Sonder 'n werktak wat veranderings naspoor, beteken dit dat selfs as jy veranderings na die submodule vaslê, sal daardie veranderings heel moontlik verlore raak die volgende keer as jy git submodule update uitvoer.
+Jy moet 'n paar ekstra stappe doen as jy wil hê dat veranderings in 'n submodule nagespoor moet word.
+
+
+
Om jou submodule so op te stel dat dit makliker is om daarin te gaan en te kap, moet jy twee dinge doen.
+Jy moet in elke submodule ingaan en 'n tak uittrek om aan te werk.
+Dan moet jy vir Git vertel wat om te doen as jy veranderings gemaak het en later git submodule update --remote nuwe werk van stroomop intrek.
+Die opsies is dat jy dit in jou plaaslike werk kan insmelt (merge), of jy kan probeer om jou plaaslike werk bo-op die nuwe veranderings te rebase.
+
+
+
Kom ons gaan eerstens in ons submodule-gids in en trek 'n tak uit.
+
+
+
+
$ cd DbConnector/
+$ git checkout stable
+Switched to branch 'stable'
+
+
+
+
Kom ons probeer ons submodule opdateer met die “merge” opsie.
+Om dit handmatig te spesifiseer, kan ons bloot die --merge opsie by ons update oproep voeg.
+Hier sal ons sien dat daar 'n verandering op die bediener vir hierdie submodule was en dit word ingesmelt.
+
+
+
+
$ cd ..
+$ git submodule update --remote --merge
+remote: Counting objects: 4, done.
+remote: Compressing objects: 100% (2/2), done.
+remote: Total 4 (delta 2), reused 4 (delta 2)
+Unpacking objects: 100% (4/4), done.
+From https://github.com/chaconinc/DbConnector
+ c87d55d..92c7337 stable -> origin/stable
+Updating c87d55d..92c7337
+Fast-forward
+ src/main.c | 1 +
+ 1 file changed, 1 insertion(+)
+Submodule path 'DbConnector': merged in '92c7337b30ef9e0893e758dac2459d07362ab5ea'
+
+
+
+
As ons in die DbConnector gids ingaan, is die nuwe veranderings reeds in ons plaaslike stable tak ingesmelt.
+Kom ons kyk nou wat gebeur wanneer ons ons eie plaaslike verandering aan die biblioteek maak en iemand anders op dieselfde tyd nog 'n verandering stroomopwaarts push.
+
+
+
+
$ cd DbConnector/
+$ vim src/db.c
+$ git commit -am 'Unicode support'
+[stable f906e16] Unicode support
+ 1 file changed, 1 insertion(+)
+
+
+
+
As ons nou ons submodule opdateer, kan ons sien wat gebeur wanneer ons 'n plaaslike verandering aangebring het en daar stroomop ook 'n verandering is wat ons moet inkorporeer.
+
+
+
+
$ cd ..
+$ git submodule update --remote --rebase
+First, rewinding head to replay your work on top of it...
+Applying: Unicode support
+Submodule path 'DbConnector': rebased into '5d60ef9bbebf5a0c1c1050f242ceeb54ad58da94'
+
+
+
+
As jy die --rebase of --merge vergeet, sal Git bloot die submodule opdateer na wat ook al op die bediener is en jou projek terugstel na 'n "detached HEAD"-toestand.
+
+
+
+
$ git submodule update --remote
+Submodule path 'DbConnector': checked out '5d60ef9bbebf5a0c1c1050f242ceeb54ad58da94'
+
+
+
+
As dit gebeur, moenie bekommerd wees nie, jy kan eenvoudig teruggaan in die gids en weer jou tak uittrek (wat steeds jou werk sal bevat) en met die hand origin/stable (of watter afgeleë tak jy ook al wil hê) insmelt of rebase.
+
+
+
As jy nie jou veranderings in jou submodule vasgelê het nie en jy voer 'n submodule update uit wat probleme sou veroorsaak, sal Git die veranderings afhaal, maar nie ongestoorde werk in jou submodulegids oorskryf nie.
+
+
+
+
$ git submodule update --remote
+remote: Counting objects: 4, done.
+remote: Compressing objects: 100% (3/3), done.
+remote: Total 4 (delta 0), reused 4 (delta 0)
+Unpacking objects: 100% (4/4), done.
+From https://github.com/chaconinc/DbConnector
+ 5d60ef9..c75e92a stable -> origin/stable
+error: Your local changes to the following files would be overwritten by checkout:
+ scripts/setup.sh
+Please, commit your changes or stash them before you can switch branches.
+Aborting
+Unable to checkout 'c75e92a2b3855c9e5b66f915308390d9db204aca' in submodule path 'DbConnector'
+
+
+
+
As jy veranderings gemaak het wat in stryd is met iets wat stroomopwaarts verander is, sal Git jou laat weet wanneer jy die opdatering uitvoer.
+
+
+
+
$ git submodule update --remote --merge
+Auto-merging scripts/setup.sh
+CONFLICT (content): Merge conflict in scripts/setup.sh
+Recorded preimage for 'scripts/setup.sh'
+Automatic merge failed; fix conflicts and then commit the result.
+Unable to merge 'c75e92a2b3855c9e5b66f915308390d9db204aca' in submodule path 'DbConnector'
+
+
+
+
Jy kan in die submodule-gids ingaan en die konflik regmaak soos jy normaalweg sou doen.
+
+
+
+
Publiseer Submodule Veranderings
+
+
Nou het ons 'n paar veranderings in ons submodule-gids.
+Sommige hiervan is van stroomop deur ons opdaterings ingebring en ander is plaaslik gemaak en is nog nie aan enigiemand anders beskikbaar nie aangesien ons dit nog nie gepush het nie.
+
+
+
+
$ git diff
+Submodule DbConnector c87d55d..82d2ad3:
+ > Merge from origin/stable
+ > Update setup script
+ > Unicode support
+ > Remove unnecessary method
+ > Add new option for conn pooling
+
+
+
+
As ons in die hoofprojek vaslê en dit push sonder om ook die submoduleveranderings op te push, gaan ander mense wat ons veranderings probeer uittrek, in die moeilikheid wees, want hulle sal geen manier hê om die submoduleveranderings te kry waarvan afhanklik is nie.
+Daardie veranderings sal slegs op ons plaaslike kopie bestaan.
+
+
+
Om seker te maak dat dit nie gebeur nie, kan jy Git vra om te kyk dat al jou submodules behoorlik gepush is voordat jy die hoofprojek push.
+Die git push opdrag neem die --recurse-submodules argument wat gestel kan word na óf “check” óf “on-demand”.
+Die “check” opsie sal maak dat push eenvoudig misluk as enige van die vasgelegde submoduleveranderings nie gepush is nie.
+
+
+
+
$ git push --recurse-submodules=check
+The following submodule paths contain changes that can
+not be found on any remote:
+ DbConnector
+
+Please try
+
+ git push --recurse-submodules=on-demand
+
+or cd to the path and use
+
+ git push
+
+to push them to a remote.
+
+
+
+
Soos jy kan sien, gee dit vir ons ook nuttige raad oor wat ons volgende sal wil doen.
+Die eenvoudige opsie is om in elke submodule in te gaan en met die hand na die remotes te push om seker te maak dat hulle ekstern beskikbaar is, en dan hierdie push weer te probeer.
+As jy wil hê dat die “check” gedrag vir alle pushes moet plaasvind, kan jy hierdie gedrag die verstek maak deur git config push.recurseSubmodules check uit te voer.
+
+
+
Die ander opsie is om die “on-demand” waarde te gebruik, wat dit vir jou sal probeer doen.
+
+
+
+
$ git push --recurse-submodules=on-demand
+Pushing submodule 'DbConnector'
+Counting objects: 9, done.
+Delta compression using up to 8 threads.
+Compressing objects: 100% (8/8), done.
+Writing objects: 100% (9/9), 917 bytes | 0 bytes/s, done.
+Total 9 (delta 3), reused 0 (delta 0)
+To https://github.com/chaconinc/DbConnector
+ c75e92a..82d2ad3 stable -> stable
+Counting objects: 2, done.
+Delta compression using up to 8 threads.
+Compressing objects: 100% (2/2), done.
+Writing objects: 100% (2/2), 266 bytes | 0 bytes/s, done.
+Total 2 (delta 1), reused 0 (delta 0)
+To https://github.com/chaconinc/MainProject
+ 3d6d338..9a377d1 master -> master
+
+
+
+
Soos jy daar kan sien, het Git na die DbConnector module gegaan en dit gepush voor die hoofprojek gepush is.
+As daardie submodule-push vir een of ander rede misluk, sal die hoofprojek-push ook misluk.
+Jy kan hierdie gedrag as die verstelling maak deur git config push.recurseSubmodules on-demand te doen.
+
+
+
+
Samesmelting van Submoduleveranderings
+
+
As jy 'n submodule-verwysing gelyktydig met iemand anders verander, kan jy dalk in 'n paar probleme vasloop.
+Dit wil sê, as die submodule geskiedenisse uiteengegaan het (diverged) en aan uiteenlopende takke in 'n superprojek vasgelê is, kan dit 'n bietjie werk verg vir jou om reg te maak.
+
+
+
As een van die vasleggings 'n direkte voorouer van die ander is ('n fast-forward saamsmelting), sal Git eenvoudig die laaste vir die saamsmelting kies, so dit werk goed.
+
+
+
Git sal egter nie eers 'n triviale saamsmelting vir jou probeer nie.
+As die submodule-vasleggings uiteenloop en saamgesmelt moet word, sal jy iets kry wat soos volg lyk:
+
+
+
+
$ git pull
+remote: Counting objects: 2, done.
+remote: Compressing objects: 100% (1/1), done.
+remote: Total 2 (delta 1), reused 2 (delta 1)
+Unpacking objects: 100% (2/2), done.
+From https://github.com/chaconinc/MainProject
+ 9a377d1..eb974f8 master -> origin/master
+Fetching submodule DbConnector
+warning: Failed to merge submodule DbConnector (merge following commits not found)
+Auto-merging DbConnector
+CONFLICT (submodule): Merge conflict in DbConnector
+Automatic merge failed; fix conflicts and then commit the result.
+
+
+
+
So basies wat hier gebeur het, is dat Git uitgevind het dat die twee takke punte in die submodule se geskiedenis aanteken wat uiteenlopend is en saamgesmelt moet word.
+Dit verduidelik dit as “merge following commits not found”, wat verwarrend is, maar ons sal oor 'n rukkie verduidelik hoekom dit so is.
+
+
+
Om die probleem op te los, moet jy uitvind in watter toestand die submodule behoort te wees.
+Vreemd genoeg gee Git jou nie regtig veel inligting om te help nie, selfs nie die SHA-1’s van die vasleggings van albei kante van die geskiedenis nie.
+Gelukkig is dit maklik om uit te vind.
+As jy git diff uitvoer, kan jy die SHA-1’s kry van die vasleggings wat aangeteken is in beide takke wat jy probeer saamsmelt het.
+
+
+
+
$ git diff
+diff --cc DbConnector
+index eb41d76,c771610..0000000
+--- a/DbConnector
++++ b/DbConnector
+
+
+
+
In hierdie geval is eb41d76 die vaslegging in ons submodule wat ons gehad het, en c771610 is die vaslegging wat stroomopwaarts (upstream) was.
+As ons by ons submodulegids ingaan, behoort dit reeds op eb41d76 te wees, aangesien die samesmelting dit nie sou geraak het nie.
+As dit om een of ander rede nie is nie, kan jy eenvoudig 'n tak skep en onttrek wat daarna verwys.
+
+
+
Wat belangrik is, is die SHA-1 van die vaslegging van die ander kant af.
+Dit is wat jy sal moet insmelt en oplos.
+Jy kan net die saamsmelting met die SHA-1 direk probeer, of jy kan 'n tak daarvoor skep en dan daardie een probeer insmelt.
+Ons beveel laasgenoemde aan, selfs net om 'n mooier samesmeltingsboodskap te maak.
+
+
+
So, ons sal na ons submodulegids gaan, 'n tak met die naam “try-merge” skep gebaseer op daardie tweede SHA-1 van git diff, en handmatig saamsmelt.
+
+
+
+
$ cd DbConnector
+
+$ git rev-parse HEAD
+eb41d764bccf88be77aced643c13a7fa86714135
+
+$ git branch try-merge c771610
+
+$ git merge try-merge
+Auto-merging src/main.c
+CONFLICT (content): Merge conflict in src/main.c
+Recorded preimage for 'src/main.c'
+Automatic merge failed; fix conflicts and then commit the result.
+
+
+
+
Ons het hier 'n werklike samesmeltingskonflik gekry, dus as ons dit oplos en vaslê, kan ons die hoofprojek bloot bywerk met die resultaat.
+
+
+
+
$ vim src/main.c (1)
+$ git add src/main.c
+$ git commit -am 'merged our changes'
+Recorded resolution for 'src/main.c'.
+[master 9fd905e] merged our changes
+
+$ cd .. (2)
+$ git diff (3)
+diff --cc DbConnector
+index eb41d76,c771610..0000000
+--- a/DbConnector
++++ b/DbConnector
+@@@ -1,1 -1,1 +1,1 @@@
+- Subproject commit eb41d764bccf88be77aced643c13a7fa86714135
+ -Subproject commit c77161012afbbe1f58b5053316ead08f4b7e6d1d
+++Subproject commit 9fd905e5d7f45a0d4cbc43d1ee550f16a30e825a
+$ git add DbConnector (4)
+
+$ git commit -m "Merge Tom's Changes" (5)
+[master 10d2c60] Merge Tom's Changes
+
+
+
+
+-
+
Eers los ons die konflik op.
+
+-
+
Dan gaan ons terug na die hoofprojekgids.
+
+-
+
Ons kan die SHA-1’s weer nagaan.
+
+-
+
Los die konfliksituasie met die submodule-inskrywing op.
+
+-
+
Lê ons saamsmelting vas.
+
+
+
+
+
Dit mag 'n bietjie verwarrend wees, maar dit is nie regtig te moeilik nie.
+
+
+
Interessant genoeg is daar 'n ander scenario wat Git hanteer.
+As daar 'n samesmeltingsvaslegging in die submodulegids is wat beide vasleggings in sy geskiedenis bevat, sal Git dit as 'n moontlike oplossing vir jou voorstel.
+Dit sien dat iemand iewers in die submoduleprojek takke saamgesmelt het wat hierdie twee vasleggings bevat, sodat jy miskien daardie een wil hê.
+
+
+
Dit is hoekom die foutboodskap vroeër was “merge following commits not found”, aangesien dit nie dit kon doen nie.
+Dit is verwarrend, want wie sou verwag het dat dit dit sou probeer doen?
+
+
+
As dit wel 'n enkele aanvaarbare samesmeltingsvaslegging vind, sal jy iets soos volg sien:
+
+
+
+
$ git merge origin/master
+warning: Failed to merge submodule DbConnector (not fast-forward)
+Found a possible merge resolution for the submodule:
+ 9fd905e5d7f45a0d4cbc43d1ee550f16a30e825a: > merged our changes
+If this is correct simply add it to the index for example
+by using:
+
+ git update-index --cacheinfo 160000 9fd905e5d7f45a0d4cbc43d1ee550f16a30e825a "DbConnector"
+
+which will accept this suggestion.
+Auto-merging DbConnector
+CONFLICT (submodule): Merge conflict in DbConnector
+Automatic merge failed; fix conflicts and then commit the result.
+
+
+
+
Die voorgestelde opdrag wat Git verskaf, sal die indeks opdateer asof jy git add uitgevoer het (wat die konflik verwyder), en dan vaslê.
+Jy moet dit waarskynlik egter nie doen nie.
+Jy kan net so maklik na die submodulegids gaan, sien wat die verskil is, met fast-forward na hierdie vaslegging versnel, dit deeglik toets, en dit dan vaslê.
+
+
+
+
$ cd DbConnector/
+$ git merge 9fd905e
+Updating eb41d76..9fd905e
+Fast-forward
+
+$ cd ..
+$ git add DbConnector
+$ git commit -am 'Fast forward to a common submodule child'
+
+
+
+
Dit bereik dieselfde doel, maar op hierdie manier kan jy ten minste verifieer dat dit werk en het jy die kode in jou submodulegids wanneer jy klaar is.
+
+
+
+
Submodule Wenke
+
+
Daar is 'n paar dinge wat jy kan doen om werk met submodules 'n bietjie makliker te maak.
+
+
+
Submodule Foreach
+
+
Daar is 'n foreach submodule opdrag om enige willekeurige opdrag in elke submodule uit te voer.
+Dit kan regtig baie nuttig wees as jy 'n aantal submodules in dieselfde projek het.
+
+
+
Byvoorbeeld, gestel ons wil 'n nuwe funksionaliteit begin of 'n foutsuiwering (bugfix) doen, en ons het werk aan die gang in verskeie submodules.
+Ons kan maklik al die werk in al ons submodules wegbêre (stash).
+
+
+
+
$ git submodule foreach 'git stash'
+Entering 'CryptoLibrary'
+No local changes to save
+Entering 'DbConnector'
+Saved working directory and index state WIP on stable: 82d2ad3 Merge from origin/stable
+HEAD is now at 82d2ad3 Merge from origin/stable
+
+
+
+
Dan kan ons 'n nuwe tak skep en na dit in al ons submodules oorslaan.
+
+
+
+
$ git submodule foreach 'git checkout -b featureA'
+Entering 'CryptoLibrary'
+Switched to a new branch 'featureA'
+Entering 'DbConnector'
+Switched to a new branch 'featureA'
+
+
+
+
Jy verstaan die idee.
+Een regtig nuttige ding wat jy kan doen, is om 'n oulike verenigde verskil (unified diff) van wat verander het in jou hoofprojek en al jou subprojekte asook voor te berei.
+
+
+
+
$ git diff; git submodule foreach 'git diff'
+Submodule DbConnector contains modified content
+diff --git a/src/main.c b/src/main.c
+index 210f1ae..1f0acdc 100644
+--- a/src/main.c
++++ b/src/main.c
+@@ -245,6 +245,8 @@ static int handle_alias(int *argcp, const char ***argv)
+
+ commit_pager_choice();
+
++ url = url_decode(url_orig);
++
+ /* build alias_argv */
+ alias_argv = xmalloc(sizeof(*alias_argv) * (argc + 1));
+ alias_argv[0] = alias_string + 1;
+Entering 'DbConnector'
+diff --git a/src/db.c b/src/db.c
+index 1aaefb6..5297645 100644
+--- a/src/db.c
++++ b/src/db.c
+@@ -93,6 +93,11 @@ char *url_decode_mem(const char *url, int len)
+ return url_decode_internal(&url, len, NULL, &out, 0);
+ }
+
++char *url_decode(const char *url)
++{
++ return url_decode_mem(url, strlen(url));
++}
++
+ char *url_decode_parameter_name(const char **query)
+ {
+ struct strbuf out = STRBUF_INIT;
+
+
+
+
Hier kan ons sien dat ons 'n funksie in 'n submodule definieer en dit in die hoofprojek oproep.
+Dit is natuurlik 'n vereenvoudigde voorbeeld, maar hopelik gee dit jou 'n idee van hoe dit nuttig mag wees.
+
+
+
+
Nuttige Aliassen
+
+
Jy mag dalk wil oorweeg om sekere aliassen op te stel vir sommige van hierdie opdragte aangesien hulle redelik lank kan wees en jy nie konfigurasieopsies vir meeste van hulle kan stel om as verstekwaardes te dien nie.
+Ons het gehandel oor die opstel van Git-aliassen in }}">Git-aliasse, maar hier is 'n voorbeeld van wat jy dalk wil opstel as jy van plan is om baie met submodules in Git te werk.
+
+
+
+
$ git config alias.sdiff '!'"git diff && git submodule foreach 'git diff'"
+$ git config alias.spush 'push --recurse-submodules=on-demand'
+$ git config alias.supdate 'submodule update --remote --merge'
+
+
+
+
Op hierdie manier kan jy net git supdate uitvoer wanneer jy jou submodules wil opdateer, of git spush om te push terwyl daar vir afhanklikhede van submodules gekontroleer word.
+
+
+
+
Probleme met Submodules
+
+
Die gebruik van submodules is egter nie sonder hikke nie.
+
+
+
Verandering van Takke
+
+
Byvoorbeeld, die verandering van takke met submodules daarin kan ook moeilik wees met Git-weergawes ouer as Git 2.13.
+As jy 'n nuwe tak skep, 'n submodule byvoeg, en dan terugverander na 'n tak sonder daardie submodule, bly jou submodulegids steeds daar as 'n ongeregistreerde (untracked) gids:
+
+
+
+
$ git --version
+git version 2.12.2
+
+$ git checkout -b add-crypto
+Switched to a new branch 'add-crypto'
+
+$ git submodule add https://github.com/chaconinc/CryptoLibrary
+Cloning into 'CryptoLibrary'...
+...
+
+$ git commit -am 'Add crypto library'
+[add-crypto 4445836] Add crypto library
+ 2 files changed, 4 insertions(+)
+ create mode 160000 CryptoLibrary
+
+$ git checkout master
+warning: unable to rmdir CryptoLibrary: Directory not empty
+Switched to branch 'master'
+Your branch is up-to-date with 'origin/master'.
+
+$ git status
+On branch master
+Your branch is up-to-date with 'origin/master'.
+
+Untracked files:
+ (use "git add <file>..." to include in what will be committed)
+
+ CryptoLibrary/
+
+nothing added to commit but untracked files present (use "git add" to track)
+
+
+
+
Dit is nie moeilik om die gids te verwyder nie, maar dit kan 'n bietjie verwarrend wees om dit daar in te hê.
+As jy dit wel verwyder en dan terugwissel na die tak wat daardie submodule het, sal jy submodule update --init moet laat loop om dit te herbevolk.
+
+
+
+
$ git clean -ffdx
+Removing CryptoLibrary/
+
+$ git checkout add-crypto
+Switched to branch 'add-crypto'
+
+$ ls CryptoLibrary/
+
+$ git submodule update --init
+Submodule path 'CryptoLibrary': checked out 'b8dda6aa182ea4464f3f3264b11e0268545172af'
+
+$ ls CryptoLibrary/
+Makefile includes scripts src
+
+
+
+
Weereens, nie werklik moeilik nie, maar dit kan 'n bietjie verwarrend wees.
+
+
+
Nuwer weergawes van Git (Git >= 2.13) vereenvoudig alles deur die --recurse-submodules vlag by die git checkout opdrag by te voeg, wat sorg dra om die submodules in die regte toestand te plaas vir die tak waarna ons oorskakel.
+
+
+
+
$ git --version
+git version 2.13.3
+
+$ git checkout -b add-crypto
+Switched to a new branch 'add-crypto'
+
+$ git submodule add https://github.com/chaconinc/CryptoLibrary
+Cloning into 'CryptoLibrary'...
+...
+
+$ git commit -am 'Add crypto library'
+[add-crypto 4445836] Add crypto library
+ 2 files changed, 4 insertions(+)
+ create mode 160000 CryptoLibrary
+
+$ git checkout --recurse-submodules master
+Switched to branch 'master'
+Your branch is up-to-date with 'origin/master'.
+
+$ git status
+On branch master
+Your branch is up-to-date with 'origin/master'.
+
+nothing to commit, working tree clean
+
+
+
+
Die gebruik van die --recurse-submodules vlag met git checkout kan ook nuttig wees as jy aan verskeie takke werk binne die superprojek, waar elkeen van jou submodules na verskillende vasleggings wys.
+Inderdaad, as jy oorskakel tussen takke wat na die submodule in verskillende vasleggings wys, sal die submodule in git status as “modified” vertoon word, asook “new commits” aandui.
+Dit is omdat die submodule se toestand by verstek nie oorgedra word by die oorskakeling na ander takke nie.
+
+
+
Dit kan baie verwarrend wees, so dit is 'n goeie idee om altyd git checkout --recurse-submodules te gebruik as jou projek submodules het.
+By ouer weergawes van Git, wat nie die --recurse-submodules vlag het nie, kan jy na die "checkout", git submodule update --init --recursive gebruik om die submodules weer reg in hul korrekte toestand te plaas.
+
+
+
Gelukkig kan jy vir Git (>=2.14) sê om altyd die --recurse-submodules vlag te gebruik deur die konfigurasie-opsie submodule.recurse in te stel: git config submodule.recurse true.
+Soos hierbo genoem, sal dit Git ook in submodules in laat afdaal vir elke opdrag wat 'n --recurse-submodules opsie het (behalwe git clone).
+
+
+
+
Skakeling van subgidse na submodules
+
+
Die ander hoofstrik waarin mense trap behels die skakeling van subgidse na submodules.
+As jy lêers in jou projek genaspoor het en jy hulle nou in 'n submodule wil plaas, moet jy versigtig wees anders gaan Git met jou ontevrede wees.
+Neem aan dat jy lêers in 'n subgids in jou projek het, en jy wil dit na 'n submodule verander.
+As jy die subgids verwyder en dan submodule add uitvoer, raas Git met jou:
+
+
+
+
$ rm -Rf CryptoLibrary/
+$ git submodule add https://github.com/chaconinc/CryptoLibrary
+'CryptoLibrary' already exists in the index
+
+
+
+
Jy moet eers die voorbereiding (staging) van die CryptoLibrary subgids ophef.
+Dan kan jy die submodule byvoeg:
+
+
+
+
$ git rm -r CryptoLibrary
+$ git submodule add https://github.com/chaconinc/CryptoLibrary
+Cloning into 'CryptoLibrary'...
+remote: Counting objects: 11, done.
+remote: Compressing objects: 100% (10/10), done.
+remote: Total 11 (delta 0), reused 11 (delta 0)
+Unpacking objects: 100% (11/11), done.
+Checking connectivity... done.
+
+
+
+
Gestel nou jy het dit in 'n tak gedoen.
+As jy poog om terug te skakel na 'n tak waar daardie lêers steeds in die werklike boom (tree) is eerder as 'n submodule, sal jy hierdie fout ontvang:
+
+
+
+
$ git checkout master
+error: The following untracked working tree files would be overwritten by checkout:
+ CryptoLibrary/Makefile
+ CryptoLibrary/includes/crypto.h
+ ...
+Please move or remove them before you can switch branches.
+Aborting
+
+
+
+
Jy kan dit forseer om oor te slaan na daardie tak toe met checkout -f, maar pasop dat jy nie nog-ongestoorde werk daarbinne het nie aangesien dit oorgeskryf kan word met hierdie opdrag.
+
+
+
+
$ git checkout -f master
+warning: unable to rmdir CryptoLibrary: Directory not empty
+Switched to branch 'master'
+
+
+
+
Dan, as jy weer teruggaan, kry jy om die een of ander rede 'n leë CryptoLibrary subgids en git submodule update herstel dit dalk ook nie.
+Jy mag dalk self binne die betrokke submodulegids moet inbeweeg en git checkout . daar uitvoer om al jou lêers weer terug te kan verkry.
+Jy kan dalk dink om eerder dit deur 'n submodule foreach draaiboekie (script) uit te voer wat dit weereens vir verskeie submodules self sal verrig.
+
+
+
Dit is belangrik om op te merk dat in deesdae se submodules, hulle al hul Git data stoor in die boonste projek se .git gids, so in teendeel as met baie ou weergawes van Git sal jy geen vasleggings of takke van 'n submodule kan kwytraak by die verwydering van daardie submodulegids nie.
+
+
+
Submodules met hierdie nutsgoed is nogal 'n vereenvoudigde en doeltreffende oplossing by die saamomgewing om in 'n verskeidenheid afsonderlike verhoudings of interafhanklike maar afsonderlike projekte terselfdertyd mee te werk.
+
+
+
Summary
+
+
You’ve seen a number of advanced tools that allow you to manipulate your commits and staging area more precisely.
+When you notice issues, you should be able to easily figure out what commit introduced them, when, and by whom.
+If you want to use subprojects in your project, you’ve learned how to accommodate those needs.
+At this point, you should be able to do most of the things in Git that you’ll need on the command line day to day and feel comfortable doing so.
+
Vervang (Replace)
+
+
Soos ons vroeër beklemtoon het, is die objekte in Git se objekdatabasis onveranderlik, maar Git bied wel 'n interessante manier om te maak asof dit objekte in sy databasis met ander objekte vervang.
+
+
Die replace opdrag laat jou toe om 'n objek in Git te spesifiseer en te sê "elke keer as jy na hierdie objek verwys, maak asof dit 'n ander objek is".
+Dit is die nuttigste om een vaslegging (commit) in jou geskiedenis met 'n ander te vervang sonder om die hele geskiedenis te hoef te herbou met, sê maar, git filter-branch.
+
+
Byvoorbeeld, sê nou jy het 'n massiewe kodegeskiedenis en wil jou bewaarplek (repository) opsplits in een kort geskiedenis vir nuwe ontwikkelaars en een baie langer en groter geskiedenis vir mense wat belangstel in data-ontginning (data mining).
+Jy kan die een geskiedenis op die ander ent (graft) deur die vroegste vaslegging in die nuwe lyn te "vervang" met die nuutste vaslegging in die oue.
+Dit is lekker omdat dit beteken dat jy nie eintlik elke vaslegging in die nuwe geskiedenis hoef te herskryf nie, soos wat jy normaalweg sou moes doen om hulle aan mekaar te koppel (omdat die afkoms die SHA-1’s beïnvloed).
+
+
Kom ons probeer dit uit.
+Kom ons neem 'n bestaande bewaarplek, deel dit op in twee bewaarplekke, een resente en een historiese, en dan sal ons sien hoe ons hulle kan herkombineer sonder om die resente bewaarplek se SHA-1-waardes via replace te wysig.
+
+
Ons sal 'n eenvoudige bewaarplek met vyf eenvoudige vasleggings gebruik:
+
+
+
$ git log --oneline
+ef989d8 Fifth commit
+c6e1e95 Fourth commit
+9c68fdc Third commit
+945704c Second commit
+c1822cf First commit
+
+
+
Ons wil dit opbreek in twee lyne van geskiedenis.
+Een lyn loop van vaslegging een tot vaslegging vier - dit sal die historiese een wees.
+Die tweede lyn sal net vasleggings vier en vyf wees - dit sal die resente geskiedenis wees.
+
+
+
}}" alt="Example Git history">
+
+
Figure 176. Voorbeeld van Git-geskiedenis
+
+
Wel, om die historiese geskiedenis te skep is maklik; ons kan net 'n tak in die geskiedenis plaas en dan daardie tak na die master tak van 'n nuwe afgeleë bewaarplek (remote repository) push.
+
+
+
$ git branch history c6e1e95
+$ git log --oneline --decorate
+ef989d8 (HEAD, master) Fifth commit
+c6e1e95 (history) Fourth commit
+9c68fdc Third commit
+945704c Second commit
+c1822cf First commit
+
+
+
+
}}" alt="Creating a new `history` branch">
+
+
Figure 177. Skep van 'n nuwe history tak
+
+
Nou kan ons die nuwe history tak na die master tak van ons nuwe bewaarplek push:
+
+
+
$ git remote add project-history https://github.com/schacon/project-history
+$ git push project-history history:master
+Counting objects: 12, done.
+Delta compression using up to 2 threads.
+Compressing objects: 100% (4/4), done.
+Writing objects: 100% (12/12), 907 bytes, done.
+Total 12 (delta 0), reused 0 (delta 0)
+Unpacking objects: 100% (12/12), done.
+To git@github.com:schacon/project-history.git
+ * [new branch] history -> master
+
+
+
Oukei, so ons geskiedenis is gepubliseer.
+Nou is die moeiliker deel om ons resente geskiedenis af te knot (truncate) sodat dit kleiner is.
+Ons het 'n oorvleueling nodig sodat ons 'n vaslegging in die een kan vervang met 'n ekwivalente vaslegging in die ander, so ons gaan dit afknot na net vasleggings vier en vyf (so vaslegging vier oorvleuel).
+
+
+
$ git log --oneline --decorate
+ef989d8 (HEAD, master) Fifth commit
+c6e1e95 (history) Fourth commit
+9c68fdc Third commit
+945704c Second commit
+c1822cf First commit
+
+
+
Dit is in hierdie geval nuttig om 'n basisvaslegging (base commit) te skep wat instruksies het oor hoe om die geskiedenis uit te brei, sodat ander ontwikkelaars weet wat om te doen as hulle die eerste vaslegging in die afgeknotte geskiedenis tref en meer nodig het.
+So, wat ons gaan doen, is om 'n aanvanklike vasleggingsobjek as ons basispunt met instruksies te skep, en dan die oorblywende vasleggings (vier en vyf) bo-op dit te rebase.
+
+
Om dit te doen, moet ons 'n punt kies om af te splits, wat vir ons die derde vaslegging is, wat 9c68fdc in SHA-taal is.
+Dus sal ons basisvaslegging op daardie boom (tree) gebaseer wees.
+Ons kan ons basisvaslegging skep met behulp van die commit-tree opdrag, wat net 'n boom neem en vir ons 'n splinternuwe, ouerlose vasleggingsobjek SHA-1 teruggee.
+
+
+
$ echo 'Get history from blah blah blah' | git commit-tree 9c68fdc^{tree}
+622e88e9cbfbacfb75b5279245b9fb38dfea10cf
+
+
+
+
+|
+ Note
+ |
+
+
+ Die commit-tree opdrag is een van 'n stel opdragte waarna algemeen as 'loodgieterswerk' (plumbing) opdragte verwys word.
+Hierdie is opdragte wat oor die algemeen nie bedoel is om direk gebruik te word nie, maar in plaas daarvan deur ander Git-opdragte gebruik word om kleiner take te verrig.
+By geleenthede wanneer ons vreemder dinge soos hierdie doen, laat hulle ons toe om regtig laevlak dinge te doen, maar dit is nie vir daaglikse gebruik bedoel nie.
+Jy kan meer oor loodgietersopdragte lees in }}">Loodgieterswerk en Porselein (Plumbing and Porcelain).
+ |
+
+
+
+
+
}}" alt="Creating a base commit using `commit-tree`">
+
+
Figure 178. Skep van 'n basisvaslegging met commit-tree
+
+
+
Goed, aangesien ons nou 'n basisvaslegging het, kan ons die res van ons geskiedenis bo-op dit rebase met git rebase --onto.
+Die --onto argument sal die SHA-1 wees wat ons pas van commit-tree af teruggekry het en die rebase-punt sal die derde vaslegging wees (die ouer van die eerste vaslegging wat ons wil behou, 9c68fdc):
+
+
+
$ git rebase --onto 622e88 9c68fdc
+First, rewinding head to replay your work on top of it...
+Applying: fourth commit
+Applying: fifth commit
+
+
+
+
}}" alt="Rebasing the history on top of the base commit">
+
+
Figure 179. Herbasering (Rebasing) van die geskiedenis bo-op die basisvaslegging
+
+
Goed, ons het nou ons resente geskiedenis herskryf bo-op 'n weggooi-basisvaslegging wat nou instruksies in het oor hoe om die hele geskiedenis te hersaamstel as ons wou.
+Ons kan daardie nuwe geskiedenis na 'n nuwe projek push en nou as mense daardie bewaarplek kloon, sal hulle net die mees onlangse twee vasleggings sien en dan 'n basisvaslegging met instruksies.
+
+
Kom ons ruil nou rolle om na iemand wat die projek vir die eerste keer kloon en wat die hele geskiedenis wil hê.
+Om die geskiedenisdata te kry na die kloning van hierdie afgeknotte bewaarplek, sal mens 'n tweede remote vir die historiese bewaarplek moet byvoeg en afhaal (fetch):
+
+
+
$ git clone https://github.com/schacon/project
+$ cd project
+
+$ git log --oneline master
+e146b5f Fifth commit
+81a708d Fourth commit
+622e88e Get history from blah blah blah
+
+$ git remote add project-history https://github.com/schacon/project-history
+$ git fetch project-history
+From https://github.com/schacon/project-history
+ * [new branch] master -> project-history/master
+
+
+
Nou sal die medewerker (collaborator) hul resente vasleggings in die master tak hê en die historiese vasleggings in die project-history/master tak.
+
+
+
$ git log --oneline master
+e146b5f Fifth commit
+81a708d Fourth commit
+622e88e Get history from blah blah blah
+
+$ git log --oneline project-history/master
+c6e1e95 Fourth commit
+9c68fdc Third commit
+945704c Second commit
+c1822cf First commit
+
+
+
Om hulle te kombineer, kan jy eenvoudig git replace aanroep met die vaslegging wat jy wil vervang en dan die vaslegging waarmee jy dit wil vervang.
+Ons wil dus die "vierde" vaslegging in die master tak vervang met die "vierde" vaslegging in die project-history/master tak:
+
+
+
$ git replace 81a708d c6e1e95
+
+
+
As jy nou na die geskiedenis van die master tak kyk, blyk dit om so te lyk:
+
+
+
$ git log --oneline master
+e146b5f Fifth commit
+81a708d Fourth commit
+9c68fdc Third commit
+945704c Second commit
+c1822cf First commit
+
+
+
Koel, nê? Sonder om al die SHA-1’s stroomop te hoef verander, kon ons een vaslegging in ons geskiedenis vervang met 'n heeltemal ander vaslegging en al die normale gereedskap (bisect, blame, ens.) sal werk soos ons sou verwag.
+
+
+
}}" alt="Combining the commits with `git replace`">
+
+
Figure 180. Kombinering van die vasleggings met git replace
+
+
+
Interessant genoeg wys dit steeds 81a708d as die SHA-1, alhoewel dit eintlik die c6e1e95 vasleggingsdata gebruik waarmee ons dit vervang het.
+Selfs al voer jy 'n opdrag soos cat-file uit, sal dit vir jou die vervangde data wys:
+
+
+
$ git cat-file -p 81a708d
+tree 7bc544cf438903b65ca9104a1e30345eee6c083d
+parent 9c68fdceee073230f19ebb8b5e7fc71b479c0252
+author Scott Chacon <schacon@gmail.com> 1268712581 -0700
+committer Scott Chacon <schacon@gmail.com> 1268712581 -0700
+
+fourth commit
+
+
+
Onthou dat die werklike ouer van 81a708d ons plekhouer-vaslegging (placeholder commit - 622e88e) was, nie 9c68fdce soos dit hier aandui nie.
+
+
Nog 'n interessante ding is dat hierdie data in ons verwysings (references) gehou word:
+
+
+
$ git for-each-ref
+e146b5f14e79d4935160c0e83fb9ebe526b8da0d commit refs/heads/master
+c6e1e95051d41771a649f3145423f8809d1a74d4 commit refs/remotes/history/master
+e146b5f14e79d4935160c0e83fb9ebe526b8da0d commit refs/remotes/origin/HEAD
+e146b5f14e79d4935160c0e83fb9ebe526b8da0d commit refs/remotes/origin/master
+c6e1e95051d41771a649f3145423f8809d1a74d4 commit refs/replace/81a708dd0e167a3f691541c7a6463343bc457040
+
+
+
Dit beteken dat dit maklik is om ons vervanging met ander te deel, want ons kan dit na ons bediener push en ander mense kan dit maklik aflaai.
+Dit is nie so nuttig in die geskiedenis-entings-scenario (history grafting scenario) waaroor ons hier gegaan het nie (aangesien almal in elk geval albei geskiedenisse sou aflaai, so hoekom hulle skei?), maar dit kan nuttig wees in ander omstandighede.
+
The world isn’t perfect.
+Usually, you can’t immediately switch every project you come in contact with to Git.
+Sometimes you’re stuck on a project using another VCS, and wish it was Git.
+We’ll spend the first part of this chapter learning about ways to use Git as a client when the project you’re working on is hosted in a different system.
At some point, you may want to convert your existing project to Git.
+The second part of this chapter covers how to migrate your project into Git from several specific systems, as well as a method that will work if no pre-built import tool exists.
+Git as a Client
+
+
+Git provides such a nice experience for developers that many people have figured out how to use it on their workstation, even if the rest of their team is using an entirely different VCS.
+There are a number of these adapters, called “bridges,” available.
+Here we’ll cover the ones you’re most likely to run into in the wild.
+
+
Git en Subversion (Git and Subversion)
+
+
+
+
+'n Groot fraksie van oopbron-ontwikkelingsprojekte en 'n goeie aantal korporatiewe projekte gebruik Subversion om hul bronkode te bestuur.
+Dit bestaan reeds vir meer as 'n dekade, en was vir die grootste deel van daardie tyd die de facto VCS-keuse vir oopbronprojekte.
+Dit is ook in baie opsigte baie soortgelyk aan CVS, wat voorheen die groot naam in die bronbeheerwêreld was.
+
+
+
+Een van Git se wonderlike kenmerke is 'n tweerigtingbrug na Subversion genaamd git svn.
+Hierdie hulpmiddel laat jou toe om Git as 'n geldige kliënt vir 'n Subversion-bediener te gebruik, sodat jy al die plaaslike kenmerke van Git kan gebruik en dan na 'n Subversion-bediener kan push asof jy Subversion plaaslik gebruik.
+Dit beteken jy kan plaaslike takking en saamsmelting (branching and merging) doen, die voorbereidingsarea (staging area) gebruik, herbasering (rebasing) en cherry-picking gebruik, ensovoorts, terwyl jou medewerkers in hul donker en antieke maniere voortgaan om te werk.
+Dit is 'n goeie manier om Git in die korporatiewe omgewing in te smokkel en jou mede-ontwikkelaars te help om doeltreffender te word terwyl jy lobby om die infrastruktuur te laat verander om Git ten volle te ondersteun.
+Die Subversion-brug is die hekdwelm (gateway drug) na die DVCS-wêreld.
+
+
+
git svn
+
+
Die basisopdrag in Git vir al die Subversion-brugopdragte is git svn.
+Dit neem 'n hele paar opdragte, so ons sal die algemeenste wys terwyl ons deur 'n paar eenvoudige werkvloeie gaan.
+
+
+
Dit is belangrik om op te let dat wanneer jy git svn gebruik, jy met Subversion wisselwerking het, wat 'n stelsel is wat baie anders as Git werk.
+Alhoewel jy plaaslike takking en saamsmelting kan doen, is dit oor die algemeen die beste om jou geskiedenis so lineair as moontlik te hou deur jou werk te rebasen, en te vermy om dinge te doen soos om gelyktydig met 'n Git-remote te wisselwerking.
+
+
+
Moenie jou geskiedenis herskryf en probeer om weer te push nie, en moenie na 'n parallelle Git-bewaarplek push om terselfdertyd met mede-Git-ontwikkelaars saam te werk nie.
+Subversion kan slegs 'n enkele lineêre geskiedenis hê, en dit is baie maklik om dit te verwar.
+As jy met 'n span werk, en sommige gebruik SVN en ander gebruik Git, maak seker almal gebruik die SVN-bediener om saam te werk – dit sal jou lewe makliker maak.
+
+
+
+
Opstelling (Setting Up)
+
+
Om hierdie funksionaliteit te demonstreer, benodig jy 'n tipiese SVN-bewaarplek waartoe jy skryftoegang het.
+As jy hierdie voorbeelde wil kopieer, sal jy 'n skryfbare kopie van 'n SVN-toetsbewaarplek moet maak.
+Om dit maklik te doen, kan jy 'n hulpmiddel genaamd svnsync gebruik wat saam met Subversion kom.
+
+
+
Om te volg, moet jy eers 'n nuwe plaaslike Subversion-bewaarplek skep:
+
+
+
+
$ mkdir /tmp/test-svn
+$ svnadmin create /tmp/test-svn
+
+
+
+
Stel dan al gebruikers in staat om revprops te verander – die maklike manier is om 'n pre-revprop-change skrip by te voeg wat altyd 0 uitstaan:
+
+
+
+
$ cat /tmp/test-svn/hooks/pre-revprop-change
+#!/bin/sh
+exit 0;
+$ chmod +x /tmp/test-svn/hooks/pre-revprop-change
+
+
+
+
Jy kan nou hierdie projek na jou plaaslike masjien sinchroniseer deur svnsync init te roep met die na- en van-bewaarplekke.
+
+
+
+
$ svnsync init file:///tmp/test-svn \
+ http://your-svn-server.example.org/svn/
+
+
+
+
Dit stel die eienskappe op om die sinchronisasie te laat loop.
+Jy kan dan die kode kloon deur dit uit te voer:
+
+
+
+
$ svnsync sync file:///tmp/test-svn
+Committed revision 1.
+Copied properties for revision 1.
+Transmitting file data .............................[...]
+Committed revision 2.
+Copied properties for revision 2.
+[…]
+
+
+
+
Alhoewel hierdie operasie säl 'n paar minute kan neem, as jy probeer om die oorspronklike bewaarplek na 'n ander afgeleë bewaarplek te kopieer in plaas van 'n plaaslike een, sal die proses amper 'n uur neem, al is daar minder as 100 vasleggings.
+Subversion moet een hersiening op 'n slag kloon en dit dan terugpush in 'n ander bewaarplek – dit is belaglik ondoeltreffend, maar dit is die enigste maklike manier om dit te doen.
+
+
+
+
Om te Begin (Getting Started)
+
+
Noudat jy 'n Subversion-bewaarplek het waartoe jy skryftoegang het, kan jy deur 'n tipiese werkvloei gaan.
+Jy sal begin met die git svn clone opdrag, wat 'n hele Subversion-bewaarplek in 'n plaaslike Git-bewaarplek inporteer.
+Onthoud dat as jy van 'n egte gehoste Subversion-bewaarplek inporteer, jy die file:///tmp/test-svn hier moet vervang met die URL van jou Subversion-bewaarplek:
+
+
+
+
$ git svn clone file:///tmp/test-svn -T trunk -b branches -t tags
+Initialized empty Git repository in /private/tmp/progit/test-svn/.git/
+r1 = dcbfb5891860124cc2e8cc616cded42624897125 (refs/remotes/origin/trunk)
+ A m4/acx_pthread.m4
+ A m4/stl_hash.m4
+ A java/src/test/java/com/google/protobuf/UnknownFieldSetTest.java
+ A java/src/test/java/com/google/protobuf/WireFormatTest.java
+…
+r75 = 556a3e1e7ad1fde0a32823fc7e4d046bcfd86dae (refs/remotes/origin/trunk)
+Found possible branch point: file:///tmp/test-svn/trunk => file:///tmp/test-svn/branches/my-calc-branch, 75
+Found branch parent: (refs/remotes/origin/my-calc-branch) 556a3e1e7ad1fde0a32823fc7e4d046bcfd86dae
+Following parent with do_switch
+Successfully followed parent
+r76 = 0fb585761df569eaecd8146c71e58d70147460a2 (refs/remotes/origin/my-calc-branch)
+Checked out HEAD:
+ file:///tmp/test-svn/trunk r75
+
+
+
+
Dit voer die ekwivalent van twee opdragte uit – git svn init gevolg deur git svn fetch – op die URL wat jy verskaf.
+Dit kan 'n rukkie neem.
+As die toetsprojek byvoorbeeld net sowat 75 vasleggings het en die kodebasis nie so groot is nie, moet Git nog steeds elke weergawe uittrek, een op 'n slag, en dit individueel vaslê.
+Vir 'n projek met honderde of duisende vasleggings kan dit letterlik ure of selfs dae neem om te voltooi.
+
+
+
Die -T trunk -b branches -t tags gedeelte sê vir Git dat hierdie Subversion-bewaarplek die basiese takking- en merkerkonvensies volg.
+As jy jou trunk, branches of tags anders noem, kan jy hierdie opsies verander.
+Omdat dit so algemeen is, kan jy hierdie hele gedeelte vervang met -s, wat standaarduitleg beteken en al daardie opsies impliseer.
+Die volgende opdrag is ekwivalent:
+
+
+
+
$ git svn clone file:///tmp/test-svn -s
+
+
+
+
Op hierdie punt behoort jy 'n geldige Git-bewaarplek te hê wat jou takke en merkers geïmporteer het:
+
+
+
+
$ git branch -a
+* master
+ remotes/origin/my-calc-branch
+ remotes/origin/tags/2.0.2
+ remotes/origin/tags/release-2.0.1
+ remotes/origin/tags/release-2.0.2
+ remotes/origin/tags/release-2.0.2rc1
+ remotes/origin/trunk
+
+
+
+
Let op hoe hierdie hulpmiddel Subversion-merkers as afgeleë verwysings (remote refs) bestuur.
+
+Kom ons kyk van naderby met die Git-loodgietersopdrag show-ref:
+
+
+
+
$ git show-ref
+556a3e1e7ad1fde0a32823fc7e4d046bcfd86dae refs/heads/master
+0fb585761df569eaecd8146c71e58d70147460a2 refs/remotes/origin/my-calc-branch
+bfd2d79303166789fc73af4046651a4b35c12f0b refs/remotes/origin/tags/2.0.2
+285c2b2e36e467dd4d91c8e3c0c0e1750b3fe8ca refs/remotes/origin/tags/release-2.0.1
+cbda99cb45d9abcb9793db1d4f70ae562a969f1e refs/remotes/origin/tags/release-2.0.2
+a9f074aa89e826d6f9d30808ce5ae3ffe711feda refs/remotes/origin/tags/release-2.0.2rc1
+556a3e1e7ad1fde0a32823fc7e4d046bcfd86dae refs/remotes/origin/trunk
+
+
+
+
Git doen dit nie wanneer dit van 'n Git-bediener kloon nie; hier is hoe 'n bewaarplek met merkers lyk na 'n vars kloon:
+
+
+
+
$ git show-ref
+c3dcbe8488c6240392e8a5d7553bbffcb0f94ef0 refs/remotes/origin/master
+32ef1d1c7cc8c603ab78416262cc421b80a8c2df refs/remotes/origin/branch-1
+75f703a3580a9b81ead89fe1138e6da858c5ba18 refs/remotes/origin/branch-2
+23f8588dde934e8f33c263c6d8359b2ae095f863 refs/tags/v0.1.0
+7064938bd5e7ef47bfd79a685a62c1e2649e2ce7 refs/tags/v0.2.0
+6dcb09b5b57875f334f61aebed695e2e4193db5e refs/tags/v1.0.0
+
+
+
+
Git fetch die merkers direk in refs/tags, eerder as om hulle as afgeleë takke te hanteer.
+
+
+
+
Vaslegging Terug na Subversion (Committing Back to Subversion)
+
+
Noudat jy 'n werkgids het, kan jy 'n bietjie werk aan die projek doen en jou vasleggings terug stroomop push, deur Git effektief as 'n SVN-kliënt te gebruik.
+As jy een van die lêers redigeer en dit vaslê, het jy 'n vaslegging wat plaaslik in Git bestaan wat nie op die Subversion-bediener bestaan nie:
+
+
+
+
$ git commit -am 'Adding git-svn instructions to the README'
+[master 4af61fd] Adding git-svn instructions to the README
+ 1 file changed, 5 insertions(+)
+
+
+
+
Volgende moet jy jou verandering stroomop push.
+Merk op hoe dit die manier verander waarop jy met Subversion werk – jy kan verskeie vasleggings vanlyn doen en dit dan alles gelyktydig na die Subversion-bediener push.
+Om na 'n Subversion-bediener te push, voer jy die git svn dcommit opdrag uit:
+
+
+
+
$ git svn dcommit
+Committing to file:///tmp/test-svn/trunk ...
+ M README.txt
+Committed r77
+ M README.txt
+r77 = 95e0222ba6399739834380eb10afcd73e0670bc5 (refs/remotes/origin/trunk)
+No changes between 4af61fd05045e07598c553167e0f31c84fd6ffe1 and refs/remotes/origin/trunk
+Resetting to the latest refs/remotes/origin/trunk
+
+
+
+
Dit neem al die vasleggings wat jy gemaak het bo-op die Subversion-bedienerkode, doen 'n Subversion-vaslegging vir elkeen, en herskryf dan jou plaaslike Git-vaslegging om 'n unieke identifiseerder in te sluit.
+Dit is belangrik omdat dit beteken dat al die SHA-1 kontrolesomme vir jou vasleggings verander.
+Gedeeltelik om hierdie rede is dit nie 'n goeie idee om gelyktydig met 'n Subversion-bediener aan Git-gebaseerde afgeleë weergawes van jou projekte te werk nie.
+As jy na die laaste vaslegging kyk, kan jy die nuwe git-svn-id sien wat bygevoeg is:
+
+
+
+
$ git log -1
+commit 95e0222ba6399739834380eb10afcd73e0670bc5
+Author: ben <ben@0b684db3-b064-4277-89d1-21af03df0a68>
+Date: Thu Jul 24 03:08:36 2014 +0000
+
+ Adding git-svn instructions to the README
+
+ git-svn-id: file:///tmp/test-svn/trunk@77 0b684db3-b064-4277-89d1-21af03df0a68
+
+
+
+
Let op dat die SHA-1 kontrolesom wat oorspronklik met 4af61fd begin het toe jy vasgelê het, nou met 95e0222 begin.
+As jy na beide 'n Git-bediener en 'n Subversion-bediener wil push, moet jy eers na die Subversion-bediener push (dcommit), omdat daardie aksie jou vasleggingsdata verander.
+
+
+
+
Intrek van Nuwe Veranderings (Pulling in New Changes)
+
+
As jy saam met ander ontwikkelaars werk, sal een van julle op 'n stadium push, en dan sal die ander een probeer om 'n verandering te push wat konstrasteer (konflik).
+Daardie verandering sal geweiger word tensy jy hul werk insmelt.
+In git svn lyk dit soos dit:
+
+
+
+
$ git svn dcommit
+Committing to file:///tmp/test-svn/trunk ...
+
+ERROR from SVN:
+Transaction is out of date: File '/trunk/README.txt' is out of date
+W: d5837c4b461b7c0e018b49d12398769d2bfc240a and refs/remotes/origin/trunk differ, using rebase:
+:100644 100644 f414c433af0fd6734428cf9d2a9fd8ba00ada145 c80b6127dd04f5fcda218730ddf3a2da4eb39138 M README.txt
+Current branch master is up to date.
+ERROR: Not all changes have been committed into SVN, however the committed
+ones (if any) seem to be successfully integrated into the working tree.
+Please see the above messages for details.
+
+
+
+
Om hierdie situasie op te los, kan jy git svn rebase uitvoer, wat enige veranderings op die bediener aftrek wat jy nog nie het nie en enige werk wat jy het rebase bo-op dit wat op die bediener is:
+
+
+
+
$ git svn rebase
+Committing to file:///tmp/test-svn/trunk ...
+
+ERROR from SVN:
+Transaction is out of date: File '/trunk/README.txt' is out of date
+W: eaa029d99f87c5c822c5c29039d19111ff32ef46 and refs/remotes/origin/trunk differ, using rebase:
+:100644 100644 65536c6e30d263495c17d781962cfff12422693a b34372b25ccf4945fe5658fa381b075045e7702a M README.txt
+First, rewinding head to replay your work on top of it...
+Applying: update foo
+Using index info to reconstruct a base tree...
+M README.txt
+Falling back to patching base and 3-way merge...
+Auto-merging README.txt
+ERROR: Not all changes have been committed into SVN, however the committed
+ones (if any) seem to be successfully integrated into the working tree.
+Please see the above messages for details.
+
+
+
+
Nou is al jou werk bo-op dit wat op die Subversion-bediener is, sodat jy suksesvol dcommit kan doen:
+
+
+
+
$ git svn dcommit
+Committing to file:///tmp/test-svn/trunk ...
+ M README.txt
+Committed r85
+ M README.txt
+r85 = 9c29704cc0bbbed7bd58160cfb66cb9191835cd8 (refs/remotes/origin/trunk)
+No changes between 5762f56732a958d6cfda681b661d2a239cc53ef5 and refs/remotes/origin/trunk
+Resetting to the latest refs/remotes/origin/trunk
+
+
+
+
Let daarop dat in teenstelling met Git, wat vereis dat jy stroomopwaartse werk wat jy nog nie plaaslik het nie, moet insmelt voordat jy kan push, dwing git svn jou om dit slegs te doen as die veranderings konflik (baie soos hoe Subversion werk).
+As iemand anders 'n verandering aan een lêer push en jy dan 'n verandering aan 'n ander lêer push, sal jou git svn dcommit goed werk:
+
+
+
+
$ git svn dcommit
+Committing to file:///tmp/test-svn/trunk ...
+ M configure.ac
+Committed r87
+ M autogen.sh
+r86 = d8450bab8a77228a644b7dc0e95977ffc61adff7 (refs/remotes/origin/trunk)
+ M configure.ac
+r87 = f3653ea40cb4e26b6281cec102e35dcba1fe17c4 (refs/remotes/origin/trunk)
+W: a0253d06732169107aa020390d9fefd2b1d92806 and refs/remotes/origin/trunk differ, using rebase:
+:100755 100755 efa5a59965fbbb5b2b0a12890f1b351bb5493c18 e757b59a9439312d80d5d43bb65d4a7d0389ed6d M autogen.sh
+First, rewinding head to replay your work on top of it...
+
+
+
+
Dit is belangrik om te onthou, aangesien die uitkoms 'n projektoestand is wat nie op enige van julle rekenaars bestaan het toe julle gepush het nie.
+As die veranderings onversoenbaar is maar nie konflik maak nie, kan jy kwessies kry wat moeilik is om te gagnostiseer.
+Dit verskil van die gebruik van 'n Git-bediener – in Git kan jy die toestand op jou kliëntstelsel ten volle toets voordat jy dit publiseer, terwyl jy in SVN nooit seker kan wees dat die toestande onmiddellik voor vaslegging en na vaslegging identies is nie.
+
+
+
Jy moet ook hierdie opdrag uitvoer om veranderings van die Subversion-bediener in te trek, selfs al is jy nie gereed om self vas te lê nie.
+Jy kan git svn fetch uitvoer om die nuwe data te gryp, maar git svn rebase doen die fetch en werk dan jou plaaslike vasleggings op.
+
+
+
+
$ git svn rebase
+ M autogen.sh
+r88 = c9c5f83c64bd755368784b444bc7a0216cc1e17b (refs/remotes/origin/trunk)
+First, rewinding head to replay your work on top of it...
+Fast-forwarded master to refs/remotes/origin/trunk.
+
+
+
+
Om git svn rebase kort-kort uit te voer, maak seker dat jou kode altyd op datum is.
+Jy moet egter seker wees dat jou werkgids skoon is wanneer jy dit uitvoer.
+As jy plaaslike veranderings het, moet jy óf jou werk bêre (stash) óf dit tydelik vaslê voordat jy git svn rebase uitvoer – anders sal die opdrag stop as dit sien dat die rebase in 'n saamsmeltingskonflik sal aanhits.
+
+
+
+
Git-Takkingkwessies (Git Branching Issues)
+
+
Wanneer jy gemaklik geraak het met 'n Git-werkvloei, sal jy waarskynlik onderwerptakke (topic branches) skep, werk daaraan doen, en dit dan insmelt.
+As jy na 'n Subversion-bediener push via git svn, wil jy dalk eerder jou werk op 'n enkele tak rebase elke keer in plaas daarvan om takke saam te smelt.
+Die rede om herbasering (rebasing) te verkies, is dat Subversion 'n lineêre geskiedenis het en nie met saamsmeltings omgaan soos Git dit doen nie, so git svn volg slegs die eerste ouer wanneer die momentopnames in Subversion-vasleggings omgeskakel word.
+
+
+
Veronderstel jou geskiedenis lyk soos die volgende: jy het 'n experiment tak geskep, twee vasleggings gedoen, en dit toe terug in master gesmelt.
+Wanneer jy dcommit, sien jy afvoer soos dit:
+
+
+
+
$ git svn dcommit
+Committing to file:///tmp/test-svn/trunk ...
+ M CHANGES.txt
+Committed r89
+ M CHANGES.txt
+r89 = 89d492c884ea7c834353563d5d913c6adf933981 (refs/remotes/origin/trunk)
+ M COPYING.txt
+ M INSTALL.txt
+Committed r90
+ M INSTALL.txt
+ M COPYING.txt
+r90 = cb522197870e61467473391799148f6721bcf9a0 (refs/remotes/origin/trunk)
+No changes between 71af502c214ba13123992338569f4669877f55fd and refs/remotes/origin/trunk
+Resetting to the latest refs/remotes/origin/trunk
+
+
+
+
Die uitvoering van dcommit op 'n tak met gesmelte geskiedenis werk goed, behalwe dat wanneer jy na jou Git-projekgeskiedenis kyk, dit geen van die vasleggings wat jy op die experiment tak gemaak het, herskryf het nie – in plaas daarvan verskyn al daardie veranderings in die SVN-weergawe van die enkele saamsmeltingsvaslegging.
+
+
+
Wanneer iemand anders daardie werk kloon, sien al wat hulle sien die saamsmeltingsvaslegging met al die werk daarin saamgepers (squashed), asof jy git_merge --squash uitgevoer het; hulle sien nie die vasleggingsdata oor waar dit vandaan kom of wanneer dit vasgelê is nie.
+
+
+
+
Subversion-Takking (Subversion Branching)
+
+
Takking in Subversion is nie dieselfde as takking in Git nie; as jy kan vermy om dit veel te gebruik, is dit waarskynlik die beste.
+Jy kan egter takke in Subversion skep en daaraan vaslê met git svn.
+
+
+
+
Skep van 'n Nuwe SVN-tak (Creating a New SVN Branch)
+
+
Om 'n nuwe tak in Subversion te skep, voer jy git svn branch [new-branch] uit:
+
+
+
+
$ git svn branch opera
+Copying file:///tmp/test-svn/trunk at r90 to file:///tmp/test-svn/branches/opera...
+Found possible branch point: file:///tmp/test-svn/trunk => file:///tmp/test-svn/branches/opera, 90
+Found branch parent: (refs/remotes/origin/opera) cb522197870e61467473391799148f6721bcf9a0
+Following parent with do_switch
+Successfully followed parent
+r91 = f1b64a3855d3c8dd84ee0ef10fa89d27f1584302 (refs/remotes/origin/opera)
+
+
+
+
Dit doen die ekwivalent van die svn copy trunk branches/opera opdrag in Subversion en werk op die Subversion-bediener.
+Dit is belangrik om op te let dat dit jou nie uittrek in daardie tak nie; as jy op hierdie punt vaslê, sal daardie vaslegging na trunk op die bediener gaan, nie opera nie.
+
+
+
+
Wisseling van Aktiewe Takke (Switching Active Branches)
+
+
Git vind uit na watter tak jou dcommits gaan deur te soek na die punt van enige van jou Subversion-takke in jou geskiedenis – jy behoort slegs een te hê, en dit behoort die laaste een te wees met 'n git-svn-id in jou huidige takgeskiedenis.
+
+
+
As jy aan meer as een tak gelyktydig wil werk, kan jy plaaslike takke opstel om na spesifieke Subversion-takke te dcommit deur hulle te begin by die geïmporteerde Subversion-vaslegging vir daardie tak.
+As jy 'n opera tak wil hê waarop jy afsonderlik kan werk, kan jy uitvoer:
+
+
+
+
$ git branch opera remotes/origin/opera
+
+
+
+
Nou, as jy jou opera tak in trunk (jou master tak) wil insmelt, kan jy dit doen met 'n normale git merge.
+Maar jy moet 'n beskrywende vasleggingsboodskap verskaf (via -m), anders sal die saamsmelting sê “Merge branch opera” in plaas van iets nuttigs.
+
+
+
Onthoud dat al gebruik jy git merge om hierdie bewerking te doen, en die saamsmelting sal waarskynlik baie makliker wees as wat dit in Subversion sou wees (omdat Git outomaties die gepaste saamsmeltingsbasis vir jou sal detekteer), is dit nie 'n normale Git-saamsmeltingsvaslegging nie.
+Jy moet hierdie data terugpush na 'n Subversion-bediener wat nie 'n vaslegging kan hanteer wat meer as een ouer naspoor nie; dus, nadat jy dit opgestoot het, sal dit lyk soos 'n enkele vaslegging wat al die werk van 'n ander tak onder 'n enkele vaslegging saamgepers het.
+Nadat jy een tak in 'n ander gesmelt het, kan jy nie maklik teruggaan en aan daardie tak voortgaan te werk soos jy normaalweg in Git kan nie.
+Die dcommit opdrag wat jy uitvoer, vee enige inligting uit wat sê watter tak ingesmelt is, so daaropvolgende saamsmeltingsbasis-berekeninge sal verkeerd wees – die dcommit laat jou git merge resultaat lyk asof jy git merge --squash uitgevoer het.
+Ongelukkig is daar geen goeie manier om hierdie situasie te vermy nie – Subversion kan nie hierdie inligting stoor nie, so jy sal altyd gekortwiek word deur sy beperkings terwyl jy dit as jou bediener gebruik.
+Om kwessies te vermy, moet jy die plaaslike tak (in hierdie geval, opera) verwyder nadat jy dit in trunk ingesmelt het.
+
+
+
+
Subversion-opdragte (Subversion Commands)
+
+
Die git svn hulpmiddelset bied 'n aantal opdragte om die oorgang na Git te vergemaklik deur sekere funksionaliteit te verskaf wat soortgelyk is aan wat jy in Subversion gehad het.
+Hier is 'n paar opdragte wat jou gee wat Subversion gewoond was om te verskaf.
+
+
+
SVN-styl Geskiedenis (SVN Style History)
+
+
As jy gewoond is aan Subversion en jou geskiedenis in SVN-afvoerstyl wil sien, kan jy git svn log uitvoer om jou vasleggingsgeskiedenis in SVN-formatering te besigtig:
+
+
+
+
$ git svn log
+------------------------------------------------------------------------
+r87 | schacon | 2014-05-02 16:07:37 -0700 (Sat, 02 May 2014) | 2 lines
+
+autogen change
+
+------------------------------------------------------------------------
+r86 | schacon | 2014-05-02 16:00:21 -0700 (Sat, 02 May 2014) | 2 lines
+
+Merge branch 'experiment'
+
+------------------------------------------------------------------------
+r85 | schacon | 2014-05-02 16:00:09 -0700 (Sat, 02 May 2014) | 2 lines
+
+updated the changelog
+
+
+
+
Jy moet twee belangrike dinge weet oor git svn log.
+Eerstens werk dit vanlyn, in teenstelling met die egte svn log opdrag, wat die Subversion-bediener vir die data vra.
+Tweedens wys dit jou slegs vasleggings wat tot op die Subversion-bediener vasgelê is.
+Plaaslike Git-vasleggings wat jy nie gedcommit het nie, wys nie op nie; ook nie vasleggings wat mense intussen op die Subversion-bediener gemaak het nie.
+Dit lyk meer soos die laaste bekende toestand van die vasleggings op die Subversion-bediener.
+
+
+
+
SVN-annotasie (SVN Annotation)
+
+
Net soos die git svn log opdrag die svn log opdrag vanlyn simuleer, kan jy die ekwivalent van svn annotate kry deur git svn blame [FILE] uit te voer.
+Die afvoer lyk soos dit:
+
+
+
+
$ git svn blame README.txt
+ 2 temporal Protocol Buffers - Google's data interchange format
+ 2 temporal Copyright 2008 Google Inc.
+ 2 temporal http://code.google.com/apis/protocolbuffers/
+ 2 temporal
+22 temporal C++ Installation - Unix
+22 temporal =======================
+ 2 temporal
+79 schacon Committing in git-svn.
+78 schacon
+ 2 temporal To build and install the C++ Protocol Buffer runtime and the Protocol
+ 2 temporal Buffer compiler (protoc) execute the following:
+ 2 temporal
+
+
+
+
Weereens wys dit nie vasleggings wat jy plaaslik in Git gedoen het of wat intussen na Subversion gepush is nie.
+
+
+
+
+
+
Jy kan ook dieselfde tipe inligting kry wat svn info vir jou gee deur git svn info uit te voer:
+
+
+
+
$ git svn info
+Path: .
+URL: https://schacon-test.googlecode.com/svn/trunk
+Repository Root: https://schacon-test.googlecode.com/svn
+Repository UUID: 4c93b258-373f-11de-be05-5f7a86268029
+Revision: 87
+Node Kind: directory
+Schedule: normal
+Last Changed Author: schacon
+Last Changed Rev: 87
+Last Changed Date: 2009-05-02 16:07:37 -0700 (Sat, 02 May 2009)
+
+
+
+
Dit is soos blame en log in dié opsig dat dit vanlyn loop en slegs op datum is sedert die laaste keer dat jy met die Subversion-bediener gekommunikeer het.
+
+
+
+
Negeer Wat Subversion Negeer (Ignoring What Subversion Ignores)
+
+
As jy 'n Subversion-bewaarplek kloon wat svn:ignore eienskappe iewers gestel het, sal jy waarskynlik ooreenstemmende .gitignore lêers wil stel sodat jy nie per ongeluk lêers vaslê wat jy nie moet nie.
+git svn het twee opdragte om met hierdie kwessie te help.
+Die eerste is git svn create-ignore, wat outomaties ooreenstemmende .gitignore lêers vir jou skep sodat jou volgende vaslegging dit kan insluit.
+
+
+
Die tweede opdrag is git svn show-ignore, wat die reëls wat jy in 'n .gitignore lêer moet plaas na stdout druk sodat jy die afvoer in jou projek se uitsluitingslêer (exclude file) kan herlei:
+
+
+
+
$ git svn show-ignore > .git/info/exclude
+
+
+
+
Op daardie manier bemors jy nie die projek met .gitignore lêers nie.
+Dit is 'n goeie opsie as jy die enigste Git-gebruiker op 'n Subversion-span is, en jou spanmaats nie .gitignore lêers in die projek wil hê nie.
+
+
+
+
+
Git-Svn Opsomming (Git-Svn Summary)
+
+
Die git svn hulpmiddels is nuttig as jy vas sit met 'n Subversion-bediener, of andersins in 'n ontwikkelingsomgewing is wat die uitvoering van 'n Subversion-bediener noodsaak.
+Jy moet dit egter as 'n gekortwiekte Git beskou, anders sal jy kwessies in vertaling teëkom wat jou en jou medewerkers kan verwar.
+Om uit die moeilikheid te bly, probeer om hierdie riglyne te volg:
+
+
+
+-
+
Hou 'n lineêre Git-geskiedenis aan wat nie saamsmeltingsvasleggings (merge commits) bevat wat deur git merge gemaak is nie.
+Rebase enige werk wat jy buite jou hooflyn-tak doen, terug daarop; moenie dit insmelt nie.
+
+-
+
Moenie 'n aparte Git-bediener opstel en daaraan saamwerk nie.
+Hê moontlik een om klone vir nuwe ontwikkelaars te versnel, maar moenie enigiets daarna push wat nie 'n git-svn-id inskrywing het nie.
+Jy wil dalk selfs 'n pre-receive haak byvoeg wat elke vasleggingsboodskap kontroleer vir 'n git-svn-id en pushes verwerp wat vasleggings sonder dit bevat.
+
+
+
+
+
As jy daardie riglyne volg, kan die werk met 'n Subversion-bediener meer draaglik wees.
+As dit egter moontlik is om na 'n egte Git-bediener te skuif, kan dit jou span veel meer besorg.
+
+
+
+
Git en Mercurial (Git and Mercurial)
+
+
+
+Die DVCS-heelal is groter as net Git.
+Om die waarheid te sê, daar is baie ander stelsels in hierdie ruimte, elk met hul eie hoek benadering oor hoe om gedistribueerde weergawebeheer korrek te doen.
+Buiten Git is Mercurial die gewildste, en die twee is in baie opsigte baie soortgelyk.
+
+
+
Die goeie nuus, as jy Git se kliëntkant-gedrag verkies maar met 'n projek werk waarvan die bronkode met Mercurial beheer word, is dat daar 'n manier is om Git as 'n kliënt te gebruik vir 'n bewaarplek wat deur Mercurial gehuisves word.
+Aangesien die manier waarop Git met bedienerbewaarplekke praat deur remotes is, behoort dit geen verrassing te wees nie dat hierdie brug as 'n afgeleë helper (remote helper) geïmplementeer word.
+Die projek se naam is git-remote-hg, en dit kan gevind word by https://github.com/felipec/git-remote-hg.
+
+
+
git-remote-hg
+
+
Eerstens moet jy git-remote-hg installeer.
+Dit behels basies om sy lêer iewers in jou pad te plaas, soos dit:
+
+
+
+
$ curl -o ~/bin/git-remote-hg \
+ https://raw.githubusercontent.com/felipec/git-remote-hg/master/git-remote-hg
+$ chmod +x ~/bin/git-remote-hg
+
+
+
+
…aannemende dat ~/bin in jou $PATH is.
+git-remote-hg het een ander afhanklikheid: die mercurial biblioteek vir Python.
+As jy Python geïnstalleer het, is dit so eenvoudig as:
+
+
+
+
$ pip install mercurial
+
+
+
+
+
Die laaste ding wat jy nodig het, is die Mercurial-kliënt.
+Gaan na https://www.mercurial-scm.org/ en installeer dit as jy dit nie reeds gedoen het nie.
+
+
+
Nou is jy gereed om te begin.
+Al wat jy nodig het, is 'n Mercurial-bewaarplek waarna jy kan push.
+Gelukkig kan elke Mercurial-bewaarplek op hierdie manier optree, so ons sal net die "hello world" bewaarplek gebruik wat almal gebruik om Mercurial te leer:
+
+
+
+
$ hg clone http://selenic.com/repo/hello /tmp/hello
+
+
+
+
+
Om te Begin (Getting Started)
+
+
Noudat ons 'n geskikte “bedienerkant”-bewaarplek het, kan ons deur 'n tipiese werkvloei gaan.
+Soos jy sal sien, is hierdie twee stelsels soortgelyk genoeg dat daar nie baie wrywing is nie.
+
+
+
Soos altyd met Git, kloon ons eerste:
+
+
+
+
$ git clone hg::/tmp/hello /tmp/hello-git
+$ cd /tmp/hello-git
+$ git log --oneline --graph --decorate
+* ac7955c (HEAD, origin/master, origin/branches/default, origin/HEAD, refs/hg/origin/branches/default, refs/hg/origin/bookmarks/master, master) Create a makefile
+* 65bb417 Create a standard 'hello, world' program
+
+
+
+
Jy sal opmerk dat die werk met 'n Mercurial-bewaarplek die standaard git clone opdrag gebruik.
+Dit is omdat git-remote-hg op 'n taamlik lae vlak werk, deur gebruik te maak van 'n meganisme wat soortgelyk is aan hoe Git se HTTP/S-protokol geïmplementeer word (remote helpers).
+Aangesien Git en Mercurial beide ontwerp is sodat elke kliënt 'n volledige kopie van die bewaarplekgeskiedenis het, maak hierdie opdrag 'n volledige kloon, insluitend al die projek se geskiedenis, en doen dit redelik vinnig.
+
+
+
Die log opdrag wys twee vasleggings, waarvan die laaste aangewys word deur 'n hele tros verwysings (refs).
+Dit blyk dat sommige van hierdie nie werklik daar is nie.
+Kom ons kyk na wat eintlik in die .git gids is:
+
+
+
+
$ tree .git/refs
+.git/refs
+├── heads
+│ └── master
+├── hg
+│ └── origin
+│ ├── bookmarks
+│ │ └── master
+│ └── branches
+│ └── default
+├── notes
+│ └── hg
+├── remotes
+│ └── origin
+│ └── HEAD
+└── tags
+
+9 directories, 5 files
+
+
+
+
git-remote-hg probeer dinge meer idiomaties Git-agtig maak, maar onder die enjinkap bestuur dit die konseptuele kartering tussen twee effens verskillende stelsels.
+Die refs/hg gids is waar die werklike afgeleë verwysings gestoor word.
+Byvoorbeeld, die refs/hg/origin/branches/default is 'n Git-verwysingslêer wat die SHA-1 bevat wat begin met “ac7955c”, wat die vaslegging is waarna master wys.
+Dus is die refs/hg gids 'n bietjie soos 'n vals refs/remotes/origin, maar dit het die bykomende onderskeid tussen boekmerke (bookmarks) en takke (branches).
+
+
+
Die notes/hg lêer is die beginpunt vir hoe git-remote-hg Git-vasleggingshuts (commit hashes) aan Mercurial-wysigingstel-ID’s (changeset IDs) karteer.
+Kom ons verken 'n bietjie:
+
+
+
+
$ cat notes/hg
+d4c10386...
+
+$ git cat-file -p d4c10386...
+tree 1781c96...
+author remote-hg <> 1408066400 -0800
+committer remote-hg <> 1408066400 -0800
+
+Notes for master
+
+$ git ls-tree 1781c96...
+100644 blob ac9117f... 65bb417...
+100644 blob 485e178... ac7955c...
+
+$ git cat-file -p ac9117f
+0a04b987be5ae354b710cefeba0e2d9de7ad41a9
+
+
+
+
Dus wys refs/notes/hg na 'n boom (tree), wat in die Git-objekdatabasis 'n lys is van ander objekte met name.
+git ls-tree voer die modus, tipe, objekhuts en lêernaam uit vir items binne 'n boom.
+Sodra ons afgrawe na een van die boomitems, vind ons dat binne-in dit 'n blob is genaamd “ac9117f” (die SHA-1 huts van die vaslegging waarna master wys), met inhoud “0a04b98” (wat die ID is van die Mercurial-wysigingstel aan die punt van die default tak).
+
+
+
Die goeie nuus is dat ons meestal nie hoef te bekommer oor al hierdie dinge nie.
+Die tipiese werkvloei sal nie baie verskil van die werk met 'n Git-remote nie.
+
+
+
Daar is een ding waaraan ons aandag moet gee voordat ons voortgaan: ignores.
+Mercurial en Git gebruik 'n baie soortgelyke meganisme hiervoor, maar dit is waarskynlik dat jy nie werklik 'n .gitignore lêer in 'n Mercurial-bewaarplek wil vaslê nie.
+Gelukkig het Git 'n manier om lêers te ignoreer wat plaaslik is vir 'n bewaarplek op die skyf, en die Mercurial-formaat is versoenbaar met Git, so jy hoef dit net oór te kopieer:
+
+
+
+
$ cp .hgignore .git/info/exclude
+
+
+
+
Die .git/info/exclude lêer tree presies soos 'n .gitignore op, maar word nie in vasleggings ingesluit nie.
+
+
+
+
Werkvloei (Workflow)
+
+
Kom ons aanvaar dat ons 'n bietjie werk gedoen het en 'n paar vasleggings op die master tak gemaak het, en jy is gereed om dit na die afgeleë bewaarplek te push.
+Hier is hoe ons bewaarplek op die oomblik lyk:
+
+
+
+
$ git log --oneline --graph --decorate
+* ba04a2a (HEAD, master) Update makefile
+* d25d16f Goodbye
+* ac7955c (origin/master, origin/branches/default, origin/HEAD, refs/hg/origin/branches/default, refs/hg/origin/bookmarks/master) Create a makefile
+* 65bb417 Create a standard 'hello, world' program
+
+
+
+
Ons master tak is twee vasleggings voor op origin/master, maar daardie twee vasleggings bestaan slegs op ons plaaslike masjien.
+Kom ons kyk of iemand anders terselfdertyd belangrike werk gedoen het:
+
+
+
+
$ git fetch
+From hg::/tmp/hello
+ ac7955c..df85e87 master -> origin/master
+ ac7955c..df85e87 branches/default -> origin/branches/default
+$ git log --oneline --graph --decorate --all
+* 7b07969 (refs/notes/hg) Notes for default
+* d4c1038 Notes for master
+* df85e87 (origin/master, origin/branches/default, origin/HEAD, refs/hg/origin/branches/default, refs/hg/origin/bookmarks/master) Add some documentation
+| * ba04a2a (HEAD, master) Update makefile
+| * d25d16f Goodbye
+|/
+* ac7955c Create a makefile
+* 65bb417 Create a standard 'hello, world' program
+
+
+
+
Aangesien ons die --all vlag gebruik het, sien ons die “notes” verwysings wat intern deur git-remote-hg gebruik word, maar ons kan hulle ignoreer.
+Die res is wat ons verwag het; origin/master het met een vaslegging gevorder, en ons geskiedenis het nou uiteengegaan.
+In teenstelling met die ander stelsels waarmee ons in hierdie hoofstuk werk, is Mercurial in staat om saamsmeltings (merges) te hanteer, so ons gaan niks fancy doen nie.
+
+
+
+
$ git merge origin/master
+Auto-merging hello.c
+Merge made by the 'recursive' strategy.
+ hello.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+$ git log --oneline --graph --decorate
+* 0c64627 (HEAD, master) Merge remote-tracking branch 'origin/master'
+|\
+| * df85e87 (origin/master, origin/branches/default, origin/HEAD, refs/hg/origin/branches/default, refs/hg/origin/bookmarks/master) Add some documentation
+* | ba04a2a Update makefile
+* | d25d16f Goodbye
+|/
+* ac7955c Create a makefile
+* 65bb417 Create a standard 'hello, world' program
+
+
+
+
Perfek.
+Ons laat die toetse loop en alles slaag, so ons is gereed om ons werk met die res van die span te deel:
+
+
+
+
$ git push
+To hg::/tmp/hello
+ df85e87..0c64627 master -> master
+
+
+
+
Dis dit!
+As jy 'n kykie neem na die Mercurial-bewaarplek, sal jy sien dat dit gedoen het wat ons sou verwag:
+
+
+
+
$ hg log -G --style compact
+o 5[tip]:4,2 dc8fa4f932b8 2014-08-14 19:33 -0700 ben
+|\ Merge remote-tracking branch 'origin/master'
+| |
+| o 4 64f27bcefc35 2014-08-14 19:27 -0700 ben
+| | Update makefile
+| |
+| o 3:1 4256fc29598f 2014-08-14 19:27 -0700 ben
+| | Goodbye
+| |
+@ | 2 7db0b4848b3c 2014-08-14 19:30 -0700 ben
+|/ Add some documentation
+|
+o 1 82e55d328c8c 2005-08-26 01:21 -0700 mpm
+| Create a makefile
+|
+o 0 0a04b987be5a 2005-08-26 01:20 -0700 mpm
+ Create a standard 'hello, world' program
+
+
+
+
Die wysigingstel genommer 2 is deur Mercurial gemaak, en die wysigingstelle genommer 3 en 4 is deur git-remote-hg gemaak deur vasleggings te push wat met Git gemaak is.
+
+
+
+
Takke en Boekmerke (Branches and Bookmarks)
+
+
Git het slegs een tipe tak: 'n verwysing wat skuif wanneer vasleggings gemaak word.
+In Mercurial word hierdie tipe verwysing 'n “boekmerke” ("bookmark") genoem, en dit tree op baie dieselfde manier op as 'n Git-tak.
+
+
+
Mercurial se konsep van 'n “tak” ("branch") is swaarder.
+Die tak waarop 'n wysigingstel gemaak word, word met die wysigingstel opgeteken, wat beteken dit sal altyd in die bewaarplekgeskiedenis wees.
+Hier is 'n voorbeeld van 'n vaslegging wat op die develop tak gemaak is:
+
+
+
+
$ hg log -l 1
+changeset: 6:8f65e5e02793
+branch: develop
+tag: tip
+user: Ben Straub <ben@straub.cc>
+date: Thu Aug 14 20:06:38 2014 -0700
+summary: More documentation
+
+
+
+
Let op die reël wat begin met “branch”.
+Git kan dit nie regtig repliseer nie (en hoef dit ook nie; beide tipes takke kan as 'n Git-verwysing voorgestel word), maar git-remote-hg moet die verskil verstaan, omdat Mercurial daaroor gee.
+
+
+
Die skep van Mercurial-boekmerke is net so maklik as die skep van Git-takke.
+Aan die Git-kant:
+
+
+
+
$ git checkout -b featureA
+Switched to a new branch 'featureA'
+$ git push origin featureA
+To hg::/tmp/hello
+ * [new branch] featureA -> featureA
+
+
+
+
Dis al wat daar is.
+Aan die Mercurial-kant lyk dit soos dit:
+
+
+
+
$ hg bookmarks
+ featureA 5:bd5ac26f11f9
+$ hg log --style compact -G
+@ 6[tip] 8f65e5e02793 2014-08-14 20:06 -0700 ben
+| More documentation
+|
+o 5[featureA]:4,2 bd5ac26f11f9 2014-08-14 20:02 -0700 ben
+|\ Merge remote-tracking branch 'origin/master'
+| |
+| o 4 0434aaa6b91f 2014-08-14 20:01 -0700 ben
+| | update makefile
+| |
+| o 3:1 318914536c86 2014-08-14 20:00 -0700 ben
+| | goodbye
+| |
+o | 2 f098c7f45c4f 2014-08-14 20:01 -0700 ben
+|/ Add some documentation
+|
+o 1 82e55d328c8c 2005-08-26 01:21 -0700 mpm
+| Create a makefile
+|
+o 0 0a04b987be5a 2005-08-26 01:20 -0700 mpm
+ Create a standard "hello, world" program
+
+
+
+
Let op die nuwe [featureA] merker op hersiening 5.
+Hierdie tree presies soos Git-takke aan die Git-kant op, met een uitsondering: jy kan nie 'n boekmerk van die Git-kant af verwyder nie (dit is 'n beperking van afgeleë helpers).
+
+
+
Jy kan ook aan 'n “swaargewig” Mercurial-tak werk: plaas net 'n tak in die branches naamruimte (namespace):
+
+
+
+
$ git checkout -b branches/permanent
+Switched to a new branch 'branches/permanent'
+$ vi Makefile
+$ git commit -am 'A permanent change'
+$ git push origin branches/permanent
+To hg::/tmp/hello
+ * [new branch] branches/permanent -> branches/permanent
+
+
+
+
Hier is hoe dit aan die Mercurial-kant lyk:
+
+
+
+
$ hg branches
+permanent 7:a4529d07aad4
+develop 6:8f65e5e02793
+default 5:bd5ac26f11f9 (inactive)
+$ hg log -G
+o changeset: 7:a4529d07aad4
+| branch: permanent
+| tag: tip
+| parent: 5:bd5ac26f11f9
+| user: Ben Straub <ben@straub.cc>
+| date: Thu Aug 14 20:21:09 2014 -0700
+| summary: A permanent change
+|
+| @ changeset: 6:8f65e5e02793
+|/ branch: develop
+| user: Ben Straub <ben@straub.cc>
+| date: Thu Aug 14 20:06:38 2014 -0700
+| summary: More documentation
+|
+o changeset: 5:bd5ac26f11f9
+|\ bookmark: featureA
+| | parent: 4:0434aaa6b91f
+| | parent: 2:f098c7f45c4f
+| | user: Ben Straub <ben@straub.cc>
+| | date: Thu Aug 14 20:02:21 2014 -0700
+| | summary: Merge remote-tracking branch 'origin/master'
+[...]
+
+
+
+
Die taknaam “permanent” is opgeteken met die wysigingstel gemerk 7.
+
+
+
Van die Git-kant af is die werk met enige van hierdie takstyle dieselfde: trek net uit (checkout), lê vas (commit), haal af (fetch), smelt saam (merge), trek in (pull), en push soos jy normaalweg sou doen.
+Een ding wat jy moet weet, is dat Mercurial nie die herskrywing van geskiedenis ondersteun nie, slegs die byvoeging daarby.
+Hier is hoe ons Mercurial-bewaarplek lyk na 'n interaktiewe herbasering (rebase) en 'n geforceerde push:
+
+
+
+
$ hg log --style compact -G
+o 10[tip] 99611176cbc9 2014-08-14 20:21 -0700 ben
+| A permanent change
+|
+o 9 f23e12f939c3 2014-08-14 20:01 -0700 ben
+| Add some documentation
+|
+o 8:1 c16971d33922 2014-08-14 20:00 -0700 ben
+| goodbye
+|
+| o 7:5 a4529d07aad4 2014-08-14 20:21 -0700 ben
+| | A permanent change
+| |
+| | @ 6 8f65e5e02793 2014-08-14 20:06 -0700 ben
+| |/ More documentation
+| |
+| o 5[featureA]:4,2 bd5ac26f11f9 2014-08-14 20:02 -0700 ben
+| |\ Merge remote-tracking branch 'origin/master'
+| | |
+| | o 4 0434aaa6b91f 2014-08-14 20:01 -0700 ben
+| | | update makefile
+| | |
++---o 3:1 318914536c86 2014-08-14 20:00 -0700 ben
+| | goodbye
+| |
+| o 2 f098c7f45c4f 2014-08-14 20:01 -0700 ben
+|/ Add some documentation
+|
+o 1 82e55d328c8c 2005-08-26 01:21 -0700 mpm
+| Create a makefile
+|
+o 0 0a04b987be5a 2005-08-26 01:20 -0700 mpm
+ Create a standard "hello, world" program
+
+
+
+
Wysigingstelle 8, 9 en 10 is geskep en behoort aan die permanent tak, maar die ou wysigingstelle is steeds daar.
+Dit kan baie verwarrend wees vir jou spanmaats wat Mercurial gebruik, so probeer om dit te vermy.
+
+
+
+
Mercurial-opsomming (Mercurial Summary)
+
+
Git en Mercurial is soortgelyk genoeg dat die werk oor die grens heen redelik pynloos is.
+As jy vermy om geskiedenis te verander wat jou masjien verlaat het (soos algemeen aanbeveel word), is jy dalk nie eens bewus daarvan dat die ander kant Mercurial is nie.
+
+
+
+
Git en Perforce (Git and Perforce)
+
+
+
+Perforce is 'n baie gewilde weergawebeheerstelsel in korporatiewe omgewings.
+Dit bestaan reeds sedert 1995, wat dit die oudste stelsel maak wat in hierdie hoofstuk gedek word.
+As sodanig is dit ontwerp met die beperkings van sy dag in gedagte; dit neem aan dat jy altyd aan 'n enkele sentrale bediener gekoppel is, en slegs een weergawe word op die plaaslike skyf gehou.
+Om seker te maak, sy kenmerke en beperkings is goed geskik vir verskeie spesifieke probleme, maar daar is baie projekte wat Perforce gebruik waar Git eintlijk beter sou werk.
+
+
+
Daar is twee opsies as jy jou gebruik van Perforce en Git wil meng.
+Die eerste een wat ons sal dek, is die “Git Fusion” brug van die makers van Perforce, wat jou toelaat om subbome van jou Perforce-depot as lees-skryf Git-bewaarplekke bloot te stel.
+Die tweede is git-p4, 'n kliëntkant-brug wat jou toelaat om Git as 'n Perforce-kliënt te gebruik, sonder om enige herkonfigurasie van die Perforce-bediener te vereis.
+
+
+
Git Fusion
+
+
+
Opstelling (Setting Up)
+
+
Vir ons voorbeelde sal ons die maklikste installasiemetode vir Git Fusion gebruik, wat die aflaai van 'n virtuele masjien is wat die Perforce-demoon (daemon) en Git Fusion laat loop.
+Jy kan die virtuele masjien-beeld van https://www.perforce.com/downloads kry, en sodra dit klaar afgelaai is, importeer dit in jou gunsteling virtualisasiesagteware (ons sal VirtualBox gebruik).
+
+
+
Met die eerste aanskakeling van die masjien vra dit jou om die wagwoord vir drie Linux-gebruikers (root, perforce en git) te pasmaak, en 'n instansienaam te verskaf, wat gebruik kan word om hierdie installasie te onderskei van ander op dieselfde netwerk.
+Wanneer dit alles voltooi is, sal jy dit sien:
+
+
+
+
}}" alt="The Git Fusion virtual machine boot screen">
+
+
Figure 184. Die Git Fusion virtuele masjien se opstartskerm
+
+
+
Jy moet kennis neem van die IP-adres wat hier gewys word, ons sal dit later gebruik.
+Volgens sal ons 'n Perforce-gebruiker skep.
+Kies die “Login” opsie onder aan en druk enter (of SSH na die masjien), en meld aan as root.
+Gebruik dan hierdie opdragte om 'n gebruiker te skep:
+
+
+
+
$ p4 -p localhost:1666 -u super user -f john
+$ p4 -p localhost:1666 -u john passwd
+$ exit
+
+
+
+
Die eerste een sal 'n VI-redigeerder oopmaak om die gebruiker te pasmaak, maar jy kan die verstekwaardes aanvaar deur :wq te tik en enter te druk.
+Die tweede een sal jou vra om 'n wagwoord twee keer in te tik.
+Dis al wat ons met 'n dop-aanwysing (shell prompt) hoef te doen, so sluit die sessie af.
+
+
+
Die volgende ding wat jy moet doen om te volg, is om vir Git te sê om nie SSL-sertifikate te verifieer nie.
+Die Git Fusion-beeld kom met 'n sertifikaat, maar dit is vir 'n domein wat nie by jou virtuele masjien se IP-adres sal pas nie, so Git sal die HTTPS-verbinding weier.
+As dit 'n permanente installasie gaan wees, raadpleeg die Perforce Git Fusion-handleiding om 'n ander sertifikaat te installeer; vir ons voorbeelddoeleindes sal dit voldoende wees:
+
+
+
+
$ export GIT_SSL_NO_VERIFY=true
+
+
+
+
Nou kan ons toets dat alles werk.
+
+
+
+
$ git clone https://10.0.1.254/Talkhouse
+Cloning into 'Talkhouse'...
+Username for 'https://10.0.1.254': john
+Password for 'https://john@10.0.1.254':
+remote: Counting objects: 630, done.
+remote: Compressing objects: 100% (581/581), done.
+remote: Total 630 (delta 172), reused 0 (delta 0)
+Receiving objects: 100% (630/630), 1.22 MiB | 0 bytes/s, done.
+Resolving deltas: 100% (172/172), done.
+Checking connectivity... done.
+
+
+
+
Die virtuele masjien-beeld kom toegerus met 'n voorbeeldprojek wat jy kan kloon.
+Hier kloon ons oor HTTPS, met die john gebruiker wat ons hierbo geskep het; Git vra vir aanmeldbewyse vir hierdie verbinding, maar die aanmeldbewyskas (credential cache) sal ons toelaat om hierdie stap vir enige opeenvolgende versoeke te omseil.
+
+
+
+
Fusion-konfigurasie (Fusion Configuration)
+
+
Sodra jy Git Fusion geïnstalleer het, sal jy die konfigurasie wil verfyn.
+Dit is eintlik redelik maklik om te doen met jou gunsteling Perforce-kliënt; kaart (map) eenvoudig die //.git-fusion gids op die Perforce-bediener in jou werkruimte.
+Die lêerstruktuur lyk soos dit:
+
+
+
+
$ tree
+.
+├── objects
+│ ├── repos
+│ │ └── [...]
+│ └── trees
+│ └── [...]
+│
+├── p4gf_config
+├── repos
+│ └── Talkhouse
+│ └── p4gf_config
+└── users
+ └── p4gf_usermap
+
+498 directories, 287 files
+
+
+
+
Die objects gids word intern deur Git Fusion gebruik om Perforce-objekte na Git te kaart en omgekeerd; jy hoef nie met enigiets daarin te mors nie.
+Daar is 'n globale p4gf_config lêer in hierdie gids, sowel as een vir elke bewaarplek – dit is die konfigurasielêers wat bepaal hoe Git Fusion optree.
+Kom ons kyk na die lêer in die wortel:
+
+
+
+
[repo-creation]
+charset = utf8
+
+[git-to-perforce]
+change-owner = author
+enable-git-branch-creation = yes
+enable-swarm-reviews = yes
+enable-git-merge-commits = yes
+enable-git-submodules = yes
+preflight-commit = none
+ignore-author-permissions = no
+read-permission-check = none
+git-merge-avoidance-after-change-num = 12107
+
+[perforce-to-git]
+http-url = none
+ssh-url = none
+
+[@features]
+imports = False
+chunked-push = False
+matrix2 = False
+parallel-push = False
+
+[authentication]
+email-case-sensitivity = no
+
+
+
+
Ons sal nie ingaan op die betekenisse van hierdie vlagges hier nie, maar let op dat dit net 'n INI-geformatteerde tekslêer is, baie soos Git vir konfigurasie gebruik.
+Hierdie lêer spesifiseer die globale opsies, wat dan oorskryf kan word deur bewaarplek-spesifieke konfigurasielêers, soos repos/Talkhouse/p4gf_config.
+As jy hierdie lêer oopmaak, sal jy 'n [@repo] afdeling sien met sommige instellings wat verskil van die globale verstekwaardes.
+Jy sal ook afdelings sien wat so lyk:
+
+
+
+
[Talkhouse-master]
+git-branch-name = master
+view = //depot/Talkhouse/main-dev/... ...
+
+
+
+
Hierdie is 'n kartering tussen 'n Perforce-tak en 'n Git-tak.
+Die afdeling kan genoem word wat jy wil, solank die naam uniek is.
+git-branch-name laat jou toe om 'n depotpad wat omslagtig onder Git sou wees, na 'n vriendeliker naam om te skakel.
+Die view instelling beheer hoe Perforce-lêers in die Git-bewaarplek gekarteer word, met behulp van die standaard uitsig-karteringsyntaksis (view mapping syntax).
+Meer as een kartering kan gespesifiseer word, soos in hierdie voorbeeld:
+
+
+
+
[multi-project-mapping]
+git-branch-name = master
+view = //depot/project1/main/... project1/...
+ //depot/project2/mainline/... project2/...
+
+
+
+
Op hierdie manier, as jou normale werkruimte-kartering veranderings in die struktuur van die gidse insluit, kan jy dit met 'n Git-bewaarplek repliseer.
+
+
+
Die laaste lêer wat ons sal bespreek is users/p4gf_usermap, wat Perforce-gebruikers na Git-gebruikers karteer, en wat jy dalk nie eens nodig het nie.
+Wanneer van 'n Perforce-wysigingstel na 'n Git-vaslegging omgeskakel word, is Git Fusion se verstekgedrag om die Perforce-gebruiker op te soek, en die e-posadres en volle naam wat daar gestoor is vir die outeur/vaslêer (author/committer) veld in Git te gebruik.
+Wanneer die ander kant toe omgeskakel word, is die verstek om die Perforce-gebruiker op te soek met die e-posadres wat in die Git-vaslegging se outeurveld gestoor is, en die wysigingstel as daardie gebruiker in te dien (met permissies wat van toepassing is).
+In die meeste gevalle sal hierdie gedrag goed genoeg vaar, maar oorweeg die volgende karteringslêer:
+
+
+
+
john john@example.com "John Doe"
+john johnny@appleseed.net "John Doe"
+bob employeeX@example.com "Anon X. Mouse"
+joe employeeY@example.com "Anon Y. Mouse"
+
+
+
+
Elke reël is van die formaat <user> <email> "<full name>", en skep 'n enkele gebruikerskartering.
+Die eerste twee reëls karteer twee duidelike e-posadresse na dieselfde Perforce-gebruikersrekening.
+Dit is nuttig as jy Git-vasleggings onder verskillende e-posadresse geskep het (of e-posadresse verander het), maar wil hê hulle moet na dieselfde Perforce-gebruiker gekarteer word.
+Wanneer 'n Git-vaslegging van 'n Perforce-wysigingstel geskep word, word die eerste reël wat by die Perforce-gebruiker pas, vir Git-outeurskapinligting gebruik.
+
+
+
Die laaste twee reëls maskeer Bob en Joe se werklike name en e-posadresse van die Git-vasleggings wat geskep word.
+Dit is oulik as jy 'n interne projek oopbron wil maak, maar nie jou personeelgids aan die hele wêreld wil publiseer nie.
+Let daarop dat die e-posadresse en volle name uniek moet wees, tensy jy wil hê dat alle Git-vasleggings aan 'n enkele fiktiewe outeur toegeskryf moet word.
+
+
+
+
Werkvloei (Workflow)
+
+
Perforce Git Fusion is 'n tweerigtingbrug tussen Perforce en Git-weergawebeheer.
+Kom ons kyk hoe dit voel om vanaf die Git-kant te werk.
+Ons sal aanvaar dat ons die “Jam” projek ingekaart het met 'n konfigurasielêer soos hierbo getoon, wat ons so kan kloon:
+
+
+
+
$ git clone https://10.0.1.254/Jam
+Cloning into 'Jam'...
+Username for 'https://10.0.1.254': john
+Password for 'https://john@10.0.1.254':
+remote: Counting objects: 2070, done.
+remote: Compressing objects: 100% (1704/1704), done.
+Receiving objects: 100% (2070/2070), 1.21 MiB | 0 bytes/s, done.
+remote: Total 2070 (delta 1242), reused 0 (delta 0)
+Resolving deltas: 100% (1242/1242), done.
+Checking connectivity... done.
+$ git branch -a
+* master
+ remotes/origin/HEAD -> origin/master
+ remotes/origin/master
+ remotes/origin/rel2.1
+$ git log --oneline --decorate --graph --all
+* 0a38c33 (origin/rel2.1) Create Jam 2.1 release branch.
+| * d254865 (HEAD, origin/master, origin/HEAD, master) Upgrade to latest metrowerks on Beos -- the Intel one.
+| * bd2f54a Put in fix for jam's NT handle leak.
+| * c0f29e7 Fix URL in a jam doc
+| * cc644ac Radstone's lynx port.
+[...]
+
+
+
+
Die eerste keer dat jy dit doen, kan dit 'n tydjie neem.
+Wat gebeur, is dat Git Fusion alle toepaslike wysigingstelle in die Perforce-geskiedenis na Git-vasleggings omskakel.
+Dit gebeur plaaslik op die bediener, so dit is relatief vinnig, maar as jy baie geskiedenis het, kan dit steeds 'n tydjie neem.
+Opeenvolgende fetch-operasies doen inkrementele omskakeling, so dit sal meer soos Git se eie spoed voel.
+
+
+
Soos jy kan sien, lyk ons bewaarplek presies soos enige ander Git-bewaarplek waarmee jy dalk mag werk.
+Daar is drie takke, en Git het behulpsaam 'n plaaslike master tak geskep wat origin/master naspoor.
+Kom ons doen 'n bietjie werk en skep 'n paar nuwe vasleggings:
+
+
+
+
# ...
+$ git log --oneline --decorate --graph --all
+* cfd46ab (HEAD, master) Add documentation for new feature
+* a730d77 Whitespace
+* d254865 (origin/master, origin/HEAD) Upgrade to latest metrowerks on Beos -- the Intel one.
+* bd2f54a Put in fix for jam's NT handle leak.
+[...]
+
+
+
+
Ons het twee nuwe vasleggings.
+Kom ons kyk nou of iemand anders gewerk het:
+
+
+
+
$ git fetch
+remote: Counting objects: 5, done.
+remote: Compressing objects: 100% (3/3), done.
+remote: Total 3 (delta 2), reused 0 (delta 0)
+Unpacking objects: 100% (3/3), done.
+From https://10.0.1.254/Jam
+ d254865..6afeb15 master -> origin/master
+$ git log --oneline --decorate --graph --all
+* 6afeb15 (origin/master, origin/HEAD) Update copyright
+| * cfd46ab (HEAD, master) Add documentation for new feature
+| * a730d77 Whitespace
+|/
+* d254865 Upgrade to latest metrowerks on Beos -- the Intel one.
+* bd2f54a Put in fix for jam's NT handle leak.
+[...]
+
+
+
+
Dit lyk of iemand was!
+Jy sou dit nie uit hierdie aansig geweet het nie, maar die 6afeb15 vaslegging is eintlik geskep deur 'n Perforce-kliënt te gebruik.
+Dit lyk net soos 'n ander vaslegging vanuit Git se oogpunt, wat presies die punt is.
+Kom ons kyk hoe die Perforce-bediener 'n saamsmeltingsvaslegging hanteer:
+
+
+
+
$ git merge origin/master
+Auto-merging README
+Merge made by the 'recursive' strategy.
+ README | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+$ git push
+Counting objects: 9, done.
+Delta compression using up to 8 threads.
+Compressing objects: 100% (9/9), done.
+Writing objects: 100% (9/9), 917 bytes | 0 bytes/s, done.
+Total 9 (delta 6), reused 0 (delta 0)
+remote: Perforce: 100% (3/3) Loading commit tree into memory...
+remote: Perforce: 100% (5/5) Finding child commits...
+remote: Perforce: Running git fast-export...
+remote: Perforce: 100% (3/3) Checking commits...
+remote: Processing will continue even if connection is closed.
+remote: Perforce: 100% (3/3) Copying changelists...
+remote: Perforce: Submitting new Git commit objects to Perforce: 4
+To https://10.0.1.254/Jam
+ 6afeb15..89cba2b master -> master
+
+
+
+
Git dink dit het gewerk.
+Kom ons kyk na die geskiedenis van die README lêer vanuit Perforce se oogpunt, met behulp van die hersieningsgraafkenmerk (revision graph feature) van p4v:
+
+
+
+
}}" alt="Perforce revision graph resulting from Git push">
+
+
Figure 185. Perforce-revisiegraaf as gevolg van Git-push
+
+
+
As jy nog nooit hierdie aansig voorheen gesien het nie, mag dit verwarrend lyk, maar dit wys dieselfde konsepte as 'n grafiese kyker vir Git-geskiedenis.
+Ons kyk na die geskiedenis van die README lêer, sodat die gidsboom links bo slegs daardie lêer wys soos dit opduik in verskeie takke.
+Regs bo het ons 'n visuele graaf van hoe verskillende hersienings van die lêer verwant is, and die groot-prentjie-aansig van hierdie graaf is regs onder.
+Die res van die aansig word gegee aan die besonderhedenaansig vir die geselekteerde hersiening (2 in hierdie geval).
+
+
+
Een ding om op te let is dat die graaf presies lyk soos die een in Git se geskiedenis.
+Perforce het nie 'n benoemde tak gehad om die 1 en 2 vasleggings te stoor nie, so dit het 'n “anonieme” tak in die .git-fusion gids gemaak om dit te hou.
+Dit sal ook gebeur vir benoemde Git-takke wat nie ooreenstem met 'n benoemde Perforce-tak nie (en jy kan hulle later na 'n Perforce-tak kaart deur die konfigurasielêer te gebruik).
+
+
+
Die meeste hiervan gebeur agter die skerms, maar die eindresultaat is dat een persoon in 'n span Git kan gebruik, 'n ander kan Perforce gebruik, en nie een van hulle sal van die ander se keuse weet nie.
+
+
+
+
Git-Fusion Opsomming (Git-Fusion Summary)
+
+
As jy toegang het (of kan kry) tot jou Perforce-bediener, is Git Fusion 'n wonderlike manier om Git en Perforce met mekaar te laat praat.
+Daar is 'n bietjie konfigurasie betrokke, maar die leerkurwe is nie baie steil nie.
+Hier is een van die min afdelings in hierdie hoofstuk waar waarskuwingstekens oor die gebruik van Git se volle krag nie sal verskyn nie.
+Dit is nie om te sê dat Perforce gelukkig sal wees met alles wat jy daarna toe gooi nie – as jy probeer om geskiedenis te herskryf wat reeds gepush is, sal Git Fusion dit weier – maar Git Fusion probeer baie hard om eie (native) te voel.
+Jy kan selfs Git-submodules gebruik (al sal dit vreemd lyk vir Perforce-gebruikers), en takke saamsmelt (dit sal aan die Perforce-kant as 'n integrasie opgeteken word).
+
+
+
As jy nie die administrateur van jou bediener kan oortuig om Git Fusion op te stel nie, is daar steeds 'n manier om hierdie gereedskap saam te gebruik.
+
+
+
+
+
Git-p4
+
+
+git-p4 is 'n tweerigtingbrug tussen Git en Perforce.
+Dit loop geheel en al binne jou Git-bewaarplek, so jy sal geen vorm van toegang tot die Perforce-bediener benodig nie (behalwe gebruikersbewyse, natuurlik).
+git-p4 is nie so 'n buigsame of volledige oplossing as Git Fusion nie, maar dit laat jou wel toe om die meeste te doen van wat jy wil doen sonder om indringend vir die bedieneromgewing te wees.
+
+
+
+
Opstelling (Setting Up)
+
+
Vir voorbeelddoeleindes sal ons die Perforce-bediener vanaf die Git Fusion OVA laat loop soos hierbo getoon, maar ons sal die Git Fusion-bediener omseil en direk na die Perforce-weergawebeheer gaan.
+
+
+
Ten einde die p4 opdragreëlkliënt te gebruik (waarop git-p4 afhanklik is), sal jy 'n paar omgewingsveranderlikes moet stel:
+
+
+
+
$ export P4PORT=10.0.1.254:1666
+$ export P4USER=john
+
+
+
+
+
Om te Begin (Getting Started)
+
+
Soos met enigiets in Git, is die eerste opdrag om te kloon:
+
+
+
+
$ git p4 clone //depot/www/live www-shallow
+Importing from //depot/www/live into www-shallow
+Initialized empty Git repository in /private/tmp/www-shallow/.git/
+Doing initial import of //depot/www/live/ from revision #head into refs/remotes/p4/master
+
+
+
+
Dit skep wat in Git-terme 'n “vlakkige” (shallow) kloon is; slegs die allernuutste Perforce-hersiening word in Git geïmporteer; onthoud, Perforce is nie ontwerp om elke hersiening aan elke gebruiker te gee nie.
+Dit is genoeg om Git as 'n Perforce-kliënt te gebruik, maar vir ander doeleindes is dit nie genoeg nie.
+
+
+
Sodra dit klaar is, het ons 'n ten volle funksionele Git-bewaarplek:
+
+
+
+
$ cd myproject
+$ git log --oneline --all --graph --decorate
+* 70eaf78 (HEAD, p4/master, p4/HEAD, master) Initial import of //depot/www/live/ from the state at revision #head
+
+
+
+
Let op hoe daar 'n “p4” remote vir die Perforce-bediener is, maar alles anders lyk soos 'n standaard kloon.
+Om die waarheid te sê, dit is 'n bietjie misleidend; daar is eintlik nie 'n remote daar nie.
+
+
+
+
Geen remotes bestaan heeltemal in hierdie bewaarplek nie.
+git-p4 het 'n paar verwysings (refs) geskep om die toestand van die bediener te verteenwoordig, en hulle lyk soos afgeleë verwysings vir git log, maar hulle word nie deur Git self bestuur nie, en jy kan nie daarna push nie.
+
+
+
+
Werkvloei (Workflow)
+
+
Goed, kom ons doen 'n bietjie werk.
+Kom ons aanvaar jy het 'n bietjie vordering gemaak met 'n baie belangrike kenmerk, en jy is gereed om dit aan die res van jou span te wys.
+
+
+
+
$ git log --oneline --all --graph --decorate
+* 018467c (HEAD, master) Change page title
+* c0fb617 Update link
+* 70eaf78 (p4/master, p4/HEAD) Initial import of //depot/www/live/ from the state at revision #head
+
+
+
+
Ons het twee nuwe vasleggings gemaak wat ons gereed is om na die Perforce-bediener in te dien.
+Kom ons kyk of iemand anders vandag gewerk het:
+
+
+
+
$ git p4 sync
+git p4 sync
+Performing incremental import into refs/remotes/p4/master git branch
+Depot paths: //depot/www/live/
+Import destination: refs/remotes/p4/master
+Importing revision 12142 (100%)
+$ git log --oneline --all --graph --decorate
+* 75cd059 (p4/master, p4/HEAD) Update copyright
+| * 018467c (HEAD, master) Change page title
+| * c0fb617 Update link
+|/
+* 70eaf78 Initial import of //depot/www/live/ from the state at revision #head
+
+
+
+
Dit lyk of hulle het, en master en p4/master het uiteengegaan.
+Perforce se takstelsel lyk geensins soos Git s’n nie, so die indiening van saamsmeltingsvasleggings maak geen sin nie.
+git-p4 beveel aan dat jy jou vasleggings rebase, en kom selfs met 'n kortpad om dit te doen:
+
+
+
+
$ git p4 rebase
+Performing incremental import into refs/remotes/p4/master git branch
+Depot paths: //depot/www/live/
+No changes to import!
+Rebasing the current branch onto remotes/p4/master
+First, rewinding head to replay your work on top of it...
+Applying: Update link
+Applying: Change page title
+ index.html | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+
+
+
Jy kan waarskynlik uit die afvoer vertel, maar git p4 rebase is 'n kortpad vir git p4 sync gevolg deur git rebase p4/master.
+Dit is 'n bietjie slimner as dit, veral wanneer daar met veelvuldige takke gewerk word, maar dit is 'n goeie benadering.
+
+
+
Nou is ons geskiedenis weer lineair, en ons is gereed om ons veranderings terug te beman na Perforce.
+Die git p4 submit opdrag sal probeer om 'n nuwe Perforce-hersiening te skep vir elke Git-vaslegging tussen p4/master en master.
+Om dit uit te voer, gooi dit ons in ons gunsteling redigeerder, en die inhoud van die lêer lyk soos iets soos dit:
+
+
+
+
# A Perforce Change Specification.
+#
+# Change: The change number. 'new' on a new changelist.
+# Date: The date this specification was last modified.
+# Client: The client on which the changelist was created. Read-only.
+# User: The user who created the changelist.
+# Status: Either 'pending' or 'submitted'. Read-only.
+# Type: Either 'public' or 'restricted'. Default is 'public'.
+# Description: Comments about the changelist. Required.
+# Jobs: What opened jobs are to be closed by this changelist.
+# You may delete jobs from this list. (New changelists only.)
+# Files: What opened files from the default changelist are to be added
+# to this changelist. You may delete files from this list.
+# (New changelists only.)
+
+Change: new
+
+Client: john_bens-mbp_8487
+
+User: john
+
+Status: new
+
+Description:
+ Update link
+
+Files:
+ //depot/www/live/index.html # edit
+
+
+######## git author ben@straub.cc does not match your p4 account.
+######## Use option --preserve-user to modify authorship.
+######## Variable git-p4.skipUserNameCheck hides this message.
+######## everything below this line is just the diff #######
+--- //depot/www/live/index.html 2014-08-31 18:26:05.000000000 0000
++++ /Users/ben/john_bens-mbp_8487/john_bens-mbp_8487/depot/www/live/index.html 2014-08-31 18:26:05.000000000 0000
+@@ -60,7 +60,7 @@
+ </td>
+ <td valign=top>
+ Source and documentation for
+-<a href="http://www.perforce.com/jam/jam.html">
++<a href="jam.html">
+ Jam/MR</a>,
+ a software build tool.
+ </td>
+
+
+
+
Dit is meestal dieselfde inhoud as wat jy sou sien deur p4 submit uit te voer, behalwe vir die goed aan die einde wat git-p4 behulpsaam ingesluit het.
+git-p4 probeer jou Git- en Perforce-instellings individueel eerbiedig wanneer dit 'n naam vir 'n vaslegging of wysigingstel moet verskaf, maar in somige gevalle wil jy dit oorskryf.
+Byvoorbeeld, as die Git-vaslegging wat jy invoer geskryf is deur 'n bydraer wat nie 'n Perforce-gebruikersrekening het nie, wil jy dalk steeds hê dat die resulterende wysigingstel moet lyk of hulle dit geskryf het (en nie jy nie).
+
+
+
git-p4 het die boodskap vanaf die Git-vaslegging behulpsaam ingevoer as die inhoud vir hierdie Perforce-wysigingstel, so al wat ons hoef te doen is om te stoor en toe te maak, twee keer (een keer vir elke vaslegging).
+Die resulterende dop-afvoer sal so iets lyk:
+
+
+
+
$ git p4 submit
+Perforce checkout for depot path //depot/www/live/ located at /Users/ben/john_bens-mbp_8487/john_bens-mbp_8487/depot/www/live/
+Synchronizing p4 checkout...
+... - file(s) up-to-date.
+Applying dbac45b Update link
+//depot/www/live/index.html#4 - opened for edit
+Change 12143 created with 1 open file(s).
+Submitting change 12143.
+Locking 1 files ...
+edit //depot/www/live/index.html#5
+Change 12143 submitted.
+Applying 905ec6a Change page title
+//depot/www/live/index.html#5 - opened for edit
+Change 12144 created with 1 open file(s).
+Submitting change 12144.
+Locking 1 files ...
+edit //depot/www/live/index.html#6
+Change 12144 submitted.
+All commits applied!
+Performing incremental import into refs/remotes/p4/master git branch
+Depot paths: //depot/www/live/
+Import destination: refs/remotes/p4/master
+Importing revision 12144 (100%)
+Rebasing the current branch onto remotes/p4/master
+First, rewinding head to replay your work on top of it...
+$ git log --oneline --all --graph --decorate
+* 775a46f (HEAD, p4/master, p4/HEAD, master) Change page title
+* 05f1ade Update link
+* 75cd059 Update copyright
+* 70eaf78 Initial import of //depot/www/live/ from the state at revision #head
+
+
+
+
Die resultaat is as ware as ons net 'n git push gedoen het, wat die nouste analogie is vir wat eintlik gebeur het.
+
+
+
Let daarop dat tydens hierdie proses elke Git-vaslegging in 'n Perforce-wysigingstel omskep word; as jy hulle wil saampers tot 'n enkele wysigingstel, kan jy dit met 'n interaktiewe rebase doen voor die uitvoering van git p4 submit.
+Let ook op dat die SHA-1 huts van al die vasleggings wat as wysigingstelle ingedien is, verander het; dit is omdat git-p4 'n reël byvoeg aan die einde van elke vaslegging wat dit omskep:
+
+
+
+
$ git log -1
+commit 775a46f630d8b46535fc9983cf3ebe6b9aa53145
+Author: John Doe <john@example.com>
+Date: Sun Aug 31 10:31:44 2014 -0800
+
+ Change page title
+
+ [git-p4: depot-paths = "//depot/www/live/": change = 12144]
+
+
+
+
Wat gebeur as jy probeer om 'n saamsmeltingsvaslegging (merge commit) in te dien?
+Kom ons gee dit 'n kans.
+Hier is die situasie waarin ons ourselves bevind het:
+
+
+
+
$ git log --oneline --all --graph --decorate
+* 3be6fd8 (HEAD, master) Correct email address
+* 1dcbf21 Merge remote-tracking branch 'p4/master'
+|\
+| * c4689fc (p4/master, p4/HEAD) Grammar fix
+* | cbacd0a Table borders: yes please
+* | b4959b6 Trademark
+|/
+* 775a46f Change page title
+* 05f1ade Update link
+* 75cd059 Update copyright
+* 70eaf78 Initial import of //depot/www/live/ from the state at revision #head
+
+
+
+
Die Git- en Perforce-geskiedenis loop uiteen na 775a46f.
+Die Git-kant het twee vasleggings, dan 'n saamsmeltingsvaslegging met die Perforce-kop (head), dan nog 'n vaslegging.
+Ons gaan probeer om hierdie in te dien bo-op 'n enkele wysigingstel aan die Perforce-kant.
+Kom ons kyk wat sou gebeur as ons nou probeer indien:
+
+
+
+
$ git p4 submit -n
+Perforce checkout for depot path //depot/www/live/ located at /Users/ben/john_bens-mbp_8487/john_bens-mbp_8487/depot/www/live/
+Would synchronize p4 checkout in /Users/ben/john_bens-mbp_8487/john_bens-mbp_8487/depot/www/live/
+Would apply
+ b4959b6 Trademark
+ cbacd0a Table borders: yes please
+ 3be6fd8 Correct email address
+
+
+
+
Die -n vlag is kort vir --dry-run, wat probeer rapporteer wat sou gebeur as die submit-opdrag vir eggo’s uitgevoer sou word.
+In hierdie geval lyk dit of ons drie Perforce-wysigingstelle sou skep, wat ooreenstem met die drie nie-saamsmeltingsvasleggings wat nog nie op die Perforce-bediener bestaan nie.
+Dit klink presies na wat ons wil hê, kom ons kyk hoe dit uitdraai:
+
+
+
+
$ git p4 submit
+[…]
+$ git log --oneline --all --graph --decorate
+* dadbd89 (HEAD, p4/master, p4/HEAD, master) Correct email address
+* 1b79a80 Table borders: yes please
+* 0097235 Trademark
+* c4689fc Grammar fix
+* 775a46f Change page title
+* 05f1ade Update link
+* 75cd059 Update copyright
+* 70eaf78 Initial import of //depot/www/live/ from the state at revision #head
+
+
+
+
Ons geskiedenis het lineair geword, presies asof ons gerebase het voor indiening (wat in werklikheid presies is wat gebeur het).
+Dit beteken dat jy vry kan wees om takke aan die Git-kant te skep, daaraan te werk, weg te gooi en saamsmelt sonder vrees dat jou geskiedenis op een of ander manier onversoenbaar met Perforce sal word.
+As jy dit kan rebase, kan jy dit by 'n Perforce-bediener bydra.
+
+
+
+
Takking (Branching)
+
+
As jou Perforce-projek veelvuldige takke het, is jy nie sonder geluk nie; git-p4 kan dit hanteer op 'n manier wat dit laat voel soos Git.
+Sê nou jou Perforce-depot is so ingedeel:
+
+
+
+
//depot
+ └── project
+ ├── main
+ └── dev
+
+
+
+
En sê nou jy het 'n dev tak, wat 'n uitsigspesifikasie (view spec) het wat so lyk:
+
+
+
+
//depot/project/main/... //depot/project/dev/...
+
+
+
+
git-p4 kan daardie situasie outomaties detekteer en die regte ding doen:
+
+
+
+
$ git p4 clone --detect-branches //depot/project@all
+Importing from //depot/project@all into project
+Initialized empty Git repository in /private/tmp/project/.git/
+Importing revision 20 (50%)
+ Importing new branch project/dev
+
+ Resuming with change 20
+Importing revision 22 (100%)
+Updated branches: main dev
+$ cd project; git log --oneline --all --graph --decorate
+* eae77ae (HEAD, p4/master, p4/HEAD, master) main
+| * 10d55fb (p4/project/dev) dev
+| * a43cfae Populate //depot/project/main/... //depot/project/dev/....
+|/
+* 2b83451 Project init
+
+
+
+
Let op die “@all” spesifiseerder in die depotpad; dit sê vir git-p4 om nie net die nuutste wysigingstel vir daardie subboom te kloon nie, maar alle wysigingstelle wat ooit daardie paaie aangeraak het.
+Dit is nader aan Git se konsep van 'n kloon, maar as jy aan 'n projek met 'n lang geskiedenis werk, kan dit 'n rukkie neem.
+
+
+
Die --detect-branches vlag sê vir git-p4 om Perforce se takspesifikasies te gebruik om die takke na Git-verwysings te kaart.
+As hierdie karterings nie op die Perforce-bediener teenwoordig is nie (wat 'n volkome geldige manier is om Perforce te gebruik), kan jy vir git-p4 sê wat die takkarterings is, en jy kry dieselfde resultaat:
+
+
+
+
$ git init project
+Initialized empty Git repository in /tmp/project/.git/
+$ cd project
+$ git config git-p4.branchList main:dev
+$ git clone --detect-branches //depot/project@all .
+
+
+
+
Deur die git-p4.branchList konfigurasieveranderlike op main:dev te stel, sê dit vir git-p4 dat “main” en “dev” beide takke is, en die tweede een is 'n kind van die eerste een.
+
+
+
As ons nou git checkout -b dev p4/project/dev uitvoer en 'n paar vasleggings maak, is git-p4 slim genoeg om die regte tak te teiken wanneer ons git p4 submit doen.
+Ongelukkig kan git-p4 nie vlakkige klone (shallow clones) en veelvuldige takke meng nie; as jy 'n enorme projek het en aan meer as een tak wil werk, sal jy git p4 clone een keer moet uitvoer vir elke tak waarna jy wil indien.
+
+
+
Vir die skep of integrering van takke sal jy 'n Perforce-kliënt moet gebruik.
+git-p4 kan slegs met bestaande takke sinchroniseer en daarheen indien, en dit kan dit slegs een lineare wysigingstel op 'n slag doen.
+As jy twee takke in Git saamsmelt en probeer om die nuwe wysigingstel in te dien, is al wat opgeteken sal word 'n trop léeerveranderings; die metadata oor watter takke betrokke is by die integrasie sal verlore gaan.
+
+
+
+
+
Git en Perforce Opsomming (Git and Perforce Summary)
+
+
git-p4 maak dit moontlik om 'n Git-werkvloei met 'n Perforce-bediener te gebruik, en dit is nogal goed daarin.
+Dit is egter belangrik om te onthou dat Perforce in beheer van die bron is, en jy gebruik slegs Git om plaaslik te werk.
+Wees net baie versigtig oor die deel van Git-vasleggings; as jy 'n remote het wat ander mense gebruik, moenie enige vasleggings push wat nie reeds by die Perforce-bediener ingedien is nie.
+
+
+
As jy vryelik die gebruik van Perforce en Git as kliënte vir bronbeheer wil meng, en jy kan die bedieneradministrateur oortuig om dit te installeer, maak Git Fusion die gebruik van Git 'n eersteklas weergawebeheerkliënt vir 'n Perforce-bediener.
+
+
+
Migrating to Git
+
+
+If you have an existing codebase in another VCS but you’ve decided to start using Git, you must migrate your project one way or another.
+This section goes over some importers for common systems, and then demonstrates how to develop your own custom importer.
+You’ll learn how to import data from several of the bigger professionally used SCM systems, because they make up the majority of users who are switching, and because high-quality tools for them are easy to come by.
+
+
Subversion
+
+
+As jy die vorige afdeling gelees het oor die gebruik van git svn, kan jy daardie instruksies maklik gebruik om git svn clone van 'n bewaarplek te doen; stop dan om die Subversion-bediener te gebruik, push na 'n nuwe Git-bediener, en begin dit gebruik.
+As jy die geskiedenis wil hê, kan jy dit bereik so vinnig as wat jy die data uit die Subversion-bediener kan uittrek (wat 'n rukkie kan neem).
+
+
+
Die invoer is egter nie perfek nie; en omdat dit so lank sal neem, kan jy dit net as goed reg doen.
+Die eerste probleem is die outeurinligting.
+In Subversion het elke persoon wat 'n vaslegging doen, 'n gebruiker op die stelsel wat in die vasleggingsinligting opgeteken word.
+Die voorbeelde in die vorige afdeling wys schacon op sommige plekke, soos die blame-afvoer en die git svn log.
+As jy dit na betere Git-outeurdata wil kaart, benodig jy 'n kartering van die Subversion-gebruikers na die Git-outeurs.
+Skep 'n lêer genaamd users.txt wat hierdie kartering in 'n formaat soos dit het:
+
+
+
+
schacon = Scott Chacon <schacon@geemail.com>
+selse = Someo Nelse <selse@geemail.com>
+
+
+
+
Om 'n lys te kry van die outeursname wat SVN gebruik, kan jy dit uitvoer:
+
+
+
+
$ svn log --xml --quiet | grep author | sort -u | \
+ perl -pe 's/.*>(.*?)<.*/$1 = /'
+
+
+
+
Dit genereer die log-afvoer in XML-formaat, behou dan slegs die reëls met outeurinligting, gooi duplikate weg en stroop die XML-merkers uit.
+Dit werk uiteraard net op 'n masjien waarop grep, sort en perl geïnstalleer is.
+Leid dan daardie afvoer na jou users.txt lêer om sodat jy die ekwivalente Git-gebruikersdata langs elke inskrywing kan byvoeg.
+
+
+
+
Jy kan hierdie lêer aan git svn verskaf om dit te help om die outeurdata akkuraat te kaart.
+Jy kan ook vir git svn sê om nie die metadata in te sluit wat Subversion normaalweg invoer nie, deur --no-metadata na die clone of init opdrag deur te gee.
+Die metadata sluit 'n git-svn-id binne elke vasleggingsboodskap in wat Git tydens invoer sal genereer.
+Dit kan jou Git-log laat uitswel en dit dalk 'n bietjie onduidelik maak.
+
+
+
+
+|
+ Note
+ |
+
+
+ Jy moet die metadata behou wanneer jy vasleggings wat in die Git-bewaarplek gemaak is, terug wil spieël in die oorspronklike SVN-bewaarplek.
+As jy nie die sinchronisasie in jou vasleggingslog wil hê nie, voel vry om die --no-metadata parameter weg te laat.
+ |
+
+
+
+
+
Dit laat jou import-opdrag so lyk:
+
+
+
+
$ git svn clone http://my-project.googlecode.com/svn/ \
+ --authors-file=users.txt --no-metadata --prefix "" -s my_project
+$ cd my_project
+
+
+
+
Nou behoort jy 'n mooier Subversion-invoer in jou my_project gids te hê.
+In plaas van vasleggings wat so lyk:
+
+
+
+
commit 37efa680e8473b615de980fa935944215428a35a
+Author: schacon <schacon@4c93b258-373f-11de-be05-5f7a86268029>
+Date: Sun May 3 00:12:22 2009 +0000
+
+ fixed install - go to trunk
+
+ git-svn-id: https://my-project.googlecode.com/svn/trunk@94 4c93b258-373f-11de-
+ be05-5f7a86268029
+
+
+
+
+
+
commit 03a8785f44c8ea5cdb0e8834b7c8e6c469be2ff2
+Author: Scott Chacon <schacon@geemail.com>
+Date: Sun May 3 00:12:22 2009 +0000
+
+ fixed install - go to trunk
+
+
+
+
Nie net lyk die Outeurveld baie beter nie, maar die git-svn-id is ook nie meer daar nie.
+
+
+
Jy moet ook 'n bietjie skoonmaak na die invoer doen.
+Een ding is dat jy die vreemde verwysings wat git svn opgestel het, moet skoonmaak.
+Eers sal jy die merkers skuif sodat dit werklike merkers is eerder as vreemde afgeleë takke, en dan sal jy die res van die takke skuif sodat hulle plaaslik is.
+
+
+
Om die merkers na egte Git-merkers te skuif, voer uit:
+
+
+
+
$ for t in $(git for-each-ref --format='%(refname:short)' refs/remotes/tags); do git tag ${t/tags\//} $t && git branch -D -r $t; done
+
+
+
+
Dit neem die verwysings wat afgeleë takke was wat met refs/remotes/tags/ begin het, en maak werklike (liggewig) merkers daarvan.
+
+
+
Volgende, skuif die res van die verwysings onder refs/remotes om plaaslike takke te wees:
+
+
+
+
$ for b in $(git for-each-ref --format='%(refname:short)' refs/remotes); do git branch $b refs/remotes/$b && git branch -D -r $b; done
+
+
+
+
Dit kan gebeur dat jy 'n paar ekstra takke sal sien wat agtervoegsels het van @xxx (waar xxx 'n nommer is), terwyl jy in Subversion net een tak sien.
+Dit is eintlik 'n Subversion-funksie genaamd “peg-revisions”, wat iets is waarvoor Git eenvoudig geen sintaktiese eweknie het nie.
+Vandaar dat git svn eenvoudig die SVN-weergawenommer by die taknaam voeg op presies dieselfde manier as wat jy dit in SVN sou geskryf het om die peg-hersiening van daardie tak te adresseer.
+As jy nie meer omgee vir die peg-hersienings nie, verwyder hulle eenvoudig:
+
+
+
+
$ for p in $(git for-each-ref --format='%(refname:short)' | grep @); do git branch -D $p; done
+
+
+
+
Nou is al die ou takke egte Git-takke en al die ou merkers egte Git-merkers.
+
+
+
Daar is een laaste ding om op te skoon.
+Ongelukkig skep git svn 'n ekstra tak genaamd trunk, wat na Subversion se verstektak karteer, maar die trunk verwysing wys na dieselfde plek as master.
+Aangesien master meer idiomaties Git is, is hier hoe om die ekstra tak te verwyder:
+
+
+
+
Die laaste ding om te doen is om jou nuwe Git-bediener as 'n remote by te voeg en daarna te push.
+Hier is 'n voorbeeld van die byvoeging van jou bediener as 'n remote:
+
+
+
+
$ git remote add origin git@my-git-server:myrepository.git
+
+
+
+
Omdat jy wil hê al jou takke en merkers moet opstoot, kan jy nou dit uitvoer:
+
+
+
+
$ git push origin --all
+$ git push origin --tags
+
+
+
+
Al jou takke en merkers behoort op jou nuwe Git-bediener te wees in 'n lekker, skoon invoer.
+
+
+
Mercurial
+
+
+Aangesien Mercurial en Git taamlik soortgelyke modelle het om weergawes te verteenwoordig, en aangesien Git 'n bietjie more buigsaam is, is dit vrij eenvoudig om 'n bewaarplek van Mercurial na Git te konverteer deur gebruik te maak van 'n hulpmiddel genaamd "hg-fast-export", waarvan jy 'n kopie nodig sal hê:
+
+
+
+
$ git clone https://github.com/frej/fast-export.git
+
+
+
+
Die eerste stap in die omskakeling is om 'n volledige kloon te kry van die Mercurial-bewaarplek wat jy wil konverteer:
+
+
+
+
$ hg clone <remote repo URL> /tmp/hg-repo
+
+
+
+
Die volgende stap is om 'n outeurskarteringslêer te skep.
+Mercurial is 'n bietjie meer vergewensgesind as Git oor wat dit in die outeursveld vir wysigingstelle (changesets) plaas, so dit is 'n goeie tyd om huis skoon te maak.
+Om dit te genereer is 'n eenreël-opdrag in 'n bash dop:
+
+
+
+
$ cd /tmp/hg-repo
+$ hg log | grep user: | sort | uniq | sed 's/user: *//' > ../authors
+
+
+
+
Dit sal 'n paar sekondes neem, afhangende van hoe lank jou projek se geskiedenis is, en daarna sal die /tmp/authors lêer so iets lyk:
+
+
+
+
bob
+bob@localhost
+bob <bob@company.com>
+bob jones <bob <AT> company <DOT> com>
+Bob Jones <bob@company.com>
+Joe Smith <joe@company.com>
+
+
+
+
In hierdie voorbeeld het dieselfde persoon (Bob) wysigingstelle geskep onder vier verskillende name, waarvan een eintlich korrek lyk, en een daarvoor heeltemal ongeldig sou wees vir 'n Git-vaslegging.
+hg-fast-export laat ons dit regmaak deur elke reël in 'n reël te verander: "<input>"="<output>", wat 'n <input> na 'n <output> karteer.
+Binne die <input> en <output> stringe word alle ontsnappingsreekse (escape sequences) wat deur die Python string_escape kodering verstaan word, ondersteun.
+As die outeurskarteringslêer nie 'n ooreenstemmende <input> bevat nie, sal daardie outeur ongewijzigd na Git aangestuur word.
+As al die gebruikersname goed lyk, benodig ons hierdie lêer glad nie.
+In hierdie voorbeeld wil ons hê ons lêer moet so lyk:
+
+
+
+
"bob"="Bob Jones <bob@company.com>"
+"bob@localhost"="Bob Jones <bob@company.com>"
+"bob <bob@company.com>"="Bob Jones <bob@company.com>"
+"bob jones <bob <AT> company <DOT> com>"="Bob Jones <bob@company.com>"
+
+
+
+
Dieselfde soort karteringslêer kan gebruik word om takke en merkers te hernoem wanneer die Mercurial-naam nie deur Git toegelaat word nie.
+
+
+
Die volgende stap is om ons nuwe Git-bewaarplek te skep en die uitvoerskrip te laat loop:
+
+
+
+
$ git init /tmp/converted
+$ cd /tmp/converted
+$ /tmp/fast-export/hg-fast-export.sh -r /tmp/hg-repo -A /tmp/authors
+
+
+
+
Die -r vlag vertel hg-fast-export waar om die Mercurial-bewaarplek te vind wat ons wil konverteer, en die -A vlag vertel dit waar om die outeurskarteringslêer te vind (tak- en merkerkarteringslêers word onderskeidelik deur die -B en -T vlae gespesifiseer).
+Die skrip ontleed Mercurial-wysigingstelle en skakel dit om in 'n skrip vir Git se "fast-import" kenmerk (wat ons 'n bietjie later in detail sal bespreek).
+Dit neem 'n bietjie (alhoewel dit baie vinniger is as wat dit oor die netwerk sou wees), en die afvoer is taamlik lankdradig (verbose):
+
+
+
+
$ /tmp/fast-export/hg-fast-export.sh -r /tmp/hg-repo -A /tmp/authors
+Loaded 4 authors
+master: Exporting full revision 1/22208 with 13/0/0 added/changed/removed files
+master: Exporting simple delta revision 2/22208 with 1/1/0 added/changed/removed files
+master: Exporting simple delta revision 3/22208 with 0/1/0 added/changed/removed files
+[…]
+master: Exporting simple delta revision 22206/22208 with 0/4/0 added/changed/removed files
+master: Exporting simple delta revision 22207/22208 with 0/2/0 added/changed/removed files
+master: Exporting thorough delta revision 22208/22208 with 3/213/0 added/changed/removed files
+Exporting tag [0.4c] at [hg r9] [git :10]
+Exporting tag [0.4d] at [hg r16] [git :17]
+[…]
+Exporting tag [3.1-rc] at [hg r21926] [git :21927]
+Exporting tag [3.1] at [hg r21973] [git :21974]
+Issued 22315 commands
+git-fast-import statistics:
+---------------------------------------------------------------------
+Alloc'd objects: 120000
+Total objects: 115032 ( 208171 duplicates )
+ blobs : 40504 ( 205320 duplicates 26117 deltas of 39602 attempts)
+ trees : 52320 ( 2851 duplicates 47467 deltas of 47599 attempts)
+ commits: 22208 ( 0 duplicates 0 deltas of 0 attempts)
+ tags : 0 ( 0 duplicates 0 deltas of 0 attempts)
+Total branches: 109 ( 1 loads )
+ marks: 1048576 ( 22208 unique )
+ atoms: 1952
+Memory total: 7860 KiB
+ pools: 2235 KiB
+ objects: 5625 KiB
+---------------------------------------------------------------------
+pack_report: getpagesize() = 4096
+pack_report: core.packedGitWindowSize = 1073741824
+pack_report: core.packedGitLimit = 8589934592
+pack_report: pack_used_ctr = 90430
+pack_report: pack_mmap_calls = 46771
+pack_report: pack_open_windows = 1 / 1
+pack_report: pack_mapped = 340852700 / 340852700
+---------------------------------------------------------------------
+
+$ git shortlog -sn
+ 369 Bob Jones
+ 365 Joe Smith
+
+
+
+
Dis omtrent al wat daar is.
+Al die Mercurial-merkers is na Git-merkers omgeskakel, en Mercurial-takke en -boekmerke is na Git-takke omgeskakel.
+Nou is jy gereed om die bewaarplek na sy nuwe bedienerkant-tuis te push:
+
+
+
+
$ git remote add origin git@my-git-server:myrepository.git
+$ git push origin --all
+
+
+
+
Perforce
+
+
+Die volgende stelsel waarna jy sal kyk om van in te voer, is Perforce.
+Soos ons hierbo bespreek het, is daar twee maniere om Git en Perforce met mekaar te laat praat: git-p4 en Perforce Git Fusion.
+
+
+
Perforce Git Fusion
+
+
Git Fusion maak hierdie proses redelik pynloos.
+Konfigureer net jou projekinstellings, gebruikerskarterings (user mappings) en takke deur 'n konfigurasielêer te gebruik (soos bespreek in }}">Git Fusion), en kloon die bewaarplek.
+Git Fusion laat jou met wat lyk soos 'n eie (native) Git-bewaarplek, wat dan gereed is om na 'n eie Git-gasheer gepush te word as jy wil.
+Jy kan selfs Perforce as jou Git-gasheer gebruik as jy verkies.
+
+
+
+
Git-p4
+
+
git-p4 kan ook as 'n invoerhulpmiddel dien.
+As 'n voorbeeld sal ons die Jam-projek vanaf die Perforce Public Depot invoer.
+Om jou kliënt op te stel, moet jy die P4PORT omgewingsveranderlike uitvoer (export) om na die Perforce-depot te wys:
+
+
+
+
$ export P4PORT=public.perforce.com:1666
+
+
+
+
+
+|
+ Note
+ |
+
+
+ Om te kan volg, sal jy 'n Perforce-depot nodig hê om mee te verbind.
+Ons sal die openbare depot by public.perforce.com vir ons voorbeelde gebruik, maar jy kan enige depot gebruik waartoe jy toegang het.
+ |
+
+
+
+
+
+Voer die git p4 clone opdrag uit om die Jam-projek van die Perforce-bediener in te voer, deur die depot- en projekpad te verskaf asook die pad waarheen jy die projek wil invoer:
+
+
+
+
$ git-p4 clone //guest/perforce_software/jam@all p4import
+Importing from //guest/perforce_software/jam@all into p4import
+Initialized empty Git repository in /private/tmp/p4import/.git/
+Import destination: refs/remotes/p4/master
+Importing revision 9957 (100%)
+
+
+
+
Hierdie spesifieke projek het slegs een tak, maar as jy takke het wat opgestel is met tak-aansigte (branch views) (of net 'n stel gidse), kan jy die --detect-branches vlag saam met git p4 clone gebruik om al die projek se takke ook in te voer.
+Sien }}">Takking (Branching) vir 'n bietjie meer besonderhede hieroor.
+
+
+
Op hierdie stadium is jy amper klaar.
+As jy na die p4import gids gaan en git log uitvoer, kan jy jou ingevoerde werk sien:
+
+
+
+
$ git log -2
+commit e5da1c909e5db3036475419f6379f2c73710c4e6
+Author: giles <giles@giles@perforce.com>
+Date: Wed Feb 8 03:13:27 2012 -0800
+
+ Correction to line 355; change </UL> to </OL>.
+
+ [git-p4: depot-paths = "//public/jam/src/": change = 8068]
+
+commit aa21359a0a135dda85c50a7f7cf249e4f7b8fd98
+Author: kwirth <kwirth@perforce.com>
+Date: Tue Jul 7 01:35:51 2009 -0800
+
+ Fix spelling error on Jam doc page (cummulative -> cumulative).
+
+ [git-p4: depot-paths = "//public/jam/src/": change = 7304]
+
+
+
+
Jy kan sien dat git-p4 'n identifiseerder in elke vasleggingsboodskap gelaat het.
+Dit is heeltemal reg om daardie identifiseerder daar te hou, vir ingeval jy later na die Perforce-veranderingsnommer moet verwys.
+As jy egter die identifiseerder wil verwyder, is dít nou die tyd om dit te doen – voordat jy aan die nuwe bewaarplek begin werk.
+
+Jy kan git filter-branch gebruik om die identifiseerder-stringe en masse te verwyder:
+
+
+
+
$ git filter-branch --msg-filter 'sed -e "/^\[git-p4:/d"'
+Rewrite e5da1c909e5db3036475419f6379f2c73710c4e6 (125/125)
+Ref 'refs/heads/master' was rewritten
+
+
+
+
As jy git log uitvoer, kan jy sien dat al die SHA-1 kontrolesomme (checksums) vir die vasleggings verander het, maar die git-p4 stringe is nie meer in die vasleggingsboodskappe nie:
+
+
+
+
$ git log -2
+commit b17341801ed838d97f7800a54a6f9b95750839b7
+Author: giles <giles@giles@perforce.com>
+Date: Wed Feb 8 03:13:27 2012 -0800
+
+ Correction to line 355; change </UL> to </OL>.
+
+commit 3e68c2e26cd89cb983eb52c024ecdfba1d6b3fff
+Author: kwirth <kwirth@perforce.com>
+Date: Tue Jul 7 01:35:51 2009 -0800
+
+ Fix spelling error on Jam doc page (cummulative -> cumulative).
+
+
+
+
Jou invoer is gereed om na jou nuwe Git-bediener gepush te word.
+
+
+
+
'n Pasgemaakte Invoerder (A Custom Importer)
+
+
+
+As jou stelsel nie een van bogenoemde is nie, moet jy aanlyn na 'n invoerder soek – gehalte-invoerders is beskikbaar vir baie ander stelsels, insluitend CVS, Clear Case, Visual Source Safe, selfs 'n gids van argiewe.
+As geen van hierdie hulpmiddels vir jou werk nie, jy 'n meer obskure hulpmiddel het, of jy andersins 'n meer pasgemaakte invoerproses benodig, moet jy git fast-import gebruik.
+Hierdie opdrag lees eenvoudige instruksies vanaf stdin om spesifieke Git-data te skryk.
+Dit is baie makliker om Git-objekte op hierdie manier te skep as om die rou Git-opdragte uit te voer of te probeer om die rou objekte te skryf (sien }}">Git Internals vir meer inligting).
+Op hierdie manier kan jy 'n invoerskrip skryf wat die nodige inligting uit die stelsel lees waaruit jy invoer en reguit instruksies na stdout druk.
+Jy kan dan hierdie program uitvoer en sy afvoer deur git fast-import pyp (pipe).
+
+
+
Om vinnig te demonstreer, gaan jy 'n eenvoudige invoerder skryf.
+Sê nou jy werk in current, jy rugsteun jou projek deur die gids af en toe te kopieer na 'n tydgestempelde back_YYYY_MM_DD rugsteungids, en jy wil dit in Git invoer.
+Jou gidsstruktuur lyk soos dit:
+
+
+
+
$ ls /opt/import_from
+back_2014_01_02
+back_2014_01_04
+back_2014_01_14
+back_2014_02_03
+current
+
+
+
+
Ten einde 'n Git-gids in te voer, moet jy hersien hoe Git sy data stoor.
+Soos jy dalk onthou, is Git fundamenteel 'n gekoppelde lys van vasleggingsobjekte (commit objects) wat wys na 'n momentopname (snapshot) van inhoud.
+Al wat jy hoef te doen is om vir fast-import te sê wat die inhoudmomentopnames is, watter vasleggingsdata daarna wys, en die volgorde waarin hulle gaan.
+Jou strategie sal wees om een vir een deur die momentopnames te gaan en vasleggings te skep met die inhoud van elke gids, en elke vaslegging terug te skakel na die vorige een.
+
+
+
Soos ons in }}">'n Voorbeeld van 'n Git-Afgedwonge Beleid (An Example Git-Enforced Policy) gedoen het, sal ons dit in Ruby skryf, omdat dit is waarmee ons gewoonlik werk en dit geneig is om maklik te lees te wees.
+Jy kan hierdie voorbeeld pretty maklik skryf in enigiets waarmee jy vertroud is – dit hoef net die gepaste inligting na stdout te druk.
+En, as jy op Windows loop, beteken dit dat jy spesiale sorg moet dra om nie wa-terugvoere (carriage returns) aan die einde van jou reëls in te voer nie – git fast-import is baie kieskeurig oor net die wil van reëltoevoere (line feeds - LF) en nie die wa-terugvoer-reëltoevoere (CRLF) wat Windows gebruik nie.
+
+
+
Om te begin, sal jy na die teikengids verander en elke subgids identifiseer, wat elk 'n momentopname is wat jy as 'n vaslegging wil invoer.
+Jy sal in elke subgids verander en die opdragte druk wat nodig is om dit te eksporteer.
+Jou basiese hooflus lyk soos dit:
+
+
+
+
last_mark = nil
+
+# loop through the directories
+Dir.chdir(ARGV[0]) do
+ Dir.glob("*").each do |dir|
+ next if File.file?(dir)
+
+ # move into the target directory
+ Dir.chdir(dir) do
+ last_mark = print_export(dir, last_mark)
+ end
+ end
+end
+
+
+
+
Jy voer print_export binne elke gids uit, wat die manifes en merker van die vorige momentopname neem en die manifes en merker van hierdie een teruggee; op daardie manier kan jy hulle behoorlik koppel.
+“Merker” (Mark) is die fast-import term vir 'n identifiseerder wat jy aan 'n vaslegging gee; terwyl jy vasleggings skep, gee jy elkeen 'n merker wat jy kan gebruik om van ander vasleggings daaraan te skakel.
+Dus, die eerste ding om te doen in jou print_export metode is om 'n merker uit die gidself te genereer:
+
+
+
+
mark = convert_dir_to_mark(dir)
+
+
+
+
Jy sal dit doen deur 'n skikking (array) van gidse te skep en die indeksiewaarde as die merker te gebruik, omdat 'n merker 'n heelgetal (integer) moet wees.
+Jou metode lyk soos dit:
+
+
+
+
$marks = []
+def convert_dir_to_mark(dir)
+ if !$marks.include?(dir)
+ $marks << dir
+ end
+ ($marks.index(dir) + 1).to_s
+end
+
+
+
+
Noudat jy 'n heelgetalvoorstelling van jou vaslegging het, benodig jy 'n datum vir die vasleggingsmetadata.
+Omdat die datum in die naam van die gids uitgedruk word, gaan jy dit ontleed.
+Die volgende reël in jou print_export lêer is:
+
+
+
+
date = convert_dir_to_date(dir)
+
+
+
+
waar convert_dir_to_date gedefinieer word as:
+
+
+
+
def convert_dir_to_date(dir)
+ if dir == 'current'
+ return Time.now().to_i
+ else
+ dir = dir.gsub('back_', '')
+ (year, month, day) = dir.split('_')
+ return Time.local(year, month, day).to_i
+ end
+end
+
+
+
+
Dit gee 'n heelgetalwaarde terug vir die datum van elke gids.
+Die laaste stukmetainligting wat jy vir elke vaslegging benodig, is die vaslêerdata (committer data), wat jy hardkodeer in 'n globale veranderlike:
+
+
+
+
$author = 'John Doe <john@example.com>'
+
+
+
+
Nou is jy gereed om te begin met die druk van die vasleggingsdata vir jou invoerder.
+Die aanvanklike inligting vermeld dat jy 'n vasleggingsobjek definieer en op watter tak dit is, gevolg deur die merker wat jy gegenereer het, die vaslêerinligting en vasleggingsboodskap, en dan die vorige vaslegging, indien enige.
+Die code lyk soos dit:
+
+
+
+
# print the import information
+puts 'commit refs/heads/master'
+puts 'mark :' + mark
+puts "committer #{$author} #{date} -0700"
+export_data('imported from ' + dir)
+puts 'from :' + last_mark if last_mark
+
+
+
+
Jy hardkodeer die tydsone (-0700) omdat dit maklik is om dit te doen.
+As jy van 'n ander stelsel invoer, moet jy die tydsone as 'n verrekening (offset) spesifiseer.
+Die vasleggingsboodskap moet in 'n spesiale formaat uitgedruk word:
+
+
+
+
data (size)\n(contents)
+
+
+
+
Die formaat bestaan uit die woord data, die grootte van die data wat gelees moet word, 'n nuwe reël, en uiteindelik die data.
+Omdat jy dieselfde formaat moet gebruik om die lêerinhoud later te spesifiseer, skep jy 'n hulpmetode, export_data:
+
+
+
+
def export_data(string)
+ print "data #{string.size}\n#{string}"
+end
+
+
+
+
Al wat oorbly, is om die lêerinhoud vir elke momentopname te spesifiseer.
+Dit is maklik, omdat jy elk in 'n gids het – jy kan die deleteall opdrag druk, gevolg deur die inhoud van elke lêer in die gids.
+Git sal dan elke momentopname gepas opteken:
+
+
+
+
puts 'deleteall'
+Dir.glob("**/*").each do |file|
+ next if !File.file?(file)
+ inline_data(file)
+end
+
+
+
+
Let wel: Omdat baie stelsels dink aan hul hersienings as veranderings van een vaslegging na 'n ander, kan fast-import ook opdragte neem met elke vaslegging om te spesifiseer watter lêers bygevoeg, verwyder of gewysig is en wat die nuwe inhoud is.
+Jy kan die verskille tussen momentopnames bereken en slegs hierdie data verskaf, maar om dit te doen is more kompleks – jy kan net as well vir Git al die data gee en dit laat uitvind.
+As dit beter by jou data pas, kyk na die fast-import man-bladsy vir besonderhede oor hoe om jou data op hierdie manier te verskaf.
+
+
+
Die formaat vir die lys van die nuwe lêerinhoud of die spesifikasie van 'n gewysigde lêer met die nuwe inhoud is as volg:
+
+
+
+
M 644 inline path/to/file
+data (size)
+(file contents)
+
+
+
+
Hier is 644 die modus (as jy uitvoerbare lêers het, moet jy 755 in plaas daarvan detekteer en spesifiseer), en inline sê dat jy die inhoud onmiddellik na hierdie reël sal lys.
+Jou inline_data metode lyk soos dit:
+
+
+
+
def inline_data(file, code = 'M', mode = '644')
+ content = File.read(file)
+ puts "#{code} #{mode} inline #{file}"
+ export_data(content)
+end
+
+
+
+
Jy hergebruik die export_data metode wat jy vroeër gedefinieer het, omdat dit dieselfde is as die manier waarop jy jou vasleggingsboodskapdata gespesifiseer het.
+
+
+
Die laaste ding wat jy moet doen is om die huidige merker terug te gee sodat dit aan die volgende herhaling (iteration) deurgegee kan word:
+
+
+
+
+
+|
+ Note
+ |
+
+
+ As jy op Windows loop, moet jy seker maak dat jy een ekstra stap byvoeg.
+Soos voorheen genoem, gebruik Windows CRLF vir nuwe reëlkarakters terwyl git fast-import slegs LF verwag.
+Om rondom hierdie probleem te kom en git fast-import gelukkig te maak, moet jy vir ruby sê om LF in plaas van CRLF te gebruik:
+ |
+
+
+
+
+
Dis dit.
+Hier is die skrip in sy geheel:
+
+
+
+
#!/usr/bin/env ruby
+
+$stdout.binmode
+$author = "John Doe <john@example.com>"
+
+$marks = []
+def convert_dir_to_mark(dir)
+ if !$marks.include?(dir)
+ $marks << dir
+ end
+ ($marks.index(dir)+1).to_s
+end
+
+def convert_dir_to_date(dir)
+ if dir == 'current'
+ return Time.now().to_i
+ else
+ dir = dir.gsub('back_', '')
+ (year, month, day) = dir.split('_')
+ return Time.local(year, month, day).to_i
+ end
+end
+
+def export_data(string)
+ print "data #{string.size}\n#{string}"
+end
+
+def inline_data(file, code='M', mode='644')
+ content = File.read(file)
+ puts "#{code} #{mode} inline #{file}"
+ export_data(content)
+end
+
+def print_export(dir, last_mark)
+ date = convert_dir_to_date(dir)
+ mark = convert_dir_to_mark(dir)
+
+ puts 'commit refs/heads/master'
+ puts "mark :#{mark}"
+ puts "committer #{$author} #{date} -0700"
+ export_data("imported from #{dir}")
+ puts "from :#{last_mark}" if last_mark
+
+ puts 'deleteall'
+ Dir.glob("**/*").each do |file|
+ next if !File.file?(file)
+ inline_data(file)
+ end
+ mark
+end
+
+# Loop through the directories
+last_mark = nil
+Dir.chdir(ARGV[0]) do
+ Dir.glob("*").each do |dir|
+ next if File.file?(dir)
+
+ # move into the target directory
+ Dir.chdir(dir) do
+ last_mark = print_export(dir, last_mark)
+ end
+ end
+end
+
+
+
+
As jy hierdie skrip uitvoer, kry jy inhoud wat so iets lyk:
+
+
+
+
$ ruby import.rb /opt/import_from
+commit refs/heads/master
+mark :1
+committer John Doe <john@example.com> 1388649600 -0700
+data 29
+imported from back_2014_01_02deleteall
+M 644 inline README.md
+data 28
+# Hello
+
+This is my readme.
+commit refs/heads/master
+mark :2
+committer John Doe <john@example.com> 1388822400 -0700
+data 29
+imported from back_2014_01_04from :1
+deleteall
+M 644 inline main.rb
+data 34
+#!/bin/env ruby
+
+puts "Hey there"
+M 644 inline README.md
+(...)
+
+
+
+
Om die invoerder te laat loop, pyp hierdie afvoer deur git fast-import terwyl jy in die Git-gids is waarin jy wil invoer.
+Jy kan 'n nuwe gids skep en dan git init daarin uitvoer vir 'n beginpunt, en dan jou skrip uitvoer:
+
+
+
+
$ git init
+Initialized empty Git repository in /opt/import_to/.git/
+$ ruby import.rb /opt/import_from | git fast-import
+git-fast-import statistics:
+---------------------------------------------------------------------
+Alloc'd objects: 5000
+Total objects: 13 ( 6 duplicates )
+ blobs : 5 ( 4 duplicates 3 deltas of 5 attempts)
+ trees : 4 ( 1 duplicates 0 deltas of 4 attempts)
+ commits: 4 ( 1 duplicates 0 deltas of 0 attempts)
+ tags : 0 ( 0 duplicates 0 deltas of 0 attempts)
+Total branches: 1 ( 1 loads )
+ marks: 1024 ( 5 unique )
+ atoms: 2
+Memory total: 2344 KiB
+ pools: 2110 KiB
+ objects: 234 KiB
+---------------------------------------------------------------------
+pack_report: getpagesize() = 4096
+pack_report: core.packedGitWindowSize = 1073741824
+pack_report: core.packedGitLimit = 8589934592
+pack_report: pack_used_ctr = 10
+pack_report: pack_mmap_calls = 5
+pack_report: pack_open_windows = 2 / 2
+pack_report: pack_mapped = 1457 / 1457
+---------------------------------------------------------------------
+
+
+
+
Soos jy kan sien, wanneer dit suksesvol voltooi word, gee dit vir jou 'n trop statistieke oor wat dit bereik het.
+In hierdie geval het jy in totaal 13 objekte vir 4 vasleggings in 1 tak ingevoer.
+Nou kan jy git log uitvoer om jou nuwe geskiedenis te sien:
+
+
+
+
$ git log -2
+commit 3caa046d4aac682a55867132ccdfbe0d3fdee498
+Author: John Doe <john@example.com>
+Date: Tue Jul 29 19:39:04 2014 -0700
+
+ imported from current
+
+commit 4afc2b945d0d3c8cd00556fbe2e8224569dc9def
+Author: John Doe <john@example.com>
+Date: Mon Feb 3 01:00:00 2014 -0700
+
+ imported from back_2014_02_03
+
+
+
+
Daar het jy dit – 'n lekker, skoon Git-bewaarplek.
+Dit is belangrik om op te let dat niks uitgetrek is nie – jy het aanvanklik geen lêers in jou werkgids nie.
+Om hulle te kry, moet jy jou tak herstel (reset) na waar master nou is:
+
+
+
+
$ ls
+$ git reset --hard master
+HEAD is now at 3caa046 imported from current
+$ ls
+README.md main.rb
+
+
+
+
Jy kan baie meer met die fast-import hulpmiddel doen – verskillende modusse hanteer, binêre data, veelvuldige takke en saamsmelting, merkers, vorderingaanwysers, en meer.
+'n Aantal voorbeelde van meer kompleks scenario’s is beskikbaar in die contrib/fast-import gids van die Git-bronkode.
+
+
Summary
+
+
You should feel comfortable using Git as a client for other version-control systems, or importing nearly any existing repository into Git without losing data.
+In the next chapter, we’ll cover the raw internals of Git so you can craft every single byte, if need be.
+
Derdeparty-gasheuroplossings (Third-Party Hosting Solutions)
+
+
+As jy nie al die werk wil doen wat gepaard gaan met die opstel van jou eie Git-bediener nie, het jy 'n aantal opsies om jou Git-projekte te laat huisves (host) op 'n eksterne webwerf wat hom hierop toespits.
+As jy dit doen, bied dit jou 'n aantal voordeel: 'n gasheerwebwerf (hosting site) is oor die algemeen vinnig opgestel en dit is maklik om projekte daarop te begin, en geen bedienerinstandhouding of -monitering is nodig nie.
+Selfs al stel jy jou eie interne bediener op en laat dit loop, wil jy dalk steeds 'n openbare gasheerwebwerf vir jou oopbronkode (open source code) gebruik — dit is oor die algemeen makliker vir die oopbrongemeenskap om jou te vind en daarmee te help.
+
+
Vandag het jy 'n groot aantal gasheeropsies waaruit jy kan kies, elk met verskillende voor- en nadele.
+Vir 'n onlangs opgedateerde lys, kyk gerus na die GitHosting-bladsy van die hoof Git-wiki by https://git.wiki.kernel.org/index.php/GitHosting
+
+
Ons sal die gebruik van GitHub in groot detail in }}">GitHub bespreek, aangesien dit min of meer die grootste Git-gasheer is wat daar is en jy waarskynlik in elk geval in aanraking sal kom met projekte wat daar gehuisves word; maar daar is nog tientalle waaruit jy kan kies as jy nie jou eie Git-bediener wil inrig nie.
+
Die Bediener Opstel (Setting Up the Server)
+
+
Kom ons stap deur die opstel van SSH-toegang aan die bedienerkant (server side).
+In hierdie voorbeeld sal jy die authorized_keys metode gebruik om jou gebruikers te verifieer (authenticate).
+Ons aanvaar ook dat jy 'n standaard Linux-verspreiding (distribution) soos Ubuntu laat loop.
+
+
+
+|
+ Note
+ |
+
+
+ 'n Goeie deel van wat hier beskryf word, kan geautomatiseer word deur die ssh-copy-id opdrag te gebruik, in plaas van om publieke sleutels handmatig te kopieer en te installeer.
+ |
+
+
+
+
Eerstens skep jy 'n git gebruikersrekening en 'n .ssh gids (directory) vir daardie gebruiker.
+
+
+
$ sudo adduser git
+$ su git
+$ cd
+$ mkdir .ssh && chmod 700 .ssh
+$ touch .ssh/authorized_keys && chmod 600 .ssh/authorized_keys
+
+
+
Vervolgens moet jy 'n paar publieke SSH-sleutels van ontwikkelaars by die authorized_keys lêer vir die git gebruiker voeg.
+Kom ons aanvaar jy het 'n paar weggesteekte publieke sleutels en het hulle in tydelike lêers gestoor.
+Weereens lyk die publieke sleutels min of meer so:
+
+
+
$ cat /tmp/id_rsa.john.pub
+ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCB007n/ww+ouN4gSLKssMxXnBOvf9LGt4L
+ojG6rs6hPB09j9R/T17/x4lhJA0F3FR1rP6kYBRsWj2aThGw6HXLm9/5zytK6Ztg3RPKK+4k
+Yjh6541NYsnEAZuXz0jTTyAUfrtU3Z5E003C4oxOj6H0rfIF1kKI9MAQLMdpGW1GYEIgS9Ez
+Sdfd8AcCIicTDWbqLAcU4UpkaX8KyGlLwsNuuGztobF8m72ALC/nLF6JLtPofwFBlgc+myiv
+O7TCUSBdLQlgMVOFq1I2uPWQOkOWQAHukEOmfjy2jctxSDBQ220ymjaNsHT4kgtZg2AYYgPq
+dAv8JggJICUvax2T9va5 gsg-keypair
+
+
+
Jy voeg hulle eenvoudig by die git gebruiker se authorized_keys lêer in sy .ssh gids:
+
+
+
$ cat /tmp/id_rsa.john.pub >> ~/.ssh/authorized_keys
+$ cat /tmp/id_rsa.josie.pub >> ~/.ssh/authorized_keys
+$ cat /tmp/id_rsa.jessica.pub >> ~/.ssh/authorized_keys
+
+
+
Nou kan jy 'n leë bewaarplek (repository) vir hulle opstel deur git init uit te voer met die --bare opsie, wat die bewaarplek initialiseer sonder 'n werkgids (working directory):
+
+
+
$ cd /srv/git
+$ mkdir project.git
+$ cd project.git
+$ git init --bare
+Initialized empty Git repository in /srv/git/project.git/
+
+
+
Dan kan John, Josie of Jessica die eerste weergawe van hul projek in daardie bewaarplek push deur dit as 'n remote by te voeg en 'n tak (branch) op te stuur.
+Let daarop dat iemand op die masjien moet inlog (shell onto) en 'n kale bewaarplek (bare repository) moet skep elk liewe keer as jy 'n projek wil byvoeg.
+Kom ons gebruik gitserver as die gasheernaam (hostname) van die bediener waarop jy jou git gebruiker en bewaarplek opgestel het.
+Als jy dit intern laat loop, en jy stel DNS op vir gitserver om na daardie bediener te wys, dan kan jy die opdragte prakties ongewysig gebruik (met die veronderstelling dat myproject 'n bestaande projek met lêers daarin is):
+
+
+
# on John's computer
+$ cd myproject
+$ git init
+$ git add .
+$ git commit -m 'Initial commit'
+$ git remote add origin git@gitserver:/srv/git/project.git
+$ git push origin master
+
+
+
Op hierdie punt kan die grotes dit net so maklik afhaal (clone) en veranderings terug push:
+
+
+
$ git clone git@gitserver:/srv/git/project.git
+$ cd project
+$ vim README
+$ git commit -am 'Fix for README file'
+$ git push origin master
+
+
+
Met hierdie metode kan jy vinnig 'n lees/skryf Git-bediener aan die gang kry vir 'n handjievol ontwikkelaars.
+
+
Jy moet let op die feit dat al hierdie gebruikers tans ook by die bediener kan aanmeld en 'n dop (shell) as die git gebruiker kan kry.
+As jy dit wil beperk, sal jy die dop na iets anders in die /etc/passwd lêer moet verander.
+
+
Jy kan die git gebruikersrekening maklik beperk tot slegs Git-verwante aktiwiteite met 'n beperkte dop-nutsding (limited shell tool) genaamd git-shell wat saam met Git kom.
+As jy dit as die git gebruikersrekening se aantekendop (login shell) stel, dan kan daardie rekening nie normale doptoegang tot jou bediener hê nie.
+Om dit te gebruik, spesifiseer git-shell in plaas van bash of csh vir daardie rekening se aantekendop.
+Om dit te doen, moet jy eers die volle padnaam van die git-shell opdrag by /etc/shells voeg as dit nie reeds daar is nie:
+
+
+
$ cat /etc/shells # see if git-shell is already in there. If not...
+$ which git-shell # make sure git-shell is installed on your system.
+$ sudo -e /etc/shells # and add the path to git-shell from last command
+
+
+
Nou kan jy die dop vir 'n gebruiker wysig deur chsh <username> -s <shell> te gebruik:
+
+
+
$ sudo chsh git -s $(which git-shell)
+
+
+
Nou kan die git gebruiker steeds die SSH-verbinding gebruik om Git-bewaarplekke te push en pull, maar kan nie op die masjien 'n dop oopmaak nie.
+As jy dit probeer, sal jy 'n aanmeldingsweigering soos hierdie sien:
+
+
+
$ ssh git@gitserver
+fatal: Interactive git shell is not enabled.
+hint: ~/git-shell-commands should exist and have read and execute access.
+Connection to gitserver closed.
+
+
+
Op hierdie punt kan gebruikers steeds SSH-poortaanleiding (port forwarding) gebruik om toegang te verkry tot enige gasheer wat die git-bediener kan bereik.
+As jy dit wil voorkom, kan jy die authorized_keys lêer wysig en die volgende opsies vooraf voeg by elke sleutel wat jy wil beperk:
+
+
+
no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty
+
+
+
Die resultaat behoort so te lyk:
+
+
+
$ cat ~/.ssh/authorized_keys
+no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa
+AAAAB3NzaC1yc2EAAAADAQABAAABAQCB007n/ww+ouN4gSLKssMxXnBOvf9LGt4LojG6rs6h
+PB09j9R/T17/x4lhJA0F3FR1rP6kYBRsWj2aThGw6HXLm9/5zytK6Ztg3RPKK+4kYjh6541N
+YsnEAZuXz0jTTyAUfrtU3Z5E003C4oxOj6H0rfIF1kKI9MAQLMdpGW1GYEIgS9EzSdfd8AcC
+IicTDWbqLAcU4UpkaX8KyGlLwsNuuGztobF8m72ALC/nLF6JLtPofwFBlgc+myivO7TCUSBd
+LQlgMVOFq1I2uPWQOkOWQAHukEOmfjy2jctxSDBQ220ymjaNsHT4kgtZg2AYYgPqdAv8JggJ
+ICUvax2T9va5 gsg-keypair
+
+no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa
+AAAAB3NzaC1yc2EAAAADAQABAAABAQDEwENNMomTboYI+LJieaAY16qiXiH3wuvENhBG...
+
+
+
Nou sal Git-netwerkopdragte steeds perfek werk, maar die gebruikers sal nie 'n dop kan kry nie.
+Soos die afvoer aandui, kan jy ook 'n gids opstel in die git gebruiker se tuisgids (home directory) wat die git-shell opdrag 'n bietjie aanpas.
+Jy kan byvoorbeeld die Git-opdragte wat die bediener sal aanvaar beperk, of jy kan die boodskap aanpas wat gebruikers sien as hulle probeer om so via SSH aan te meld.
+Voer git help shell uit vir meer inligting oor die aanpassing van die dop.
+
+At this point, you should be able to do most of the day-to-day tasks for which you’ll be using Git.
+However, in order to do any collaboration in Git, you’ll need to have a remote Git repository.
+Although you can technically push changes to and pull changes from individuals' repositories, doing so is discouraged because you can fairly easily confuse what they’re working on if you’re not careful.
+Furthermore, you want your collaborators to be able to access the repository even if your computer is offline — having a more reliable common repository is often useful.
+Therefore, the preferred method for collaborating with someone is to set up an intermediate repository that you both have access to, and push to and pull from that.
Running a Git server is fairly straightforward.
+First, you choose which protocols you want your server to support.
+The first section of this chapter will cover the available protocols and the pros and cons of each.
+The next sections will explain some typical setups using those protocols and how to get your server running with them.
+Last, we’ll go over a few hosted options, if you don’t mind hosting your code on someone else’s server and don’t want to go through the hassle of setting up and maintaining your own server.
If you have no interest in running your own server, you can skip to the last section of the chapter to see some options for setting up a hosted account and then move on to the next chapter, where we discuss the various ins and outs of working in a distributed source control environment.
A remote repository is generally a bare repository — a Git repository that has no working directory.
+Because the repository is only used as a collaboration point, there is no reason to have a snapshot checked out on disk; it’s just the Git data.
+In the simplest terms, a bare repository is the contents of your project’s .git directory and nothing else.
+Die Protokolle (The Protocols)
+
+
Git kan vier verskillende protokolle gebruik om data oor te dra: Lokaal, HTTP, Secure Shell (SSH) en Git.
+Hier bespreek ons wat dit is en in watter basiese omstandighede jy dit wil (of nie wil nie) gebruik.
+
+
Die Lokale Protokol (Local Protocol)
+
+
+Die mees basiese is die lokale protokol, waarin die afgeleë bewaarplek (remote repository) in 'n ander gids (directory) op dieselfde gasheer (host) is.
+Dit word dikwels gebruik as almal op jou span toegang het tot 'n gedeelde lêerstelsel (shared filesystem) soos 'n NFS-aankoppeling (mount), of in die minder waarskynlike geval dat almal op dieselfde rekenaar aanmeld (logs in).
+Laasgenoemde sou nie ideaal wees nie, omdat al jou kodedatabasis-bewaarplek-instansies op dieselfde rekenaar sou bly, wat 'n katastrofiese verlies veel waarskynliker maak.
+
+
+
As jy 'n gedeelde aangekoppelde lêerstelsel het, kan jy van 'n plaaslike lêergebaseerde bewaarplek kloon (clone), daarheen push, en daarvandaan pull.
+Om so 'n bewaarplek te kloon, of om een as 'n remote by 'n bestaande projek te voeg, gebruik die pad na die bewaarplek as die URL.
+Om 'n plaaslike bewaarplek te kloon, kan jy byvoorbeeld iets soos dit uitvoer:
+
+
+
+
$ git clone /srv/git/project.git
+
+
+
+
+
+
$ git clone file:///srv/git/project.git
+
+
+
+
Git werk 'n bietjie anders as jy eksplisiet file:// aan die begin van die URL spesifiseer.
+As jy net die pad spesifiseer, probeer Git harde skakels (hardlinks) gebruik of die lêers wat dit benodig direk kopieer.
+As jy file:// spesifiseer, vuur Git die prosesse aan wat dit normaalweg gebruik om data oor 'n netwerk te dra, wat oor die algemeen veel minder doeltreffend is.
+Die hoofrede om die file:// voorvoegsel te spesifiseer is as jy 'n skoon kopie van die bewaarplek wil hê met oortollige verwysings of objekte uitgelaat — gewoonlik na 'n invoer (import) vanaf 'n ander VCS of iets soortgelyks (sien }}">Git Internals vir onderhoudstake).
+Ons sal die normale pad hier gebruik omdat dit amper altyd vinniger is.
+
+
+
Om 'n plaaslike bewaarplek by 'n bestaande Git-projek te voeg, kan jy iets soos dit uitvoer:
+
+
+
+
$ git remote add local_proj /srv/git/project.git
+
+
+
+
Dan kan jy na en van daardie remote push en pull via jou nuwe remote-naam local_proj asof jy dit oor 'n netwerk gedoen het.
+
+
+
Die Voordele (The Pros)
+
+
Die voordele van lêergebaseerde bewaarplekke is dat hulle eenvoudig is en bestaande lêerregte (file permissions) en netwerktoegang gebruik.
+As jy reeds 'n gedeelde lêerstelsel het waartoe jou hele span toegang het, is dit baie maklik om 'n bewaarplek op te stel.
+Jy sit die kale bewaarplekkopie (bare repository copy) iewers waar almal gedeelde toegang toe het en stel die lees-/skryfregte in soos jy vir enige ander gedeelde gids sou doen.
+Ons sal bespreek hoe om 'n kale bewaarplekkopie vir hierdie doel uit te voer (export) in }}">Git op 'n Bediener kry (Getting Git on a Server).
+
+
+
Dit is ook 'n lekker opsie om vinnig werk van iemand anders se werkende bewaarplek te gryp.
+As jy en 'n medewerker aan dieselfde projek werk en hulle wil hê jy moet iets uitsit (check out), is dit dikwels makliker om 'n opdrag soos git pull /home/john/project uit te voer as dat hulle na 'n afgeleë bediener push en jy dit daarna daarvandaan afhaal (fetch).
+
+
+
+
Die Nadele (The Cons)
+
+
Die nadele van hierdie metode is dat gedeelde toegang oor die algemeen moeiliker is om op te stel en vanaf verskeie liggings te bereik as basiese netwerktoegang.
+As jy van jou skootrekenaar wil push wanneer jy by die huis is, moet jy die afgeleë skyf aanheg (mount), wat moeilik en stadig kan wees in vergelyking met netwerkgebaseerde toegang.
+
+
+
Dit is belangrik om te vermeld dat dit nie noodwendig die vinnigste opsie is as jy een of ander gedeelde aankoppeling (shared mount) gebruik nie.
+'n Plaaslike bewaarplek is slegs vinnig as jy vinnige toegang tot die data het.
+'n Bewaarplek op NFS is dikwels stadiger as die bewaarplek oor SSH op dieselfde bediener, wat Git in staat stel om vanaf plaaslike skywe op elke stelsel te loop.
+
+
+
Ten slotte beskerm hierdie protokol nie die bewaarplek teen perke skade nie.
+Elke gebruiker het volle doptoegang (shell access) tot die “remote” gids, en niks verhoed hulle om interne Git-lêers te verander of te verwyder en die bewaarplek te korrumpeer nie.
+
+
+
+
Die HTTP-protokolle (The HTTP Protocols)
+
+
Git kan oor HTTP kommunikeer met twee verskillende modusse.
+Voor Git 1.6.6 was daar net een manier waarop dit dit kon doen, wat baie eenvoudig en oor die algemeen leesalleen (read-only) was.
+In weergawe 1.6.6 is 'n nuwe, slimmar protokol bekendgestel wat behels dat Git data-oordrag intelligent kan onderhandel op 'n manier soortgelyk aan hoe dit oor SSH doen.
+In die laaste paar jaar het hierdie nuwe HTTP-protokolle baie gewild geword aangesien dit eenvoudiger vir die gebruiker is en slim is oor hoe dit kommunikeer.
+Na die nuwe weergawe word dikwels verwys as die Slim HTTP-protokol (Smart HTTP) en die ouer manier as Dom HTTP (Dumb HTTP).
+Ons sal eers die nuwere Smart HTTP-protokol dek.
+
+
+
Smart HTTP
+
+
+Smart HTTP werk baie soortgelyk aan die SSH- of Git-protokolle, maar loop oor standaard HTTPS-poorte en kan verskeie HTTP-verifikasiemeganismes gebruik, wat beteken dat dit dikwels makliker vir die gebruiker is as iets soos SSH, aangesien jy dinge soos gebruikersnaam-/wagwoordverifikasie kan gebruik in plaas daarvan om SSH-sleutels op te stel.
+
+
+
Dit het waarskynlik nou die gewildste manier geword om Git te gebruik, aangesien dit opgestel kan word om beide anoniem te bedien soos die git:// protokol, en kan ook oor gepush word met verifikasie en enkripsie soos die SSH-protokol.
+In plaas daarvan om verskillende URL’e vir hierdie dinge te moet opstel, kan jy nou 'n enkele URL vir beide gebruik.
+As jy probeer push en die bewaarplek verifikasie vereis (wat dit normaalweg behoort te doen), kan die bediener vir 'n gebruikersnaam en wagwoord vra.
+Dieselfde geld vir leestoegang.
+
+
+
Trouens, vir dienste soos GitHub is die URL wat jy gebruik om die bewaarplek aanlyn te bekyk (byvoorbeeld https://github.com/schacon/simplegit) dieselfde URL wat jy kan gebruik om te kloon en, as jy toegang het, oor te push.
+
+
+
+
Dumb HTTP
+
+
+As die bediener nie met 'n Git HTTP-slimdiens reageer nie, sal die Git-kliënt probeer terugval op die eenvoudiger Dom HTTP-protokol (Dumb HTTP).
+Die Dom-protokol verwag dat die kale Git-bewaarplek bedien word soos normale lêers vanaf die webbediener.
+Die skoonheid van Dumb HTTP is die eenvoud van die opstel daarvan.
+Basies is al wat jy hoef te doen om 'n kale Git-bewaarplek onder jou HTTP-dokumentwortel (document root) te plaas en 'n spesifieke post-update haak (hook) op te stel, en jy is klaar (sien }}">Git-hake (Git Hooks)).
+Op daardie oomblik kan enigiemand wat toegang het tot die webbediener waarvoor jy die bewaarplek geplaas het, ook jou bewaarplek kloon.
+Om leestoegang tot jou bewaarplek oor HTTP toe te staan, doen iets soos dit:
+
+
+
+
$ cd /var/www/htdocs/
+$ git clone --bare /path/to/git_project gitproject.git
+$ cd gitproject.git
+$ mv hooks/post-update.sample hooks/post-update
+$ chmod a+x hooks/post-update
+
+
+
+
Dis al.
+Die post-update haak wat by verstek saam met Git kom, laat die toepaslike opdrag (git update-server-info) loop om HTTP-afhaling en -kloning behoorlik te laat werk.
+Hierdie opdrag word uitgevoer wanneer jy na hierdie bewaarplek push (oor SSH miskien); dan kan ander mense kloon via iets soos:
+
+
+
+
$ git clone https://example.com/gitproject.git
+
+
+
+
In hierdie spesifieke geval gebruik ons die /var/www/htdocs pad wat algemeen is vir Apache-opstellings, maar jy kan enige statiese webbediener gebruik — sit net die kale bewaarplek in sy pad.
+Die Git-data word as basiese statiese lêers bedien (sien die }}">Git Internals hoofstuk vir besonderhede oor presies hoe dit bedien word).
+
+
+
Oor die algemeen sou jy óf kies om 'n lees-/skryf Smart HTTP-bediener te laat loop óf eenvoudig die lêers as leesalleen op die Dumb-manier toeganklik hê.
+Dit is seldsaam om 'n kombinasie van die twee dienste te laat loop.
+
+
+
+
Die Voordele (The Pros)
+
+
Ons sal konsentreer op die voordele van die Smart-weergawe van die HTTP-protokol.
+
+
+
Die eenvoud om 'n enkele URL vir alle tipes toegang te hê en dat die bediener slegs vra wanneer verifikasie nodig is, maak dinge baie maklik vir die eindgebruiker.
+Om met 'n gebruikersnaam en wagwoord te kan verifieer, is ook 'n groot voordeel bo SSH, aangesien gebruikers nie SSH-sleutels lokaal hoef te genereer en hul publieke sleutel na die bediener op te laai voordat hulle daarmee kan wisselwerking hê nie.
+Vir minder gesofistikeerde gebruikers, of gebruikers op stelsels waar SSH minder algemeen is, is dit 'n groot voordeel in bruikbaarheid.
+Dit is ook 'n baie vinnige en doeltreffende protokol, soortgelyk aan dié van SSH.
+
+
+
Jy kan ook jou bewaarplekke leesalleen oor HTTPS bedien, wat beteken jy kan die inhoudsoordrag enkripteer; of jy kan so ver gaan as om die kliënte spesifieke getekende SSL-sertifikate te laat gebruik.
+
+
+
Nog 'n oulike ding is dat HTTP en HTTPS so algemeen gebruikte protokolle is dat korporatiewe brandmure dikwels opgestel is om verkeer deur hul poorte toe te laat.
+
+
+
+
Die Nadele (The Cons)
+
+
Git oor HTTPS kan 'n bietjie moeiliker wees om op te stel in vergelyking met SSH op sommige bedieners.
+Behalwe dit is daar baie min voordeel wat ander protokolle bo Smart HTTP het vir die bediening van Git-inhoud.
+
+
+
As jy HTTP vir geverifieerde push gebruik, is die verskaffing van jou aanmeldbewyse (credentials) soms meer ingewikkeld as om sleutels oor SSH te gebruik.
+Daar is egter verskeie aanmeldbewys-kasinstrumente (credential caching tools) wat jy kan gebruik, insluitend Keychain-toegang op macOS en Credential Manager op Windows, om dit taamlik pynloos te maak.
+Lees }}">Die Stoor van Aanmeldbewyse (Credential Storage) om te sien hoe om veilige HTTP-wagwoordkassing op jou stelsel op te stel.
+
+
+
+
Die SSH-protokol (The SSH Protocol)
+
+
+'n Algemene vervoerprotokol vir Git wanneer self-gehuisves word, is oor SSH.
+Dit is omdat SSH-toegang tot bedieners reeds op die meeste plekke opgestel is — en indien nie, is dit maklik om te doen.
+SSH is ook 'n geverifieerde netwerkprotokol en, omdat dit alomteenwoordig is, is dit oor die algemeen maklik om op te stel en te gebruik.
+
+
+
Om 'n Git-bewaarplek oor SSH te kloon, kan jy 'n ssh:// URL soos dit spesifiseer:
+
+
+
+
$ git clone ssh://[user@]server/project.git
+
+
+
+
Of jy kan die korter scp-agtige sintaksis vir die SSH-protokol gebruik:
+
+
+
+
$ git clone [user@]server:project.git
+
+
+
+
In beide bogenoemde gevalle, as jy nie die opsionele gebruikersnaam spesifiseer nie, aanvaar Git die gebruiker as wie jy tans aangemeld is.
+
+
+
Die Voordele (The Pros)
+
+
Die voordele van die gebruik van SSH is baie.
+Eerstens is SSH relatief maklik om op te stel — SSH-daemons kom algemeen voor, baie netwerkadministrateurs het ervaring daarmee, en baie bedryfstelselverspreidings (OS distributions) is daarmee opgestel of het gereedskap om dit te bestuur.
+Tweedens is toegang oor SSH veiling — alle data-oordrag is geënkripteer en geverifieer.
+Laastens, soos die HTTPS-, Git- en Lokale protokolle, is SSH doeltreffend, wat die data so kompak moontlik maak voordat dit oorgedra word.
+
+
+
+
Die Nadele (The Cons)
+
+
Die negatiewe aspek van SSH is dat dit nie anonieme toegang tot jou Git-bewaarplek ondersteun nie.
+As jy SSH gebruik, moet mense SSH-toegang tot jou masjien hê, selfs in 'n leesalleen-kapasiteit, wat nie SSH bevorderlik maak vir oopbronprojekte waarvoor mense eenvoudig jou bewaarplek dalk wil kloon om dit te ondersoek nie.
+As jy dit slegs binne jou korporatiewe netwerk gebruik, is SSH dalk die enigste protokol waarmee jy te kampe het.
+As jy anonieme leesalleen-toegang tot jou projekte wil toelaat en ook SSH wil gebruik, sal jy SSH vir jou moet opstel om oor te push, maar iets anders vir ander om van af te haal.
+
+
+
+
Die Git-protokol (The Git Protocol)
+
+
+Ten slotte het ons die Git-protokol.
+Dit is 'n spesiale daemon wat saam met Git verpak word; dit luister op 'n toegewyde poort (9418) wat 'n diens soortgelyk aan die SSH-protokol lewer, maar met absoluut geen verifikasie of kriptografie nie.
+Sodat 'n bewaarplek oor die Git-protokol bedien kan word, moet jy 'n git-daemon-export-ok lêer skep — die daemon sal nie 'n bewaarplek bedien sonder daardie lêer daarin nie — maar behalwe dit is daar geen sekuriteit nie.
+Óf die Git-bewaarplek is beskikbaar vir almal om te kloon, óf dit is nie.
+Dit beteken dat daar oor die algemeen geen push oor hierdie protokol is nie.
+Jy kan push-toegang aktiveer, maar gegewe die gebrek aan verifikasie, kan enigiemand op die internet wat jou projek se URL vind, na daardie projek push.
+Dit is genoeg om te sê dat dit seldsaam is.
+
+
+
Die Voordele (The Pros)
+
+
Die Git-protokol is dikwels die vinnigste netwerkoordragprotokol wat beskikbaar is.
+As jy baie verkeer vir 'n openbare projek bedien of 'n baie groot projek bedien wat nie gebruikersverifikasie vir leestoegang vereis nie, sal jy waarskynlik 'n Git-daemon wil opstel om jou projek te bedien.
+Dit gebruik dieselfde data-oordragmeganisme as die SSH-protokol, maar sonder die enkripsie- en verifikasie-bokoste (overhead).
+
+
+
+
Die Nadele (The Cons)
+
+
As gevolg van die gebrek aan TLS of ander kriptografie, kan kloning oor git:// lei tot 'n arbitrêre kode-uitvoeringskwesbaarheid (arbitrary code execution vulnerability), en moet dit dus vermy word tensy jy weet wat jy doen.
+
+
+
+-
+
As jy git clone git://example.com/project.git uitvoer, kan 'n aanvaller wat bv. jou roeteerder (router) beheer, die bewaarplek wat jy net gekloon het, modifiseer en kwaadwillige kode daarin plaas.
+As jy dan die kode wat jy pas gekloon het kompileer/laat loop, sal jy die kwaadwillige kode uitvoer.
+Om git clone http://example.com/project.git uit te voer, moet om dieselfde rede vermy word.
+
+-
+
Om git clone https://example.com/project.git uit te voer, ly nie aan dieselfde probleem nie (tensy die aanvaller 'n TLS-sertifikaat vir example.com kan verskaf).
+Om git clone git@example.com:project.git uit te voer, ly slegs aan hierdie probleem as jy 'n verkeerde SSH-sleutel-vingerafdruk aanvaar.
+
+
+
+
+
Dit het ook geen verifikasie nie, d.w.s. enigiemand kan die bewaarplek kloon (al is dit dikwels presies wat jy wil hê).
+Dit is ook waarskynlik die moeilikste protokol om op te stel.
+Dit moet sy eie daemon laat loop, wat xinetd- of systemd-konfigurasie of iets dergelijks vereis, wat nie altyd 'n uitstappie in die park is nie.
+Dit vereis ook brandmuurtoegang tot poort 9418, wat nie 'n standaardpoort is wat korporatiewe brandmure altyd toelaat nie.
+Agter groot korporatiewe brandmure word hierdie obskure poort algemeen geblokkeer.
+
+
+
Git Daemon
+
+
+Vervolgens sal ons 'n daemon opstel wat bewaarplekke (repositories) bedien met behulp van die “Git” protokol.
+Dit is 'n algemene keuse vir vinnige, ongeverifieerde toegang (unauthenticated access) tot jou Git-data.
+Onthou dat aangesien dit nie 'n geverifieerde diens (authenticated service) is nie, is enigiets wat jy oor hierdie protokol bedien, publiek binne die netwerk daarvan.
+
+
As jy hierdie op 'n bediener (server) buite jou brandmuur (firewall) laat loop, behoort dit slegs gebruik te word vir projekte wat publiek sigbaar is vir die wêreld.
+As die bediener waarop jy dit laat loop binne jou brandmuur is, kan jy dit gebruik vir projekte waartoe 'n groot aantal mense of rekenaars (deurlopende integrasie- of bou-bedieners / continuous integration or build servers) leesalleen-toegang (read-only access) het, wanneer jy nie 'n SSH-sleutel (SSH key) vir elkeen wil byvoeg nie.
+
+
In elk geval is die Git-protokol redelik maklik om op te stel.
+Basies moet jy hierdie opdrag op 'n ge-daemoniseerde manier (daemonized manner) uitvoer:
+
+
+
$ git daemon --reuseaddr --base-path=/srv/git/ /srv/git/
+
+
+
Die --reuseaddr opsie laat die bediener toe om te herbegin sonder om te wag vir ou verbindings om uit te tel (time out), terwyl die --base-path opsie mense toelaat om projekte te kloon (clone) sonder om die hele pad (path) te spesifiseer, en die pad aan die einde vertel die Git-daemon waar om te soek vir bewaarplekke (repositories) om uit te voer (export).
+As jy 'n brandmuur (firewall) gebruik, sal jy ook 'n gaatjie daarin moet slaan by poort 9418 op die masjien waarop jy dit opstel.
+
+
Jy kan hierdie proses op 'n aantal maniere daemoniseer, afhangende van die bedryfstelsel (operating system) wat jy gebruik.
+
+
Aangesien systemd die algemeenste inisialiserings-stelsel (init system) onder moderne Linux-verspreidings (distributions) is, kan jy dit vir daardie doel gebruik.
+Plaas eenvoudig 'n lêer in /etc/systemd/system/git-daemon.service met hierdie inhoud:
+
+
+
[Unit]
+Description=Start Git Daemon
+
+[Service]
+ExecStart=/usr/bin/git daemon --reuseaddr --base-path=/srv/git/ /srv/git/
+
+Restart=always
+RestartSec=500ms
+
+StandardOutput=syslog
+StandardError=syslog
+SyslogIdentifier=git-daemon
+
+User=git
+Group=git
+
+[Install]
+WantedBy=multi-user.target
+
+
+
Jy het dalk opgemerk dat Git-daemon hier met git as beide groep (group) en gebruiker (user) begin word.
+Verander dit om by jou behoeftes te pas en maak seker dat die verskafde gebruiker op die stelsel bestaan.
+Maak ook seker dat die Git-binêre lêer (binary) wel by /usr/bin/git geleë is en verander die pad indien nodig.
+
+
Ten slotte sal jy systemctl enable git-daemon uitvoer om die diens outomaties by selflaai (boot) te begin, en jy kan die diens begin en stop met onderskeidelik systemctl start git-daemon en systemctl stop git-daemon.
+
+
Op ander stelsels wil jy dalk xinetd, 'n skrip in jou sysvinit stelsel, of iets anders gebruik — solank jy net daardie opdrag ge-daemoniseer kry en dat dit op een of ander manier dopgehou (watched) word.
+
+
Vervolgens moet jy vir Git vertel watter bewaarplekke (repositories) ongeverifieerde Git-bedienergebaseerde toegang (unauthenticated Git server-based access) mag toelaat.
+Jy kan dit in elke bewaarplek doen deur 'n lêer genaamd git-daemon-export-ok te skep.
+
+
+
$ cd /path/to/project.git
+$ touch git-daemon-export-ok
+
+
+
Die teenwoordigheid van daardie lêer vertel vir Git dat dit reg is om hierdie projek sonder verifikasie (authentication) te bedien.
+
Git op 'n Bediener kry (Getting Git on a Server)
+
+
Ons gaan nou die opstel van 'n Git-diens (Git service) op jou eie bediener (server) behandel wat hierdie protokolle gebruik.
+
+
+
+|
+ Note
+ |
+
+
+ Ons sal hier die opdragte en stappe wys om 'n eenvoudige, vereenvoudigde installasie op 'n Linux-gebaseerde bediener op te stel, alhoewel dit ook moontlik is om hierdie dienste op 'n macOS of Windows bediener te laat loop.
+Die werklike opstel van 'n produksie-bediener binne jou infrastruktuur sal byna sekerlik verskil in die manier waarop die sekuriteitsmaatreëls (security measures) ingerig is of die spesifieke bedryfstelsel-hulpmiddels (operating system tools) wat gebruik word, maar hopelik sal dit jou 'n idee gee van wat alles behels word.
+ |
+
+
+
+
Om aanvanklik 'n Git-bediener op te stel, moet jy 'n bestaande bewaarplek (repository) na 'n nuwe kale bewaarplek (bare repository) uitvoer — 'n bewaarplek wat geen werkgids (working directory) bevat nie.
+Dit is oor die algemeen maklik om te doen.
+Om jou bewaarplek te kloon (clone) om sodoende 'n nuwe kale bewaarplek te skep, voer jy die clone opdrag met die --bare opsie uit.
+Die konvensie is om gidse (directories) wat kale bewaarplekke bevat, met .git te laat eindig, soos hier:
+
+
+
$ git clone --bare my_project my_project.git
+Cloning into bare repository 'my_project.git'...
+done.
+
+
+
Jy behoort nou 'n kopie van die Git-gids data in jou my_project.git gids te hê.
+
+
Dit is min of meer gelykstaande aan:
+
+
+
$ cp -Rf my_project/.git my_project.git
+
+
+
Daar is 'n paar klein verskille in die konfigurasielêer (configuration file), maar dit kom op dieselfde neer.
+Dit neem die Git-bewaarplek self, sonder 'n werkgids (working directory), en skep 'n gids spesifiek net daarvoor.
+
+
Die kale bewaarplek op 'n bediener plaas (Putting the Bare Repository on a Server)
+
+
Noudat jy 'n kale kopie (bare copy) van jou bewaarplek het, is al wat jy hoef te doen om dit op 'n bediener te plaas en jou protokolle op te stel.
+Kom ons neem aan jy het 'n bediener opgestel genaamd git.example.com, waarop jy SSH-toegang het, en waar jy al jou Git-bewaarplekke onder die /srv/git gids wil stoor.
+Aannemende dat /srv/git op daardie bediener bestaan, kan jy hierdie nuwe bewaarplek beskikbaar stel deur jou kale bewaarplek daarnatoe te kopieer:
+
+
+
+
$ scp -r my_project.git user@git.example.com:/srv/git
+
+
+
+
Vanaf daardie oomblik kan ander gebruikers wat SSH-toegang tot dieselfde bediener het en leestoegang (read access) tot die /srv/git gids het, jou bewaarplek kloon (clone) deur dit uit te voer:
+
+
+
+
$ git clone user@git.example.com:/srv/git/my_project.git
+
+
+
+
As 'n gebruiker met SSH op 'n bediener aanteken (logs in) en skryftoegang (write access) het tot die /srv/git/my_project.git gids, dan het hulle outomaties ook push-toegang.
+
+
+
Git sal outomaties die korrekte groep-skryfregte (group write permissions) aan 'n bewaarplek toeken as jy die git init opdrag met die --shared opsie uitvoer.
+Let daarop dat die uitvoering van hierdie opdrag geen vasleggings (commits), verwysings (refs), ens. sal uitvee nie.
+
+
+
+
$ ssh user@git.example.com
+$ cd /opt/git/my_project.git
+$ git init --bare --shared
+
+
+
+
Jy sien hoe eenvoudig dit is om 'n Git-bewaarplek te neem, 'n kale weergawe (bare version) te skep, en dit op 'n bediener te plaas waartoe jy en jou medewerkers SSH-toegang het.
+Nou is julle gereed om aan dieselfde projek saam te werk.
+
+
+
Dit is belangrik om daarop te let dat dit letterlik al is wat jy hoef te doen om 'n bruikbare Git-bediener te laat loop waartoe verskeie mense toegang het: skep bloot 'n paar rekeninge (accounts) met SSH-toegang op 'n bediener, en plaas 'n kale bewaarplek êrens waar al daardie gebruikers lees- en skryftoegang het.
+Jy is gereed — jy het niks anders nodig nie.
+
+
+
In die volgende afdelings sal jy sien hoe jy meer komplekse opstellings kan maak.
+Hierdie bespreking sal dek hoe om nie gebruikersrekeninge vir elke gebruiker te hoef skep nie, asook publieke leestoegang tot bewaarplekke, grafiese webkoppelvlakke (web interfaces), en meer.
+Maar hou in gedagte dat om op 'n privaat projek met mense saam te werk, al wat jy nodig het, 'n SSH-bediener en 'n kale bewaarplek is.
+
+
+
Klein Opstellings (Small Setups)
+
+
As jy deel is van 'n klein groepie of net met Git in jou organisasie begin en slegs 'n paar ontwikkelaars het, kan dinge vir jou eenvoudig wees.
+Een van die mees ingewikkelde aspekte van die opstel van 'n Git-bediener is die bestuur van gebruikers.
+As jy sommige bewaarplekke as leesalleen (read-only) vir sekere gebruikers wil hê, en lees/skryf (read/write) vir ander, kan toegang en regte (permissions) 'n bietjie moeiliker wees om te reël.
+
+
+
SSH-toegang (SSH Access)
+
+
+As jy reeds 'n bediener het waartoe al jou ontwikkelaars SSH-toegang het, is dit oor die algemeen die maklikste om jou eerste bewaarplek (repository) daar op te stel, aangesien jy byna niks hoef te doen nie (soos in die vorige afdeling beskryf).
+As jy meer komplekse toegangsbeheer (access control) op jou bewaarplekke wil hê, kan jy dit opstel met die normale lêerstelsel-regte (file system permissions) van die bedryfstelsel (operating system) wat op jou bediener loop.
+
+
+
As jy jou bewaarplekke op 'n bediener wil plaas wat nie rekeninge (accounts) het vir almal in jou span aan wie jy skryftoegang (write access) wil gee nie, sal jy SSH-toegang vir hulle moet opstel.
+Ons aanvaar dat jy 'n bediener het waarmee jy dit kan doen, dat jy reeds 'n SSH-bediener geïnstalleer het, en dat dit die manier is waarop jy toegang tot die bediener verkry.
+
+
+
Daar is 'n paar maniere waarop jy aan almal in jou span toegang kan gee.
+Die eerste is om vir almal rekeninge (accounts) te skep, wat eenvoudig is maar redelik tydrowend kan wees.
+Jy wil waarskynlik nie adduser uitvoer en tydelike wagwoorde vir elke gebruiker instel nie.
+
+
+
Die tweede metode is om 'n enkele 'git'-gebruiker op die masjien te skep, elke gebruiker wat skryftoegang moet kry te vra om vir jou 'n publieke SSH-sleutel (SSH public key) te stuur, en daardie sleutel by die ~/.ssh/authorized_keys lêer van daardie nuwe gebruiker by te voeg.
+Van daardie oomblik af sal almal toegang tot die masjien hê via die 'git'-gebruiker.
+Dit beïnvloed die vasleggingsdata (commit data) op geen manier nie — die SSH-gebruiker waarmee jy aanteken, sal nie die vasleggings wat jy gemaak het, beïnvloed nie.
+
+
+
'n Ander manier om dit te doen, is om jou SSH-bediener te laat verifieer (authenticate) deur middel van 'n LDAP-bediener of 'n ander gesentraliseerde verifikasiebron wat miskien reeds vir jou opgestel is.
+Solank elke gebruiker doptoegang (shell access) op die masjien kan kry, behoort enige SSH-verifikasiemeganisme waaraan jy kan dink, te werk.
+
+
+
GitLab
+
+
+GitWeb is egter redelik simplisties.
+As jy op soek is na 'n moderne, ten volle toegeruste Git-bediener (Git server), is daar verskeie oopbron-oplossings (open source solutions) daar buite wat jy eerder kan installeer.
+Aangesien GitLab een van die gewildstes is, sal ons as voorbeeld dek hoe om dit te installeer en te gebruik.
+Dit is moeiliker as die GitWeb-opsie en sal meer instandhouding vereis, maar dit is 'n ten volle toegeruste opsie.
+
+
Installasie (Installation)
+
+
GitLab is 'n databasis-gerugsteunde webtoepassing (database-backed web application), so die installering daarvan is meer ingewikkeld as by sommige ander Git-bedieners.
+Gelukkig is hierdie proses goed gedokumenteer en ondersteun.
+GitLab beveel sterk aan om GitLab op jou bediener (server) te installeer via die amptelike Omnibus GitLab-pakket.
+
+
+
Die ander installasie-opsies is:
+
+
+
+-
+
GitLab Helm-grafiek (GitLab Helm chart), vir gebruik met Kubernetes.
+
+-
+
Gedoekeriseerde (Dockerized) GitLab-pakkette vir gebruik met Docker.
+
+-
+
Vanaf die bronlêers (source files).
+
+-
+
Wolkverskaffers (Cloud providers) soos AWS, Google Cloud Platform, Azure, OpenShift en Digital Ocean.
+
+
+
+
+
+
Administrasie (Administration)
+
+
GitLab se administrasiekoppelvlak (administration interface) word oor die web verkry.
+Wys eenvoudig jou blaaier (browser) na die gasheernaam (hostname) of IP-adres waar GitLab geïnstalleer is, en meld aan as die root gebruiker.
+Die wagwoord sal afhang van jou installasietipe, maar by verstek (by default) genereer Omnibus GitLab outomaties 'n wagwoord daarvoor en stoor dit in /etc/gitlab/initial_root_password vir ten minste 24 uur.
+Volg die dokumentasie vir meer besonderhede.
+Nadat jy aangemeld het, klik op die “Admin area” ikoon in die kieslys regs bo.
+
+
+
+
Gebruikers (Users)
+
+
Almal wat jou GitLab-bediener gebruik, moet 'n gebruikersrekening (user account) hê.
+Gebruikersrekeninge is redelik eenvoudig; dit bevat hoofsaaklik persoonlike inligting gekoppel aan aantekendata (login data).
+Elke gebruikersrekening het 'n naampas (namespace), wat 'n logiese groepering is van projekte wat aan daardie gebruiker behoort.
+As die gebruiker jane 'n projek genaamd project gehad het, sou daardie projek se URL http://server/jane/project wees.
+
+
+
+
}}" alt="The GitLab user administration screen">
+
+
Figure 51. Die GitLab gebruikersadministrasie-skerm
+
+
+
Jy kan 'n gebruikersrekening op twee maniere verwyder:
+Deur 'n gebruiker te “blokkeer” (Blocking), word verhoed dat hulle op die GitLab-instansie aanmeld, maar al die data onder daardie gebruiker se naampas sal behoue bly, en vasleggings (commits) wat met daardie gebruiker se e-posadres onderteken is, sal steeds terugskakel na hul profiel.
+
+
+
Aan die ander kant, deur 'n gebruiker te “vernietig” (Destroying), word hulle heeltemal van die databasis en lêerstelsel verwyder.
+Alle projekte en data in hul naampas (namespace) word verwyder, en enige groepe wat hulle besit sal ook verwyder word.
+Dit is natuurlik 'n baie meer permanente en vernietigende aksie, en jy sal dit selde nodig hê.
+
+
+
+
Groepe (Groups)
+
+
'n GitLab-groep is 'n versameling projekte, tesame met data oor hoe gebruikers toegang tot daardie projekte kan verkry.
+Elke groep het 'n projek-naampas (die selfde manier as wat gebruikers dit het), so as die groep training 'n projek genaamd materials het, sou die URL http://server/training/materials wees.
+
+
+
+
}}" alt="The GitLab group administration screen">
+
+
Figure 52. Die GitLab groepsadministrasie-skerm
+
+
+
Elke groep is geassosieer met 'n aantal gebruikers, en elkeen het 'n sekere vlak van regte (permissions) vir die groep se projekte en die groep self.
+Dit wissel van “Gas” (Guest - slegs kwessies en klets) tot “Eienaar” (Owner - volle beheer oor die groep, sy lede en sy projekte).
+Die tipe regte is te veel om hier te lys, maar GitLab het 'n nuttige skakel op die administrasieskerm.
+
+
+
+
Projekte (Projects)
+
+
'n GitLab-projek kom min of meer ooreen met 'n enkele Git-bewaarplek (repository).
+Elke projek behoort aan 'n enkele naampas (namespace), hetsy 'n gebruiker of 'n groep.
+As die projek aan 'n gebruiker behoort, het die eienaar van die projek direkte beheer oor wie toegang tot die projek het; as die projek aan 'n groep behoort, sal die groep se gebruikervlak-regte (user-level permissions) in werking tree.
+
+
+
Elke projek het 'n sigbaarheidsvlak (visibility level), wat beheer wie leestoegang (read access) tot daardie projek se bladsye en bewaarplek het.
+As 'n projek Privaat (Private) is, moet die projek se eienaar eksplisiet toegang aan spesifieke gebruikers verleen.
+'n Interne (Internal) projek is sigbaar vir enige aangemelde gebruiker, en 'n Publieke (Public) projek is sigbaar vir enigiemand.
+Let daarop dat dit beide git fetch toegang beheer, asook toegang tot die web-UI vir daardie projek.
+
+
+
+
Hake (Hooks)
+
+
GitLab sluit ondersteuning vir hake (hooks) in, beide op 'n projek- of stelselvlak.
+Vir enige van hierdie sal die GitLab-bediener 'n HTTP POST uitvoer met beskrywende JSON wanneer relevante gebeure plaasvind.
+Dit is 'n wonderlike manier om jou Git-bewaarplekke en GitLab-instansie te koppel aan die res van jou ontwikkelingsoutomatisering, soos CI-bedieners, kletskamers (chat rooms), of uitrol-gereedskap (deployment tools).
+
+
+
+
Basiese Gebruik (Basic Usage)
+
+
Die eerste ding wat jy met GitLab sal wil doen, is om 'n nuwe projek te skep.
+Jy kan dit doen deur op die “+” ikoon in die nutsbalk (toolbar) te klik.
+Jy sal gevra word vir die projek se naam, aan watter naampas (namespace) dit behoort, en wat sy sigbaarheidsvlak (visibility level) moet wees.
+Die meeste van wat jy hier spesifiseer, is nie permanent nie, en kan later deur die instellingskoppelvlak (settings interface) verander word.
+Klik op “Create Project”, en jy is klaar.
+
+
+
Sodra die projek bestaan, sal jy dit waarskynlik met 'n plaaslike Git-bewaarplek (local Git repository) wil koppel.
+Elke projek is toeganklik oor HTTPS of SSH, wat enigeen gebruik kan word om 'n Git-remote op te stel.
+Die URL’e is sigbaar bo-aan die projek se tuisblad.
+Vir 'n bestaande plaaslike bewaarplek, sal hierdie opdrag 'n afgeleë bewaarplek (remote) genaamd gitlab na die gasheerligging skep:
+
+
+
+
$ git remote add gitlab https://server/namespace/project.git
+
+
+
+
As jy nie 'n plaaslike kopie van die bewaarplek het nie, kan jy eenvoudig dit doen:
+
+
+
+
$ git clone https://server/namespace/project.git
+
+
+
+
Die web-UI bied toegang tot verskeie nuttige aansigte (views) van die bewaarplek self.
+Elke projek se tuisblad wys onlangse aktiwiteit, en skakels (links) bo-aan sal jou na aansigte van die projek se lêers en vasleggingslog (commit log) lei.
+
+
+
Saamwerk (Working Together)
+
+
Die eenvoudigste manier om saam aan 'n GitLab-projek te werk, is deur aan elke gebruiker direkte push-toegang tot die Git-bewaarplek te gee.
+Jy kan 'n gebruiker by 'n projek voeg deur na die “Lede” (Members) afdeling van daardie projek se instellings te gaan, en die nuwe gebruiker aan 'n toegangsvlak (access level) te koppel (die verskillende toegangsvlakke word in 'n mate bespreek in }}">Groepe (Groups)).
+Deur vir 'n gebruiker 'n toegangsvlak van “Ontwikkelaar” (Developer) of hoër te gee, kan daardie gebruiker vasleggings (commits) en takke (branches) direk na die bewaarplek push.
+
+
+
'n Ander, meer ontkoppelde (decoupled) manier van samewerking is deur gebruik te maak van saamsmeltingsversoeke (merge requests).
+Hierdie kenmerk stel enige gebruiker in staat wat 'n projek kan sien, om op 'n beheerde manier daartoe by te dra.
+Gebruikers met direkte toegang kan bloot 'n tak (branch) skep, vasleggings (commits) soontoe push, en 'n saamsmeltingsversoek van hul tak af terug in master of enige ander tak oopmaak.
+Gebruikers wat nie push-regte (push permissions) vir 'n bewaarplek het nie, kan dit “vurk” (fork) om hul eie kopie te skep, vasleggings na hul kopie push, en 'n saamsmeltingsversoek vanaf hul gevurkte weergawe na die hoofprojek oopmaak.
+Hierdie model stel die eienaar in staat om ten volle in beheer te wees van wat in die bewaarplek ingaan en wanneer, terwyl dit bydraes van onbekende (untrusted) gebruikers toelaat.
+
+
+
Saamsmeltingsversoeke (merge requests) en kwessies (issues) is die hoofeenhede van langdurige besprekings in GitLab.
+Elke saamsmeltingsversoek laat 'n reël-vir-reël bespreking van die voorgestelde verandering toe (wat 'n liggewig tipe kodehersiening / code review ondersteun), sowel as 'n algemene oorhoofse besprekingsdraad (discussion thread).
+Beide kan aan gebruikers toegewys word, of in mylpale (milestones) georganiseer word.
+
+
+
Hierdie afdeling is hoofsaaklik gefokus op die Git-verwante kenmerke van GitLab, maar as 'n volwasse projek bied dit baie ander funksies om jou span te help saamwerk, soos projek-wiki’s en stelselinstandhoudingsinstrumente (system maintenance tools).
+Een voordeel van GitLab is dat, sodra die bediener opgestel is en loop, jy selde nodig sal hê om aan 'n konfigurasielêer te verander of via SSH toegang tot die bediener te verkry; die meeste administrasie en algemene gebruik kan deur die blaaier-koppelvlak (in-browser interface) gedoen word.
+
+
GitWeb
+
+
+Noudat jy basiese lees/skryf- en leesalleen-toegang (read/write and read-only access) tot jou projek het, wil jy dalk 'n eenvoudige webgebaseerde visualiseerder (web-based visualizer) opstel.
+Git word vergesel van 'n CGI-skrip genaamd GitWeb wat soms hiervoor gebruik word.
+
+
+
}}" alt="The GitWeb web-based user interface">
+
+
Figure 49. Die GitWeb webgebaseerde gebruikerskoppelvlak (web-based user interface)
+
+
As jy wil kyk hoe GitWeb vir jou projek sal lyk, kom Git met 'n opdrag om 'n tydelike instansie aan die gang te sit as jy 'n liggewig webbediener (lightweight web server) soos lighttpd of webrick op jou stelsel het.
+Op Linux-masjiene is lighttpd dikwels reeds geïnstalleer, so jy mag dalk in staat wees om dit te laat loop deur git instaweb in jou projekgids (project directory) te tik.
+As jy macOS gebruik, kom Leopard vooraf geïnstalleer met Ruby, so webrick is dalk jou beste opsie.
+Om instaweb met 'n nie-lighttpd hanteerder (handler) te begin, kan jy dit met die --httpd opsie uitvoer.
+
+
+
$ git instaweb --httpd=webrick
+[2009-02-21 10:02:21] INFO WEBrick 1.3.1
+[2009-02-21 10:02:21] INFO ruby 1.8.6 (2008-03-03) [universal-darwin9.0]
+
+
+
Dit begin 'n HTTPD-bediener op poort 1234 en begin dan outomaties 'n webblaaier (web browser) wat op daardie bladsy oopmaak.
+Dit is redelik maklik van jou kant af.
+Wanneer jy klaar is en die bediener wil afskakel, kan jy dieselfde opdrag met die --stop opsie uitvoer:
+
+
+
$ git instaweb --httpd=webrick --stop
+
+
+
As jy die webkoppelvlak (web interface) heeltyd op 'n bediener wil laat loop vir jou span of vir 'n oopbronprojek (open source project) wat jy huisves, sal jy die CGI-skrip moet opstel om deur jou normale webbediener bedien te word.
+Sommige Linux-verspreidings (distributions) het 'n gitweb pakket wat jy moontlik via apt of dnf kan installeer, so jy sal dalk eers dit wil probeer.
+Ons sal baie vinnig deur die handmatige installasie van GitWeb stap.
+Eerstens moet jy die Git-bronkode (source code) kry, waarmee GitWeb saamkom, en die pasgemaakte CGI-skrip genereer:
+
+
+
$ git clone https://git.kernel.org/pub/scm/git/git.git
+$ cd git/
+$ make GITWEB_PROJECTROOT="/srv/git" prefix=/usr gitweb
+ SUBDIR gitweb
+ SUBDIR ../
+make[2]: `GIT-VERSION-FILE' is up to date.
+ GEN gitweb.cgi
+ GEN static/gitweb.js
+$ sudo cp -Rf gitweb /var/www/
+
+
+
Let daarop dat jy die opdrag moet vertel waar om jou Git-bewaarplekke (repositories) te vind met die GITWEB_PROJECTROOT veranderlike (variable).
+Nou moet jy Apache CGI vir daardie skrip laat gebruik, waarvoor jy 'n VirtualHost kan byvoeg:
+
+
+
<VirtualHost *:80>
+ ServerName gitserver
+ DocumentRoot /var/www/gitweb
+ <Directory /var/www/gitweb>
+ Options +ExecCGI +FollowSymLinks +SymLinksIfOwnerMatch
+ AllowOverride All
+ order allow,deny
+ Allow from all
+ AddHandler cgi-script cgi
+ DirectoryIndex gitweb.cgi
+ </Directory>
+</VirtualHost>
+
+
+
Weereens, GitWeb kan bedien word met enige webbediener wat CGI of Perl ondersteun; as jy verkies om iets anders te gebruik, behoort dit nie moeilik te wees om op te stel nie.
+Op hierdie stadium behoort jy http://gitserver/ te kan besoek om jou bewaarplekke (repositories) aanlyn te bekyk.
+
Jou Publieke SSH-sleutel Genereer (Generating Your SSH Public Key)
+
+
+Baie Git-bedieners verifieer (authenticate) met behulp van publieke SSH-sleutels (SSH public keys).
+Om 'n publieke sleutel te verskaf, moet elke gebruiker in jou stelsel een genereer as hulle nie reeds een het nie.
+Hierdie proses is soortgelyk oor alle bedryfstelsels (operating systems) heen.
+Eerstens moet jy seker maak dat jy nie reeds 'n sleutel het nie.
+By verstek (by default) word 'n gebruiker se SSH-sleutels in daardie gebruiker se ~/.ssh gids (directory) gestoor.
+Jy kan maklik kyk of jy reeds 'n sleutel het deur na daardie gids te gaan en die inhoud te lys:
+
+
+
$ cd ~/.ssh
+$ ls
+authorized_keys2 id_dsa known_hosts
+config id_dsa.pub
+
+
+
Jy is op soek na 'n paar lêers met 'n naam soos id_dsa of id_rsa en 'n bypassende lêer met 'n .pub uitbreiding (extension).
+Die .pub lêer is jou publieke sleutel, en die ander lêer is die ooreenstemmende privaat sleutel (private key).
+As jy nie hierdie lêers het nie (of jy het nie eens 'n .ssh gids nie), kan jy dit skep deur 'n program genaamd ssh-keygen uit te voer, wat saam met die SSH-pakket op Linux/macOS-stelsels verskaf word en saam met Git vir Windows kom:
+
+
+
$ ssh-keygen -o
+Generating public/private rsa key pair.
+Enter file in which to save the key (/home/schacon/.ssh/id_rsa):
+Created directory '/home/schacon/.ssh'.
+Enter passphrase (empty for no passphrase):
+Enter same passphrase again:
+Your identification has been saved in /home/schacon/.ssh/id_rsa.
+Your public key has been saved in /home/schacon/.ssh/id_rsa.pub.
+The key fingerprint is:
+d0:82:24:8e:d7:f1:bb:9b:33:53:96:93:49:da:9b:e3 schacon@mylaptop.local
+
+
+
Eers bevestig dit waar jy die sleutel wil stoor (.ssh/id_rsa), en dan vra dit twee keer vir 'n wagwoordfrase (passphrase), wat jy leeg kan laat as jy nie 'n wagwoord wil intik wanneer jy die sleutel gebruik nie.
+As jy egter wel 'n wagwoord gebruik, maak seker dat jy die -o opsie byvoeg; dit stoor die privaat sleutel in 'n formaat wat meer bestand is teen brute-krag wagwoordkraking (brute-force password cracking) as wat die verstekformaat is.
+Jy kan ook die ssh-agent instrument gebruik om te verhoed dat jy elke keer die wagwoord moet intik.
+
+
Nou moet elke gebruiker wat dit doen hul publieke sleutel aan jou stuur, of aan wie ook al die Git-bediener administreer (met die veronderstelling dat jy 'n SSH-bedieneropstelling gebruik wat publieke sleutels vereis).
+Al wat hulle hoef te doen is om die inhoud van die .pub lêer te kopieer en dit te e-pos.
+Die publieke sleutels lyk min of meer so:
+
+
+
$ cat ~/.ssh/id_rsa.pub
+ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAklOUpkDHrfHY17SbrmTIpNLTGK9Tjom/BWDSU
+GPl+nafzlHDTYW7hdI4yZ5ew18JH4JW9jbhUFrviQzM7xlELEVf4h9lFX5QVkbPppSwg0cda3
+Pbv7kOdJ/MTyBlWXFCR+HAo3FXRitBqxiX1nKhXpHAZsMciLq8V6RjsNAQwdsdMFvSlVK/7XA
+t3FaoJoAsncM1Q9x5+3V0Ww68/eIFmb1zuUFljQJKprrX88XypNDvjYNby6vw/Pb0rwert/En
+mZ+AW4OZPnTPI89ZPmVMLuayrD2cE86Z/il8b+gw3r3+1nKatmIkjn2so1d01QraTlMqVSsbx
+NrRFi9wrf+M7Q== schacon@mylaptop.local
+
+
Slim HTTP (Smart HTTP)
+
+
+Ons het nou geverifieerde toegang (authenticated access) deur SSH en ongeverifieerde toegang deur git://, maar daar is ook 'n protokol wat albei tegelykertyd kan doen.
+Die opstel van Smart HTTP is basies net die aktiveer van 'n CGI-skrip wat saam met Git voorsien word, genaamd git-http-backend op die bediener (server).
+Hierdie CGI sal die pad (path) en opskrifte (headers) lees wat deur 'n git fetch of 'n git push na 'n HTTP-URL gestuur word, en vasstel of die kliënt oor HTTP kan kommunikeer (wat waar is vir enige kliënt sedert weergawe 1.6.6).
+As die CGI sien dat die kliënt slim is, sal dit slim daarmee kommunikeer; anders sal dit terugval op die dom gedrag (sodat dit agterwaarts versoenbaar / backward compatible is vir leeswerk met ouer kliënte).
+
+
Kom ons stap deur 'n baie basiese opstelling.
+Ons gaan dit opstel met Apache as die CGI-bediener.
+As jy nie Apache opgestel het nie, kan jy dit op 'n Linux-boks doen met iets soos dit:
+
+
+
$ sudo apt-get install apache2 apache2-utils
+$ a2enmod cgi alias env
+
+
+
Dit aktiveer ook die mod_cgi, mod_alias en mod_env modules, wat almal nodig behoort te wees om dit behoorlijk te laat werk.
+
+
Jy sal ook die Unix-gebruikersgroep van die /srv/git gidse na www-data moet stel sodat jou webbediener lees- en skryftoegang tot die bewaarplekke (repositories) kan hê, omdat die Apache-instansie wat die CGI-skrip laat loop (by verstek / by default) as daardie gebruiker sal loop:
+
+
+
$ chgrp -R www-data /srv/git
+
+
+
Vervolgens moet ons 'n paar dinge by die Apache-konfigurasie voeg om die git-http-backend te laat loop as die hanteerder (handler) vir enigiets wat by die /git pad van jou webbediener inkom.
+
+
+
SetEnv GIT_PROJECT_ROOT /srv/git
+SetEnv GIT_HTTP_EXPORT_ALL
+ScriptAlias /git/ /usr/lib/git-core/git-http-backend/
+
+
+
As jy die GIT_HTTP_EXPORT_ALL omgewingsveranderlike weerskryf (leave out), sal Git slegs bewaarplekke met die git-daemon-export-ok lêer daarin aan ongeverifieerde kliënte bedien, net soos die Git-daemon gedoen het.
+
+
Ten slotte sal jy vir Apache wil sê om versoeke aan git-http-backend toe te laat en skryfbewerking op een of ander manier geverifieer te maak, moontlik met 'n Auth-blok soos hierdie:
+
+
+
<Files "git-http-backend">
+ AuthType Basic
+ AuthName "Git Access"
+ AuthUserFile /srv/git/.htpasswd
+ Require expr !(%{QUERY_STRING} -strmatch '*service=git-receive-pack*' || %{REQUEST_URI} =~ m#/git-receive-pack$#)
+ Require valid-user
+</Files>
+
+
+
Dit sal van jou vereis om 'n .htpasswd lêer te skep wat die wagwoorde van al die geldige gebruikers bevat.
+Hier is 'n voorbeeld van die byvoeging van 'n “schacon” gebruiker by die lêer:
+
+
+
$ htpasswd -c /srv/git/.htpasswd schacon
+
+
+
Daar is talle maniere om te sorg dat Apache gebruikers verifieer; jy sal een van hulle moet kies en implementeer.
+Dit is net die eenvoudigste voorbeeld waaraan ons kon dink.
+Jy sal dit byna seker ook oor SSL wil opstel sodat al hierdie data geënkripteer word.
+
+
Ons wil nie too veel in die diep ent ingaan oor spesifieke Apache-konfigurasies nie, aangesien jy dalk 'n ander bediener gebruik of verskillende verifikasiebehoeftes het.
+Die idee is dat Git met 'n CGI genaamd git-http-backend kom wat, wanneer dit geroep word, al die onderhandeling sal doen om data oor HTTP te stuur en te ontvang.
+Dit implementeer nie self enige verifikasie nie, maar dit kan maklik beheer word op die vlak van die webbediener wat dit aanroep.
+Jy kan dit met prakties enige CGI-bekwame webbediener doen, so gaan met die een wat jy die beste ken.
+
Summary
+
+
You have several options to get a remote Git repository up and running so that you can collaborate with others or share your work.
+
+
Running your own server gives you a lot of control and allows you to run the server within your own firewall, but such a server generally requires a fair amount of your time to set up and maintain.
+If you place your data on a hosted server, it’s easy to set up and maintain; however, you have to be able to keep your code on someone else’s servers, and some organizations don’t allow that.
+
+
It should be fairly straightforward to determine which solution or combination of solutions is appropriate for you and your organization.
+
Bydra tot 'n projek
+
+
Noudat die rekening opgestel is, kom ons loop deur die besonderhede wat jou kan help om by te dra tot bestaande projekte.
+
+
Projekte afsplits (forking [forking])
+
+
+As jy wil bydra tot 'n bestaande projek waarby jy nie push-toegang [push access] het nie, kan jy die projek ``fork''.
+Dit hou in dat GitHub jou 'n kopie van die projek laat maak wat heeltemal joune is; dit bestaan in die naamruimte [namespace] van jou gebruiker en jy kan daarheen push.
+
+
+
+
+|
+ Note
+ |
+
+
+ Histories gesien is die term fork'' 'n bietjie negatief in konteks, in die sin dat iemand 'n oopbron-projek [open source project] in 'n ander rigting gelei het, soms 'n mededingende projek geskep het en die bydraers onderling verdeel het.
+Op GitHub is 'n fork'' bloot dieselfde projek in jou naamruimte, wat jou toelaat om veranderinge aan 'n projek openbaar te maak met die doel om op 'n meer oop manier by te dra.
+ |
+
+
+
+
+
Op hierdie manier hoef projekte nie bekommerd te wees om gebruikers as bydraers by te voeg om hulle push-toegang te gee nie.
+Mense kan 'n projek fork, daarheen push, en hulle veranderinge terugbring na die oorspronklike projek deur 'n sogenaamde Pull Request te skep, wat ons binnekort sal behandel.
+Dit open 'n gespreksdraad [discussion thread] met kodenagaan [code review], en die eienaar en die bydraer kan dan oor die verandering kommunikeer totdat die eienaar tevrede is, waarna die eienaar dit kan merge.
+
+
+
Om 'n projek te fork, besoek jy die projekbladsy en klik op die ``Fork''-knoppie regs bo op die bladsy.
+
+
+
+
}}" alt="Die ``Fork''-knoppie.">
+
+
Figure 101. Die ``Fork''-knoppie.
+
+
+
Na 'n paar sekondes sal jy na jou nuwe projekbladsy gelei word, met jou eie skryfbare kopie van die kode.
+
+
+
Die GitHub-vloei (flow [flow])
+
+
+GitHub is ontwerp rondom 'n spesifieke samewerkings-werksvloei [collaboration workflow] wat om pull requests draai.
+Hierdie werksvloei werk of jy nou saamwerk met 'n hegte span in 'n enkele gedeelde bewaarplek [repository], of 'n maatskappy wat wêreldwyd versprei is, of 'n netwerk van vreemdelinge wat bydra tot 'n projek deur middel van baie forks.
+Dit is gerig op die }}">Onderwerp-takke (Topic Branches)-werksvloei wat behandel is in }}">Git Branching.
+
+
+
Hier is hoe dit oor die algemeen werk:
+
+
+
+-
+
Fork die projek
+
+-
+
Maak 'n onderwerptak [topic branch] van master.
+
+-
+
Doen 'n aantal commits om die projek te verbeter.
+
+-
+
Push hierdie tak [branch] na jou GitHub-projek.
+
+-
+
Open 'n Pull Request op GitHub.
+
+-
+
Bespreek en bly commit soos jy wil.
+
+-
+
Die projekeienaar merge of sluit die Pull Request.
+
+-
+
Sinkroniseer die opgedateerde master terug na jou fork
+
+
+
+
+
Dit is eintlik die Integrasiebestuurder-werksvloei [Integration Manager workflow] soos dit behandel is in }}">[_integration_manager], maar in plaas daarvan om e-pos te gebruik om te kommunikeer en veranderinge na te gaan, gebruik spanne die web-gebaseerde instrumente van GitHub.
+
+
+
Kom ons bespreek 'n voorbeeld van 'n voorstel tot verandering aan 'n oopbron-projek wat op GitHub gehuisves word en wat hierdie werksvloei gebruik.
+
+
+
'n Pull Request skep
+
+
Tony is op soek na kode om op sy Arduino programmeerbare mikrobeheerder [microcontroller] te laat loop en het 'n fantastiese projek op GitHub gevind by https://github.com/schacon/blink.
+
+
+
+
}}" alt="Die projek waartoe ons wil bydra.">
+
+
Figure 102. Die projek waartoe ons wil bydra.
+
+
+
Die enigste probleem is dat die lig te vinnig flikker.
+Ons voel dit is baie beter as ons 3 sekondes wag in plaas van 1 tussen elke statusverandering.
+Kom ons verbeter dus die program en stuur dit terug na die projek as 'n veranderingsvoorstel.
+
+
+
Eerstens klik ons die 'Fork'-knoppie soos vantevore genoem om ons eie kopie van die projek te kry.
+Ons gebruikersnaam is in hierdie geval `tonychacon'', dus ons kopie van hierdie projek is by `https://github.com/tonychacon/blink en dit is waar ons dit kan verander.
+Ons kloon [clone] dit plaaslik, maak 'n onderwerptak, doen die kodeverandering en druk ten slotte die verandering weer na GitHub.
+
+
+
+
$ git clone https://github.com/tonychacon/blink (1)
+Cloning into 'blink'...
+
+$ cd blink
+$ git checkout -b slow-blink (2)
+Switched to a new branch 'slow-blink'
+
+$ sed -i '' 's/1000/3000/' blink.ino (macOS) (3)
+# If you're on a Linux system, do this instead:
+# $ sed -i 's/1000/3000/' blink.ino (3)
+
+$ git diff --word-diff (4)
+diff --git a/blink.ino b/blink.ino
+index 15b9911..a6cc5a5 100644
+--- a/blink.ino
++++ b/blink.ino
+@@ -18,7 +18,7 @@ void setup() {
+// the loop routine runs over and over again forever:
+void loop() {
+ digitalWrite(led, HIGH); // turn the LED on (HIGH is the voltage level)
+ [-delay(1000);-]{+delay(3000);+} // wait for a second
+ digitalWrite(led, LOW); // turn the LED off by making the voltage LOW
+ [-delay(1000);-]{+delay(3000);+} // wait for a second
+}
+
+$ git commit -a -m 'three seconds is better' (5)
+[slow-blink 5ca509d] three seconds is better
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+$ git push origin slow-blink (6)
+Username for 'https://github.com': tonychacon
+Password for 'https://tonychacon@github.com':
+Counting objects: 5, done.
+Delta compression using up to 8 threads.
+Compressing objects: 100% (3/3), done.
+Writing objects: 100% (3/3), 340 bytes | 0 bytes/s, done.
+Total 3 (delta 1), reused 0 (delta 0)
+To https://github.com/tonychacon/blink
+ * [new branch] slow-blink -> slow-blink
+
+
+
+
+-
+
Kloon ons fork van die projek plaaslik
+
+-
+
Maak 'n beskrywende onderwerptak
+
+-
+
Voer ons verandering aan die kode uit
+
+-
+
Kontroleer dat die verandering korrek is
+
+-
+
Commit die verandering na die onderwerptak
+
+-
+
Push ons nuwe onderwerptak terug na ons GitHub-fork
+
+
+
+
+
As ons nou teruggaan na ons fork op GitHub, kan ons sien dat GitHub opgemerk het dat ons 'n nuwe onderwerptak gepush het, en dit wys vir ons 'n groot groen knoppie om ons veranderinge te bekyk en 'n Pull Request na die oorspronklike projek oop te maak.
+
+
+
'n Alternatief sou wees om na die `Branches''-bladsy te gaan by `https://github.com/<user>/<project>/branches, jou tak op te soek en 'n Pull Request vanaf daardie plek oop te maak.
+
+
+
+
}}" alt="Pull Request-knoppie">
+
+
Figure 103. Pull Request-knoppie
+
+
+
+As ons op daardie groen knoppie klik, sal ons 'n skerm sien wat ons in staat stel om 'n titel en 'n beskrywing vir die verandering wat ons wil aanvra, in te voer.
+Dit is oor die algemeen 'n goeie idee om moeite te doen om die beste moontlike beskrywing te skryf, sodat die eienaar van die oorspronklike projek weet waarom dit voorgestel word, dat jou verandering korrek is, en waarom dit 'n waardevolle verandering is indien dit aanvaar word.
+
+
+
Ons sien ook 'n lys van die commits in ons onderwerptak wat `voorloop'' op die `master-tak (in hierdie geval, net hierdie een), en 'n eenvormige verskil [unified diff] van al die veranderinge wat gemaak sal word as hierdie tak deur die projekeienaar gemerge sou word.
+
+
+
+
}}" alt="Pull Request-skepping">
+
+
Figure 104. Pull Request-skeppingsbladsy
+
+
+
As jy op die 'Create pull request'-knoppie op hierdie bladsy druk, sal die eienaar van die projek waarvandaan jy geforkit het 'n boodskap kry dat iemand 'n verandering voorstel, en dit sal wys na 'n bladsy waar al hierdie inligting vermeld word.
+
+
+
+
+|
+ Note
+ |
+
+
+ Alhoewel Pull Requests gewoonlik gebruik word vir openbare projekte soos hierdie een, waar die bydraer 'n volledige verandering gereed het, word dit ook dikwels in interne projekte gebruik aan die begin van die ontwikkelsiklus.
+Aangesien jy kan bly push na die onderwerptak selfs nadat die Pull Request oopgemaak is, word dit dikwels vroeg oopgemaak en gebruik as 'n manier om aan werk te itereer as 'n span binne 'n konteks, in plaas daarvan om heeltemal aan die einde van die proses oopgemaak te word.
+ |
+
+
+
+
+
+
Iterasies op 'n Pull Request
+
+
Op hierdie punt kan die projekeienaar na die voorgestelde verandering kyk en dit merge, verwerp of daarop reageer.
+Kom ons maak of die idee hom aanspreek, maar hy wil hê die lig moet 'n bietjie langer af as aan wees.
+
+
+
Waar hierdie bespreking via e-pos sou kon plaasvind in die werksvloeie wat ons in }}">Distributed Git gewys het, vind dit by GitHub aanlyn [online] plaas.
+Die projekeienaar kan die eenvormige verskil bekyk en 'n kommentaar los deur op een of meer reëls te klik.
+
+
+
+
}}" alt="PR reëlkommentaar">
+
+
Figure 105. Kommentaar lewer op 'n spesifieke kodereël in 'n Pull Request
+
+
+
Sodra die onderhouer [maintainer] hierdie kommentaar gemaak het, sal die persoon wat die Pull Request oopgemaak het (en enigiemand anders wat hierdie bewaarplek volg) 'n boodskap ontvang.
+Ons sal binnekort behandel hoe hierdie aangepas kan word, maar as hy e-poskennisgewings [email notifications] aan het, sou Tony 'n e-pos soos hierdie kry:
+
+
+
+
}}" alt="E-poskennisgewing">
+
+
Figure 106. Kommentaar gestuur as e-poskennisgewing
+
+
+
Dit is vir almal toegelaat om algemene kommentaar op die Pull Request te maak.
+In }}">Pull Request-besprekingsbladsy kan ons 'n voorbeeld sien van die projekeienaar wat sowel 'n kodereël kommentarieer as daarna 'n algemene kommentaar in die besprekingsgedeelte los.
+Jy kan sien dat die kode-kommentare ook by die gesprek gevoeg word.
+
+
+
+
}}" alt="PR-besprekingsbladsy">
+
+
Figure 107. Pull Request-besprekingsbladsy
+
+
+
Nou kan die bydraer sien wat hy moet doen om sy verandering aanvaar te kry.
+Gelukkig is dit ook baie maklik om te doen.
+Waar jy by e-pos jou reeks patches [patch series] moet hersaamstel en dit weer na die poslys [mailing list] moet indien, hoef jy met GitHub bloot weer na die onderwerptak te commit en te push.
+In }}">Pull Request finaal is te sien dat die ou kode-kommentaar in die bygewerkte Pull Request ingevou is, aangesien dit gemaak is op kode wat sedertdien verander is.
+
+
+
Die byvoeg van commits by 'n bestaande Pull Request veroorsaak geen kennisgewing nie, so sodra Tony sy regstellings gepush het, besluit hy om 'n kommentaar te los om die projekeienaar in te lig dat hy die gevraagde verandering gemaak het.
+
+
+
+
}}" alt="PR finaal">
+
+
Figure 108. Pull Request finaal
+
+
+
'n Interessante ding om op te let, is dat wanneer jy die Files Changed''-oortjie [tab] op hierdie Pull Request klik, jy die eenvormige'' [unified] verskil kry — daarmee word bedoel die uiteindelike opgehoopte verskil wat na jou hooftak ingevoer sal word as hierdie onderwerptak gemerge sou word.
+In git diff-terminologie wys dit eintlik outomaties git diff master…<branch> vir die tak waarop hierdie Pull Request gebaseer is.
+Sien }}">Bepaling van Wat Ingestel Is (Determining What Is Introduced) vir meer inligting oor hierdie tipe verskil.
+
+
+
Die ander ding wat jy sal sien, is dat GitHub kontroleer of die Pull Request goed sal merge, en 'n knoppie bied om die merge namens jou op die bediener [server] te doen.
+Hierdie knoppie sien jy net as jy skryfregte op die bewaarplek het en 'n triviale merge moontlik is.
+As jy die knoppie klik, sal GitHub 'n ``non-fast-forward''-merge uitvoer, wat beteken dat selfs al sou die merge 'n fast-forward kon wees, dit steeds 'n merge-commit skep.
+
+
+
As jy dit eerder verkies, kan jy die tak eenvoudig pull en dit plaaslik merge.
+As jy hierdie tak in die master-tak merge en dit na GitHub push, word die Pull Request outomaties gesluit.
+
+
+
Dit is die eenvoudige werksvloei wat die meeste GitHub-projekte gebruik.
+Onderwerptakke word geskep, Pull Requests word daarop oopgemaak, 'n bespreking volg, moontlik word meer werk op die tak gedoen, en uiteindelik word die versoek gesluit of gemerge.
+
+
+
+
+|
+ Note
+ |
+
+ Nie net forks nie
+
+ Dit is belangrik om op te let dat jy ook 'n Pull Request tussen twee takke in dieselfde bewaarplek kan oopmaak.
+As jy met iemand saamwerk aan 'n funksie [feature] en julle het albei skryfregte op die projek, kan jy 'n onderwerptak na die bewaarplek push en 'n Pull Request na die master-tak van dieselfde projek oopmaak om die kodenagaan- en besprekingsproses te begin.
+Fork is nie nodig nie.
+ |
+
+
+
+
+
+
Pull Requests vir gevorderdes
+
+
Noudat ons die grondbeginsels van bydra tot 'n projek op GitHub behandel het, kom ons wys 'n paar interessante wenke en truuks met betrekking tot Pull Requests sodat jy nog effektiewer kan wees in die gebruik daarvan.
+
+
+
Pull Requests as pleisters (patches [patches])
+
+
Dit is belangrik om te verstaan dat baie projekte Pull Requests nie regtig sien as stapels perfekte patches wat altyd netjies agtermekaar toegepas sal kan word nie, soos die meeste poslys-gebaseerde projekte die reeks bygedraagde patches sien.
+Die meeste GitHub-projekte sien Pull Request-takke as iteratiewe gesprekke rondom 'n voorgestelde verandering, wat uitloop op 'n eenvormige verskil wat met 'n merge toegepas word.
+
+
+
Dit is 'n belangrike onderskeid, want die verandering word oor die algemeen voorgestel voordat die kode as perfek beskou word, wat skaarser is by die reeks patch-bydraes op poslyste.
+Dit maak 'n vroeë gesprek met die onderhouers moontlik, sodat om 'n goeie oplossing te vind meer 'n poging van die hele gemeenskap word.
+As kode voorgestel word met 'n Pull Request en die onderhouers of die gemeenskap 'n verandering voorstel, word die reeks patches nie hersaamgestel nie; in plaas daarvan word die verskil as 'n nuwe commit op die tak gepush, terwyl die gesprek voortgaan met behoud van die konteks van die vorige werk.
+
+
+
Byvoorbeeld, as jy na }}">Pull Request finaal terugkyk, sal jy sien dat die bydraer sy commit nie gerebase het en 'n ander Pull Request gestuur het nie.
+In plaas daarvan is nuwe commits bygevoeg en na die bestaande tak gepush.
+Op hierdie manier kan jy in die toekoms na hierdie Pull Request teruggaan en al die konteks terugvind waarop besluite geneem is.
+Die ``Merge''-knoppie op die webwerf te druk skep opsetlik 'n merge-commit wat na die Pull Request verwys, sodat dit maklik is om terug te gaan en die oorspronklike gesprek te ondersoek indien nodig.
+
+
+
+
Byhou met die upstream
+
+
As jou Pull Request verouder raak of om 'n ander rede nie skoon merge nie, sal jy dit wil regmaak sodat die onderhouer dit maklik kan merge.
+GitHub sal dit vir jou kontroleer en jou onderaan elke Pull Request laat weet of die merge triviaal is of nie.
+
+
+
+
}}" alt="PR-merge misluk">
+
+
Figure 109. Pull Request sal nie netjies merge nie
+
+
+
+
Jy het twee voor-die-hand-liggende opsies om dit te doen.
+Jy kan jou tak rebase op waar die teiken-tak [target branch] is (gewoonlik die master-tak van die bewaarplek wat jy geforkit het), of jy kan die teiken-tak in jou eie tak merge.
+
+
+
Die meeste ontwikkelaars op GitHub sal laasgenoemde doen, om dieselfde redes wat ons in die vorige paragraaf behandel het.
+Waaroor dit gaan, is die geskiedenis en die laaste merge; rebase gee jou dus nie veel meer as 'n effens skoner geskiedenis nie, en is aan die ander kant baie moeiliker en foutgevoelig.
+
+
+
As jy die teiken-tak wil merge om jou Pull Request merge-baar te maak, moet jy die oorspronklike bewaarplek as 'n nuwe afgeleë verwysing [remote] byvoeg, daarvan fetch, die hooftak van daardie bewaarplek in jou onderwerptak merge, die probleme oplos as daar enige is, en daarna jou onderwerptak weer na dieselfde tak push as waar jy die Pull Request op oopgemaak het.
+
+
+
As voorbeeld, kom ons neem aan dat in die ``tonychacon''-voorbeeld wat ons vantevore gebruik het, die oorspronklike outeur 'n verandering gemaak het wat 'n konflik in die Pull Request veroorsaak.
+Kom ons loop deur die stappe.
+
+
+
+
$ git remote add upstream https://github.com/schacon/blink (1)
+
+$ git fetch upstream (2)
+remote: Counting objects: 3, done.
+remote: Compressing objects: 100% (3/3), done.
+Unpacking objects: 100% (3/3), done.
+remote: Total 3 (delta 0), reused 0 (delta 0)
+From https://github.com/schacon/blink
+ * [new branch] master -> upstream/master
+
+$ git merge upstream/master (3)
+Auto-merging blink.ino
+CONFLICT (content): Merge conflict in blink.ino
+Automatic merge failed; fix conflicts and then commit the result.
+
+$ vim blink.ino (4)
+$ git add blink.ino
+$ git commit
+[slow-blink 3c8d735] Merge remote-tracking branch 'upstream/master' \
+ into slower-blink
+
+$ git push origin slow-blink (5)
+Counting objects: 6, done.
+Delta compression using up to 8 threads.
+Compressing objects: 100% (6/6), done.
+Writing objects: 100% (6/6), 682 bytes | 0 bytes/s, done.
+Total 6 (delta 2), reused 0 (delta 0)
+To https://github.com/tonychacon/blink
+ ef4725c..3c8d735 slower-blink -> slow-blink
+
+
+
+
+-
+
Voeg die oorspronklike bewaarplek as afgeleë verwysing by met die naam ``upstream''
+
+-
+
Fetch die nuutste werk vanaf daardie afgeleë verwysing
+
+-
+
Merge die hooftak in jou onderwerptak
+
+-
+
Los die konflik op wat voorgekom het
+
+-
+
Push na dieselfde onderwerptak
+
+
+
+
+
Sodra jy dit gedoen het, sal die Pull Request outomaties opgedateer word en weer kontroleer word of dit skoon merge.
+
+
+
+
}}" alt="PR reggemaak">
+
+
Figure 110. Pull Request merge goed
+
+
+
Een van die wonderlike dinge van Git is dat jy dit voortdurend kan bly doen.
+As jy 'n baie langlopende projek het, kan jy eenvoudig keer op keer die teiken-tak merge, en hoef jy net die konflikte op te los wat ontstaan het sedert die vorige keer dat jy gemerge het, wat die proses baie hanteerbaar maak.
+
+
+
As jy regtig die tak wil rebase om dit op te ruim, kan jy dit gerus doen, maar dit word sterk aangeraai om nie te forseer-push [force push] na die tak waarop reeds 'n Pull Request oopgemaak is nie.
+As ander mense dit gepull het en daarop begin voortwerk het, sal jy met al die probleme te doen kry wat genoem is in }}">Die Gevare van Rebasing (The Perils of Rebasing).
+In plaas daarvan push jy die gerebasede tak na 'n nuwe tak op GitHub en maak 'n splinternuwe Pull Request oop waarin jy na die ou een verwys, en sluit daarna die oorspronklike versoek.
+
+
+
+
Verwysings
+
+
Jou volgende vraag mag wees ``Hoe verwys ek na die ou Pull Request?''
+Daar blyk baie, baie maniere te wees waarop jy na ander dinge kan verwys, so ongeveer oral waar jy op GitHub kan skryf.
+
+
+
Kom ons begin met hoe om na 'n ander Pull Request of Issue te verwys.
+Alle Pull Requests en Issues het 'n nommer toegeken gekry, en hierdie is uniek binne die projek.
+Byvoorbeeld, jy kan nie Pull Request 3 en Issue #3 hê nie.
+As jy na enige Pull Request of Issue vanuit 'n ander wil verwys, kan jy eenvoudig gebruikersnaam#<num> as jy verwys na 'n Issue of Pull Request in 'n fork of bewaarplek waarin jy is, of gebruikersnaam/repo#<num> om te verwys na iets in 'n ander bewaarplek.
+
+
+
Kom ons kyk na 'n voorbeeld.
+Stel ons het die tak in die vorige voorbeeld gerebase, 'n nuwe pull request daarvoor geskep, en nou wil ons verwys na die ou pull request vanuit die nuwe een.
+Ons wil ook verwys na 'n issue in die fork van die bewaarplek in 'n heel ander projek.
+Ons maak die beskrywing soos in }}">Verwysings in 'n Pull Request..
+
+
+
+
}}" alt="PR-verwysings">
+
+
Figure 111. Verwysings in 'n Pull Request.
+
+
+
+
+
}}" alt="PR-verwysings vertoon">
+
+
Figure 112. Verwysings vertoon in 'n Pull Request.
+
+
+
Let daarop dat die volledige GitHub-URL wat ons ingesit het, verkort is tot net die nodige inligting.
+
+
+
As Tony nou die oorspronklike Pull Request sluit, sien ons dit omdat ons dit in die nuwe een vermeld het — GitHub het outomaties 'n terugverwysingsgebeurtenis [backlink event] in die tydlyn van die Pull Request geskep.
+Dit beteken dat enigiemand wat hierdie Pull Request besoek en sien dat dit gesluit is, maklik kan terugskakel na die een wat dit oorvleuel/vervang.
+Die skakel sal lyk soos in }}">Verwysing vertoon in 'n Pull Request..
+
+
+
+
}}" alt="PR gesluit">
+
+
Figure 113. Verwysing vertoon in 'n Pull Request.
+
+
+
Benewens issue-nommers, kan jy ook na 'n spesifieke commit verwys deur middel van die SHA-1.
+Jy moet 'n volledige 40-karakter SHA-1 vermeld, maar as GitHub dit in 'n kommentaar sien, sal dit direk na die commit skakel.
+Weereens kan jy na commits in forks of ander bewaarplekke verwys op dieselfde manier as wat jy met issues gedoen het.
+
+
+
+
Markdown met 'n GitHub-geurtjie (GitHub Flavored Markdown [GitHub Flavored Markdown])
+
+
Skakel na ander Issues is maar die begin van die interessante dinge wat jy met byna enige teksveld op GitHub kan doen.
+In Issue- en Pull Request-beskrywings, kommentare, kode-kommentare en ander plekke kan jy die sogenaamde ``GitHub Flavored Markdown'' gebruik.
+Markdown is soos om in gewone teks te skryf, maar met meer funksionaliteit wanneer dit vertoon word.
+
+
+
+
+
}}" alt="Voorbeeld Markdown">
+
+
Figure 114. 'n Voorbeeld van Markdown soos geskryf en vertoon.
+
+
+
Die geurtjie wat GitHub aan Markdown byvoeg, is meer as wat jy met standaard Markdown kry.
+Hierdie geurtjies kan almal baie nuttig wees as jy bruikbare Pull Request- of Issue-kommentaar of -beskrywings skep.
+
+
+
Taaklyste (task lists [task lists])
+
+
Die eerste werklik bruikbare GitHub-spesifieke Markdown-opsie, veral vir gebruik in Pull Requests, is die taaklys.
+'n Taaklys is 'n lys merkblokkies [checkboxes] van dinge wat jy gedoen wil hê.
+Om dit in 'n Issue of Pull Request neer te sit, wys gewoonlik die dinge wat jy gedoen wil hê voordat jy die onderwerp as gesluit beskou.
+
+
+
Jy kan op hierdie manier 'n taaklys skep:
+
+
+
+
- [X] Write the code
+- [ ] Write all the tests
+- [ ] Document the code
+
+
+
+
+
+
}}" alt="voorbeeld taaklys">
+
+
Figure 115. Taaklyste soos vertoon in 'n Markdown-kommentaar.
+
+
+
Dit word dikwels in 'n Pull Request gebruik om aan te dui wat jy alles op die tak gedoen wil sien voordat die Pull Request gereed is om te merge.
+Die werklik gawe ding hiervan is dat jy eenvoudig op die merkblokkies kan klik om die kommentaar by te werk — jy hoef nie die teks van die Markdown self te verander om die take af te merk nie.
+
+
+
En daar is meer: GitHub sal na taaklyste soek in jou Issues en Pull Requests en dit as metadata op die bladsy vertoon wat hulle bevat.
+Byvoorbeeld, as jy 'n Pull Request met take het en jy kyk na die oorsigbladsy van alle Pull Requests, kan jy sien hoe ver dit gereed is. Dit help mense om Pull Requests in subtake in te deel, en ander mense om die vordering van die tak te volg.
+Jy kan 'n voorbeeld hiervan sien in }}">Opsomming van taaklyste in die Pull Request-lys..
+
+
+
+
}}" alt="Voorbeeld taaklys">
+
+
Figure 116. Opsomming van taaklyste in die Pull Request-lys.
+
+
+
Dit is uiters handig as jy vroeg 'n Pull Request oopmaak en dit gebruik om die vordering tydens die implementering van die funksie te volg.
+
+
+
+
Kodegreepies (code snippets [code snippets])
+
+
Jy kan ook kodegreepies by kommentare voeg.
+Dit is veral handig as jy iets wil voorstel wat jy sou kon probeer doen voordat jy dit werklik as 'n commit in jou tak implementeer.
+Dit word ook dikwels gebruik om 'n voorbeeld te gee van kode wat nie werk nie, of wat in hierdie Pull Request geïmplementeer sou kon word.
+
+
+
Om 'n kodegreepie by te voeg, moet jy dit met 'omgekeerde kommas' (backticks [backticks]) omsluit.
+
+
+
+
```java
+for(int i=0 ; i < 5 ; i++)
+{
+ System.out.println("i is : " + i);
+}
+```
+
+
+
+
As jy die naam van die taal byvoeg, soos ons hier met 'java' gedoen het, sal GitHub ook probeer om die sintaks te merk [syntax highlighting].
+In die bostaande voorbeeld sou dit vertoon word soos in }}">Vertoonde omsluite kodevoorbeeld..
+
+
+
+
}}" alt="Vertoonde omsluite kode">
+
+
Figure 117. Vertoonde omsluite kodevoorbeeld.
+
+
+
+
Aanhaal (quoting [quoting])
+
+
As jy op 'n klein deel van 'n lang kommentaar reageer, kan jy na keuse aanhaal uit die ander kommentaar deur die reël met die >-teken te laat begin.
+Dit is so algemeen en bruikbaar dat daar 'n sleutelbordkortpad [keyboard shortcut] daarvoor geskep is.
+As jy die teks selekteer in die kommentaar waarop jy direk wil reageer en die r-sleutel druk, word dit outomaties as aanhaling in die kommentaarruimte vir jou geplaas.
+
+
+
Die aanhalings lyk ongeveer so:
+
+
+
+
> Whether 'tis Nobler in the mind to suffer
+> The Slings and Arrows of outrageous Fortune,
+
+How big are these slings and in particular, these arrows?
+
+
+
+
+
+
}}" alt="Vertoonde aanhaling">
+
+
Figure 118. Vertoonde aanhalingsvoorbeeld.
+
+
+
+
Emoji
+
+
Laastens kan jy ook emoji in jou kommentaar gebruik.
+Dit word eintlik redelik gereeld gebruik in die kommentare wat jy by baie GitHub-issues en Pull Requests sien.
+Daar is selfs 'n emoji-hulpmiddel op GitHub.
+As jy 'n kommentaar intik en met 'n :-teken begin, sal 'n outovoltooiingshulp [autocomplete] jou kom help om te vind wat jy soek.
+
+
+
+
}}" alt="Emoji-voltooiingshulp">
+
+
Figure 119. Emoji-voltooiingshulp in aksie.
+
+
+
Emoji’s lyk soos :<naam>: iewers in jou kommentaar.
+Jy sou byvoorbeeld iets soos hierdie kon skryf:
+
+
+
+
I :eyes: that :bug: and I :cold_sweat:.
+
+:trophy: for :microscope: it.
+
+:+1: and :sparkles: on this :ship:, it's :fire::poop:!
+
+:clap::tada::panda_face:
+
+
+
+
+
+
}}" alt="Emoji">
+
+
Figure 120. Swaar emoji-kommentaar.
+
+
+
Dit voeg nie regtig veel inhoudelik by nie, maar dit gee wel 'n bietjie kleur en emosie aan 'n medium wat gewoonlik nogal moeilik emosies kan weergee.
+
+
+
+
+|
+ Note
+ |
+
+
+ Daar is deesdae nogal 'n paar webdienste wat van emoji gebruik maak. 'n Goeie spiekbrief om emoji te vind wat uitdruk wat jy wil sê, kan jy vind by:
+ |
+
+
+
+
+
+
Prente (images [images])
+
+
Streng gesproke is dit nie 'n GitHub-geurtjie van Markdown nie, maar dit is baie handig.
+Benewens die byvoeg van Markdown-prentskakels [image links] aan kommentaar, waarvoor dit moeilik kan wees om URL’s te vind en in te voeg, laat GitHub jou toe om prente te sleep-en-los [drag & drop] in teksareas om hulle in te voeg.
+
+
+
+
}}" alt="Prente sleep-en-los">
+
+
Figure 121. Sleep-en-los van prente om hulle op te laai en outomaties in te voeg.
+
+
+
As jy terugkyk na }}">Verwysings in 'n Pull Request., kan jy 'n klein ``Parsed as Markdown''-leidraad bo die teksarea sien.
+As jy hierop klik, sal dit vir jou 'n volledige spiekbrief wys van alles wat jy met Markdown op GitHub kan doen.
+
+
+
+
Hou jou openbare GitHub-bewaarplek op datum
+
+
Sodra jy 'n GitHub-bewaarplek geforkit het, bestaan jou bewaarplek (jou "fork") onafhanklik van die oorspronklike een.
+Spesifiek, as die oorspronklike bewaarplek nuwe commits het, stel GitHub jou in kennis met 'n boodskap soos hierdie:
+
+
+
+
This branch is 5 commits behind progit:master.
+
+
+
+
Maar jou GitHub-bewaarplek sal nooit outomaties deur GitHub bygewerk word nie; dit is iets wat jy self moet doen.
+Gelukkig is dit baie maklik om te doen.
+
+
+
Een moontlikheid om dit te doen vereis geen konfigurasie nie.
+Byvoorbeeld, as jy van https://github.com/progit/progit2.git geforkit het, kan jy jou master-tak soos volg op datum hou:
+
+
+
+
$ git checkout master (1)
+$ git pull https://github.com/progit/progit2.git (2)
+$ git push origin master (3)
+
+
+
+
+-
+
As jy op 'n ander tak is, keer terug na master.
+
+-
+
Fetch veranderinge vanaf https://github.com/progit/progit2.git en merge dit in master.
+
+-
+
Push jou master-tak na origin.
+
+
+
+
+
Dit werk, maar dit is 'n bietjie vervelig om elke keer die volledige fetch-URL te moet intik.
+Jy kan dit met 'n bietjie konfigurasie outomatiseer.
+
+
+
+
$ git remote add progit https://github.com/progit/progit2.git (1)
+$ git branch --set-upstream-to=progit/master master (2)
+$ git config --local remote.pushDefault origin (3)
+
+
+
+
+-
+
Voeg die bronbewaarplek by en gee dit 'n naam.
+Hier het ek die naam progit gekies
+
+-
+
Stel jou master-tak in om vanaf die progit-afgeleë verwysing te fetch.
+
+-
+
Sorg dat die standaard push-bewaarplek origin is.
+
+
+
+
+
Sodra dit gedoen is, word die werksvloei baie eenvoudiger:
+
+
+
+
$ git checkout master (1)
+$ git pull (2)
+$ git push (3)
+
+
+
+
+-
+
As jy op 'n ander tak is, keer terug na master.
+
+-
+
Fetch veranderinge vanaf progit en merge dit in master.
+
+-
+
Push jou master-tak na origin.
+
+
+
+
+
Hierdie benadering kan handig wees, maar dit is nie sonder nadele nie.
+Git sal blymoedig al hierdie werk stilweg vir jou doen, maar dit sal jou nie waarsku as jy 'n commit na master doen, van progit pull en dan na origin push nie; al hierdie handelinge is geldig met hierdie opset.
+Jy moet dus goed oplet om nooit direk na master te commit nie, aangesien daardie tak effektief aan 'n voorafgaande bewaarplek behoort.
+
+
Die Bestuur van 'n Organisasie (Managing an Organization)
+
+
+Benewens enkelgebruikerrekeninge, het GitHub wat Organisasies (Organizations) genoem word.
+Soos persoonlike rekeninge, het Organisasie-rekeninge 'n naampas (namespace) waar al hul projekte bestaan, maar baie ander dinge is anders.
+Hierdie rekeninge verteenwoordig 'n groep mense met gedeelde eienaarskap van projekte, en daar is baie gereedskap om subgroepe van daardie mense te bestuur.
+Normaalweg word hierdie rekeninge gebruik vir Oopbrongroepe (Open Source groups - soos “perl” of “rails”) of maatskappye (soos “google” of “twitter”).
+
+
Organisasie-grondbeginsels (Organization Basics)
+
+
'n Organisasie is redelik maklik om te skep; klik net op die “+” ikoon regs bo op enige GitHub-bladsy, en kies “New organization” uit die kieslys.
+
+
+
+
}}" alt="The “New organization” menu item">
+
+
Figure 138. Die “New organization” kieslysopsie
+
+
+
Eerstens moet jy jou organisasie 'n naam gee en 'n e-posadres verskaf vir 'n hoofkontakpunt vir die groep.
+Dan kan jy ander gebruikers nooi om medeeienaars van die rekening te wees as jy wil.
+
+
+
Volg hierdie stappe en jy sal binnekort die eienaar van 'n splinternuwe organisasie wees.
+Soos persoonlike rekeninge, is organisasies gratis as alles wat jy beplan om daar te stoor, oopbron sal wees.
+
+
+
As 'n eienaar in 'n organisasie, wanneer jy 'n bewaarplek (repository) vurk (fork), sal jy die keuse hê om dit na jou organisasie se naampas te vurk.
+Wanneer jy nuwe bewaarplekke skep, kan jy dit óf onder jou persoonlike rekening óf onder enige van die organisasies waarin jy 'n eienaar is, skep.
+Jy “volg” (watch) ook outomaties enige nuwe bewaarplek wat onder hierdie organisasies geskep word.
+
+
+
Net soos in }}">Jou Avatar (Your Avatar), kan jy 'n avatar vir jou organisasie oplaai om dit 'n bietjie te verpersoonlik.
+Ook net soos persoonlike rekeninge, het jy 'n landingsblad vir die organisasie wat al jou bewaarplekke lys en deur ander mense besigtig kan word.
+
+
+
Kom ons dek nou 'n paar van die dinge wat 'n bietjie anders is met 'n organisasie-rekening.
+
+
+
Spanne (Teams)
+
+
Organisasies word geassosieer met individuele mense by wyse van spanne, wat bloot 'n groepering is van individuele gebruikersrekeninge en bewaarplekke binne die organisasie en watter soort toegang daardie mense in daardie bewaarplekke het.
+
+
+
Byvoorbeeld, sê jou maatskappy het drie bewaarplekke: frontend, backend, en deployscripts.
+Jy sal wil hê jou HTML/CSS/JavaScript-ontwikkelaars moet toegang hê tot frontend en miskien backend, en jou bedryfsmense (Operations) moet toegang hê tot backend en deployscripts.
+Spanne maak dit maklik, sonder om die medewerkers vir elke individuele bewaarplek te hoef bestuur.
+
+
+
Die Organisasie-bladsy wys jou 'n eenvoudige kontroleskerm (dashboard) van al die bewaarplekke, gebruikers en spanne wat onder hierdie organisasie is.
+
+
+
+
}}" alt="The Organization page">
+
+
Figure 139. Die Organisasie-bladsy
+
+
+
Om jou spanne te bestuur, kan jy klik op die Teams-kantbalk aan die regterkant van die bladsy in }}">Die Organisasie-bladsy.
+Dit sal jou bring na 'n bladsy wat jy kan gebruik om lede by die span te voeg, bewaarplekke by die span te voeg of die instellings en toegangsbeheervlakke vir die span te bestuur.
+Elke span kan leesalleen-, lees/skryf- of administratiewe toegang tot die bewaarplekke hê.
+Jy kan daardie vlak verander deur op die “Settings” knoppie in }}">Die Span-bladsy te klik.
+
+
+
+
}}" alt="The Team page">
+
+
Figure 140. Die Span-bladsy
+
+
+
Wanneer jy iemand na 'n span nooi, sal hulle 'n e-pos kry wat hulle laat weet hulle is genooi.
+
+
+
Daarbenewens werk span @vermeldings (@mentions - soos @acmecorp/frontend) baie dieselfde as met individuele gebruikers, behalwe dat alle lede van die span dan op die draad geabonneer is.
+Dit is nuttig as jy die aandag van iemand in 'n span wil hê, maar jy weet nie presies vir wie om te vra nie.
+
+
+
'n Gebruiker kan aan enige aantal spanne behoort, so moenie jouself beperk tot slegs toegangsbeheer-spanne nie.
+Spesiale-belange spanne soos ux, css, of refactoring is nuttig vir sekere soorte vrae, en ander soos legal en colorblind vir 'n heeltemal ander soort.
+
+
+
Ouditlog (Audit Log)
+
+
Organisasies gee eienaars ook toegang tot al die inligting oor wat onder die organisasie aangegaan het.
+Jy kan na die 'Audit Log' oortjie gaan en sien watter gebeurtenisse op 'n organisasievlak plaasgevind het, wie dit gedoen het en waar in die wêreld dit gedoen is.
+
+
+
+
}}" alt="The Audit log">
+
+
Figure 141. Die Ouditlog
+
+
+
Jy kan ook filter tot spesifieke tipes gebeurtenisse, spesifieke plekke of spesifieke mense.
+
+
Die Instandhouding van 'n Projek (Maintaining a Project)
+
+
Noudat ons gemaklik is om tot 'n projek by te dra, kom ons kyk na die ander kant: die skep, instandhouding en administrasie van jou eie projek.
+
+
Die Skep van 'n Nuwe Bewaarplek (Creating a New Repository)
+
+
Kom ons skep 'n nuwe bewaarplek (repository) om ons projekkode mee te deel.
+Begin deur op die “New repository” knoppie aan die regterkant van die kontroleskerm (dashboard) te klik, of van die + knoppie in die boonste nutsbalk langs jou gebruikersnaam soos gesien in }}">Die “New repository” aftrekkieslys.
+
+
+
+
}}" alt="The “Your repositories” area">
+
+
Figure 122. Die “Your repositories” area
+
+
+
+
}}" alt="The “New repository” dropdown">
+
+
Figure 123. Die “New repository” aftrekkieslys
+
+
+
Dit neem jou na die “new repository” vorm:
+
+
+
+
}}" alt="The “new repository” form">
+
+
Figure 124. Die “new repository” vorm
+
+
+
Al wat jy werklik hier hoef te doen is om 'n projeknaam te verskaf; die res van die velde is heeltemal opsioneel.
+Vir nou, klik net op die “Create Repository” knoppie, en doef — jy het 'n nuwe bewaarplek op GitHub, genaamd <user>/<project_name>.
+
+
+
Aangesien jy nog geen kode daar het nie, sal GitHub vir jou instruksies wys oor hoe om 'n splinternuwe Git-bewaarplek te skep, of 'n bestaande Git-projek te koppel.
+Ons gaan nie nou hierby stilstaan nie; as jy 'n opknapping nodig het, kyk na }}">Git Basics.
+
+
+
Noudat jou projek op GitHub gehuisves word, kan jy die URL gee aan enigiemand met wie jy jou projek wil deel.
+Elke projek op GitHub is toeganklik oor HTTPS as https://github.com/<user>/<project_name>, en oor SSH as git@github.com:<user>/<project_name>.
+Git kan van albei hierdie URL’s afhaal (fetch) en daarnatoe opstuur (push), maar hulle word toegangsbeheer gebaseer op die aanmeldbewyse (credentials) van die gebruiker wat daaraan koppel.
+
+
+
+
+|
+ Note
+ |
+
+
+ Dit is dikwels verkieslik om die HTTPS-gebaseerde URL vir 'n openbare projek te deel, aangesien die gebruiker nie 'n GitHub-rekening hoef te hê om toegang daartoe te kry vir kloning nie.
+Gebruikers sal 'n rekening en 'n opgelaaide SSH-sleutel moet hê om toegang tot jou projek te kry as jy vir hulle die SSH-URL gee.
+Die HTTPS-een is ook presies dieselfde URL wat hulle in 'n blaaier sou plak om die projek daar te bekyk.
+ |
+
+
+
+
+
Medewerkers Byvoeg (Adding Collaborators)
+
+
As jy met ander mense werk aan wie jy vasleggingstoegang (commit access) wil gee, moet jy hulle as “medewerkers” (collaborators) byvoeg.
+As Ben, Jeff en Louise almal vir rekeninge op GitHub inteken, en jy wil hulle push-toegang tot jou bewaarplek gee, kan jy hulle by jou projek voeg.
+Deur dit te doen sal hulle “push” toegang gee, wat beteken hulle het beide lees- en skryftoegang tot die projek en Git-bewaarplek.
+
+
+
Klik op die “Settings” skakel onderaan die regterkantste kantbalk.
+
+
+
+
}}" alt="The repository settings link">
+
+
Figure 125. Die bewaarplek-instellingsskakel
+
+
+
Kies dan “Collaborators” uit die kieslys aan die linkerkant.
+Tik dan net 'n gebruikersnaam in die boks in, en klik op “Add collaborator.”
+Jy kan dit soveel keer herhaal as wat jy wil om toegang te verleen aan almal wat jy wil.
+As jy toegang moet intrek, klik net op die “X” aan die regterkant van hul ry.
+
+
+
+
}}" alt="The repository collaborators box">
+
+
Figure 126. Die bewaarplek-medewerkersboks
+
+
+
Bestuur van Pull Requests (Managing Pull Requests)
+
+
Noudat jy 'n projek het met 'n bietjie kode daarin en dalk selfs 'n paar medewerkers wat ook push-toegang het, kom ons gaan oor wat om te doen wanneer jy self 'n Pull Request kry.
+
+
+
Pull Requests kan óf kom van 'n tak in 'n vurk (fork) van jou bewaarplek óf hulle kan kom van 'n ander tak in dieselfde bewaarplek.
+Die enigste verskil is dat dié in 'n vurk dikwels van mense is waar jy nie na hul tak kan push nie en hulle nie na joune kan push nie, terwyl met interne Pull Requests beide partye oor die algemeen toegang tot die tak kan kry.
+
+
+
Vir hierdie voorbeelde, kom ons aanvaar jy is “tonychacon” en jy het 'n nuwe Arduino-kode-projek genaamd “fade” geskep.
+
+
+
E-poskennisgewings (Email Notifications)
+
+
Iemand kom verby en maak 'n verandering aan jou kode en stuur vir jou 'n Pull Request.
+Jy behoort 'n e-pos te kry wat jou in kennis stel van die nuwe Pull Request en dit behoort min of meer te lyk soos }}">E-poskennisgewing van 'n nuwe Pull Request.
+
+
+
+
}}" alt="Email notification of a new Pull Request">
+
+
Figure 127. E-poskennisgewing van 'n nuwe Pull Request
+
+
+
Daar is 'n paar dinge om op te let oor hierdie e-pos.
+Dit sal jou 'n klein diffstat gee — 'n lys van lêers wat in die Pull Request verander het en met hoeveel.
+Dit gee jou 'n skakel na die Pull Request op GitHub.
+Dit gee jou ook 'n paar URL’s wat jy vanaf die opdragreël kan gebruik.
+
+
+
As jy die reël opmerk wat sê git pull <url> patch-1, is dit 'n eenvoudige manier om 'n afgeleë tak in te smelt (merge) sonder om 'n remote by te voeg.
+Ons het vinnig hieroor gegaan in }}">Uitcheck van Afgeleë Takke (Checking Out Remote Branches).
+As jy wil, kan jy skep en oorskakel na 'n onderwerp-tak (topic branch) en dan hierdie opdrag uitvoer om die Pull Request-veranderings in te smelt.
+
+
+
Die ander interessante URL’s is die .diff en .patch URL’s, wat soos jy dalk kan raai, verenigde diff (unified diff) en pleisterweergawes van die Pull Request verskaf.
+Jy kan tegnies die Pull Request-werk insmelt met iets soos dit:
+
+
+
+
$ curl https://github.com/tonychacon/fade/pull/1.patch | git am
+
+
+
+
+
Samewerking op die Pull Request (Collaborating on the Pull Request)
+
+
Soos ons gedek het in }}">Die GitHub-vloei (flow [flow]), kan jy nou 'n gesprek hê met die persoon wat die Pull Request oopgemaak het.
+Jy kan kommentaar lewer op spesifieke reëls kode, kommentaar lewer op hele vasleggings (commits) of kommentaar lewer op die hele Pull Request self, deur GitHub-gegeurde Markdown (GitHub Flavored Markdown) oral te gebruik.
+
+
+
Elke keer as iemand anders kommentaar lewer op die Pull Request sal jy aanhou om e-poskennisgewings te kry sodat jy weet daar is aktiwiteit besig om te gebeur.
+Hulle sal elkeen 'n skakel hê na die Pull Request waar die aktiwiteit plaasvind en jy kan ook direk op die e-pos reageer om op die Pull Request-draad kommentaar te lewer.
+
+
+
+
}}" alt="Responses to emails are included in the thread">
+
+
Figure 128. Antwoorde op e-posse word in die draad ingesluit
+
+
+
Sodra die kode op 'n plek is waarvan jy hou en dit wil insmelt, kan jy óf die kode aftrek (pull) en dit plaaslik insmelt, óf met die git pull <url> <branch> sintaksis wat ons vroeër gesien het, óf deur die vurk as 'n remote by te voeg en te fetch en te merge.
+
+
+
As die saamsmelting triviaal is, kan jy ook net die “Merge” knoppie op die GitHub-webwerf druk.
+Dit sal 'n “non-fast-forward” saamsmelting doen, en 'n saamsmeltingsvaslegging (merge commit) skep selfs al was 'n vinnig-vorentoe (fast-forward) saamsmelting moontlik.
+Dit beteken dat, wat ook al gebeur, elke keer as jy die saamsmelting-knoppie druk, 'n saamsmeltingsvaslegging geskep word.
+Soos jy kan sien in }}">Merge-knoppie en instruksies vir die handmatige saamsmelting van 'n Pull Request, gee GitHub jou al hierdie inligting as jy op die wenkskakel klik.
+
+
+
+
As jy besluit jy wil dit nie insmelt nie, kan jy ook net die Pull Request sluit en die persoon wat dit geopen het, sal in kennis gestel word.
+
+
+
+
Pull Request-verwysings (Pull Request Refs)
+
+
As jy met 'n klomp Pull Requests te doen het en nie 'n klomp remotes wil byvoeg of eenmalige pulls elke keer wil doen nie, is daar 'n netjiese truuk wat GitHub jou toelaat om te doen.
+Hierdie is 'n bietjie van 'n gevorderde truuk en ons sal die besonderhede hiervan 'n bietjie meer in }}">Die Refspec (Verwysingspesifikasie) deurgaan, maar dit kan redelik nuttig wees.
+
+
+
GitHub adverteer eintlik die Pull Request-takke vir 'n bewaarplek as 'n soort pseudo-takke op die bediener.
+By verstek kry jy dit nie wanneer jy kloon nie, maar dit is daar op 'n verborge manier en jy kan redelik maklik toegang daartoe kry.
+
+
+
Om dit te demonstreer, gaan ons 'n laevlakopdrag gebruik (daar word dikwels na verwys as 'n “loodgieterswerk” / “plumbing” opdrag, waaroor ons meer sal lees in }}">Loodgieterswerk en Porselein (Plumbing and Porcelain)) genaamd ls-remote.
+Hierdie opdrag word oor die algemeen nie in dag-tot-dag Git-bedrywighede gebruik nie, maar dit is nuttig om vir ons te wys watter verwysings op die bediener teenwoordig is.
+
+
+
As ons hierdie opdrag uitvoer teen die “blink” bewaarplek wat ons vroeër gebruik het, sal ons 'n lys kry van al die takke en merkers en ander verwysings in die bewaarplek.
+
+
+
+
$ git ls-remote https://github.com/schacon/blink
+10d539600d86723087810ec636870a504f4fee4d HEAD
+10d539600d86723087810ec636870a504f4fee4d refs/heads/master
+6a83107c62950be9453aac297bb0193fd743cd6e refs/pull/1/head
+afe83c2d1a70674c9505cc1d8b7d380d5e076ed3 refs/pull/1/merge
+3c8d735ee16296c242be7a9742ebfbc2665adec1 refs/pull/2/head
+15c9f4f80973a2758462ab2066b6ad9fe8dcf03d refs/pull/2/merge
+a5a7751a33b7e86c5e9bb07b26001bb17d775d1a refs/pull/4/head
+31a45fc257e8433c8d8804e3e848cf61c9d3166c refs/pull/4/merge
+
+
+
+
Natuurlik, as jy in jou bewaarplek is en jy voer git ls-remote origin uit, of watter remote jy ook al wil nagaan, sal dit jou iets soortgelyks aan dit wys.
+
+
+
As die bewaarplek op GitHub is en jy het enige Pull Requests wat geopen is, sal jy hierdie verwysings kry wat voorafgegaan word met refs/pull/.
+Dit is basies takke, maar aangesien dit nie onder refs/heads/ is nie, kry jy dit normaalweg nie wanneer jy kloon of van die bediener afhaal (fetch) nie — die proses van afhaling ignoreer dit normaalweg.
+
+
+
Daar is twee verwysings per Pull Request - die een wat op /head eindig, wys na presies dieselfde vaslegging as die laaste vaslegging in die Pull Request-tak.
+So as iemand 'n Pull Request in ons bewaarplek open en hul tak word bug-fix genoem en dit wys na vaslegging a5a775, dan sal ons in ons bewaarplek nie 'n bug-fix tak hê nie (aangesien dit in hul vurk is), maar ons sal pull/<pr#>/head hê wat na a5a775 wys.
+Dit beteken dat ons redelik maklik elke Pull Request-tak in een slag kan aftrek sonder om 'n klomp remotes by te voeg.
+
+
+
Nou kan jy iets doen soos om die verwysing direk af te haal.
+
+
+
+
$ git fetch origin refs/pull/958/head
+From https://github.com/libgit2/libgit2
+ * branch refs/pull/958/head -> FETCH_HEAD
+
+
+
+
Dit sê vir Git: “Koppel aan die origin remote, en laai die verwysing genaamd refs/pull/958/head af.”
+Git gehoorsaam vrolik, en laai alles af wat jy nodig het om daardie verwysing saam te stel, en plaas 'n wyser na die vaslegging wat jy wil hê onder .git/FETCH_HEAD.
+Jy kan dit opvolg met git merge FETCH_HEAD in 'n tak waarin jy dit wil toets, maar daardie saamsmeltingsvasleggingsboodskap lyk 'n bietjie vreemd.
+Ook, as jy 'n klomp pull requests hersien, raak dit vervelig.
+
+
+
Daar is ook 'n manier om al die pull requests af te haal, en hulle op datum te hou wanneer jy ook al aan die remote koppel.
+Maak .git/config oop in jou gunsteling redigeerder (editor), en soek die origin remote.
+Dit behoort 'n bietjie soos volg te lyk:
+
+
+
+
[remote "origin"]
+ url = https://github.com/libgit2/libgit2
+ fetch = +refs/heads/*:refs/remotes/origin/*
+
+
+
+
Daardie reël wat met fetch = begin is 'n “refspec.”
+Dit is 'n manier om name op die remote te karteer (map) met name in jou plaaslike .git gids.
+Hierdie spesifieke een sê vir Git: "die dinge op die remote wat onder refs/heads is, moet in my plaaslike bewaarplek onder refs/remotes/origin gaan."
+Jy kan hierdie afdeling wysig om nog 'n refspec by te voeg:
+
+
+
+
[remote "origin"]
+ url = https://github.com/libgit2/libgit2.git
+ fetch = +refs/heads/*:refs/remotes/origin/*
+ fetch = +refs/pull/*/head:refs/remotes/origin/pr/*
+
+
+
+
Daardie laaste reël sê vir Git: “Al die verwysings wat soos refs/pull/123/head lyk, moet plaaslik gestoor word soos refs/remotes/origin/pr/123.”
+Nou, as jy daardie lêer stoor en 'n git fetch doen:
+
+
+
+
$ git fetch
+# …
+ * [new ref] refs/pull/1/head -> origin/pr/1
+ * [new ref] refs/pull/2/head -> origin/pr/2
+ * [new ref] refs/pull/4/head -> origin/pr/4
+# …
+
+
+
+
Nou word al die afgeleë pull requests plaaslik verteenwoordig met verwysings wat baie soos opsporingstakke (tracking branches) optree; hulle is leesalleen (read-only), en hulle werk op wanneer jy 'n fetch doen.
+Dit maak dit super maklik om die kode van 'n pull request plaaslik te probeer:
+
+
+
+
$ git checkout pr/2
+Checking out files: 100% (3769/3769), done.
+Branch pr/2 set up to track remote branch pr/2 from origin.
+Switched to a new branch 'pr/2'
+
+
+
+
Die arendsoë onder julle sal die head aan die einde van die afgeleë gedeelte van die refspec oplet.
+Daar is ook 'n refs/pull/#/merge verwysing aan die GitHub-kant, wat die vaslegging verteenwoordig wat sou volg as jy die “merge” knoppie op die webwerf druk.
+Dit kan jou toelaat om die saamsmelting te toets voordat jy selfs die knoppie druk.
+
+
+
+
Pull Requests op Pull Requests
+
+
Nie net kan jy Pull Requests oopmaak wat die main of master tak teiken nie, jy kan eintlik 'n Pull Request oopmaak wat enige tak in die netwerk teiken.
+Trouens, jy kan selfs 'n ander Pull Request teiken.
+
+
+
As jy 'n Pull Request sien wat in die regte rigting beweeg en jy het 'n idee vir 'n verandering wat daarvan afhang of jy nie seker is dat dit 'n goeie idee is nie, of jy het net nie push-toegang tot die teikentak nie, kan jy 'n Pull Request direk daaraan oopmaak.
+
+
+
Wanneer jy gaan om 'n Pull Request oop te maak, is daar 'n boksie aan die bokant van die bladsy wat spesifiseer na watter tak jy versoek om te pull en van watter jy versoek om te pull.
+As jy die “Edit” knoppie regs van daardie boksie druk, kan jy nie net die takke verander nie, maar ook watter vurk.
+
+
+
+
}}" alt="Manually change the Pull Request target fork and branch">
+
+
Figure 130. Verander die Pull Request teikenvurk en -tak handmatig
+
+
+
Hier kan jy redelik maklik spesifiseer om jou nuwe tak in 'n ander Pull Request of 'n ander vurk van die projek in te smelt.
+
+
+
+
Vermeldings en Kennisgewings (Mentions and Notifications)
+
+
GitHub het ook 'n redelik oulike kennisgewingstelsel ingebou wat handig te pas kan kom wanneer jy vrae het of terugvoer van spesifieke individue of spanne benodig.
+
+
+
In enige opmerking kan jy 'n @ karakter begin tik en dit sal begin outovoltooi met die name en gebruikersname van mense wat medewerkers of bydraers in die projek is.
+
+
+
+
}}" alt="Start typing @ to mention someone">
+
+
Figure 131. Begin @ tik om iemand te vermeld
+
+
+
Jy kan ook 'n gebruiker vermeld wat nie in daardie aftrekkieslys is nie, maar dikwels kan die outovoltooier dit vinniger maak.
+
+
+
Sodra jy 'n opmerking met 'n gebruikersvermelding plaas, sal daardie gebruiker in kennis gestel word.
+Dit beteken dit kan 'n baie doeltreffende manier wees om mense in gesprekke in te trek eerder as om hulle te laat soek of wag (poll).
+Baie dikwels in Pull Requests op GitHub sal mense ander mense in hul spanne of in hul maatskappy intrek om 'n Issue of Pull Request te hersien.
+
+
+
As iemand op 'n Pull Request of Issue vermeld word, sal hulle daarop “geabonneer” (subscribed) word en sal hulle aanhou om kennisgewings te kry enige tyd as daar aktiwiteit daarop plaasvind.
+Jy sal ook op iets geabonneer wees as jy dit oopgemaak het, as jy die bewaarplek volg (watching) of as jy op iets kommentaar lewer.
+As jy nie meer kennisgewings wil ontvang nie, is daar 'n “Unsubscribe” (Teken uit) knoppie op die bladsy waarop jy kan klik om op te hou om opdaterings daaroor te ontvang.
+
+
+
+
}}" alt="Unsubscribe from an Issue or Pull Request">
+
+
Figure 132. Teken uit (unsubscribe) van 'n Issue of Pull Request
+
+
+
Die Kennisgewingsblad (The Notifications Page)
+
+
Wanneer ons hier "kennisgewings" noem met betrekking tot GitHub, bedoel ons 'n spesifieke manier waarop GitHub probeer om met jou in kontak te kom wanneer gebeure plaasvind en daar is 'n paar verskillende maniere waarop jy hulle kan konfigureer.
+As jy na die “Notification center” oortjie vanaf die instellingsblad gaan, kan jy sommige van die opsies wat jy het, sien.
+
+
+
+
}}" alt="Notification center options">
+
+
Figure 133. Kennisgewingsentrum opsies
+
+
+
Die twee keuses is om kennisgewings oor “Email” en oor “Web” te kry, en jy kan enige, geeneen of albei kies vir wanneer jy aktief aan dinge deelneem en vir aktiwiteit op bewaarplekke wat jy volg.
+
+
+
Webkennisgewings (Web Notifications)
+
+
Webkennisgewings bestaan net op GitHub en jy kan dit net op GitHub nagaan.
+As jy hierdie opsie gekies het in jou voorkeure en 'n kennisgewing word vir jou geaktiveer, sal jy 'n klein blou kolletjie bo jou kennisgewing-ikoon aan die bokant van jou skerm sien soos gesien in }}">Kennisgewingsentrum.
+
+
+
+
}}" alt="Notification center">
+
+
Figure 134. Kennisgewingsentrum
+
+
+
As jy daarop klik, sal jy 'n lys sien van al die items waaroor jy in kennis gestel is, gegroepeer volgens projek.
+Jy kan filter tot die kennisgewings van 'n spesifieke projek deur op sy naam in die linkerkantse kantbalk te klik.
+Jy kan ook die kennisgewing erken deur op die regmerkie-ikoon langs enige kennisgewing te klik, of al die kennisgewings in 'n projek te erken deur op die regmerkie bo-aan die groep te klik.
+Daar is ook 'n demp-knoppie (mute) langs elke regmerkie waarop jy kan klik om geen verdere kennisgewings oor daardie item te ontvang nie.
+
+
+
Al hierdie gereedskap is baie nuttig vir die hantering van groot getalle kennisgewings.
+Baie GitHub-kraggebruikers sal eenvoudig e-poskennisgewings heeltemal afskakel en al hul kennisgewings deur hierdie skerm bestuur.
+
+
+
+
E-poskennisgewings (Email Notifications)
+
+
+
Daar is ook 'n redelike hoeveelheid metadata ingebed in die opskrifte van die e-posse wat GitHub vir jou stuur, wat regtig nuttig kan wees vir die opstel van pasgemaakte filters en reëls.
+
+
+
+
+
To: tonychacon/fade <fade@noreply.github.com>
+Message-ID: <tonychacon/fade/pull/1@github.com>
+Subject: [fade] Wait longer to see the dimming effect better (#1)
+X-GitHub-Recipient: tonychacon
+List-ID: tonychacon/fade <fade.tonychacon.github.com>
+List-Archive: https://github.com/tonychacon/fade
+List-Post: <mailto:reply+i-4XXX@reply.github.com>
+List-Unsubscribe: <mailto:unsub+i-XXX@reply.github.com>,...
+X-GitHub-Recipient-Address: tchacon@example.com
+
+
+
+
Hier is 'n paar interessante dinge.
+As jy e-posse wil uitlig of herlei na hierdie spesifieke projek of selfs Pull Request, gee die inligting in Message-ID vir jou al die data in <user>/<project>/<type>/<id> formaat.
+As dit byvoorbeeld 'n issue was, sou die <type> veld “issues” gewees het in plaas van “pull”.
+
+
+
Die List-Post en List-Unsubscribe velde beteken dat as jy 'n e-poskliënt het wat dit verstaan, jy maklik na die lys kan plaas of van die draad kan “Unsubscribe”.
+Dit sou in wese dieselfde wees as om op die “mute” knoppie op die webweergawe van die kennisgewing of “Unsubscribe” op die Issue- of Pull Request-blad self te klik.
+
+
+
Dit is ook die moeite werd om te let op dat as jy beide e-pos- en webkennisgewings geaktiveer het en jy lees die e-posweergawe van die kennisgewing, die webweergawe ook as gelees gemerk sal word as jy prente in jou e-poskliënt toelaat.
+
+
+
+
+
Spesiale Lêers (Special Files)
+
+
Daar is 'n paar spesiale lêers wat GitHub sal oplet as dit in jou bewaarplek teenwoordig is.
+
+
+
README
+
+
Die eerste is die README lêer, wat in byna enige formaat kan wees wat GitHub as prosa herken.
+Byvoorbeeld, dit kan README, README.md, README.asciidoc, ens. wees.
+As GitHub 'n README lêer in jou bronkode sien, sal dit dit op die landingsblad van die projek weergee.
+
+
+
Baie spanne gebruik hierdie lêer om al die relevante projekinligting te hou vir iemand wat dalk nuut in die bewaarplek of projek is.
+Dit sluit gewoonlik dinge in soos:
+
+
+
+-
+
Waarvoor die projek is
+
+-
+
Hoe om dit op te stel en te installeer
+
+-
+
'n Voorbeeld van hoe om dit te gebruik of dit aan die gang te kry
+
+-
+
Die lisensie waaronder die projek aangebied word
+
+-
+
Hoe om daartoe by te dra
+
+
+
+
+
Aangesien GitHub hierdie lêer sal weergee, kan jy prente of skakels daarin insluit vir bykomende begrip.
+
+
+
CONTRIBUTING
+
+
+
+
}}" alt="Opening a Pull Request when a CONTRIBUTING file exists">
+
+
Figure 135. Oopmaak van 'n Pull Request wanneer 'n CONTRIBUTING lêer bestaan
+
+
+
Die idee hier is dat jy spesifieke dinge kan spesifiseer wat jy wil of nie wil hê nie in 'n Pull Request wat na jou projek gestuur word.
+Op hierdie manier mag mense werklik die riglyne lees voordat hulle die Pull Request oopmaak.
+
+
+
Projekadministrasie (Project Administration)
+
+
Oor die algemeen is daar nie baie administratiewe dinge wat jy met 'n enkele projek kan doen nie, maar daar is 'n paar items wat van belang kan wees.
+
+
+
Verandering van die Verstek-tak (Changing the Default Branch)
+
+
As jy 'n ander tak as “master” gebruik as jou verstek-tak waarop jy wil hê mense Pull Requests moet oopmaak of by verstek moet sien, kan jy dit verander in jou bewaarplek se instellingsblad onder die “Options” oortjie.
+
+
+
+
}}" alt="Change the default branch for a project">
+
+
Figure 136. Verander die verstek-tak vir 'n projek
+
+
+
Verander eenvoudig die verstek-tak in die aftrekkieslys en dit sal van toe af die verstek wees vir alle groot bewerkings, insluitend watter tak by verstek uitgetrek (checked out) word wanneer iemand die bewaarplek kloon.
+
+
+
+
Oordrag van 'n Projek (Transferring a Project)
+
+
As jy 'n projek na 'n ander gebruiker of 'n organisasie in GitHub wil oordra, is daar 'n “Transfer ownership” opsie onderaan dieselfde “Options” oortjie van jou bewaarplekinstellingsblad wat jou toelaat om dit te doen.
+
+
+
+
}}" alt="Transfer a project to another GitHub user or Organization">
+
+
Figure 137. Dra 'n projek oor na 'n ander GitHub-gebruiker of Organisasie
+
+
+
Dit is nuttig as jy 'n projek laat vaar en iemand dit wil oorneem, of as jou projek groter word en jy dit na 'n organisasie wil skuif.
+
+
+
Dit skuif nie net die bewaarplek saam met al sy volgers (watchers) en sterre (stars) na 'n ander plek nie, dit stel ook 'n herleiding van jou URL na die nuwe plek op.
+Dit sal ook klone en fetch-aksies van Git herlei, nie net webversoeke nie.
+
+
+
Die Skriptering van GitHub (Scripting GitHub)
+
+
Ons het nou al die hooffunksies en werkvloeie van GitHub gedek, maar enige groot groep of projek sal pasgemaakte aanpassings (customizations) wil maak of eksterne dienste wil integreer.
+
+
Gelukkig vir ons is GitHub op baie maniere redelik kapbaar (hackable).
+In hierdie afdeling sal ons dek hoe om die GitHub-hakestelsel (hooks system) en die API daarvan te gebruik om GitHub te laat werk soos ons dit wil hê.
+
+
Dienste en Hake (Services and Hooks)
+
+
Die Dienste en Hake-afdeling (Hooks and Services) van GitHub-bewaarplekadministrasie is die maklikste manier om GitHub met eksterne stelsels te laat kommunikeer.
+
+
+
Dienste (Services)
+
+
Eerstens sal ons na Dienste kyk.
+Beide die Hake- en Dienste-integrasies kan gevind word in die Settings-afdeling van jou bewaarplek, waar ons vroeër gekyk het na die byvoeging van Medewerkers (Collaborators) en die verandering van die verstek-tak van jou projek.
+Onder die “Webhooks and Services” oortjie sal jy iets sien soos }}">Dienste en Hake konfigurasie-afdeling.
+
+
+
+
}}" alt="Services and Hooks configuration section">
+
+
Figure 142. Dienste en Hake konfigurasie-afdeling
+
+
+
Daar is dosyne dienste waaruit jy kan kies, waarvan die meeste integrasies is na ander kommersiële en oopbronstelsels.
+Die meeste daarvan is vir Deurlopende Integrasie-dienste (Continuous Integration services), fout- en kwessie-opspoorders (bug and issue trackers), kletskamerstelsels en dokumentasiestelsels.
+Ons sal stap vir stap deur die opstelling van 'n baie eenvoudige een gaan, naamlik die Email-haak.
+As jy “email” uit die “Add Service” aftrekkieslys kies, sal jy 'n konfigurasieskerm soos }}">E-posdiens konfigurasie kry.
+
+
+
+
}}" alt="Email service configuration">
+
+
Figure 143. E-posdiens konfigurasie
+
+
+
In hierdie geval, as ons die “Add service” knoppie druk, sal die e-posadres wat ons gespesifiseer het 'n e-pos kry elke keer as iemand na die bewaarplek push.
+Dienste kan luister vir baie verskillende tipes gebeurtenisse, maar die meeste luister slegs vir push-gebeurtenisse en doen dan iets met daardie data.
+
+
+
As daar 'n stelsel is wat jy gebruik wat jy met GitHub wil integreer, moet jy hier kyk om te sien of daar 'n bestaande diensintegrasie beskikbaar is.
+Byvoorbeeld, as jy Jenkins gebruik om toetse op jou kodebasis te laat loop, kan jy die ingeboude Jenkins-diensintegrasie aktiveer om 'n toetslopie af te skop elke keer as iemand na jou bewaarplek push.
+
+
+
+
Hake (Hooks)
+
+
As jy iets meer spesifiek nodig het of jy wil integreer met 'n diens of webwerf wat nie in hierdie lys is nie, kan jy in plaas daarvan die meer generiese hakestelsel (hooks system) gebruik.
+GitHub-bewaarplekhake is redelik eenvoudig.
+Jy spesifiseer 'n URL en GitHub sal 'n HTTP-loonvrag (payload) na daardie URL stuur (post) op enige gebeurtenis wat jy wil hê.
+
+
+
Die manier waarop dit oor die algemeen werk, is dat jy 'n klein webdiens kan opstel om te luister vir 'n GitHub-haakloonvrag en dan iets met die data doen wanneer dit ontvang word.
+
+
+
+
+
}}" alt="Web hook configuration">
+
+
Figure 144. Webhaak konfigurasie
+
+
+
Die konfigurasie vir 'n webhaak is redelik eenvoudig.
+In die meeste gevalle voer jy eenvoudig 'n URL en 'n geheime sleutel (secret key) in en druk “Add webhook”.
+Daar is 'n paar opsies vir watter gebeurtenisse jy wil hê GitHub 'n loonvrag voor moet stuur — die verstelling (default) is om slegs 'n loonvrag vir die push gebeurtenis te kry, wanneer iemand nuwe kode na enige tak van jou bewaarplek push.
+
+
+
Kom ons kyk na 'n klein voorbeeld van 'n webdiens wat jy kan opstel om 'n webhaak te hanteer.
+Ons sal die Ruby-webraamwerk Sinatra gebruik aangesien dit redelik bondig is en jy maklik behoort te kan sien wat ons besig is om te doen.
+
+
+
Sê nou ons wil 'n e-pos kry as 'n spesifieke persoon na 'n spesifieke tak van ons projek push en 'n spesifieke lêer wysig.
+Ons kan dit redelik maklik doen met kode soos hierdie:
+
+
+
+
require 'sinatra'
+require 'json'
+require 'mail'
+
+post '/payload' do
+ push = JSON.parse(request.body.read) # parse the JSON
+
+ # gather the data we're looking for
+ pusher = push["pusher"]["name"]
+ branch = push["ref"]
+
+ # get a list of all the files touched
+ files = push["commits"].map do |commit|
+ commit['added'] + commit['modified'] + commit['removed']
+ end
+ files = files.flatten.uniq
+
+ # check for our criteria
+ if pusher == 'schacon' &&
+ branch == 'ref/heads/special-branch' &&
+ files.include?('special-file.txt')
+
+ Mail.deliver do
+ from 'tchacon@example.com'
+ to 'tchacon@example.com'
+ subject 'Scott Changed the File'
+ body "ALARM"
+ end
+ end
+end
+
+
+
+
Hier neem ons die JSON-loonvrag wat GitHub aan ons aflewer en soek wie dit gepush het, na watter tak hulle gepush het en watter lêers geraak is in al die vasleggings wat gepush is.
+Dan kontroleer ons dit teen ons kriteria en stuur 'n e-pos as dit ooreenstem.
+
+
+
Om so iets te ontwikkel en te toets, het jy 'n oulike ontwikkelaarskonsole in dieselfde skerm waar jy die haak opgestel het.
+Jy kan die laaste paar aflewerings sien wat GitHub probeer maak het vir daardie webhaak.
+Vir elke haak kan jy in diepte kyk na wanneer dit afgelewer is, of dit suksesvol was en die liggaam en opskrifte (headers) vir beide die versoek en die reaksie.
+Dit maak dit ongelooflik maklik om jou hake te toets en te ontfout (debug).
+
+
+
+
}}" alt="Web hook debugging information">
+
+
Figure 145. Webhaak ontfoutingsinligting
+
+
+
Die ander wonderlike kenmerk hiervan is dat jy enige van die loonvragte weer kan aflewer (redeliver) om jou diens maklik te toets.
+
+
+
+
+
Die GitHub API (The GitHub API)
+
+
+Dienste en hake gee jou 'n manier om push-kennisgewings te ontvang oor gebeurtenisse wat op jou bewaarplekke plaasvind, maar wat as jy meer inligting oor hierdie gebeurtenisse nodig het?
+Wat as jy iets moet outomatiseer soos om medewerkers by te voeg of Issues te etiketteer?
+
+
+
Dit is waar die GitHub API handig te pas kom.
+GitHub het tonne API-eindpunte (endpoints) om byna enigiets wat jy op die webwerf kan doen, op 'n geoutomatiseerde manier te doen.
+In hierdie afdeling sal ons leer hoe om te verifieer (authenticate) en aan die API te koppel, hoe om kommentaar te lewer op 'n Issue en hoe om die status van 'n Pull Request deur die API te verander.
+
+
+
Basiese Gebruik (Basic Usage)
+
+
Die mees basiese ding wat jy kan doen, is 'n eenvoudige GET-versoek (GET request) op 'n eindpunt wat nie verifikasie vereis nie.
+Dit kan 'n gebruiker wees of leesalleen-inligting (read-only information) oor 'n oopbronprojek.
+Byvoorbeeld, as ons meer wil weet oor 'n gebruiker genaamd “schacon”, kan ons iets soos dit uitvoer:
+
+
+
+
$ curl https://api.github.com/users/schacon
+{
+ "login": "schacon",
+ "id": 70,
+ "avatar_url": "https://avatars.githubusercontent.com/u/70",
+# …
+ "name": "Scott Chacon",
+ "company": "GitHub",
+ "following": 19,
+ "created_at": "2008-01-27T17:19:28Z",
+ "updated_at": "2014-06-10T02:37:23Z"
+}
+
+
+
+
Daar is tonne eindpunte soos hierdie om inligting te kry oor organisasies, projekte, issues, vasleggings — so te sê enigiets wat jy in die openbaar op GitHub kan sien.
+Jy kan selfs die API gebruik om willekeurige Markdown weer te gee of 'n .gitignore sjabloon te vind.
+
+
+
+
$ curl https://api.github.com/gitignore/templates/Java
+{
+ "name": "Java",
+ "source": "*.class
+
+# Mobile Tools for Java (J2ME)
+.mtj.tmp/
+
+# Package Files #
+*.jar
+*.war
+*.ear
+
+# virtual machine crash logs, see https://www.java.com/en/download/help/error_hotspot.xml
+hs_err_pid*
+"
+}
+
+
+
+
+
+
As jy egter 'n aksie op die webwerf wil doen, soos om kommentaar te lewer op 'n Issue of Pull Request of as jy privaat inhoud wil sien of daarmee in wisselwerking tree, sal jy moet verifieer.
+
+
+
Daar is verskeie maniere om te verifieer.
+Jy kan basiese verifikasie (basic authentication) met net jou gebruikersnaam en wagwoord gebruik, maar oor die algemeen is dit 'n beter idee om 'n persoonlike toegangsteken (personal access token) te gebruik.
+Jy kan dit genereer vanaf die “Applications” oortjie van jou instellingsbladsy.
+
+
+
+
}}" alt="Generate your access token from the “Applications” tab of your settings page">
+
+
Figure 146. Genereer jou toegangsteken vanaf die “Applications” oortjie van jou instellingsbladsy
+
+
+
Dit sal jou vra watter bestekke (scopes) jy vir hierdie teken wil hê en 'n beskrywing.
+Maak seker jy gebruik 'n goeie beskrywing sodat jy gemaklik voel om die teken te verwyder wanneer jou skrip of toepassing nie meer gebruik word nie.
+
+
+
GitHub sal die teken net een keer vir jou wys, so maak seker dat jy dit kopieer.
+Jy kan dit nou gebruik om in jou skrip te verifieer in plaas daarvan om 'n gebruikersnaam en wagwoord te gebruik.
+Dit is lekker omdat jy die bestek van wat jy wil doen kan beperk en die teken herroepbaar (revocable) is.
+
+
+
Dit het ook die bykomende voordeel dat dit jou tempobeperking (rate limit) verhoog.
+Sonder verifikasie sal jy beperk word tot 60 versoeke per uur.
+As jy verifieer, kan jy tot 5 000 versoeke per uur rig.
+
+
+
Kom ons gebruik dit dus om 'n opmerking op een van ons Issues te maak.
+Sê nou ons wil 'n opmerking los op 'n spesifieke Issue, Issue #6.
+Om dit te doen moet ons 'n HTTP POST-versoek aan repos/<user>/<repo>/issues/<num>/comments rig met die teken wat ons pas gegenereer het as 'n Authorization-opskrif (header).
+
+
+
+
$ curl -H "Content-Type: application/json" \
+ -H "Authorization: token TOKEN" \
+ --data '{"body":"A new comment, :+1:"}' \
+ https://api.github.com/repos/schacon/blink/issues/6/comments
+{
+ "id": 58322100,
+ "html_url": "https://github.com/schacon/blink/issues/6#issuecomment-58322100",
+ ...
+ "user": {
+ "login": "tonychacon",
+ "id": 7874698,
+ "avatar_url": "https://avatars.githubusercontent.com/u/7874698?v=2",
+ "type": "User",
+ },
+ "created_at": "2014-10-08T07:48:19Z",
+ "updated_at": "2014-10-08T07:48:19Z",
+ "body": "A new comment, :+1:"
+}
+
+
+
+
+
+
Jy kan die API gebruik om net omtrent enigiets te doen wat jy op die webwerf kan doen — die skep en stel van mylpale (milestones), die toewysing van mense aan Issues en Pull Requests, die skep en verandering van etikette (labels), toegang tot vasleggingsdata (commit data), die skep van nuwe vasleggings en takke, die oopmaak, toemaak of saamsmelt van Pull Requests, die skep en redigering van spanne, kommentaar op reëls kode in 'n Pull Request, soek op die werf en so meer.
+
+
+
Verandering van die Status van 'n Pull Request (Changing the Status of a Pull Request)
+
+
Daar is nog een laaste voorbeeld waarna ons sal kyk, aangesien dit regtig nuttig is as jy met Pull Requests werk.
+Elke vaslegging kan een of meer statusse hê wat daarmee geassosieer is en daar is 'n API om daardie status by te voeg en te bevraagteken (query).
+
+
+
Die meeste van die Deurlopende Integrasie (Continuous Integration) en toetsdienste maak gebruik van hierdie API om op pushes te reageer deur die kode te toets wat gepush is, en dan terug te rapporteer of daardie vaslegging al die toetse geslaag het.
+Jy kan dit ook gebruik om te kyk of die vasleggingsboodskap behoorlik geformatteer is, of die indiener al jou bydraeriglyne gevolg het, of die vaslegging geldig geteken was — enige aantal dinge.
+
+
+
Kom ons sê jy stel 'n webhaak (webhook) op jou bewaarplek op wat 'n klein webdiens tref wat vir 'n Signed-off-by string in die vasleggingsboodskap soek.
+
+
+
+
require 'httparty'
+require 'sinatra'
+require 'json'
+
+post '/payload' do
+ push = JSON.parse(request.body.read) # parse the JSON
+ repo_name = push['repository']['full_name']
+
+ # look through each commit message
+ push["commits"].each do |commit|
+
+ # look for a Signed-off-by string
+ if /Signed-off-by/.match commit['message']
+ state = 'success'
+ description = 'Successfully signed off!'
+ else
+ state = 'failure'
+ description = 'No signoff found.'
+ end
+
+ # post status to GitHub
+ sha = commit["id"]
+ status_url = "https://api.github.com/repos/#{repo_name}/statuses/#{sha}"
+
+ status = {
+ "state" => state,
+ "description" => description,
+ "target_url" => "http://example.com/how-to-signoff",
+ "context" => "validate/signoff"
+ }
+ HTTParty.post(status_url,
+ :body => status.to_json,
+ :headers => {
+ 'Content-Type' => 'application/json',
+ 'User-Agent' => 'tonychacon/signoff',
+ 'Authorization' => "token #{ENV['TOKEN']}" }
+ )
+ end
+end
+
+
+
+
Hopelik is dit redelik eenvoudig om te volg.
+In hierdie webhaak-hanteerder kyk ons deur elke vaslegging wat pas gepush is, ons soek na die string 'Signed-off-by' in die vasleggingsboodskap en uiteindelik doen ons 'n POST via HTTP na die /repos/<user>/<repo>/statuses/<commit_sha> API-eindpunt (endpoint) met die status.
+
+
+
In hierdie geval kan jy 'n toestand ('success', 'failure', 'error') stuur, 'n beskrywing van wat gebeur het, 'n teiken-URL waarheen die gebruiker kan gaan vir meer inligting en 'n “konteks” (context) ingeval daar veelvuldige statusse vir 'n enkele vaslegging is.
+Byvoorbeeld, 'n toetsdiens kan 'n status verskaf en 'n valideringsdiens soos hierdie kan ook 'n status verskaf — die “konteks” veld is hoe hulle onderskei word.
+
+
+
+
+
}}" alt="Commit status via the API">
+
+
Figure 148. Vasleggingstatus via die API
+
+
+
Jy kan nou 'n klein groen regmerkie sien langs die vaslegging wat 'n “Signed-off-by” string in die boodskap het en 'n rooi kruisie deur die een waar die outeur vergeet het om af te teken.
+Jy kan ook sien dat die Pull Request die status aanneem van die laaste vaslegging op die tak en jou waarsku as dit 'n mislukking (failure) is.
+Dit is baie nuttig as jy hierdie API vir toetsresultate gebruik sodat jy nie per ongeluk iets insmelt (merge) waar die laaste vaslegging toetse dop nie.
+
+
+
Octokit
+
+
Alhoewel ons byna alles in hierdie voorbeelde deur curl en eenvoudige HTTP-versoeke gedoen het, bestaan daar verskeie oopbron-biblioteke (open-source libraries) wat hierdie API op 'n meer idiomatiese manier beskikbaar stel.
+Ten tyde van hierdie skrywe sluit die ondersteunde tale Go, Objective-C, Ruby en .NET in.
+Kyk na https://github.com/octokit vir meer inligting hieroor, aangesien hulle baie van die HTTP vir jou hanteer.
+
+
+
Hopelik kan hierdie gereedskap jou help om GitHub aan te pas en te wysig om beter vir jou spesifieke werkvloeie te werk.
+Vir volledige dokumentasie oor die hele API asook gidse vir algemene take, kyk na https://docs.github.com/.
+
+
+GitHub is the single largest host for Git repositories, and is the central point of collaboration for millions of developers and projects.
+A large percentage of all Git repositories are hosted on GitHub, and many open-source projects use it for Git hosting, issue tracking, code review, and other things.
+So while it’s not a direct part of the Git open source project, there’s a good chance that you’ll want or need to interact with GitHub at some point while using Git professionally.
This chapter is about using GitHub effectively.
+We’ll cover signing up for and managing an account, creating and using Git repositories, common workflows to contribute to projects and to accept contributions to yours, GitHub’s programmatic interface and lots of little tips to make your life easier in general.
If you are not interested in using GitHub to host your own projects or to collaborate with other projects that are hosted on GitHub, you can safely skip to Git Tools.
+Rekeningopstelling en Konfigurasie (Account Setup and Configuration)
+
+
+Die eerste ding wat jy moet doen, is om 'n gratis gebruikersrekening op te stel.
+Besoek eenvoudig https://github.com, kies 'n gebruikersnaam wat nie reeds geneem is nie, voorsien 'n e-posadres en 'n wagwoord, en klik op die groot groen “Sign up for GitHub” knoppie.
+
+
+
}}" alt="The GitHub sign-up form">
+
+
Figure 94. Die GitHub-aanmeldingsvorm
+
+
Die volgende ding wat jy sal sien, is die prysbladsy vir opgegradeerde planne, maar dit is veilig om dit vir eers te negeer.
+GitHub sal vir jou 'n e-pos stuur om die adres wat jy verskaf het, te verifieer.
+Gaan gerus voort en doen dit; dit is taamlik belangrik (soos ons later sal sien).
+
+
+
+|
+ Note
+ |
+
+
+ GitHub bied amper al sy funksionaliteit met gratis rekeninge aan, behalwe vir sommige gevorderde kenmerke.
+
+ GitHub se betaalde planne sluit gevorderde gereedskap en kenmerke in sowel as verhoogde limiete vir gratis dienste, maar ons gaan dit nie in hierdie boek dek nie.
+Vir meer inligting oor beskikbare planne en hul vergelyking, besoek https://github.com/pricing.
+ |
+
+
+
+
Deur op die Octocat-logo links bo op die skerm te klik, gaan jy na jou dashboard-bladsy.
+Jy is nou gereed om GitHub te gebruik.
+
+
SSH-toegang (SSH Access)
+
+
+Van nou af is jy ten volle in staat om met Git-bewaarplekke (repositories) te koppel deur die https:// protokol te gebruik, deur te verifieer met die gebruikersnaam en wagwoord wat jy pas opgestel het.
+Om egter eenvoudig openbare projekte te kloon (clone), hoef jy nie eens in te skryf nie — die rekening wat ons pas geskep het, kom te pas wanneer ons later projekte vurk (fork) en na ons vurke push.
+
+
+
+
+
}}" alt="The “Account settings” link">
+
+
Figure 95. Die “Account settings” skakel
+
+
+
Selekteer dan die “SSH keys” afdeling aan die linkerkant.
+
+
+
+
}}" alt="The “SSH keys” link">
+
+
Figure 96. Die “SSH keys” skakel
+
+
+
Klik van daar af op die “Add an SSH key” knoppie, gee jou sleutel 'n naam, plak die inhoud van jou ~/.ssh/id_rsa.pub (of wat ook al jy dit genoem het) publieke-sleutellêer in die teksgebied, en klik “Add key”.
+
+
+
+
+|
+ Note
+ |
+
+
+ Maak seker dat jy jou SSH-sleutel iets noem wat jy kan onthou.
+Jy kan elk van jou sleutels 'n naam gee (bv. "My Laptop" of "Work Account") sodat as jy later 'n sleutel moet intrek (revoke), jy maklik kan sien watter een jy soek.
+ |
+
+
+
+
+
Jou Avatar (Your Avatar)
+
+
Volgens, as jy wil, kan jy die avatar wat vir jou gegenereer word, vervang met 'n afbeelding van jou keuse.
+Gaan eers na die “Profile” oortjie (bo die SSH Keys oortjie) en klik op “Upload new picture”.
+
+
+
+
}}" alt="The “Profile” link">
+
+
Figure 97. Die “Profile” skakel
+
+
+
Ons kies 'n kopie van die Git-logo wat op ons hardeskyf is en kry dan die geleentheid om dit te sny (crop).
+
+
+
+
}}" alt="Crop your uploaded avatar">
+
+
Figure 98. Sny jou geüploade avatar
+
+
+
Nou sal mense oral waar jy op die webwerf wisselwerking het, jou avatar langs jou gebruikersnaam sien.
+
+
+
As jy toevallig 'n avatar op die gewilde Gravatar-diens opgelaai het (dikwels gebruik vir WordPress-rekeninge), sal daardie avatar by verstek gebruik word en hoef jy nie hierdie stap te doen nie.
+
+
+
Jou E-posadresse (Your Email Addresses)
+
+
Die manier waarop GitHub jou Git-vasleggings (commits) aan jou gebruiker koppel, is per e-posadres.
+As jy verskeie e-posadresse in jou vasleggings gebruik en jy wil hê GitHub moet hulle behoorlijk koppel, moet jy al die e-posadresse wat jy gebruik het, by die Emails-afdeling van die admin-afdeling voeg.
+
+
+
+
}}" alt="Add all your email addresses">
+
+
Figure 99. Voeg al jou e-posadresse by
+
+
+
In }}">Voeg al jou e-posadresse by kan ons van die verskillende state sien wat moontlik is.
+Die boonste adres is geverifieer en as die primêre adres ingestel, wat beteken dit is waar jy enige kennisgewings en kwitansies sal ontvang.
+Die tweede adres is geverifieer en kan dus as die primêre gestel word as jy dit wil omruil.
+Die laaste adres is ongeverifieer, wat beteken jy kan dit nie jou primêre adres maak nie.
+As GitHub enige van hierdie in vasleggingsboodskappe in enige bewaarplek op die webwerf sien, sal dit nou aan jou gebruiker gekoppel word.
+
+
+
Twee-faktor-verifikasie (Two Factor Authentication)
+
+
Ten slotte, vir ekstra sekuriteit, moet jy beslis Twee-faktor-verifikasie of “2FA” opstel.
+Twee-faktor-verifikasie is 'n verifikasiemeganisme wat deesdae meer en meer gewild word om die risiko te verminder dat jou rekening gekompromitteer word as jou wagwoord op een of ander manier gesteel word.
+Deur dit aan te skakel, sal GitHub jou vir twee verskillende metodes van verifikasie vra, sodat as een van hulle gekompromitteer word, 'n aanvaller nie toegang tot jou rekening sal kan kry nie.
+
+
+
Jy kan die Twee-faktor-verifikasie-opstelling vind onder die Security-oortjie van jou rekeninginstellings.
+
+
+
+
}}" alt="2FA in the Security Tab">
+
+
Figure 100. 2FA in die Security-oortjie
+
+
+
As jy op die “Set up two-factor authentication” knoppie klik, sal dit jou na 'n konfigurasiebladsy neem waar jy kan kies om 'n foonprogram te gebruik om jou sekondêre kode te genereer (n “tydgebaseerde eenmalige wagwoord” / time based one-time password), of jy kan hê dat GitHub vir jou elke keer 'n kode via SMS stuur wanneer jy moet aanmeld.
+
+
+
Nadat jy kies watter metode jy verkies en die instruksies volg om 2FA op te stel, sal jou rekening 'n bietjie more veilig wees en sal jy 'n kode moet verskaf bykomend tot jou wagwoord wanneer jy ook al by GitHub aanmeld.
+
+
Summary
+
+
Now you’re a GitHub user.
+You know how to create an account, manage an organization, create and push to repositories, contribute to other people’s projects and accept contributions from others.
+In the next chapter, you’ll learn more powerful tools and tips for dealing with complex situations, which will truly make you a Git master.
+
Translations started for
+ | Afrikaans, |
| Беларуская, |
| Indonesian, |
| Italiano, |
diff --git a/script/book.rb b/script/book.rb
index a13758ec3c..849ecd8892 100644
--- a/script/book.rb
+++ b/script/book.rb
@@ -5,6 +5,7 @@
class Book
@@all_books = {
+ "af" => "progit2-af/progit2",
"az" => "progit2-aze/progit2",
"be" => "progit/progit2-be",
"bg" => "progit/progit2-bg",