Samenwerken in team (met git)

Git repositories

1. Repository

Een repo is als een map waarin je alle bestanden en hun volledige geschiedenis opslaat. Het is de plek waar het project leeft.

Waarom zijn Git repositories nodig?

Git repositories zijn essentieel voor het bijhouden van de geschiedenis van je project. Ze maken het mogelijk om wijzigingen in je code te volgen, samen te werken met andere ontwikkelaars en verschillende versies van je project te beheren. Het zorgt ervoor dat je altijd kunt terugkeren naar eerdere versies, conflicten tussen verschillende wijzigingen kunt oplossen en je werk efficiënt kunt delen met anderen.

2. Clone

Je maakt een kopie van een repo van bijvoorbeeld GitHub naar je eigen computer. Dit heet "clonen".

3. Branch

Een branch is een aparte versie van de code. Je kunt hier wijzigingen maken zonder de main branch (de hoofdlijn) te verstoren.

4. Commit

Een commit is een "snapshot" van je wijzigingen. Het is een veilige manier om stappen van je werk op te slaan.

5. Push

Met pushen stuur je jouw commits naar de centrale repo (bijvoorbeeld op GitHub), zodat anderen je werk kunnen zien.

6. Pull

Met pullen haal je de laatste wijzigingen van de centrale repo op naar je eigen computer. Zo blijf je up-to-date.

7. Merge

Met mergen voeg je de wijzigingen van één branch samen met een andere, meestal de main branch.

8. Conflict

Een conflict gebeurt als twee mensen dezelfde code aanpassen. Git vraagt je om te kiezen welke wijzigingen belangrijk zijn.

9. Pull Request (PR)

Een pull request is een voorstel om je branch samen te voegen met de main branch. Andere teamleden kunnen je werk bekijken en goedkeuren.

---

GitLab Branching Strategie

1. Main Branch (of Master)

De main branch (ook wel master genoemd) is de stabiele versie van de code. Deze wordt altijd gebruikt voor de productieversie van je project. Alleen goedgekeurde en geteste code wordt naar deze branch gepusht.

2. Feature Branches

Wanneer je een nieuwe functie toevoegt, maak je een feature branch. Deze branch is specifiek voor één taak of functie en wordt regelmatig bijgewerkt met de laatste wijzigingen van de main branch. Zodra je werk voltooid is, merge je je feature branch terug naar de main branch.

3. Develop Branch

In grotere teams wordt vaak een develop branch gebruikt. Alle nieuwe functies en fixes worden in deze branch samengevoegd, waarna deze uiteindelijk naar de main branch wordt gepusht voor release.

4. Release Branches

Een release branch wordt gebruikt om een nieuwe versie van het product voor te bereiden. Hier wordt de laatste fine-tuning gedaan voordat het naar de main branch wordt gemerged en geüpdatet voor productie.

5. Hotfix Branches

Hotfix branches worden gemaakt wanneer er een kritieke bug of probleem in de productieversie van de code is. Deze branch wordt snel gemerged met de main en develop branches nadat de bug is opgelost, om de stabiliteit van de productie te waarborgen.

Waarom deze strategie?
De GitLab branching strategie zorgt ervoor dat de verschillende aspecten van een project gescheiden blijven, waardoor de ontwikkelingsworkflow overzichtelijk blijft. Het maakt samenwerking efficiënter en minimaliseert het risico op conflicten in de code.

---

Code Reviews en Developer Agreements

Code Reviews

Een code review is een proces waarbij ontwikkelaars elkaars code beoordelen om de kwaliteit en functionaliteit te waarborgen. Code reviews helpen bij het ontdekken van fouten, verbeteren van de codekwaliteit, en zorgen voor kennisdeling binnen het team.

• Waarom code reviews belangrijk zijn:

  • Verbeteren van kwaliteit: Door code door anderen te laten nakijken, worden bugs en verbeterpunten vaak sneller opgemerkt.
  • Consistentie: Code reviews zorgen ervoor dat de code voldoet aan de afgesproken normen en best practices binnen het team.
  • Kennisdeling: Junior ontwikkelaars leren van de feedback van senior developers, waardoor iedereen op hetzelfde niveau komt te werken.

