OASIS-SVN en git gebruiken voor toegang tot broncodecontrole

OPMERKING: Ik zal dieper ingaan op dit onderwerp in het komende maandelijkse webinar over Access en SQL Server op 9 juli om 18.30 uur CDT. Registreer je zodat je het proces live kunt bekijken en vragen kunt stellen!

Omdat we met verschillende applicaties en soms in een team werken, is broncodebeheer behoorlijk belangrijk voor het beheren van wijzigingen. We zijn dol geworden op het gebruik van git voor onze projecten. Oorspronkelijk zou het gebruik van git met Access een uitdaging zijn, maar dankzij een invoegtoepassing met de naam OASIS-SVN kunnen we git effectief gebruiken met Access-projecten voor het beheren van de wijzigingen.

Waarom broncodebeheer gebruiken? Kun je het niet gewoon dichtritsen?

Het belangrijkste doel achter broncodebeheer is om gemakkelijk whodunit te kunnen beantwoorden.

Dat is vooral van cruciaal belang als je te maken hebt met een bugrapport en je eraan wordt herinnerd dat je iets soortgelijks eerder hebt gezien en je dacht dat je het misschien had opgelost, maar de klant meldt het nog steeds. Toen de bug echter zes maanden geleden werd 'gerepareerd', kan het net zo goed een geheel nieuwe bug zijn, omdat we de fix die we zes maanden geleden hebben aangebracht, al zijn vergeten. Ik weet niet hoe het met u zit, maar het vooruitzicht om door een heleboel gecomprimeerde back-ups te spitten voelt niet erg ... vindbaar.

Uw wijzigingen in een broncodecontrole plaatsen vereist discipline, maar zal het veel gemakkelijker maken om wijzigingen te beoordelen en te beheren. Je kunt gemakkelijk in de geschiedenis zoeken en zien wat er precies verandert.

Een ander scenario is uitzoeken wat er precies is veranderd. Als je verschillende wijzigingen hebt aangebracht en deze moet bekijken voordat je een nieuwe versie pusht, is dat waar broncodebeheer je helpt. Je hebt de mogelijkheid om je werk te controleren en ervoor te zorgen dat je alles hebt gedaan wat je van plan was te doen. Niet meer "Ik denk dat ik dat al gedaan heb." alleen om door de klant te horen dat je dat kleine detail bent vergeten waar de klant je vorige week naar vroeg. Bovendien stelt dit het team in staat om code-reviews voor anderen te doen; we kunnen naar het werk van anderen kijken en feedback geven en elkaar helpen een hoge kwaliteitsstandaard te handhaven.

Waarom git? Access werkt toch met Visual SourceSafe?

In versies voorafgaand aan Access 2013 ondersteunde Access broncodebeheer native, maar het deed het met behulp van een eigen Microsoft-specificatie, MSSCCI. Om het nog erger te maken, gaat de specificatie uit van een check-out/check-in-model dat ontwikkelaars een exclusieve vergrendeling geeft over de objecten waarmee ze werken. Bovendien waren de tabellen in de Access-toepassing eigenlijk één grote klodder die niet kon worden gelezen, laat staan ​​beoordeeld.

In de praktijk is een dergelijk model erg omslachtig om te gebruiken, zelfs in kleine teamverbanden. Een belangrijk probleem is dat een wijzigingsverzoek zelden wordt bevestigd aan slechts één object; de ontwikkelaars kunnen merken dat ze meer dan een handvol objecten moeten aanraken en daarom kunnen botsingen onvermijdelijk zijn, vooral voor de kern/gedeelde modules.

Git vermijdt alle lelijkheid die we zien bij het oude check-out/check-in-model, maar dit vereist wel een andere filosofie bij het beheren van de wijzigingen. In plaats van iets uit te checken, werken we gewoon vanuit een branch en als we daarmee klaar zijn, mergen we het weer in de hoofdbranch. We kunnen meerdere takken parallel hebben als we dat zouden willen, hoewel we in de praktijk maar 2 of 3 parallelle takken nodig hebben; een om de productieversie te vertegenwoordigen; andere voor ontwikkeling en misschien een derde voor kritieke bugfixes. Dit kan worden gedaan met een Access-project, en zou moeten zijn. Anders kan het erg moeilijk zijn om bij te houden wat er in het productiebestand gaat, vooral voor niet-triviale toepassingen.

Een uitstekende bron om git te leren is hier te vinden; het heeft een zandbak zodat je mee kunt spelen. Als je net als ik bent en graag de vlezige stukjes eet en weet hoe het werkt, is dit een goede hulpbron.

