Git 🌙
Chapters ▾ 2nd Edition

9.1 Git in ostali sistemi - Git kot odjemalec

Svet ni popoln. Običajno ne morete takoj preklopiti v Git vsakega projekta, s katerim pridete v stik. Včasih obtičite na projektu, ki uporablja drug VCS, in želite, da bi bil Git. Prvi del tega poglavja bomo posvetili učenju načinov, kako uporabiti Git kot odjemalca, ko projekt, na katerem delate, gostuje na drugačnem sistemu.

Na neki točki boste morda želeli pretvoriti vaš obstoječi projekt v Git. Drugi del tega poglavja zajema, kako migrirati vaš projekt v Git iz več določenih sistemov kot tudi metodo, ki bo delovala, če ne obstaja nobeno vnaprej zgrajeno orodje za uvažanje.

Git kot odjemalec

Git ponuja tako dobro izkušnjo za razvijalce, da so mnogi ljudje ugotovili, kako ga uporabljati na njihovih delovnih postajah, tudi če preostanek njihove ekipe uporablja v celoti drug VCS. Na voljo je vrsta teh pretvornikov imenovanih »mostovi« (angl. bridges). Tu bomo pokrili tiste, na katere boste najverjetneje naleteli tam zunaj.

Git in Subversion

Velik delež projektov za razvoj odprtokodne programske opreme in dobra mera podjetniških projektov uporablja Subversion za upravljanje z izvorno kodo. Ta je prisoten že več kot desetletje in večino tega časa je veljal za privzeti izbor sistema za nadzor različic za projekte odprtokodne programske opreme. Subversion je v veliko pogledih tudi podoben CVS, ki je bil velikan na področju nadzora nad izvorno kodo pred tem.

Ena od velikih funkcionalnosti Gita je dvosmerna povezava s Subversionom, imenovana git svn. To orodje vam omogoča uporabo Gita kot veljavnega odjemalca strežnika Subversion, tako da lahko uporabljate vse lokalne funkcije Gita in nato potiskate v strežnik Subversion, kot da bi lokalno uporabljali Subversion. To pomeni, da lahko uporabljate lokalno razvejanje in združevanje, uporabljate področje priprave, ponovno baziranje in izbiranje najboljšega (angl. cherry picking) ter druge funkcionalnosti, medtem ko vaši sodelavci še vedno delajo na svoj način. To je dober način za uvedbo Gita v korporativno okolje in tako pomagate svojim sodelavcem postati učinkovitejši, medtem ko se trudite, da bi infrastruktura v celoti podpirala Git. Most Subversion je prehod v svet DVCS.

git svn

Osnovni ukaz v Gitu za vse ukaze povezane s Subversionom je git svn. Prikazali bomo najpogostejše ukaze, medtem ko se bomo sprehajali skozi nekaj preprostih potekov dela.

Pomembno je opozoriti, da pri uporabi git svn komunicirate s sistemom Subversion, ki deluje zelo drugače od Gita. Čeprav lahko izvajate lokalno razvejanje in združevanje, je običajno najbolje ohraniti zgodovino čim bolj linearno z uporabo ponovnega baziranja in izogibanjem stvarem, kot je hkratna interakcija z oddaljenim repozitorijem Git.

Ne spreminjajte svoje zgodovine in da poskusite znova potisniti, prav tako ne potiskajte v vzporedni repozitorij Git za sodelovanje s kolegi sodelavci Git hkrati. Subversion ima lahko samo eno linearno zgodovino in zamenjati jo je zelo enostavno. Če delate z ekipo, pri čemer nekateri uporabljajo SVN in drugi Git, poskrbite, da vsi uporabljajo strežnik SVN za sodelovanje — to vam bo olajšalo življenje.

Nastavitev

Za prikaz te funkcionalnosti potrebujete tipični repozitorij SVN, ki ga lahko urejate. Če želite kopirati te primere, morate ustvariti zapisljivo kopijo testnega repozitorija SVN. Da to enostavno naredite, lahko uporabite orodje, ki ga dobite s Subversionom, imenovano svnsync.

Za nadaljevanje morate najprej ustvariti nov lokalni repozitorij Subversion:

$ mkdir /tmp/test-svn
$ svnadmin create /tmp/test-svn

Nato omogočite vsem uporabnikom, da spreminjajo revprops — enostaven način je dodati skript pre-revprop-change, ki vedno vrne izhodno kodo 0:

$ cat /tmp/test-svn/hooks/pre-revprop-change
#!/bin/sh
exit 0;
$ chmod +x /tmp/test-svn/hooks/pre-revprop-change

Sedaj lahko sinhronizirate ta projekt na vašo lokalno napravo s klicem svnsync init za v in iz repozitorijev.

$ svnsync init file:///tmp/test-svn \
  http://your-svn-server.example.org/svn/

To nastavi lastnosti za zagon sinhronizacije. Nato lahko klonirate kodo s pogonom:

$ 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.
[…]

Čeprav ta operacija lahko traja le nekaj minut, bo proces kopiranja prvotnega repozitorija na drug oddaljeni repozitorij namesto lokalnega trajal skoraj eno uro, kljub temu da je manj kot 100 potrditev. Subversion mora klonirati eno revizijo naenkrat in jo nato potisniti nazaj v drug repozitorij — to je nesmiselno neučinkovito, vendar je to edini enostaven način za izvedbo tega.

Kako začeti

Zdaj, ko imate dostop za pisanje v repozitorij Subversion, lahko začnete s tipičnim potekom dela. Začnete z ukazom git svn clone, ki uvozi celoten repozitorij Subversion v lokalni repozitorij Git. Upoštevajte, da če uvažate iz resničnega gostujočega repozitorija Subversion, morate file:///tmp/test-svn nadomestiti z URL-jem vašega repozitorija Subversion:

$ 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

To izvede ekvivalent dveh ukazov — git svn init in git svn fetch — na naslovu URL, ki ga podate. To lahko traja nekaj časa. Če ima na primer testni projekt približno samo 75 potrditev in koda ni tako velika, mora Git vseeno preveriti vsako različico eno za drugo in jo posamezno potrditi. Za projekt s stotine ali tisoče potrditev lahko to dejansko traja ure ali celo dni, da se dokonča.

