Git workflow

De stappen in de Git workflow

Wanneer je Git gebruikt, dan hou je een Git workflow aan. De workflow die eerst wordt besproken is voor 1 of 2 developers. Het is wel belangrijk om te weten hoe deze workflow uitgevoerd wordt.

De Git workflow begint nadat je een clone van een repository hebt gemaakt. Daarna kan je op je eigen machine de lokale repository aanpassen.

In je project heb je een main branch: dat is de code die actief is op je productie-omgeving (in principe: we komen hier later nog op terug).

In semester 1 probeerde je om jouw main en de team-repository "in sync" te houden: in een UML Sequence Diagram ziet het er zo uit.

sequenceDiagram
    autonumber
    box Jouw Local Copy
        participant workdir as Working directory
        participant staging as Git staging area
        participant localrepo as Local repository
    end
    box GitLab server
        participant remoterepo as GitLab repository
    end

    remoterepo ->> localrepo: clone
    localrepo ->> workdir: checkout main branch
    activate workdir

    workdir ->> workdir: update source code

    workdir ->> staging: git add ...
    activate staging
    deactivate workdir
    staging ->> localrepo: git commit ...

    remoterepo ->> localrepo: git pull

    opt Merge conflicts?
        activate workdir
        workdir ->> workdir: fix conflicts
        workdir ->> staging: git add ...
        deactivate workdir
        staging ->> localrepo: git merge commit ...
    end
    deactivate staging

    localrepo ->> remoterepo: git push

• Stappen 1 en 2 heb je al uitgevoerd: je hebt een lokale clone gemaakt, en daarmee ook een checkout van de main branch in je Working Directory gedaan.

• In stap 3 voeg je lokaal files toe of pas je ze aan. Dit gebeurd in de Working Directory. Alle aanpassingen in de Working Directory zijn fysieke aanpassingen aan je harde schijf waar de local repository staat. Git heeft nog niets gedaan met deze aanpassingen.

• In stap 4 voeg je nieuwe files en aanpassingen toe aan de Staging area. Heb je een onderdeel van je functionaliteit af, en ben je echt zeker dat alle stappen correct zijn doorgevoerd, dan kan je stap 3 uitvoeren.

  Info

  Je gebruikt de Staging area om bij elkaar horende aanpassingen die je hebt gedaan klaar te zetten om aan de repository (de geschiedenis van het project) toe te voegen.

  Tip

  Je voert git add zo vaak mogelijk uit. In VS Code kan je dan gemakkelijk controleren wat je ten opzichte van je vorige git add hebt veranderd. Ook kan je kijken wat er in de staging area veranderd is t.o.v. de repository.

  Note

  Ook als je een file verwijdert, geef je dit aan met git add. Dit is wat tegenstrijdig, maar je geeft de actie voor het verwijderen door aan staging en niet het daadwerkelijke verwijderen van de file zoals gedaan wordt in jouw Working Directory.

• In stap 5 maak je een nieuwe snapshot van je local repository. Je maakt als ware een foto van de huidige staat van de repository. Alles wat je hebt toegevoegd aan de Staging area tijdens stap 2 wordt toegevoegd aan de snapshot. Dus via de commando’s git add en git commit voeg je toe aan de geschiedenis van je repository.

  Info

  Een commit zou je minder vaak moeten uitvoeren dan git add, maar in praktijk is dit vaak 1 op 1.

  Tip

  Leer jezelf aan om in elk geval aan het einde van de dag het werk dat af is te committen.

• Ben je klaar met wat je moet doen en wil je de local repository opslaan op de GitLab server, dan voer je de volgende stappen uit.

• Tijdens stap 6 zorg je dat je local repository gecombineerd wordt met de huidige remote repository. Dus alle aanpassingen die jij nog niet local had worden dan opgehaald en verwerkt in je local repository. Het commando git pull moet je meerdere keren per dag uitvoeren.

  Tip

  Zorg dat je al je eigen wijzigingen verwerkt hebt. Als je bij een git pull conflicten krijgt, dan worden die toegevoegd aan alle andere wijzigingen in je Working Directory. Dat wordt snel onoverzichtelijk.