Stop tot slot gewoon al met het gebruik van Visual SourceSafe. Het zit vol met fouten, kan uw gegevens verliezen en wordt al _years_ niet ondersteund, zelfs niet door Access sinds 2013.

Maar als Access 2013+ broncodebeheer niet langer ondersteunt, hoe kunnen we het dan nog hebben?!?

Omdat OASIS-SVN geen MSSCCI-provider is, maar gewoon een eenvoudige Access-invoegtoepassing. Er zijn andere vergelijkbare Access-invoegtoepassingen (bijvoorbeeld Ivercy) die de beperking omzeilen. In alle gevallen maken die add-ins intensief gebruik van exact dezelfde ongedocumenteerde methoden die Access intern gebruikte voor broncodecontrole; Application.SaveAsText en Application.LoadFromText . Die methoden zijn nog steeds aanwezig in de huidige versie van Access. Even terzijde, er is een UV-item om het te documenteren om de continuïteit te waarborgen. OASIS-SVN blijft goed werken, zelfs met de huidige Access-versie.

Waarom blijf je praten over OASIS-SVN en git? Kan ik gewoon de een of de ander gebruiken?

Het is belangrijk om te begrijpen dat beide tools complementair zijn en dat je beide nodig hebt. Kijk, de reden waarom je OASIS-SVN nodig hebt, is om het je zo gemakkelijk mogelijk te maken om je harde werk uit handen te nemen en ze te presenteren als een stel tekstbestanden, in plaats van ze in een grote klodder van een binair bestand te plaatsen dat de ACCD*-bestand. Het heeft geen zin om het ACCDB-bestand door de broncode te laten beheren, omdat het geen goede geschiedenis van wijzigingen zou hebben en grotendeels onleesbaar zou zijn. OASIS-SVN is dus de tool om de tekstbestanden te maken die kunnen worden gebruikt om je Access-toepassing opnieuw op te bouwen, en het is de taak van git om die bestanden daadwerkelijk te coderen. De git kan en zou niet moeten werken met het ACCDB-bestand.

Als git nieuw voor je is, heb je een extra stap vergeleken met wat anderen gewoonlijk doen op hun Visual Studio-projecten, omdat je met een binair bestand werkt, niet met een echte set mappen met een heleboel tekstbestanden met grappige extensies. Je zult er dus een gewoonte van moeten maken om je wijzigingen consequent te exporteren/importeren tussen het ACCDB-bestand en de tekstbestanden waaruit je git-repository bestaat.

Vereisten

Om te beginnen hebben we 3 stukjes software nodig:

1. Git voor Windows
2. TortoiseGit
3. OASIS-SVN

Strikt genomen heb je de 2e en 3e software niet nodig. Je zou eigenlijk alleen met de eerste kunnen volstaan, maar het grote nadeel is dat je handmatig moet exporteren / importeren door je eigen VBA-module te schrijven om dit te doen en geloof me, dat is veel werk om redenen die duidelijker zullen worden naarmate wij volgen mee. Daarom wordt OASIS-SVN sterk aanbevolen. Je hoeft TortoiseGit ook niet te hebben, maar ik vind het erg fijn om een ​​GUI te hebben om het werken gemakkelijk te maken. Dat kan sommige opdrachtregelpuristen beledigen die je zullen vertellen dat je git gewoon in een opdrachtregel moet gebruiken, niet via een mooie GUI. Ik vind het echter lui en snel en meestal is het proces eenvoudig dat het sneller voor mij is om gewoon een commando uit een menu uit te voeren dan om een ​​bash-shell te openen en een commando in te typen. Dat gezegd hebbende, TortoiseGit is eigenlijk maar een dunne wikkel over git-commando's, dus je zou er goed aan doen goed op te letten welk git-commando het uitvoert en wat het betekent.

Installeer ze allemaal; Ik zal verwijzen naar hun respectieve websites voor gedetailleerde instructies. Zodra dit allemaal is ingesteld, moet u een project hebben dat u onder controle wilt krijgen. Bovendien hebt u een plaats nodig om als uw upstream-repository te fungeren. Misschien heb je een Azure DevOps-account? Bitbucket? GitHub? Er zijn verschillende opties voor u beschikbaar voor het hosten van uw broncodebeheer. Heck, als je geneigd bent, zou je zelfs een privé git-server kunnen opzetten. Maar ook dat valt buiten het bestek van het artikel. Nogmaals, ik verwijs je naar de documentatie van de respectievelijke provider voor het opzetten van een lege repository.

