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.
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.
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-svnNato 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-changeSedaj 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.
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 r75To 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 -sV 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/trunkBodite 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/trunkGit 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.0Git prinese oznake neposredno v refs/tags, namesto da jih obravnava kot oddaljene veje.
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/trunkTo 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-21af03df0a68Opazite, 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.
Č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/trunkPomnite, 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.
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/trunkPoganjanje 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 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.
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.
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).
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.
Č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 changelogMorali 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.
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 temporalPonovno to ne prikazuje potrditev, ki ste jih lokalno opravili v Gitu ali tistih, ki so bile v tem času potisnjene v Subversion.
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.
Č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/excludeNa 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.
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 kljukopre-receive, ki preveri vsako sporočilo potrditve zagit-svn-idin 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č.