9.1 Git en andere systemen - Git als een client

Het basis commando in Git voor alle Subversion bridging commando’s is git svn. Het accepteert best wel veel commando’s, dus we laten de meest gebruikte zien terwijl we een aantal eenvoudige workflows behandelen.

Het is belangrijk om op te merken dat wanneer je git svn gebruikt, je interacteert met Subversion, wat een systeem is dat behoorlijk anders werkt dan Git. Alhoewel je lokaal kunt branchen en mergen, is het over het algemeen het beste om je historie zo lineair als mogelijk te houden door je werk te rebasen, en te vermijden dat je zaken doet als het tegelijkertijd interacteren met een remote repository in Git.

Ga niet je historie overschrijven en dan weer proberen te pushen, en push niet tegelijk naar een parallelle Git repository om samen te werken met andere Git ontwikkelaars. Subversion kan alleen maar een lineaire historie aan, en het is eenvoudig om het in de war te brengen. Als je met een team samenwerkt, en sommigen gebruiken SVN en anderen gebruiken Git, zorg er dan voor dat iedereen de SVN server gebruikt om samen te werken - als je dit doet wordt je leven een stuk aangenamer.

Om deze functionaliteit te laten zien, heb je een typische SVN repository nodig waar je schrijfrechten op hebt. Als je deze voorbeelden wilt kopiëren, moet je een schrijfbare kopie maken van een SVN test repository. Om dat eenvoudig te doen, kan je een tool svnsync genaamd gebruiken die bij Subversion wordt geleverd.

Om het te volgen, moet je eerst een nieuwe lokale Subversion repository maken:

Daarna moet je alle gebruikers toestaan om revprops te wijzigen - een makkelijke manier is om een pre-revprop-change toe te voegen die altijd met 0 afsluit:

Je kunt dit project nu synchroniseren naar je lokale machine door svnsync init aan te roepen met de naar en van repositories.

Dit richt de properties in om de synchronisatie te laten lopen. Je kunt dan de code clonen door het volgende te doen

Alhoewel deze handeling maar enkele minuten in beslag neemt, zal het proces, als je de orginele repository naar een andere remote repository probeert te kopiëren, bijna een uur in beslag nemen, zelfs als er minder dan 100 commits zijn. Subversion moet een revisie per keer kopiëren en deze dan naar de andere repository pushen - het is belachelijk inefficiënt, maar het is de enige makkelijke manier om dit te doen.

Nu je een Subversion repository hebt waar je schrijfrechten op hebt, kan je een typische workflow gaan volgen. Je begint met het git svn clone commando, die een hele Subversion repository importeert naar een lokale Git repository. Onthoud dat als je van een echte gehoste Subversion repository importeert, je de file:///tmp/test-svn moet vervangen met de URL van je Subversion repository:

Dit roept het equivalent van twee commando’s aan - git svn init gevolgd door git svn fetch - op de URL die je opgeeft. Dit kan even duren. Bijvoorbeeld, als het project maar ongeveer 75 commits heeft en de codebase is niet zo groot, maar Git moet elke versie uitchecken, een voor een, en deze allemaal individueel committen. Voor een project met honderden of duizenden commits, kan dit letterlijk uren of zelfs dagen in beslag nemen voor het klaar is.

Het -T trunk -b branches -t tags gedeelte vertelt Git dat deze Subversion repository de normale branch en tag conventies volgt. Als je jouw trunk, branches of tags andere namen geeft, kan je deze opties veranderen. Omdat dit zo gewoonlijk is, kan je dit gehele gedeelte vervangen met -s, wat standaard indeling betekent en al die opties impliceert. Het volgende commando doet hetzelfde:

Op dit punt zou je een valide Git repository moeten hebben die jouw branches en tags heeft geïmporteerd.

Merk op hoe dit instrument Subversion tags als remote refs beheert. Laten we het Git binnenwerk commando show-ref gebruiken om het iets nauwkeuriger te bekijken:

Git doet dit niet als het van een Git server kloont; zo ziet een repository met tags eruit na een verse clone:

Git fetched de tags direct naar refs/tags, in plaats van ze te behandelen als remote branches.

Nu je een werkende repository hebt, kan je wat werk doen op het project en je commits terug stroomopwaarts pushen, waarbij je Git feitelijk als een SVN client gebruikt. Als je een van de bestanden hebt gewijzigd en deze commit, heb je een commit die lokaal in Git bestaat, maar die niet op de Subversion server bestaat:

Nu moet je jouw wijziging stroomopwaarts pushen. Merk op dat dit de manier waarop je met Subversion werkt wijzigt - je kunt verschillende commits offline doen en ze dan allemaal in een keer naar de Subversion server pushen. Om naar een Subversion server te pushen, roep je het git svn dcommit commando aan:

Dit pakt alle commits die je hebt gemaakt bovenop de Subversion server code, maakt een Subversion commit voor elk van deze, en herschrijft je lokale Git commit om een unieke referentienummer in te voegen. Dit is belangrijk omdat dit betekent dat al de SHA-1 checksums voor je lokale commits zal wijzigen. Deels om deze reden, is het werken met Git-gebaseerde remote versies van je project tegelijk met een Subversion server geen goed idee. Als je naar de laatste commit kijkt, kan je het nieuwe git-svn-id zien die was toegevoegd:

Merk op dat de SHA-1 checksum die oorspronkelijk begon met 4af61fd toen je ging committen nu begint met 95e0222. Als je zowel naar een Git server als een Subversion server wilt pushen, moet je eerst anar de Subversion server pushen (dcommit), omdat deze actie je commit gegevens wijzigt.

Als je met andere ontwikkelaars werkt, dan zal op een gegeven moment iemand van jullie gaan pushen, en dan zal de ander een wijziging proberen te pushen die conflicteert. Die wijziging zal afgewezen worden totdat je hun werk merget. In git svn ziet dit er zo uit:

Om deze situatie op te lossen, kan je git svn rebase uitvoeren, die alle wijzigingen op de server pullt die je nog niet hebt, en rebaset al het werk dat je hebt bovenop hetgeen op de server is:

Nu is al jouw werk uitgevoerd bovenop hetgeen wat op de Subversion server staat, dus je kunt met goed gevolg dcommit doen:

Merk op dat, in tegenstelling tot Git die vereist dat je werk van stroomopwaarts dat je lokaal nog niet hebt merget voordat je kunt pushen, git svn je dat alleen verplicht te doen als de wijzigingen conflicteren (vergelijkbaar met hoe Subversion werkt). Als iemand een wijziging op een bestand pushed en jij pushed een wijziging op een ander bestand, zal je dcommit prima werken:

Dit is belangrijk om te onthouden, omdat de uitkomst een project status is die niet eerder bestond op een van jullie computers toen jij pushde. Als de wijzigingen niet compatible zijn, maar geen conflict veroorzaken, kan je problemen krijgen die moeilijk te diagnostiseren zijn. Dit verschilt met de manier van werken met een Git server - in Git kan je de situatie op je lokale werkstation testen voordat je het publiceert, terwijl in SVN, je er nooit zeker van kunt zijn dat de situatie direct voor en na een commit gelijk zijn.

Je kunt ook dit commando aanroepen om wijzigingen binnen te halen van de Subversion server, zelfs als je zelf nog niet klaar bent om te committen. Je kunt git svn fetch aanroepen om de nieuwe gegevens te pakken, maar git svn rebase doet de fetch en werkt daarna je lokale commits bij.

Regelmatig git svn rebase aanroepen verzekert je ervan dat je code altijd is bijgewerkt. Je moet er echter zeker van zijn dat je werk directory schoon is als je dit aanroept. Als je lokale wijzigingen hebt, moet je je werk stashen of tijdelijk committen voordat je git svn rebase aanroept - anders zal het commando stoppen als het ziet dat de rebase in een merge conflict zal resulteren.

Als je je op je gemak voelt met een Git workflow, zal je waarschijnlijk topic branches maken, daar werk op doen en ze dan weer in mergen. Als je anar een Subversion server pushed met git svn, dan is het waarschijnlijk verstandig om je werk elke keer op een enkele branch te rebasen in plaats van branches samen te mergen. De achterliggende reden om rebasen te gebruiken is dat Subversion een lineaire historie kent en niet met merges omgaat zoals Git dit doet, dus git svn volgt alleen de eerste ouder als het de snapshots naar Subversion commits converteert.

Stel dat je historie er als volgt uitziet: je hebt een experiment-branch gemaakt, heb daar twee commits gedaan, en deze daarna terug in master gemerged. Als je dcommit doet, zie je uitvoer als dit:

Het aanroepen van dcommit op een branch met gemergde historie werkt prima, behalve als je naar je Git project historie kijkt, heeft het geen van beide commits die je op de experiment-branch gemaakt hebt herschreven - in plaats daarvan komen al deze wijzigingen als een enkele merge commit in de SVN versie.