Zodra u een lege repository heeft, moet u er een link naar krijgen. We gebruiken Auzre DevOps en we hebben een nieuwe repository gemaakt op deze URL:
https://samplecompany.visualstudio.com/DefaultCollection/z_Sandbox/_git/SampleApplication
Nu we een link hebben voor een lege repository, kunnen we de installatie starten.

Een lokale opslagplaats maken

Hoewel OASIS-SVN een wizard heeft, vind ik het gemakkelijker om een ​​bestaande repository te klonen en van daaruit te werken. U bent vrij om de wizard te gebruiken die iets soortgelijks zal doen, maar ik denk dat het volgen van de handmatige manier u zal helpen begrijpen wat er werkelijk gebeurt en het gemakkelijker zal maken om met de tools te werken. We gaan ervan uit dat we een toepassing in een bepaalde map hebben:

De map Bron is leeg en zal de plaats zijn waar we de tekstbestanden voor onze lokale repository zullen huisvesten. We kunnen met de rechtermuisknop op de witte ruimte in de map klikken om de TortoiseGit . te openen contextmenu en kies repository voor kloon.

Voer in het dialoogvenster dat wordt geopend de URL in die u van uw hostingprovider hebt gekregen:

LET OP

U zou dan een succesdialoogvenster moeten krijgen dat de repository is gekloond:

Als gevolg van het klonen heb je nu een verborgen map met de naam .git . Dat is hoe git je commits en wijzigingen in je lokale repository bijhoudt.

We hebben nu een werkende lokale repository die we kunnen gebruiken om onze tekstbestanden van Access te bewaren. We moeten OASIS-SVN configureren om hiervan gebruik te maken.

OASIS-SVN configureren

Zoals eerder vermeld, heeft OASIS-SVN een wizard die kan worden gebruikt om ons op te zetten, maar we willen dit handmatig doen, zodat u bekend bent met hoe OASIS-SVN werkt en dus de wizard effectief kunt gebruiken. We beginnen door naar de Instellingen . te gaan menu op de OASIS-SVN linttab.

Dit opent het dialoogvenster. Want op dit moment hoeven we maar één ding te doen; het bronpad instellen. Over het algemeen vind ik het handiger om een ​​relatief pad te gebruiken in plaats van een absoluut pad, dus we zullen \Bron invoegen zoals geïllustreerd:

Eenmaal ingevoerd, moet u het selectievakje aanvinken always use :

Dat maakt de repository-map relatief en stelt u dus in staat om de projectmap te verplaatsen waar u maar wilt. Maar let op:als u het Access-bestand kopieert of buiten die map verplaatst, kan het niet onder broncodebeheer worden gehouden omdat OASIS-SVN dan de .oasis niet zou hebben bestand dat OASIS-SVN nodig heeft. Klik op OK om het dialoogvenster te sluiten om de wijzigingen in de instellingen op te slaan. Als je in de map kijkt, zie je nu de .oasis bestand voor uw ACCDB-bestand.

De .oase bestand is gewoon een XML-bestand dat alle projectinstellingen bevat, en het moet dezelfde naam hebben als het ACCDB-bestand zodat OASIS-SVN weet dat dit ACCDB-bestand onder broncodebeheer moet staan. Dus als je de gewoonte hebt om je ACCDB-bestand te hernoemen, moet je die gewoonte doorbreken. Als uw bestaande workflow het hernoemen van bestanden omvat, is een benadering die ik handig vind, het gebruik van een vaste naam voor ontwikkelkopie (bijv. SampleApplication Dev.accdb , misschien), en als ik de naam moet wijzigen, maak ik een kopie van dat bestand en geef ik de juiste naam op. Het moet worden benadrukt dat met het in broncodebeheer, hernoemen als middel om versies bij te houden nu minder zin heeft, omdat je het zou moeten kunnen recreëren vanuit de git-geschiedenis in plaats van een heleboel kopieën met verschillende namen te hebben.

De rest van de instellingen configureren

In de vorige stap hebben we alleen het bronbestand ingesteld omdat we geen .oasis . hadden het dossier; als we andere wijzigingen hadden aangebracht, is deze misschien niet opgeslagen, maar nu we er een hebben gemaakt als resultaat van het instellen van de projectmap, kunnen we de rest van de instellingen bekijken. Het is waarschijnlijk een goed idee om een ​​sjabloon .oasis te hebben bestand, zodat u snel kunt kopiëren en met de hand kunt aanpassen om een ​​uniforme projectinstelling te hebben voor uw verschillende Access-projecten. Laten we teruggaan naar Instellingen knop op het lint en begin met het eerste tabblad in het dialoogvenster.