Del -T trunk -b branches -t tags pove Gitu, da ta repozitorij Subversion sledi osnovnim konvencijam za razvejanje in označevanje. Če poimenujete svojo glavno vejo, veje ali oznake drugače, lahko spremenite te možnosti. Ker je to tako pogosto, lahko ta celoten del zamenjate s -s, kar pomeni standardni razpored in predpostavlja vse te možnosti. Naslednji ukaz je enakovreden:

$ git svn clone file:///tmp/test-svn -s

V tem trenutku bi morali imeti veljaven repozitorij Git, ki je uvozil vaše veje in oznake:

$ 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

Bodite pozorni, saj to orodje upravlja oznake Subversion kot oddaljene reference. Poglejmo podrobneje Gitov ukaz napeljave 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 tega ne naredi, ko klonira iz strežnika Git; tako je videti repozitorij z oznakami po svežem kloniranju:

$ 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 prinese oznake neposredno v refs/tags, namesto da jih obravnava kot oddaljene veje.

Potrjevanje nazaj v Subversion

Zdaj, ko imate delovno mapo, lahko opravite nekaj dela na projektu in potisnete svoje spremembe nazaj navzgor in učinkovito uporabljate Git kot odjemalca SVN. Če uredite eno od datotek in jo potrdite, imate potrditev, ki obstaja v Gitu lokalno, vendar ne obstaja na strežniku Subversion:

$ git commit -am 'Adding git-svn instructions to the README'
[master 4af61fd] Adding git-svn instructions to the README
 1 file changed, 5 insertions(+)

Naslednji korak je, da svojo spremembo potisnete navzgor. Opazite, kako to spremeni način dela s Subversionom — lahko opravite več potrditev brez povezave in jih nato hkrati potisnete na strežnik Subversion. Za potiskanje na strežnik Subversion izvedete ukaz git svn dcommit:

$ 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

To vzame vse potrditve, ki ste jih naredili na vrhu kode strežnika Subversion, za vsakega naredi potrditev Subversion in nato prepiše vašo lokalno potrditev Git tako, da vključi edinstven identifikator. To je pomembno, saj to pomeni, da se vse kontrolne vsote SHA-1 vaših potrditev spremenijo. Delno iz tega razloga ni dobra ideja, da bi hkrati delali z Gitovimi različicami vaših projektov na daljavo in strežnikom Subversion. Če si ogledate zadnjo potrditev, lahko vidite novi git-svn-id, ki je bil dodan:

$ 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

Opazite, da se kontrolna vsota SHA-1, ki se je prvotno začela s 4af61fd, zdaj začne z 95e0222. Če želite potisniti na strežnik Git in strežnik Subversion, morate najprej potisniti (dcommit) na strežnik Subversion, saj ta dejanja spremenijo vaše podatke potrditve.

Vlečenje novih sprememb

Če delate z drugimi razvijalci, se bo nekoč zgodilo, da bo eden od vas potisnil svoje spremembe, drugi pa bo poskušal potisniti spremembe, ki so v nasprotju s temi. Te spremembe bodo zavrnjene, dokler ne združite njihovega dela. V git svn je to videti tako:

$ 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.

Za rešitev te situacije lahko poženete git svn rebase, ki prenese spremembe na strežniku, ki jih še nimate, in ponovno bazira delo, ki ga imate na vrhu tega, kar je na strežniku:

$ 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.

Zdaj je vse vaše delo na vrhu tistega, kar je na strežniku Subversion, zato lahko uspešno izvedete dcommit:

$ 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

Pomnite, da v primerjavi z Gitom, ki zahteva, da združite zgornje spremembe, ki jih še nimate lokalno, preden lahko potisnete, git svn to naredi le, če so spremembe konfliktne (podobno kot deluje Subversion). Če nekdo drug potisne spremembo v eno datoteko, nato pa vi potisnete spremembo v drugo datoteko, bo vaš dcommit deloval brez težav:

$ 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...

To si je pomembno zapomniti, saj je rezultat stanje projekta, ki ni obstajalo na nobenem od vaših računalnikov, ko ste ga objavili. Če spremembe niso združljive, vendar se prekrivajo brez konfliktov, lahko dobite težave, ki jih je težko diagnosticirati. To je drugače kot pri uporabi strežnika Git — v Gitu lahko stanje v celoti preizkusite na svojem odjemalcu pred objavo, medtem ko pri SVN-ju nikoli ne morete biti prepričani, da sta stanji takoj pred in po potrditvi enaki.

Prav tako morate pognati to ukazno vrstico, da pridobite spremembe s strežnika Subversion, tudi če še niste pripravljeni na potrditev. Za pridobitev novih podatkov lahko zaženete git svn fetch, vendar git svn rebase opravi pridobivanje in nato posodobi vaše lokalne potrditve.

$ 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.

Z občasnim zagonom ukaza git svn rebase zagotovite, da je vaša koda vedno posodobljena. Pri tem morate biti prepričani, da je vaš delovni direktorij čist, ko izvedete ta ukaz. Če imate lokalne spremembe, morate shraniti svoje delo, ali pa ga začasno potrditi, preden zaženete ukaz git svn rebase — sicer bo ukaz prekinjen, če ugotovi, da bo ponovno baziranje povzročilo konflikt med združevanjem.

Težave vej Git

Ko ste seznanjeni z Gitovim potekom dela, boste verjetno ustvarili tematske veje, delali na njih in jih nato združili. Če objavljate na strežniku Subversion prek git svn, boste morda želeli vsakič znova ponovno bazirati svoje delo na eno samo vejo, namesto da bi veje združevali skupaj. Razlog za prednost ponovnega baziranja je, da ima Subversion linearno zgodovino in se ne ukvarja z združevanjem, kot to počne Git, zato git svn sledi le prvi nadrejeni pri pretvarjanju posnetkov v potrditve Subversion.

Recimo, da je vaša zgodovina videti takole: ustvarili ste vejo experiment, naredili dve potrditvi in ju nato združili nazaj v master. Ko naredite dcommit, vidite izpis, kot je ta:

$ 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

Poganjanje dcommit na veji z združeno zgodovino deluje, razen ko si ogledate zgodovino projekta v Gitu, saj ni preoblikoval nobene od sprememb, ki ste jih naredili na veji experiment — namesto tega se vsi ti podatki pojavijo v različici SVN posamezne potrditve združitve.

Ko to delo klonira nekdo drug, vidi le potrditev združitve s celotnim delom stisnjenim vanj, kot da ste izvedli git merge --squash; ne vidi se podatkov o potrditvi, od kod je prišla, ali kdaj je bila potrjena.

Veje Subversion