Als iemand anders dat werk kloont, is alles wat ze zien de merge commit met al het werk erin gepropt, alsof je git merge --squash aangeroepen hebt; ze zien niet de commit gegevens over waar het vandaan kwam of wanneer het was gecommit.

Branches maken in Subversion is niet hetzelfde als branches maken in Git; als je kunt voorkomen dat je het vaak doet, is dat eigenlijk wel het beste. Echter, je kunt in Subversion branches maken en ernaar committen met git svn.

Om een nieuwe branch in Subversion te maken, roep je git svn branch [branchnaam] aan:

Dit is het equivalent van het svn copy trunk branches/opera commando in Subversion en wordt uitgevoerd op de Subversion server. Het is belangrijk op te merken dat dit je niet uitcheckt in die branch; als je op dat moment gaat committen, dan zal die commit naar trunk gaan op de server, niet opera.

Git probeert uit te vinden naar welke branch je dcommits gaan door te kijken naar de punt van al je Subversion branches in je historie - je zou er maar een moeten hebben, en het zou de laatste moeten zijn met een git-svn-id in je huidige branch historie.

Als je op meer dan een branch tegelijk wilt werken, kan je lokale branches inrichten om te dcommit-ten naar specifieke Subversion branches door ze te beginnen op de geïmporteerde Subversion commit voor die branch. Als je een opera-branch wilt waar je apart op kunt werken, kan je het volgende aanroepen:

Vervolgens, als je je opera-branch wilt mergen naar trunk (je master-branch), kan je dat doen met een gewone git merge. Maar als je een beschrijvende commit bericht (via -m) moeten meegeven, anders zal de merge “Merge branch opera” vermelden in plaats van iets nuttigs.

Onthoud dat hoewel je git merge gebruikt om deze handeling uit te voeren, en de merge waarschijnlijk veel makkelijker zal zijn dan het in Subversion zou zijn (omdat Git automatisch de juiste merge basis voor je zal uitzoeken), dit geen normale Git merge commit is. Je zult deze gegevens naar een Subversion server terug moeten pushen die niet in staat is een commit te verwerken die naar meer dan een ouder terug te herleiden is; dus, nadat je het gepusht hebt, zal het eruit zien als een enkele commit waarin al het werk van een andere branch is gepropt onder een enkele commit. Nadat je een branch in de een andere hebt gemerged, kan je niet simpelweg doorgaan met werken op die branch, zoals je in Git zou doen. Het dcommit commando dat je hebt aangeroepen verwijdert alle informatie die aangeeft welke branch erin was gemerged, dus daarop volgende merge-basis berekeningen zullen fout gaan - de dcommit maakt dat je git merge resultaat eruit ziet alsof je git merge --squash had aangeroepen. Jammergenoeg is er geen goede manier om deze situatie te vermijden - Subversion kan deze informatie niet opslaan, dus je zult altijd gehinderd worden door de beperkingen zolang je het gebruikt als je server. Om problemen te voorkomen, moet je de lokale branch verwijderen (in dit geval, opera) nadat je het in de trunk hebt gemerged.

De git svn toolset biedt een aantal commando’s om de overgang naar Git te vergemakkelijken door wat functionaliteit te leveren die vergelijkbaar is met wat je in Subversion had. Hie zijn een paar commando’s die je geven wat Subversion normaalgesproken deed.

De git svn instrumenten zijn nuttig als je vastzit aan een Subversion server, of op een andere manier in een ontwikkelteam zit waar het gebruik van een Subversion server noodzakelijk is. Je moet het echter als een gemankeerde Git beschouwen, of je loopt al snel tegen terminologie-verschillen aan die jou en je medewerkers zullen verwarren. Probeer, om niet in de problemen te komen, de volgende richtlijnen te volgen:

Als je deze richtlijnen volgt, wordt het werken met een Subversion server misschien iets dragelijker. Echter, als het ook maar enigszins mogelijk is om naar een echte Git server te gaan, zal dit je team veel meer opleveren.

Allereerst moet je git-remote-hg installeren. Dit houdt niet veel meer in dan het bestand ergens op je pad neer te zetten, op deze manier:

…aangenomen dat ~/bin op je $PATH staat. Git-remote-hg heeft een andere afhankelijkheid: de mercurial library voor Python. Als je Python geïnstalleerd hebt, is dit zo simpel als:

(Als je geen Python geïnstalleerd hebt, bezoek dan https://www.python.org/ en haal dat eerst op.)

Het laatste wat je nodig hebt is de Mercurial client. Ga naar https://www.mercurial-scm.org/ en installeer dit als je dat al niet hebt gedaan.

Nu is alles klaar voor gebruik. Al wat je nodig hebt is een Mercurial repository waar je naar kunt pushen. Gelukkig kan elke Mercurial repository zich op deze manier gedragen, dus we hoeven alleen de "hello world" repository die iedereen gebruikt om Mercurial te leren gebruiken:

Nu we een passende “server-side” repository hebben, kunnen we een normale workflow gaan volgen. Zoals je zult zien zijn deze twee systemen voldoende vergelijkbaar dat er niet veel wrijving zal zijn.

Zoals altijd met Git, gaan we eerst clonen:

Je zult opgemerkt hebben dat je bij het werken met een Mercurial repository het standaard git clone commando gebruikt. Dat is omdat git-remote-hg op een behoorlijk laag niveau werkt, en gebruik maakt van een vergelijkbaar mechanisme als het HTTP/S protocol dat in Git geïmplementeerd is (remote helpers). Omdat Git en Mercurial beide zijn ontworpen vanuit het principe dat elk werkstation een volledige kopie van de historie van de repository heeft, maakt dit commando een volledige kloon, inclusief alle historie van het project en doet dit redelijk snel.

Het log commando laat twee commits zien, maar naar de laatste daarvan wordt door een hele sloot refs verwezen. Nu is het zo dat een aantal van deze er eigenlijk helemaal niet zijn. Laten we kijken naar wat er eigenlijk in de .git directory staat:

Git-remote-hg probeert dingen meer letterlijk op z’n Gits te maken, maar onder de motorkap beheert het de conceptuele mapping tussen twee marginaal verschillende systemen. De refs/hg directory is waar de echte remote refs worden opgeslagen. Bijvoorbeeld, de refs/hg/origin/branche/default is een Git ref bestand die de SHA-1 bevat die begint met “ac7955c”, wat de commit is waar master naar wijst. Dus de refs/hg directory is een soort van nep refs/remotes/origin, maar het heeft het toegevoegde onderscheid tussen boekenleggers ("bookmarks") en branches.

Het notes/hg bestand is het beginpunt van hoe git-remote-hg Git commit hashes mapt op Mercurial changeset IDs. Laten we dit een beetje verkennen:

Dus refs/notes/hg wijst naar een tree, wat in de Git object database een lijst van andere objecten met namen is. git ls-tree produceert de mode, type, object hash en bestandsnamen voor items in een tree. Zodra we gaan graven naar een van de tree items, vinden we dat hierbinnen een blog zit met de naam “ac9117f” (de SHA-1 hash van de commit waar master naar wijst), met de inhoud “0a04b98” (wat de ID is van de Mercurial changeset aan de punt van de default-branch).

Het goede nieuwe is dat we ons over het algemeen hierover geen zorgen hoeven te maken. De typische workflow zal niet veel verschillen van het werken met een Git remote.

Er is een extra onderwerp waar we even aandacht aan moeten schenken voordat we doorgaan: ignores. Mercurial en Git gebruiken een erg vergelijkbare mechanisme hiervoor, maar het is erg aannemelijk dat je een .gitignore niet echt in een Mercurial repository wilt committen. Gelukkig heeft Git een manier om bestanden te negeren die lokaal is voor een repository die op schijf staat, en het formaat van Mercurial is compatibel met die van Git, dus je moet het ernaartoe kopiëren:

Het .git/info/exclude bestand gedraagt zich als een .gitignore, maar wordt niet in commits meegenomen.

Laten we aannemen dat we wat werk gedaan hebben en een aantal commits op de master-branch uitgevoerd hebben, en je bent klaar om dit naar de remote repository te pushen. Zo ziet onze repository eruit op dit moment:

Onze master-branch loopt twee commits voor op origin/master, maar deze twee commits bestaan alleen op onze lokale machine. Laten we kijken of iemand anders belangrijk werk heeft gedaan in de tussentijd:

Omdat we de --all vlag gebruikt hebben, zien we de “notes” refs die intern gebruikt worden door git-remote-hg, maar deze kunnen we negeren. De rest is zoals we hadden verwacht; origin/master is een commit naar voren gegaan, en onze histories zijn nu uiteengelopen. In tegenstelling tot andere systemen waar we mee werken in dit hoofdstuk, is Mercurial in staat om merges te verwerken, dus we gaan nu geen moeilijke dingen doen.

Perfect. We laten de tests draaien en alles slaagt, dus we zijn klaar om ons werk te delen met de rest van het team:

Dat is alles! Als je de Mercurial repository bekijkt, zul je zien dat dit gedaan heeft wat we mogen verwachten:

De wijzigingsset ("changeset") met nummer 2 is gemaakt door Mercurial, en de changesets nummers 3 en 4 zijn door git-remote-hg gemaakt, door het pushen van de met Git gemaakte commits.

Git heeft maar een soort branch: een referentie die verplaatst wordt als commits worden gemaakt. In Mercurial, worden deze soorten referenties een “bookmark” genoemd, en het gedraagt zich grotendeels vergelijkbaar met een branch in Git.

Het concept van een “branch” in Mercurial heeft iets meer voeten in de aarde. De branch waar een changeset op is gebaseerd wordt opgeslagen met de changeset, wat inhoudt dat het altijd in de historie van de repository aanwezig is. Hier is een voorbeeld van een commit die gemaakt is op de develop-branch:

Merk de regel op die begint met “branch”. Git kan dit niet echt simuleren (en hoeft dit ook niet; beide soorten branches kunnen in Git als een ref worden weergegeven), maar git-remote-hg moet het onderscheid kunnen maken, omdat Mercurial hier om geeft.

Het aanmaken van Mercurial bookmarks is net zo eenvoudig als het maken van Git branches. Aan de Git kant:

En dat is alles wat nodig is. Aan de kant van Mercurial ziet het er zo uit:

Merk de nieuwe [featureA] tag in revisie 5 op. Deze gedragen zich precies als Git branches aan de Git kant, met een uitzondering: je kunt een bookmark niet van de Git kant verwijderen (dit is een beperking van remote helpers).

Je kunt ook op een “zwaargewicht” Mercurial branch werken: gewoon een branch in de branches naamsruimte ("namespace") zetten:

En hier is hoe het er aan de kant van Mercurial uit ziet:

De branchnaam “permanent” is opgeslagen met de changeset gemarkeerd met 7.

Aan de kant van Git, is het werken met beide stijlen branch gelijk: gewoon checkout, commit, fetch, merge, pull en push zoals je gewoonlijk zou doen. Een ding wat je moet weten is dat Mercurial het overschrijven van historie niet ondersteunt, alleen eraan toevoegen. Dit is hoe onze Mercurial repository eruit ziet na een interactieve rebase en een force-push:

Changesets 8, 9 en 10 zijn gemaakt voor en behoren bij de permanent-branch, maar de oude changesets zijn er nog steeds. Dit kan erg verwarrend worden voor je teamgenoten die Mercurial gebruiken, dus probeer dit te vermijden.

Git en Mercurial zijn gelijk genoeg dat het werken over deze grenzen redelijk goed gaat. Als je het wijzigen van historie die achterblijft op je machine vermijdt (zoals over het algemeen aangeraden wordt), zou je niet eens kunnen zeggen dat Mercurial aan de andere kant staat.

Het is eenvoudig in gebruik. Het is voldoende om een Bazaar repository te klonen door het vooraf te laten gaan bzr::. Omdat Git en Bazaar beide een volledige kloon doen naar je machine, is het mogelijk om een Git kloon aan je lokale Bazaar kloon te knopen, maar dat wordt niet aangeraden. Het is veel eenvoudiger om je Git kloon direct aan dezelfde plaats te knopen als waar je Bazaar kloon aan verbonden is - de centrale repository.

Laten we er vanuit gaan dat je gewerkt heb met een remote repository die staat op het adres bzr+ssh://developer@mybazaarserver:myproject. Dan moet je het op de volgende manier klonen:

Nu is je Git repository gemaakt, maar het is nog niet geoptimaliseerd voor schijf gebruik. Dat is waarom je ook je Git repository moet schoonmaken en optimaliseren, zeker als het een grote is:

Bazaar staat alleen toe om branches te klonen, maar een repository kan verscheidene branches bevatten, en git-remote-bzr kan beide klonen. Bijvoorbeeld: om een branch te klonen:

En om de gehele repository te klonen:

The second command clones all the branches contained in the emacs repository; nevertheless, it is possible to point out some branches:

Some remote repositories don’t allow you to list their branches, in which case you have to manually specify them, and even though you could specify the configuration in the cloning command, you may find this easier:

Since you are working on a project managed with Bazaar, you shouldn’t create a .gitignore file because you may accidentally set it under version control and the other people working with Bazaar would be disturbed. The solution is to create the .git/info/exclude file either as a symbolic link or as a regular file. We’ll see later on how to solve this question.

Bazaar uses the same model as Git to ignore files, but also has two features which don’t have an equivalent into Git. The complete description may be found in the documentation. The two features are:

As a consequence, there are two different situations to consider:

Whatever the case is, you will have to remain vigilant against any change of .bzrignore to make sure that the .git/info/exclude file always reflects .bzrignore. Indeed, if the .bzrignore file were to change and contained one or more lines starting with "!!" or "RE:", Git not being able to interpret these lines, you’ll have to adapt your .git/info/exclude file to ignore the same files as the ones ignored with .bzrignore. Moreover, if the .git/info/exclude file was a symbolic link, you’ll have to first delete the symbolic link, copy .bzrignore to .git/info/exclude and then adapt the latter. However, be careful with its creation because with Git it is impossible to re-include a file if a parent directory of that file is excluded.

To fetch the changes of the remote, you pull changes as usually, using Git commands. Supposing that your changes are on the master-branch, you merge or rebase your work on the origin/master-branch:

Because Bazaar also has the concept of merge commits, there will be no problem if you push a merge commit. So you can work on a branch, merge the changes into master and push your work. Then, you create your branches, you test and commit your work as usual. You finally push your work to the Bazaar repository:

Git’s remote-helpers framework has some limitations that apply. In particular, these commands don’t work:

Since Git’s and Bazaar’s models are similar, there isn’t a lot of resistance when working across the boundary. As long as you watch out for the limitations, and are always aware that the remote repository isn’t natively Git, you’ll be fine.

Perforce stelt een product ter beschikking met de naam Git Fusion (beschikbaar op http://www.perforce.com/git-fusion), welke een Perforce server synchroniseert met Git repositories aan de kant van de server.

Git-p4 is een tweewegs bridge tussen Git en Perforce. Het draait volledig binnen je Git repository, dus je hebt geen enkele vorm van toegang tot de Perforce server nodig (buiten de login gegevens natuurlijk). Git-p4 is niet zo flexibel of compleet als oplossing als Git Fusion, maar het stelt je wel in staat om het meeste wat je zou willen doen uit te voeren zonder afbreuk te doen aan de omgeving van de server.

Git-p4 maakt het mogelijk om een Git workflow te gebruiken met een Perforce server, en het is er best wel goed in. Echter, het is belangrijk om te onthouden dat Perforce de baas is over de broncode, en dat je Git alleen maar gebruikt om er lokaal mee te werken. Wees vooral erg voorzichtig om Git commits te delen; als je een remote hebt die andere mensen ook gebruiken, push dan geen enkele commit die niet al eerder naar die Perforce server zijn gestuurd.

Als je vrijelijk zowel de Perforce en Git clients tegelijk wilt gebruiken voor broncode beheer, en je kunt de beheerder van de server ervan overtuigen om het te installeren, zal Git Fusion Git een eersterangs versiebeheer client maken voor een Perforce server.

Er zijn er in feite twee: git-tf en git-tfs.

Git-tfs (te vinden op https://github.com/git-tfs/git-tfs) is een .NET project, en (op het tijdstip van schrijven) kan alleen onder Windows draaien. Om met Git repositories te werken, gebruikt het de .NET bindings voor libgit2, een library-oriented implementatie van Git die zeer hoog performant is en die een hoge mate van flexibiliteit biedt met de pretentie van een Git repository. Libgit2 is geen volledige implementatie van Git, dus om dit verschil te compenseren zal git-tfs gewoon de commando-regel versie van de Git client aanroepen om bepaalde operaties uit te voeren, dus er zijn geen kunstmatige beperkingen in wat het met Git repositories kan doen. De ondersteuning van de TFVC functies is zeer volwassen, omdat het de mogelijkheden van Visual Studio gebruikt voor operaties met servers. Dit houdt in dat je toegang nodig hebt tot deze mogelijkheden, wat betekent dat je een recente versie van Visual Studio moet installeren (elke editie sinds versie 2010, inclusief Express sinds versie 2012), of de Visual Studio SDK.

Git-tf (welke huist op https://gittf.codeplex.com) is een Java project, en als zodanig loopt het op elke computer met een Java runtime omgeving. Het interacteert met Git repositories middels JGit (een JVM implementatie van Git), wat inhoudt dat het vrijwel geen beperkingen kent in termen van Git functies. Echter, de ondersteuning voor TFVC is beperkt ten opzichte van git-tfs - het ondersteunt bijvoorbeeld geen branches.

Dus elke tool heeft z’n voors en tegens, en er zijn genoeg situaties waarbij de een te prefereren is boven de ander. We zullen het normale gebruik van beide gaan behandelen in dit boek.

Het eerste wat je doet, net als met elk andere Git project is klonen. Dit is hoe het er uit ziet met git-tf:

Het eerste argument is de URL van een TFVC collectie, het tweede is er een in de vorm $/project/branch, en het derde is het pad naar de lokale Git repository die gemaakt moet worden (deze laatste is optioneel). Git-tf kan maar met een branch tegelijk werken; als je checkins wilt maken op een andere TFVC branch, zul je een nieuwe kloon moeten maken van die branch.

Dit maakt een volledig functionele Git repository:

Dit wordt een shallow clone (oppervlakkige kloon) genoemd, wat inhoudt dat alleen de laatste changeset is gedownload. TFVC is niet ontworpen met het het idee dat elk werkstation een volledige kopie van de historie heeft, dus git-tf valt terug op het ophalen van de laatste versie, wat veel sneller is.

Als je de tijd hebt, is het waarschijnlijk de moeite om de gehele project historie te klonen, met de --deep optie:

Merk de tags op met namen als TFS_C35189; dit is een functionaliteit die je helpt met het relateren van Git commits aan TFVC changesets. Dit is een aardige manier om het weer te geven, omdat je met een simpele log commando kunt zien welke van jouw commits zijn gerelateerd aan een snapshot die leeft in TFVC. Ze zijn niet noodzakelijk (en je kunt ze gewoon uitschakelen met git config git-tf.tag false) - git-tf houdt de echte commit-changeset relaties bij in het .git/git-tf bestand.

Het klonen met git-tfs gedraagt zich iets anders. Neem waar:

Merk de --with-branches vlag op. Git-tfs is in staat de TFVC branches aan Git branches te relateren, en deze vlag geeft aan dat er een lokale Git branch moet worden aangemaakt voor elke TFVC branch. Dit wordt sterk aangeraden als je ooit gebrancht of gemerged hebt in TFS, maar het gaat niet werken met een server die ouder is dan TFS 2010 - voor die versie waren “branches” gewoon folders, dus git-tfs kan ze niet onderscheiden van reguliere folders.

Laten we een kijkje nemen naar de Git repository die het resultaat is:

Er zijn twee lokale branches, master en featureA, die staan voor het initiele uitgangspunt van de kloon (Trunk in TFVC) en een afgesplitste branch (featureA in TFVC). Je kunt ook zien dat de tfs “remote” een aantal refs heeft: default en featureA, die staan voor de TFVC branches. Git-tfs relateert de branch die je hebt gekloont aan tfs/default, en de andere krijgen hun eigen namen.

Iets anders om op te merken is de git-tfs-id: regels in de commit berichten. In plaats van tags, gebruikt git-tfs deze markeringen om een relatie te leggen tussen TFVC changesets en Git commits. Dit heeft de implicatie dat je Git commits een andere SHA-1 hash zullen hebben voor- en nadat ze naar TFVC zijn gepusht.

Het meest voor de hand liggende ding wat je hierna zult wilen doen is aan het project werken. TFVC en TFS hebben een aantal kenmerken die je workflow een stuk complexer kunnen maken:

In het belang van beknoptheid, zullen we hier alleen het foutloze pad volgen, die de om de meeste van deze problemen heen leidt of die ze vermijdt.

Stel dat je wat werk gedaan hebt, je hebt een aantal Git commits op master gemaakt, en je staat gereed om je voortgang te delen op de TFVC server. Hier is onze Git repository:

We willen snapshot die in de 4178a821 commit zit nemen en die pushen naar de TFVC server. Maar laten we bij het begin beginnen: laten we eerst kijken of een van onze teamgenoten iets gedaan heeft sinds we voor het laatst verbonden waren:

Het ziet er naar uit dat er iemand ook aan het werk is, en we hebben nu een uiteengelopen historie. Dit is waar Git uitblinkt, maar we hebben een keuze uit twee verschillende manieren om door te gaan:

De keuze is aan jou. In dit voorbeeld zullen we rebasen:

Nu zijn we gereed om een checkin te doen naar de TFVC server. Git-tf geeft je de keuze om een enkele changeset te maken die alle wijzigingen sinds de laatste (--shallow, wat standaard is) en het maken van een nieuwe changeset voor elke Git commit (--deep). In dit voorbeeld zullen we één changeset maken:

Er is een nieuwe TFS_C35348 tag, wat aangeeft dat TFVC exact dezelfde snapshot heeft opgeslagen als de 5a0e25e commit. Het is belangrijk om op te merken dat niet elke Git commit perse een exacte evenknie in TFVC dient te hebben; de 6eb3eb5 commit bijvoorbeeld bestaat nergens op de server.

Dat is de belangrijkste workflow. Er zijn een aantal andere overwegingen die je in je achterhoofd dient te houden:

Laten we hetzelfde scenario doorlopen waarbij we git-tfs gebruiken. Hier zijn de nieuwe commits die we gemaakt hebben op de master-branch in onze Git repository:

En laten we nu eens kijken of iemand anders werk gedaan heeft terwijl wij lekker aan het kloppen waren:

Ja, we kunnen zien dat onze collega een nieuwe TFVC changeset heeft toegevoegd, die getoond wordt als de nieuwe aea74a0 commit, en de tfs/default remote branch is verplaatst.

Net als met git-tf, hebben we twee basis opties hoe we deze uiteengelopen histories kunnen verwerken:

In dit geval zullen we een “deep” checkin uitvoeren, waar elke Git commit een TFVC changeset wordt, dus we willen gaan rebasen.

Nu zijn we klaar om onze bijdrage te leveren door onze code in te checken bij de TFVC server. Ze zullen hier het rcheckin command gebruiken om een TFVC changeset te maken voor elke Git commit in het pad van HEAD naar de eerste tfs remote branch die gevonden wordt (het checkin commando zou slechts één changeset maken, vergelijkbaar met het squashen van Git commits).

Merk op hoe na elke succesvolle checkin naar de TFVC server, git-tfs het overblijvende werk rebased op wat het zojuist heeft gedaan. Dat is omdat het git-tfs-id veld onderaan de commitberichten wordt toegevoegd, wat de SHA-1 hashes verandert. Dit is precies volgens ontwerp, en er is niets om je zorgen over te maken, maar je moet je ervan bewust zijn dat dit gebeurt, vooral als je Git commits met anderen gaat delen.

TFS heeft veel functionaliteit die integreren met zijn eigen beheer systeem, zoals werkbonnen, aangewezen reviewers, gelaagde checkins (gated checkins) en zo voorts. Het kan nogal omslachtig zijn om met deze functionaliteit te werken met alleen maar een commando-regel tool, maar gelukkig stelt git-tfs je in staat om eenvoudig een grafische checkin tool aan te roepen:

En dat ziet er ongeveer zo uit:

Dit ziet er vertrouwd uit voor TFS gebruikers, omdat het dezelfde dialoog is die aangeroepen wordt vanuit Visual Studio.

Git-tfs laat je ook TFVC branches beheren vanuit je Git repository. Laten we als voorbeeld er eens een maken:

Een branch maken in TFVC houdt het maken van een changeset in waar die branch nu in bestaat, en dit is voorgesteld als een Git commit. Merk ook op dat git-tfs de tfs/featureBee remote branch aangemaakt heeft, maar dat HEAD nog steeds naar master wijst. Als je op de nieuw aangemaakte branch wilt werken, zal je je nieuwe commits op de 1d54865 willen baseren, mogelijk door een topic branch van die commit te maken.

Git-tf en Git-tfs zijn beide geweldige instrumenten om met een TFVC server te interacteren. Ze stellen je in staat om de kracht van Git lokaal te gebruiken, te voorkomen dat je voortdurend met de centrale TFVC server contact moet leggen, en je leven als ontwikkelaar veel eenvoudiger te maken, zonder je hele team te dwingen over te stappen op Git. Als je op Windows werkt (wat waarschijnlijk is als je team TFS gebruikt), zal je waarschijnlijk git-tfs willen gebruiken, omdat deze de meest complete functionaliteit biedt, maar als je op een ander platform werkt, zal je git-tf gebruiken die beperkter is. Zoals de meeste gereedschappen in dit hoofdstuk, zal je een van deze versie-beheer systemen als leidend kiezen, en de andere in een volgende rol gebruiken - Git of TFVC moet het middelpunt van de samenwerking zijn, niet beide.