deelvenster Objecttypen

Omdat we niet langer met ADP's werken en we geen verouderde pagina's voor gegevenstoegang gebruiken, schakelen we deze meestal uit om de rommel van het import-/exportvenster tot een minimum te beperken. Misschien vindt u het ook handig om het automatisch gewijzigde programma automatisch te laten selecteren, waarvoor het tijdstempel van het object moet worden bijgehouden. Houd er echter rekening mee dat de tijdstempel van het object niet volledig betrouwbaar is binnen Access. We zullen dit in een later gedeelte meer bespreken. Dat gezegd hebbende, is het een goede manier om u te helpen aangeven of u misschien bent vergeten een verdwaald object te committen.

paneel met tabelopties

Dit deelvenster vereist enige zorgvuldige overwegingen en is afhankelijk van het soort projecten waarmee u te maken hebt. De belangrijkste regel is dat u _niet_ de broncode van de gegevens in uw tabellen wilt beheren. Dat is niet logisch, aangezien data geen code is. Dat is echter niet altijd strikt waar. We hebben bijvoorbeeld een aantal tabellen die we gebruiken als applicatieconfiguratiegegevens. Dus in zekere zin zijn die tabellen "code", omdat ze van invloed zijn op hoe de applicatie zal werken. Omdat het merendeel van onze projecten Access front-ends zijn met een SQL Server backends, zijn de tabellen die meestal aanwezig zijn vooral configuratietabellen en dus geschikt voor broncode controle. Maar als we gegevenstabellen hadden, zouden die waarschijnlijk niet moeten worden opgenomen. Dat is waar de Geavanceerde knop is handig. Als u hierop klikt, wordt dit dialoogvenster geopend:

Door het vinkje weg te halen bij Gegevens exporteren voor alle tabellen aanvinkvakje onderaan, kunt u vervolgens de gegevens van de tabellen selecteren die u onder controle van de broncode wilt houden, met uitzondering van die tabellen die slechts een gegevenstabel zijn en geen deel uitmaken van de broncode van de toepassing.

We nemen over het algemeen ook geen ODBC-gekoppelde tabellen op omdat we meestal een coderoutine hebben om de tabellen opnieuw te koppelen, dus het is voor ons niet logisch om het in broncodebeheer te hebben. Het is echter een goed idee om de applicatieconfiguratietabel of misschien zelfs alleen de definitie voor de lokale tabel te hebben, omdat we een kapotte applicatie zouden hebben als we een bestand zouden bouwen vanuit de git-repository zonder de definitie van die tabellen.

Instellingenvenster

We zagen dit al eerder toen we de .oasis . maakten het dossier. Nu we het bestand hebben, zullen we de rest van de instellingen instellen. Dit is onze typische opstelling.

Zoals ik in het begin al zei, zou je mogelijk je eigen import-/exportroutine kunnen schrijven. De waarde van OASIS-SVN is echter dat we verschillende problemen kunnen aanpakken die bestaan ​​met het onder broncode houden van Access-tekstbestanden. Een Access-tekstbestand kan bijvoorbeeld de typische velden bovenaan het bestand hebben:
Version =21
VersionRequired =20
PublishOption =1
Checksum =-571006847
Begin Form
...
End Form
Die zijn slecht voor de broncodecontrole omdat ze onnodige wijzigingen kunnen aanbrengen en de geschiedenis van wijzigingen kunnen vervuilen die niet echt wijzigingen zijn. De controlesom kan veranderen, ook al heb je niets veranderd aan het formulier zelf. Met OASIS-SVN kunnen we die onnodige gegevens verwijderen met de optie Geëxporteerde bestanden opschonen :
Version =21
VersionRequired =20
Begin Form
...
End Form
Je hebt misschien een geel waarschuwingspictogram gezien voor rapporten. De reden waarom het er is, is omdat OASIS-SVN ook de printergegevens weghaalt, wat notoir slecht is voor broncodecontrole. Wanneer de rapporten de standaardprinter gebruiken, is dat meestal geen probleem. Het is echter niet ongebruikelijk om rapporten te maken die afhankelijk zijn van een specifieke printer. Misschien hebben we bijvoorbeeld een rapport dat barcodelabels maakt op een gespecialiseerde printer. In dat rapport hebben we een specifieke printer gekozen in plaats van een standaardprinter. Als u dat vakje aanvinkt voor rapporten, worden de printergegevens weggeblazen. Als uw project niet afhankelijk is van bepaalde printerinstellingen, vindt u het misschien gemakkelijker om de rapporten af ​​te vinken. Anders is er geen reden om het niet af te vinken voor formulieren.