Veje v Subversionu niso enake kot v Gitu; če ga lahko čim manj uporabljate, je verjetno najbolje. Vendar pa lahko z uporabo git svn ustvarite veje v Subversionu in na njih potrjujete.

Ustvarjanje nove veje SVN

Da ustvarite novo vejo v Subversionu, lahko poženete git svn branch [new-branch]:

$ 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)

To naredi ekvivalent ukaza svn copy trunk branches/opera v Subversionu in deluje na strežniku Subversion. Pomembno je omeniti, da vas to ne izvleče v tisto vejo; če izvedete potrditev v tem trenutku, bo ta potrditev šla v trunk na strežniku, ne v vejo opera.

Preklapljanje aktivnih vej

Git ugotovi, kam gredo vaši dcommiti, tako da išče vrh katerih koli vaših vej Subversion v vaši zgodovini — imeti morate samo eno, in to bi morala biti zadnja z git-svn-id v vaši trenutni veji.

Če želite delati na več kot eni veji hkrati, lahko nastavite lokalne veje, na katerih boste naredili dcommit v določene veje Subversion, tako da jih začnete pri uvoženi potrditvi Subversion za to vejo. Če želite vejo opera, na kateri lahko delate ločeno, lahko zaženete:

$ git branch opera remotes/origin/opera

Če želite združiti vašo vejo opera v trunk (vaša veja master), lahko to storite z običajnim git merge. Vendar morate zagotoviti opisno sporočilo za potrditev (preko -m), sicer bo sporočilo o združevanju »Združi vejo opera« (angl. »Merge branch opera«) namesto nečesa uporabnega.

Pomnite, da čeprav za to operacijo uporabljate git merge in bo združevanje verjetno veliko lažje kot v Subversionu (ker bo Git samodejno zaznal ustrezno osnovo za združevanje), to ni običajna potrditev združevanja Git. Podatke morate potisniti nazaj na strežnik Subversion, ki ne more obdelati potrditve, ki sledi več kot eni nadrejeni; zato bo po potiskanju videti kot ena sama potrditev, ki je združila vsa dela druge veje pod eno potrditev. Po združevanju ene veje v drugo se ne morete enostavno vrniti in nadaljevati dela na tej veji, kot lahko običajno storite v Gitu. Ukaz dcommit, ki ga zaženete, izbriše vse informacije, ki pravijo, katera veja je bila združena, zato bodo naslednji izračuni osnovnih točk za združevanje napačni — dcommit naredi, da je vaš git merge videti, kot da ste zagnali git merge --squash. Na žalost ni dobrega načina za izogibanje tej situaciji — Subversion ne more shraniti teh informacij, zato boste vedno omejeni z njegovimi omejitvami, ko ga uporabljate kot vaš strežnik. Za izogibanje težavam morate po združitvi veje v trunk izbrisati lokalno vejo (v tem primeru opera).

Ukazi Subversion

Orodja git svn ponujajo nekaj ukazov, ki pomagajo olajšati prehod na Git s funkcionalnostjo, ki je podobna tisti, ki ste jo imeli v Subversionu. Tu je nekaj ukazov, ki vam dajo tisto, kar ste imeli v Subversionu.

Zgodovina v stilu SVN

Če ste navajeni na Subversion in želite videti svojo zgodovino v slogu izhoda SVN, lahko za ogled zgodovine vaših potrditev v obliki formata SVN, uporabite ukaz git svn log:

$ 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

Morali bi vedeti dve pomembni stvari o git svn log. Prva je, da deluje brez povezave, v primerjavi s pravim ukazom svn log, ki zaprosi strežnik Subversion za podatke. Druga pomembna lastnost pa je, da prikazuje samo potrditve, ki so bile potrjene na strežniku Subversion. Lokalne spremembe Git, ki jih še niste potrdili z dcommit , se ne prikažejo; prav tako se ne prikažejo spremembe, ki so jih ljudje v tem času potrdili na strežniku Subversion. Je bolj kot zadnje znano stanje potrditev na strežniku Subversion.

Anotacija SVN

Podobno kot ukaz git svn log simulira ukaz svn log brez povezave z omrežjem, lahko z ukazom git svn blame [DATOTEKA] dobite ekvivalent svn annotate. Izpis je videti takole:

$ 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

Ponovno to ne prikazuje potrditev, ki ste jih lokalno opravili v Gitu ali tistih, ki so bile v tem času potisnjene v Subversion.

Informacije strežnika SVN

Podobne informacije, kot jih daje svn info, lahko dobite tudi z zagonom git svn info:

$ 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)

To je podobno kot blame in log, vendar deluje brez internetne povezave in je posodobljeno samo do zadnjega časa, ko ste se zadnjič povezali s strežnikom Subversion.

Ignoriranje, kar ignorira Subversion

Če klonirate repozitorij Subversion, ki ima lastnosti svn:ignore nastavljene kjerkoli, boste verjetno želeli nastaviti ustrezne datoteke .gitignore, da ne boste naključno objavljali datotek, ki jih ne bi smeli. git svn ima dva ukaza, ki pomagata pri tem problemu. Prvi je git svn create-ignore, ki samodejno ustvari ustrezne datoteke .gitignore, tako da jih lahko vključite v naslednjo spremembo.

Drugi ukaz je git svn show-ignore, ki izpiše vrstice, ki jih morate vstaviti v datoteko .gitignore, tako da lahko izhod preusmerite v svojo izključitveno datoteko projekta:

$ git svn show-ignore > .git/info/exclude

Na ta način ne boste raztresli projekta z .gitignore datotekami. To je dobra možnost, če ste edini uporabnik Git v ekipi Subversion in vaši sodelavci ne želijo datotek .gitignore v projektu.

Povzetek Git-Svn

Orodja git svn so uporabna, če ste ujeti s strežnikom Subversion ali pa ste v razvojnem okolju, ki zahteva zagon strežnika Subversion. Vendar ga morate šteti kot osiromašeni Git, saj se boste sicer soočili s težavami pri prevajanju, ki vas in vaše sodelavce lahko zmedejo. Da bi se izognili težavam, poskusite slediti tem smernicam:

  • Ohranite linearno zgodovino Git, ki ne vsebuje potrditev združitev, ustvarjenih z git merge. Vsako delo, ki ga opravite izven glavne veje, ponovno bazirajte na njej; ne združujte ga.

  • Ne nastavljajte in ne sodelujte na ločenem strežniku Git. Morda ga imate, da pospešite kloniranje za nove razvijalce, vendar ne potiskajte nanj ničesar, kar nima vnosa git-svn-id. Morda boste želeli dodati kljuko pre-receive, ki preveri vsako sporočilo potrditve za git-svn-id in zavrne potiskanje potrditev, ki jih ne vsebujejo.