• Hoe een goede code review eruit ziet:

  • Duidelijke uitleg: De ontwikkelaar moet uitleg geven over de wijzigingen die hij/zij heeft aangebracht, zodat reviewers de context begrijpen.
  • Focus op één ding tegelijk: Zorg ervoor dat je tijdens een code review focust op specifieke aspecten zoals leesbaarheid, efficiëntie of bugfixes.
  • Constructieve feedback: Wees specifiek en constructief in je feedback. In plaats van simpelweg te zeggen "Dit moet anders", leg uit waarom en geef suggesties voor verbetering.

Developer Agreements

Een developer agreement is een formele overeenkomst binnen een team die richtlijnen biedt voor hoe code reviewed moet worden en welke normen gevolgd moeten worden. Het kan onderdeel zijn van een bredere werkcultuur die bijdraagt aan het succes van de samenwerking. Enkele belangrijke punten die in een developer agreement opgenomen kunnen worden:

• Code standaarden: Dit kan specificeren hoe code gestructureerd moet worden, welke stijlregels er zijn en welke tools gebruikt moeten worden (zoals linters, formatters, enz.).
• Review criteria: Het definiëren van de verwachtingen voor code reviews, zoals het aantal goedkeuringen dat nodig is voordat code gemerged kan worden.
• Beveiliging en privacy: De overeenkomst kan regels bevatten over het omgaan met gevoelige gegevens en beveiligingsmaatregelen tijdens de code review.

Waarom een developer agreement?
Een developer agreement zorgt voor een gemeenschappelijke basis van verwachtingen en normen. Het maakt de werkprocessen duidelijker, zorgt voor minder misverstanden en verbetert de samenwerking binnen het team.

---

Meer details over Scrum

Belangrijkste Kenmerken van Scrum

1. Sprints:

   • Vaste tijdsperioden (meestal 2 weken) waarin een deel van het werk wordt afgerond.
   • Elk sprint heeft een vooraf vastgesteld doel (Sprint Goal).
   • Aan het einde van elke sprint wordt werkbare software opgeleverd.

2. Rollen:

   • Scrum Master: Zorgt ervoor dat het Scrum-proces wordt gevolgd en verwijdert obstakels.
   • Product Owner: Prioriteert werk op basis van waarde voor de klant, beheert de product backlog.
   • Development Team: Multidisciplinair team dat verantwoordelijk is voor het uitvoeren van het werk.

3. Artefacten:

   • Product Backlog: Lijst van alle gewenste functies of verbeteringen, gesorteerd op prioriteit.
   • Sprint Backlog: Subset van de Product Backlog waaraan het team werkt tijdens een sprint.
   • Increment: De opleverbare, werkende software

aan het einde van een sprint.

4. Events:
   • Sprint Planning: Vaststellen wat er in de komende sprint wordt opgeleverd.
   • Daily Scrum: Korte (15 minuten) dagelijkse meeting om voortgang te bespreken en obstakels te identificeren.
   • Sprint Review: Team demonstreert het werk van de afgelopen sprint aan stakeholders.
   • Sprint Retrospective: Reflectie op de sprint om processen te verbeteren.

Sterke punten van Scrum

• Duidelijkheid: Structuur en vaste rollen geven helderheid over verantwoordelijkheden.
• Iteratief: Feedback na elke sprint zorgt voor continue verbetering.
• Transparantie: Stakeholders kunnen regelmatig de voortgang bekijken.
• Focus op prioriteiten: Het team werkt altijd aan de meest waardevolle taken.

Zwakke punten van Scrum

• Intensief: Vereist discipline en betrokkenheid van het team en stakeholders.
• Overhead: Regelmatige meetings en rollen kunnen tijdrovend zijn.
• Niet voor alle teams: Teams die geen stabiele samenwerking hebben of met veel onverwachte taken werken, kunnen moeite hebben met het model.

Wanneer Scrum gebruiken?

Scrum is ideaal als:

• Het project complex is en vereisten regelmatig veranderen.
• Je team multidisciplinair is en zelfstandig kan werken.
• Feedback van klanten of stakeholders cruciaal is tijdens de ontwikkeling.