Om vergelijkbare redenen houden we erg van Split Form-bestanden en Rapportbestanden splitsen optie aangevinkt. Normaal gesproken Application.SaveAsText exporteert een enkel tekstbestand voor een enkel Access-object. Als u echter het tekstbestand hebt gelezen, zult u zien dat de lay-outcode ... vervelend kan zijn om te lezen. Als we deze optie aanvinken, krijgen we 2 tekstbestanden per Access-object; één om alle lay-outgegevens te bevatten, en andere de daadwerkelijke VBA-broncode achter het formulier. Dat maakt het beoordelen van de code veel gemakkelijker, omdat u zich kunt concentreren op de VBA-wijzigingen en begrijpt wat er is gewijzigd, waardoor het gemakkelijker wordt om te begrijpen waar de lay-outwijziging over gaat.

U herinnert zich dat misschien uit het vorige gedeelte over Objecttypen deelvenster, kozen we het gewijzigde, wat vereist dat we de datum/tijd van het object opslaan als een bestandsdatum/tijd. Ook dat is hier afgevinkt. Het is vermeldenswaard dat Access de tijdstempel niet altijd betrouwbaar afstempelt bij het wijzigen van de objecten. We zullen dit later opnieuw bespreken over het maken van commits.

Integratievenster

We willen er meestal voor zorgen dat de autocorrectie altijd is uitgeschakeld, maar belangrijker is de optie om Ctrl+S te gebruiken als een hokey om een ​​export te doen. Dat is heel erg handig en vermijdt het probleem met de tijdstempel van het Access-object. Dit vereist echter discipline om consequent de sneltoets te gebruiken om de wijzigingen op te slaan. Telkens wanneer u het toetsenbord gebruikt, wordt dit dialoogvenster kort weergegeven:

Dat zorgt ervoor dat je git-werkboom zo nauw synchroon wordt gehouden met je werkende ACCDB-bestand terwijl je door de wijzigingen werkt. Het is belangrijk om te benadrukken dat je niet verlegen hoeft te zijn om vaak op te slaan - het hoeft niet te betekenen dat je elke keer dat je moet opslaan, moet vastleggen, maar door regelmatig op te slaan, zal je werkboom nauwkeurig de omvang van je wijzigingen weergeven wanneer je zijn klaar om zich in te zetten. We zullen dat in detail bespreken in een later gedeelte.

Automatische UPDATE vóór import en Automatische COMMIT na export lijkt misschien handig, maar in de praktijk hebben we gemerkt dat het veel beter is om dit handmatig te doen, vooral wanneer we exporteren met de sneltoets Ctrl+S, omdat we ons niet per se willen vastleggen; sla alleen ons onderhanden werk op, zodat we weten wat er verandert als we daadwerkelijk klaar zijn om ons te committeren. Om die reden laten we ze weg.

.oasis Bestand instellen

Zodra u op OK klikt in het instellingendialoogvenster, worden de wijzigingen die u in verschillende panelen hebt aangebracht, naar de .oasis geschreven bestand in een XML-vorm. Zoals vermeld, kunt u het kopiëren en een sjabloon maken, zodat u snel een andere Access-toepassing kunt configureren. We zijn nu klaar om daadwerkelijke broncodecontrole uit te voeren.

Exporteren en vastleggen

Zoals eerder vermeld, moeten we, omdat we met een binair bestand werken, alles exporteren naar een tekstuele weergave zodat ze goed kunnen worden beheerd door de broncodecontrole. Om dit te doen, moeten we de objecten exporteren. U kunt de OASIS-SVN exportknop gebruiken zoals aangegeven.

U krijgt een dialoogvenster met alle objecttypen die voor export worden vermeld. Aangezien dit onze eerste export is, gebruiken we Ctrl + A om alles te selecteren voor export.

Klik op OK om het exporteren te voltooien. Als alles goed gaat, krijg je een bericht dat dit aangeeft.