Če sledite tem smernicam, bo delo s strežnikom Subversion bolj znosno. Vendar če je mogoče, preklop na pravi strežnik Git lahko vaši ekipi prinese veliko več.

Git in Mercurial

Vesolje DVCS (porazdeljenega nadzora nad različicami) je večje od samega Gita. Dejansko obstaja veliko drugih sistemov na tem področju, vsak s svojim pristopom, kako pravilno izvajati porazdeljeni nadzor različic. Poleg Gita je najbolj priljubljen Mercurial, oba pa sta si v mnogih pogledih zelo podobna.

Dobra novica, če vam je vedenje odjemalca Gita ljubše, vendar delate na projektu, kjer je koda shranjena v sistemu Mercurial, je, da obstaja način uporabe Gita kot odjemalca za Mercurialov repozitorij. Ker Git na strežniku uporablja daljave, ni presenetljivo, da je ta mostovna povezava implementirana kot pomožni program za daljave. Projekt se imenuje git-remote-hg in najdete ga na spletnem naslovu https://github.com/felipec/git-remote-hg.

git-remote-hg

Najprej morate namestiti git-remote-hg. To v bistvu vključuje odlaganje njegove datoteke nekam v vašo pot, takole:

$ curl -o ~/bin/git-remote-hg \
  https://raw.githubusercontent.com/felipec/git-remote-hg/master/git-remote-hg
$ chmod +x ~/bin/git-remote-hg

… če je ~/bin v vaši $PATH. Git-remote-hg ima še eno odvisnost: knjižnico mercurial za Python. Če imate Python nameščen, je to zelo preprosto:

$ pip install mercurial

Če nimate nameščenega Pythona, obiščite https://www.python.org/ in ga najprej namestite.

Zadnja stvar, ki jo boste potrebovali, je odjemalec Mercurial. Če ga še niste namestili, obiščite https://www.mercurial-scm.org/ in ga namestite.

Zdaj ste pripravljeni za uporabo. Potrebujete samo repozitorij Mercurial, kamor lahko potiskate. Na srečo lahko vsak repozitorij Mercurial deluje na ta način, zato bomo uporabili repozitorij »hello world«, ki ga vsi uporabljajo za učenje Mercuriala:

$ hg clone http://selenic.com/repo/hello /tmp/hello

Začetek

Zdaj, ko imamo ustrezen repozitorij »strežniške strani«, lahko opravimo običajen potek dela. Kot boste videli, sta ta dva sistema dovolj podobna, da ni veliko trenja.

Kot vedno pri Gitu, najprej kloniramo:

$ 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

Opazili boste, da delo z Mercurialovim repozitorijem uporablja standardni ukaz git clone. To je zato, ker git-remote-hg deluje na precej nizki ravni in uporablja podoben mehanizem, kot je implementacija Gitovega protokola HTTP/S (oddaljeni pomočniki). Ker sta Git in Mercurial zasnovana tako, da ima vsak odjemalec polno kopijo zgodovine repozitorija, ta ukaz naredi celotno kopijo, vključno z vso zgodovino projekta, in to relativno hitro.

Ukaz log prikaže dve spremembi, najnovejša od teh je označena z velikim številom referenc. Izkazalo se je, da nekatere od teh referenc dejansko ne obstajajo. Poglejmo, kaj je dejansko v direktoriju .git:

$ 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 skuša stvari narediti bolj v slogu, ki je bolj podoben Gitu, toda v ozadju upravlja osnovno preslikavo med dvema nekoliko drugačnima sistemoma. Mapiranje med oddaljenimi referencami dejansko poteka v mapi refs/hg. Na primer, datoteka z referenco Git refs/hg/origin/branches/default vsebuje SHA-1, ki se začne z »ac7955c«, to pa je tista potrditev, na katero kaže master. Tako je mapa refs/hg nekako lažna različica refs/remotes/origin, vendar ima dodatno razlikovanje med zaznamki in vejami.

Datoteka notes/hg je izhodišče za preslikavo med Gitovimi zgoščenimi vrednostmi potrditev in ID-ji sprememb Mercuriala, ki jih uporablja git-remote-hg. Poglejmo si to nekoliko podrobneje:

$ 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

Torej refs/notes/hg kaže na drevo, ki je v Gitovi objektni bazi podatkov seznam drugih objektov z imeni. git ls-tree izpiše način, vrsto, zgoščeno vrednost objekta in ime datoteke za elemente znotraj drevesa. Ko se potopimo v enega od elementov drevesa, odkrijemo, da je znotraj njega objekt z imenom ac9117f (zgoščena vrednost SHA-1 potrditve, na katero kaže master), z vsebino 0a04b98 (to je ID nabora sprememb Mercurial na vrhu veje default).

Dobra novica je, da se nam s tem večinoma ni treba ukvarjati. Tipičen potek dela ne bo preveč drugačen od dela z oddaljenim repozitorijem Git.

Preden nadaljujemo, moramo rešiti še eno stvar: ignoriranje datotek. Mercurial in Git uporabljata za to zelo podoben mehanizem, vendar verjetno ne želite dejansko shraniti datoteke .gitignore v repozitorij Mercurial. Na srečo ima Git način za ignoriranje datotek, ki je lokalno za posamezen diskovni repozitorij, in format Mercuriala je združljiv z Gitom, zato ga le prekopirajte:

$ cp .hgignore .git/info/exclude

Datoteka .git/info/exclude se obnaša enako kot .gitignore, vendar v potrditvah ni vključena.

Potek dela

Naj predpostavimo, da smo opravili nekaj dela in naredili nekaj potrditev na veji master ter ste pripravljeni, da jih pošljete na oddaljeni repozitorij. Tako je videti naš repozitorij trenutno:

$ 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

Naša veja master je dva predhodnika pred origin/master, toda ti dve potrditvi obstajata le na našem lokalnem računalniku. Poglejmo, ali je kdo drug v istem času opravljal kakšno pomembno delo:

$ 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