• Stap 7 is belangrijk als je samen met andere ontwikkelaars werkt. Het kan zijn dat iemand anders een aanpassing heeft gedaan die overlapt met een van jouw wijzigingen. Werk je nog niet samen, dan zul je geen conflicten hebben natuurlijk.
  
  Tijdens stap 7 moet je conflicten in de files binnen je Working directory verhelpen. Dit is een stap die je local wilt uitvoeren, want je kan dan meteen de code van het project testen en het resultaat zien.
  
  Als je de conflicten hebt opgelost, voeg je de extra wijzigingen toe met een extra commit (stappen 8 en 9).

• Heb je geen conflicten meer, dan kan je stap 10 uitvoeren: het delen van jouw lokale aanpassingen met de remote repository. Na het commando git push zijn de local repository en remote repository gelijk.

• Stap 11 is weer het ophalen van de remote repository. Als stap 10 goed gegaan is, dan moet je de melding krijgen dat er geen aanpassingen binnen zijn gehaald.

Naslagwerk

Hier volgt wat naslagwerk en meer uitleg over de workflow en commando’s.

• https://github.com/git-guides/git-add
• https://github.com/git-guides/git-commit
• https://github.com/git-guides/git-pull
• https://github.com/git-guides/git-push
• https://git-scm.com/docs/git-checkout

Opdrachten

Voor deze opdracht ga je een nieuwe file toevoegen aan de repository. Deze opdracht kan je in je eentje uitvoeren. Voer de volgende stappen uit:

1. Clone de repository voor deze workshop

2. Maak een nieuwe html file

   a. Gebruik onze file name-conventie voor deze html file

   b. Zorg dat deze file jouw naam afdrukt

3. Voer alle stappen uit van de git workflow

   Tip

   Zorg ervoor dat je duidelijke commit messages schrijft, zodat je later gemakkelijk kunt terugvinden wat je hebt gedaan.

Ben je klaar met de opdracht hierboven, dan kan je de volgende uitvoeren. Voer deze opdracht uit met nog een teamgenoot of met je hele team. Voor deze opdracht gaan jullie allemaal werken in hetzelfde bestand.

1. Iedereen doet een pull van de remote repository

2. Iedereen dubbel checkt of local en remote gelijk is (dus voor elk teamlid is een html file)

3. Iedereen maakt een aanpassing in de index.html

   a. Iedereen voegt een <p> toe met wat max 3 onzin tekst

4. Voer alle stappen uit van de git workflow

   a. Zorg dat iedereen om de buurt stap 4 uitvoert

   b. Los ook het conflict op per teamlid

Veel gemaken fouten

Helaas kan nog steeds veel fout gaan bij het gebruik van Gitlab. Hieronder staan foutmeldingen en een link naar hoe je met deze foutmeldingen om moet gaan.

”Please clean your repository working tree before checkout”

Waarschijnlijk probeer je een pull te doen, maar staan er nog wijzigingen die niet via de workflow in de locale repo staan. Dus onder changes staat 1 file of staan meerdere files met aanpassingen.

Wanneer deze geen onderdeel zijn van de commit, dan kan je deze in de stash zetten via de Stash Changes. Heb je daarna de pull uitgevoerd haal je alles uit de stash via Pop Stash….

In het eerste antwoord op stackoverflow wordt getoond hoe je file in en uit de stash haalt. https://stackoverflow.com/questions/51817479/vscode-please-clean-your-repository-working-tree-before-checkout

Commit zonder message

Een ander fout is wanneer je een commit doet, je vergeet om een commit message toe te voegen. Opent COMMIT_EDITMSG in een tab van VSCode en voor de rest gebeurt er niets.

Je moet dan de tab COMMIT_EDITMSG sluiten en een commit message toevoegen in het tekstveld boven de juiste commit-knop.

Ander foutje

Gitlab heeft ook een blog post over andere foutjes die gemaakt worden met Gitlab en hoe ze opgelost kunnen worden.

https://about.gitlab.com/blog/2018/08/08/git-happens/