Als u in de bronmap kijkt, ziet u alle tekstbestanden die verschillende objecten vertegenwoordigen die u zojuist hebt geëxporteerd. Houd er rekening mee dat de naamgevingsconventie kan verschillen, afhankelijk van wat u hebt geselecteerd in het deelvenster Instellingen, zoals weergegeven in de vorige sectie. Ook omdat we ervoor hebben gekozen om bestanden te splitsen, hebben we allebei een .def en een .lay-out bestand voor een enkel Access-object.

Nu de objecten zijn geëxporteerd als tekstbestanden, moeten we nu onze wijzigingen vastleggen. OASIS-SVN levert de TortoiseGit-commando's rechtstreeks vanuit Access, zoals weergegeven.

Meestal worden de 4 commando's die je wilt gebruiken hier getoond - de andere commando's zijn goed om te gebruiken, maar we hoeven ons daar geen zorgen over te maken totdat we in meer complexe git-scenario's terechtkomen. Trouwens, die commando's zijn eigenlijk dezelfde commando's die door TortoiseGit worden getoond via het contextmenu van de Windows verkenner:

Verder is een subset van commando's beschikbaar via het rechtsklikmenu in het Access-navigatievenster:

Je hebt dus verschillende manieren om met OASIS-SVN of met TortoiseGit rechtstreeks vanuit Access te werken, of je kunt TortotiseGit gewoon rechtstreeks vanuit de Windows-verkenner gebruiken. Merk op dat je Commit . hebt in alle schermafbeeldingen; wat onze volgende stap wordt. Als je het kiest, wordt een TortoiseGit-dialoogvenster geopend:

Meestal wil je alles selecteren. Merk op dat het alleen de tekstbestanden bijhoudt die we in de projectmap plaatsen. Dat punt is het benadrukken waard; als je geen object uit Access hebt geëxporteerd, kan git er onmogelijk van weten. U moet een beschrijvend commit-bericht opgeven; hoe gedetailleerder, hoe beter. We geven er ook de voorkeur aan om meerdere kleine commits te doen omdat op die manier de geschiedenis beter te begrijpen is. Je wilt niet één keer per week een commit doen met 1000 wijzigingen; dat zou niet te begrijpen zijn. Je wilt een vastlegging nadat je een taak hebt voltooid (bijvoorbeeld het oplossen van een specifieke bug of het introduceren van een functie), zodat je geschiedenis gemakkelijk te begrijpen is.

Als je de gewoonte krijgt om je werk te committen, wil je misschien opmerken dat TortoiseGit je 3 opties geeft om te committen:

Opnieuw vastleggen is handig als je meerdere commits moet maken omdat je 2 of meer taken hebt gedaan en je de commit voor elke taak wilt scheiden. Het is waarschijnlijk het beste om dat niet te doen en vast te leggen zodra je een taak hebt voltooid, maar als je verstrikt raakt in opwinding, vink je gewoon een subset van bestanden aan die je wilt vastleggen en klik je op opnieuw vastleggen. TortoiseGit zal alleen die subset-bestanden vastleggen en vervolgens de vastleggingsdialoog opnieuw instellen zodat je de andere subset(s) van bestanden kunt vastleggen met een apart bericht.

Toezeggen en pushen wordt vaak gebruikt om commit en push te combineren. Het is belangrijk om te onthouden dat commits alleen naar je lokale git-repository schrijft. Maar we begonnen met een externe repository. Je kunt je codewijzigingen niet delen met je collega's of een externe back-up van je werk hebben totdat je je lokale commits naar de server hebt gepusht, en daar is push voor. We zullen dit later in detail bespreken.

Wanneer je je commit, zal TortoiseGit je een voortgangsdialoogvenster geven en je laten weten of het gelukt is.

Afronden

Tot nu toe heb je geleerd hoe je een git-repository opzet, OASIS configureert en je eerste commit doet. Dat is echter nauwelijks krassen op het oppervlak. De volledige kracht van git is nog niet duidelijk totdat je in vertakkingen komt, de geschiedenis leest en de conflicten oplost. Dit zijn echter strikt git-dingen en hebben minder te maken met Access of OASIS; elke algemene git-gids die we al aan het begin van het artikel hebben gelinkt, zal zeer nuttig zijn om te begrijpen hoe een git-repository moet worden beheerd. Het is de moeite waard om eraan te herinneren dat TortoiseGit slechts een dunne GUI-wrapper is over git-commando's, dus zelfs als de tutorial spreekt over het gebruik van een bash-shell, zou je hetzelfde moeten kunnen doen via het TortoiseGit-menu met dezelfde naam. Vragen hebben? Vraag weg in reacties!