Ker smo uporabili zastavico --all, vidimo tudi reference »notes«, ki jih uporablja git-remote-hg, vendar jih lahko ignoriramo. Preostalo je tako, kot smo pričakovali; origin/master se je premaknil za eno potrditev in naša zgodovina se je zdaj razcepila. V primerjavi z drugimi sistemi, s katerimi delamo v tem poglavju, lahko Mercurial upravlja združevanja, zato ne bomo počeli ničesar zapletenega.

$ 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

Odlično. Zaženemo teste in vse poteka brez napak, zato smo pripravljeni deliti svoje delo z ostalimi člani ekipe:

$ git push
To hg::/tmp/hello
   df85e87..0c64627  master -> master

To je vse! Če si ogledamo repozitorij Mercurial, vidimo, da je ta ukaz storil, kar smo pričakovali:

$ 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

Spremenitve z oznako 2 so bile narejene z Mercurialom, spremembe z oznakami 3 in 4 pa so bile narejene z git-remote-hg, s pomočjo potiskanja potrditev, narejenih z Gitom.

Veje in zaznamki

Git ima samo eno vrsto veje: referenco, ki se premika, ko so narejene potrditve. V Mercurialu se ta vrsta reference imenuje »zaznamek« (angl. bookmark) in se obnaša podobno kot Gitova veja.

Mercurialova zasnova »veje« je bolj obremenjujoča. Veja, na kateri je bil narejen nabor sprememb, je zabeležena z naborom sprememb, kar pomeni, da bo vedno v zgodovini repozitorija. Tu je primer za potrditev, ki je bila izvedena na veji develop:

$ 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

Poglejte vrstico, ki se začne z »branch«. Git tega ne more dejansko ponoviti (in tudi ne potrebuje; oba tipa vej lahko predstavimo kot Git ref), vendar mora git-remote-hg razumeti razliko, saj Mercurial skrbi za to.

Ustvarjanje zaznamkov Mercurial je enostavno, kot ustvarjanje vej Git. Na strani Git:

$ git checkout -b featureA
Switched to a new branch 'featureA'
$ git push origin featureA
To hg::/tmp/hello
 * [new branch]      featureA -> featureA

To je vse, kar spada sem. Na strani Mercurial je videti takole:

$ 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

Opazite novo oznako [featureA] v reviziji 5. Te se obnašajo enako kot veje Git na strani Git, do ene izjeme: iz Gitove strani ne morete izbrisati zaznamka (to je omejitev oddaljenih pomočnikov).

Prav tako lahko delate na »težkih« vejah Mercurial: preprosto postavite vejo v imenski prostor branches:

$ 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

Takole bo videti stran Mercurial:

$ 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'
[...]

Ime veje »permanent« je bilo zabeleženo z označenim naborom sprememb 7.

S stališča Gita je delo z enim od teh načinov vej enako: preprosto izvlečete, potrdite, pridobite, združite, povlečete in potisnite, kot bi sicer storili. Ena stvar, ki jo morate vedeti, je, da Mercurial ne podpira ponovnega pisanja zgodovine, ampak samo dodajanje k njej. Tako je videti naš repozitorij Mercurial po interaktivnem ponovnem baziranju in prisilnem potiskanju:

$ 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

Nabori sprememb 8, 9 in 10 so bili ustvarjeni in spadajo v vejo permanent, vendar so stari nabori sprememb še vedno tam. To lahko zelo zmede vaše sodelavce, ki uporabljajo Mercurial, zato se temu poskusite izogniti.

Povzetek Mercurial

Git in Mercurial sta dovolj podobna, da je delo prek meje precej neboleče. Če se izogibate spreminjanju zgodovine, ki je že zapustila vaš računalnik (kar je običajno priporočljivo), morda sploh ne boste vedeli, da je drugi konec Mercurial.

Git in Perforce

Perforce je zelo priljubljen sistem za nadzor različic v korporativnih okoljih. Obstaja že od leta 1995, kar ga uvršča med najstarejše sisteme, ki so obravnavani v tem poglavju. Zasnovan je bil z omejitvami njegovega časa; predpostavlja, da ste vedno povezani z enim samim osrednjim strežnikom in da je na lokalnem disku shranjena le ena različica. Njegove lastnosti in omejitve so zagotovo primerne za več specifičnih problemov, vendar obstaja veliko projektov, kjer bi Git dejansko deloval bolje kot Perforce.

Če želite kombinirati uporabo Perforce in Gita, imate na voljo dve možnosti. Prva, o kateri bomo govorili, je most »Git Fusion« izdelovalcev Perforce, ki vam omogoča izpostavljanje poddreves repozitorija Perforce kot bralno-pisalnega repozitorija Git. Druga možnost pa je git-p4, most na strani odjemalca, ki vam omogoča uporabo Gita kot odjemalca Perforce, brez potrebe po ponovni konfiguraciji strežnika Perforce.

Git Fusion

Perforce ponuja izdelek, imenovan Git Fusion (dostopen na https://www.perforce.com/manuals/git-fusion), ki sinhronizira strežnik Perforce z repozitoriji Git na strežniški strani.

Nastavitev

Za svoje primere bomo uporabili najlažjo namestitveno metodo Git Fusion in sicer prenos virtualne naprave, ki poganja prikriti proces Perforce in Git Fusion. Sliko virtualne naprave lahko dobite na https://www.perforce.com/downloads in ko se prenos konča, ga uvozite v svoj najljubši program za virtualizacijo (uporabili bomo VirtualBox).

Ob prvem zagonu naprave vas prosi, da prilagodite geslo za tri uporabnike v sistemu Linux (root, perforce in git) ter podate ime instance, ki se lahko uporabi za razlikovanje te namestitve od drugih v istem omrežju. Ko je vse to dokončano, boste videli to:

Zagonski zaslon virtualne naprave Git Fusion
Slika 171. Zagonski zaslon virtualne naprave Git Fusion

Zabeležiti si morate IP-naslov, ki je prikazan tukaj, saj ga bomo kasneje uporabili. Naslednji korak je ustvarjanje uporabnika Perforce. Izberite možnost »Login« na dnu in pritisnite enter (ali se povežite na napravo preko SSH) ter se prijavite kot root. Uporabite naslednje ukaze za ustvarjanje uporabnika:

$ p4 -p localhost:1666 -u super user -f john
$ p4 -p localhost:1666 -u john passwd
$ exit

Prvi ukaz bo odprl urejevalnik VI za prilagajanje uporabnika, vendar lahko sprejmete privzete vrednosti tako, da vpišete :wq in pritisnete enter. Drugi ukaz vas bo pozval, da dvakrat vnesete geslo. To je vse, kar morate narediti s pomočjo ukazne lupine, zato zapustite sejo.

Naslednje, kar morate storiti, da boste lahko sledili navodilom, je, da Gitu poveste, naj ne preverja certifikatov SSL. Slika Git Fusion ima certifikat, vendar je namenjen domeni, ki se ne ujema z IP-naslovom vaše virtualne naprave, zato Git zavrne povezavo HTTPS. Če bo to trajna namestitev, se obrnite na priročnik za Perforce Git Fusion, da namestite drugačen certifikat; za naš namen bo to zadostovalo:

$ export GIT_SSL_NO_VERIFY=true

Sedaj lahko stestiramo, če vse deluje.

$ 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.

Slika virtualne naprave je opremljena s primerom projekta, ki ga lahko klonirate. Tukaj ga kloniramo prek HTTPS, z uporabnikom john, ki smo ga ustvarili zgoraj; Git vas bo zaprosil za poverilnice za to povezavo, vendar bo predpomnilnik poverilnic omogočil, da boste lahko preskočili ta korak za vsa nadaljnja zahtevanja.

Nastavitev Fusiona

Ko ste namestili Git Fusion, boste želeli prilagoditi konfiguracijo. To je dejansko precej enostavno storiti z vašim najljubšim odjemalcem Perforce; preprosto preslikajte imenik //.git-fusion na strežniku Perforce v svoj delovni prostor. Struktura datotek je videti tako:

$ tree
.
├── objects
│   ├── repos
│   │   └── [...]
│   └── trees
│       └── [...]
│
├── p4gf_config
├── repos
│   └── Talkhouse
│       └── p4gf_config
└── users
    └── p4gf_usermap

498 directories, 287 files

Imenik objects se interno uporablja v Git Fusion za preslikovanje objektov Perforce v Git in obratno; tam vam ne bo treba ničesar spreminjati. V tem imeniku je globalna datoteka p4gf_config, pa tudi ena za vsak repozitorij — to so konfiguracijske datoteke, ki določajo, kako se obnaša Git Fusion. Poglejmo si datoteko v korenskem imeniku:

[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

Tu ne bomo razlagali pomena teh zastavic, vendar bodite pozorni, saj gre za besedilno datoteko oblikovano v formatu INI, podobno kakršno Git uporablja za konfiguracijo. Ta datoteka določa globalne možnosti, ki jih lahko nato preglasijo konfiguracijske datoteke specifične za posamezen repozitorij, kot je repos/Talkhouse/p4gf_config. Če odprete to datoteko, boste videli odsek [@repo] z nekaterimi nastavitvami, ki se razlikujejo od globalnih privzetih. Videli boste tudi odseke, ki so videti takole:

[Talkhouse-master]
git-branch-name = master
view = //depot/Talkhouse/main-dev/... ...

To je preslikava med vejami Perforce in vejami Git. Odsek se lahko imenuje poljubno, dokler je ime edinstveno. git-branch-name omogoča pretvorbo poti depoja (angl. depot) v bolj prijazno ime, saj bi bilo pod Gitom nerodno. Nastavitev view nadzoruje, kako so datoteke iz Perforce preslikane v repozitorij Git, pri čemer se uporablja standardna sintaksa preslikave pogledov. Določite lahko več preslikav kot v tem primeru:

[multi-project-mapping]
git-branch-name = master
view = //depot/project1/main/... project1/...
       //depot/project2/mainline/... project2/...

Tako lahko, če običajna preslikava delovnega prostora vključuje spremembe v strukturi map, to replicirate z repozitorijem Git.

Zadnja datoteka, o kateri bomo razpravljali, je users/p4gf_usermap, ki preslika uporabnike Perforce v uporabnike Git, in ki je morda sploh ne boste potrebovali. Pri pretvorbi iz nabora sprememb Perforce v potrditev Git, je privzeto obnašanje Git Fusiona, da poišče uporabnika Perforce in uporabi tam shranjen e-poštni naslov in polno ime za polje avtorja/potrjevalca v Gitu. Pri pretvorbi v drugo smer pa privzeto poišče uporabnika Perforce z e-poštnim naslovom, shranjenim v polju avtorja potrditve Git, in pošlje nabor sprememb kot tega uporabnika (s primernimi dovoljenji). V večini primerov bo ta način obnašanja povsem dovolj, vendar upoštevajte naslednjo preslikovalno datoteko:

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"

Vsaka vrstica je oblike <uporabnik> <e-pošta> "<polno ime>" in ustvari eno preslikavo uporabnika. Prvi dve vrstici preslikata dva različna e-poštna naslova v isti uporabniški račun Perforce. To je uporabno, če ste ustvarili potrditve Git pod več različnimi e-poštnimi naslovi (ali spremenili e-poštni naslov), vendar jih želite preslikati v istega uporabnika Perforce. Pri ustvarjanju potrditve Git iz nabora sprememb Perforce se prva vrstica, ki ustreza uporabniku Perforce, uporabi za informacije Git o avtorju.

Zadnji dve vrstici prikrijeta prava imena in e-poštne naslove Boba in Joeja iz potrditev Git, ki so ustvarjeni. To je koristno, če želite narediti izvorno kodo internega projekta odprtokodno, vendar ne želite objaviti svojega imenika zaposlenih celotnemu svetu. Upoštevajte, da morajo biti e-poštni naslovi in polna imena edinstveni, razen če želite, da se vse potrditve Git pripisujejo enemu fiktivnemu avtorju.

Potek dela

Perforce Git Fusion je dvosmerna povezava med nadzorom različic Perforce in Git. Poglejmo, kako se počutimo pri delu s strani Gita. Predpostavimo, da smo preslikali projekt »Jam« z uporabo konfiguracijske datoteke, kot je prikazano zgoraj, in ga lahko kloniramo na naslednji način:

$ 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.
[...]

Prvič, ko to storite, lahko traja nekaj časa. Kar se dogaja, je, da Git Fusion pretvarja vse ustrezne spremembe v zgodovini Perforce v potrditve Git. To se dogaja lokalno na strežniku, zato je relativno hitro, vendar če imate veliko zgodovine, lahko še vedno traja nekaj časa. Nadaljnje pridobitve izvajajo postopno pretvorbo, zato bo občutek bolj kot domača hitrost Gita.

Kot vidite, naš repozitorij je videti enako kot kateri koli drugi repozitorij Git, s katerim lahko delate. Obstajajo tri veje in Git je prijazno ustvaril lokalno vejo master, ki sledi origin/master. Naredimo nekaj dela in ustvarimo nekaj novih potrditev:

# ...
$ 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.
[...]

Sedaj imamo dve novi potrditvi. Sedaj preverimo, ali je delal še kdo:

$ 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.
[...]

Videti je, da nekdo je! S te perspektive tega ne bi vedeli, vendar je bila potrditev 6afeb15 ustvarjena z uporabo odjemalca Perforce. Za Git pa zgleda kot katerakoli druga potrditev, kar je pravzaprav cilj. Poglejmo, kako se strežnik Perforce spopade s potrditvijo združitve:

$ 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 misli, da je to delovalo. Poglejmo zgodovino datoteke README iz zornega kota Perforca z uporabo lastnosti revizijskega grafa p4v:

Revizijski graf Perforce, ki izhaja iz potiskanja Git
Slika 172. Revizijski graf Perforce, ki izhaja iz potiskanja Git

Če tega pogleda še niste videli, se vam lahko zdi zmeden, toda prikazuje iste zasnove kot grafični prikazovalnik zgodovine Gita. Gledamo zgodovino datoteke README, zato nam drevesna struktura v zgornjem levem kotu prikazuje samo to datoteko, ki se pojavlja v različnih vejah. Na zgornjem desnem delu imamo vizualni graf, kako so povezane različne različice datoteke, in celostni pogled na ta graf je na spodnjem desnem delu. Preostanek prikaza je namenjen podrobnostim za izbrano revizijo (v tem primeru 2).

Ena stvar, ki jo je treba opaziti, je, da se graf zdi povsem enak kot v Gitovi zgodovini. Perforce ni imel imenovane veje, kjer bi shranil potrditvi 1 in 2, zato je ustvaril vejo »anonymous« v imeniku .git-fusion. To se bo zgodilo tudi za imenovane veje Git, ki se ne ujemajo z imenovano vejo Perforce (kasneje pa jih lahko preslikate na vejo Perforce z uporabo konfiguracijske datoteke).

Večina tega se zgodi za zavesami, vendar končni rezultat je, da lahko ena oseba v ekipi uporablja Git, druga pa lahko Perforce in nobena izmed njiju bo vedela o izbiri drug drugega.

Povzetek Git-Fusion

Če imate (ali lahko dobite) dostop do vašega strežnika Perforce, je Git Fusion odličen način, da Git in Perforce komunicirata med seboj. Vključeno je malo konfiguracije, vendar krivulja učenja ni zelo strma. To je eden od redkih delov tega poglavja, kjer opozorila o uporabi celotne zmogljivosti Gita ne bodo navedena. To ne pomeni, da bo Perforce vesel vsega, kar boste poslali vanj — če poskušate preoblikovati zgodovino, ki je že bila poslana, jo bo Git Fusion zavrnil — toda Git Fusion se trudi, da bi bil občutek naraven. Lahko celo uporabite podmodule Git (čeprav bodo za uporabnike Perforce videti čudno) in združite veje (to bo zabeleženo kot integracija na strani Perforce).

Če ne morete prepričati administratorja svojega strežnika, da nastavi Git Fusion, še vedno obstaja način, kako ta orodja uporabiti skupaj.

Git-p4

Git-p4 je most med Gitom in Perforceom v dveh smereh. Deluje v celoti znotraj vašega repozitorija Git, zato ne boste potrebovali nobene vrste dostopa do strežnika Perforce (razen seveda uporabniških poverilnic). Git-p4 ni tako prilagodljiva ali popolna rešitev tako kot Git Fusion, vendar vam omogoča, da večino tega, kar bi radi storili, izvedete brez poseganja v okolje strežnika.

Opomba

Da boste lahko delali z git-p4, boste potrebovali orodje p4 nekje v vaši poti PATH. V času tega pisanja je prosto dostopno na https://www.perforce.com/downloads/helix-command-line-client-p4.

Nastavitev

Za namene primerov bomo zagnali strežnik Perforce iz Git Fusion OVA, kot je prikazano zgoraj, vendar bomo zaobšli strežnik Git Fusion in neposredno dostopali do nadzora različic Perforce.

Da bi lahko uporabljali ukazno vrstico p4 (odvisna je od git-p4), boste morali nastaviti nekaj okoljskih spremenljivk:

$ export P4PORT=10.0.1.254:1666
$ export P4USER=john
Kako začeti

Kot z vsem v Gitu je prvi ukaz kloniranje:

$ 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

To ustvari »površinski« (angl. shallow) klon v izrazoslovju Git; v Git uvozimo samo najnovejšo revizijo Perforce; spomnimo se, da Perforce ni zasnovan tako, da bi vsakemu uporabniku zagotovil vsako revizijo. To je dovolj za uporabo Gita kot odjemalca Perforce, vendar za druge namene ni dovolj.

Ko je postopek končan, imamo popolnoma funkcionalni repozitorij Git:

$ 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

Opazite, da obstaja »p4« oddaljeno mesto za strežnik Perforce, vendar vse drugo je videti kot običajen klon. V resnici pa je to nekoliko zavajajoče; tam v resnici ni oddaljenega mesta.

$ git remote -v

V tem repozitoriju sploh ni oddaljenih mest. Git-p4 je ustvaril nekaj referenc, ki predstavljajo stanje strežnika, in so videti kot oddaljene reference v git log, vendar jih Git sam ne upravlja in nanje ne morete potiskati.

Potek dela

V redu, opravimo nekaj dela. Predpostavimo, da ste naredili nekaj napredka pri zelo pomembni funkciji in ste pripravljeni, da jo pokažete drugim v svoji ekipi.

$ 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

Naredili smo dve novi potrditvi, ki ju želimo poslati na strežnik Perforce. Preverimo, ali je še kdo drug danes delal:

$ 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

Videti je, da sta se različna razvoja master in p4/master razšla. Perforceov sistem razvejanja ni nič podoben Gitovemu, zato predložitev potrditev združitev nima smisla. Git-p4 priporoča, da pred predložitvijo ponovno bazirate svoje potrditve, za to pa ima celo pripravljeno bližnjico:

$ 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(-)

Iz izhodnih sporočil lahko že razberete, vendar git p4 rebase pomeni bližnjico za git p4 sync, ki ji sledi git rebase p4/master. Je nekoliko pametnejše kot to, zlasti pri delu z več vejami, vendar je to dober približek.

Sedaj je naša zgodovina spet linearna in pripravljeni smo prispevati svoje spremembe nazaj v Perforce. Ukaz git p4 submit bo poskušal ustvariti novo revizijo Perforce za vsako potrditev Git med p4/master in master. Zagon ukaza nas spusti v naš najljubši urejevalnik, vsebina datoteke pa je nekaj podobnega temu:

# 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>

To bi bilo večinoma enako, kot bi videli, če bi zagnali p4 submit, razen zadnjega dela, ki ga je git-p4 prijazno vključil. Git-p4 poskuša upoštevati vaše nastavitve za Git in Perforce ločeno, kadar mora zagotoviti ime za potrditev ali nabor sprememb, vendar v nekaterih primerih želite to preglasiti. Na primer, če je bila potrditev Git, ki jo uvažate, napisana s strani sodelavca, ki nima uporabniškega računa Perforce, želite morda, da je videti, kot da so ga napisali oni (in ne vi).

Git-p4 je prijazno uvozil sporočilo iz potrditve Git kot vsebino tega nabora spremembe Perforce, zato moramo le shraniti in zapustiti, dvakrat (enkrat za vsako potrditev). Rezultat izhoda lupine bo nekaj takega:

$ 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

Rezultat je tak, kot da bi pravkar izvedli git push, kar je najbližja analogija temu, kar se je dejansko zgodilo.

Upoštevajte, da se med tem postopkom vsaka potrditev Git pretvori v nabor sprememb Perforce; če jih želite stisniti v en sam nabor sprememb, to lahko storite s pomočjo interaktivnega zaslona ponovnega baziranja pred zagonom git p4 submit. Poleg tega bodite pozorni na to, da se zgoščene vrednosti SHA-1 vseh potrditev, ki so bile predložene kot nabori sprememb, spremenijo; to je zato, ker git-p4 dodaja vrstico na konec vsake pretvorjene potrditve:

$ 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]

Kaj se zgodi, če poskusite poslati potrditev združitve? Poskusimo. Tu je situacija, v katero smo se vpletli:

$ 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

Zgodovina Git in Perforce se začneta razhajati po potrditvi 775a46f. Na Gitovi strani imamo dve potrditvi, nato potrditev združitve z glavo Perforca in še eno potrditev. Poskusimo jih zdaj predložiti (angl. submit) na stran Perforce na vrh enega samega nabora spremembe. Poglejmo, kaj bi se zgodilo, če bi poskusili predložiti zdaj:

$ 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

Zastavica -n je kratka oblika za --dry-run, ki poskusi poročati, kaj bi se zgodilo, če bi ukaz za predložitev dejansko tekel. V tem primeru se zdi, da bi ustvarili tri spremembe Perforce, ki se ujemajo s tremi potrditvami nezdružitev, ki še ne obstajajo na strežniku Perforce. To se zdi točno tisto, kar želimo, torej poglejmo, kako se izkaže:

$ 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

Naša zgodovina je postala linearna, tako kot bi bilo po ponovnem baziranju pred predložitvijo (kar je dejansko tudi res). To pomeni, da lahko ustvarjate, delate, zavržete in združujete veje na strani Git, ne da bi se bali, da bo vaša zgodovina na kakršenkoli način postala nezdružljiva s Perforceom. Če lahko ponovno bazirate, lahko prispevate k strežniku Perforce.

Veje

Če ima vaš projekt v Perforcu več vej, imate srečo; git-p4 lahko to obdela na način, ki se zdi kot Git. Recimo, da je vaš depo (angl. depot) Perforce urejen takole:

//depot
  └── project
      ├── main
      └── dev

In recimo, da imate vejo dev, ki ima specifikacijo pogleda, ki je videti takole:

//depot/project/main/... //depot/project/dev/...

Git-p4 lahko samodejno zazna to situacijo in naredi pravo stvar:

$ 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

Opazite določevalec »@all« v poti depoja; to pove git-p4, naj ne klonira samo najnovejšega nabora sprememb za to poddrevo, temveč celoten nabor sprememb, ki so se kdaj koli dotaknile teh poti. To je bližje zasnovi kloniranja v Gitu, vendar lahko pri delu na projektu z dolgo zgodovino to traja nekaj časa.

Zastavica --detect-branches pove git-p4, naj uporabi specifikacije vej Perforce za preslikavo vej na reference Git. Če te preslikave niso prisotne na strežniku Perforce (kar je povsem veljaven način uporabe Perforce), lahko git-p4 pove, kaj so preslikave vej in dosežete enak rezultat:

$ 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 .

Nastavljanje konfiguracijske spremenljivke git-p4.branchList na main:dev pove git-p4, da sta main in dev obe veji in da je druga veja potomec prve.

Če zdaj naredimo git checkout -b dev p4/project/dev in naredimo nekaj potrditev, bo git-p4 dovolj pameten, da bo pravilno ciljal na pravo vejo, ko bomo izvedli git p4 submit. Na žalost git-p4 ne more mešati površinskih klonov in več vej; če imate ogromen projekt in želite delati na več kot eni veji, boste morali git p4 clone izvesti enkrat za vsako vejo, v katero želite predložiti.

Za ustvarjanje ali integracijo vej boste morali uporabiti odjemalca Perforce. Git-p4 lahko samo sinhronizira in predloži obstoječe veje in to lahko stori samo po eno linearno spremembo hkrati. Če združite dve veji v Git in poskušate predložiti novo zbirko sprememb, bo zabeleženo samo nekaj sprememb datotek; izgubljeni bodo metapodatki o tem, katere veje so vključene v integracijo.

Povzetek Gita in Perforca

Git-p4 omogoča uporabo poteka dela Git s strežnikom Perforce in je pri tem zelo učinkovit. Vendar pa je pomembno vedeti, da je Perforce odgovoren za vir in da uporabljate Git le lokalno. Bodite previdni pri deljenju potrditev Git; če imate oddaljeni repozitorij, ki ga uporabljajo druge osebe, ne potiskajte nobenih potrditev, ki še niso bile predložene na strežnik Perforce.

Če želite prosto mešati uporabo Perforce in Git kot odjemalcev za nadzor izvorne kode, in če lahko prepričate upravitelja strežnika, da ga namesti, lahko uporabite Git Fusion, ki omogoča uporabo Git kot odjemalca za strežnik Perforce.

scroll-to-top