GIT Workflow

Git Workflow / Gitflow Workflow

Onze git workflow is los gebaseerd op de Gitflow Workflow, maar neemt deze niet 100% over. Het kern-idee is hetzelfde:

• Er wordt steeds gewerkt met een develop en master branch, waarvan de origin (Bitbucket) altijd lijdend is:
  
  • Aanpassingen ( feature of fix ) voor een Minor Release of Major Release worden op de develop branch gedaan;
  • Aanpassingen ( hotfix ) voor een Maintenence Release worden op de master en, indien nodig, op de develop branch gedaan.
• Er wordt niet gewerkt met aparte release branches:
  • Voor elke release wordt de develop branch met de master branch gemerged;
  • Een release is vervolgens slechts een tag met een release nummer op de master branch.
• Er wordt uitsluitend met pull-requests gewerkt en niets wordt handmatig gemerged
  • Tenzij er sprake is van een conflict en dit niet anders kan;
  • Dit betekent dat git merge en git pull onnodig zijn (gebruiken = appelflappen trakteren).
• Er wordt geen gebruik gemaakt van de git flow opdracht.

Soorten branches, aanpassingen, releases en versienummering

Zoals hierboven benoemd, is een Maintenence release alleen in het geval er een hotfix gedaan moet worden. Een Minor of Major release kan zowel fixes als features bevatten. Het enige verschil tussen een Minor en Major release is de omvang van de aanpassingen. Van een Major release is sprake als er in de kern van het project erg veel veranderd is. Dit is meestal niet het geval en daardoor is er normaliter sprake van een minor release.

De format van het versienummer is steeds A.B.C , waarbij A = Major, B = Minor, C = Maintenence. Losse nullen mogen afgekort worden, dus 2.1.0 is 2.1 en 3.0.0 is 3.0 is 3 .

Git workflow proces

1. Jira issue
   Een issue in Jira vormt de basis voor de aanpassing. Er wordt altijd een issue in Jira gemaakt, zelfs als het om een hotfix gaat.
   Refereer je in je commit message niet aan deze issue, dan weigert Bitbucket de pull-request.
2. Fetch, Branch en Checkout
   Op basis van het issue in Jira maak je een nieuwe branch, met de juiste prefix: feature , fix of hotfix .
   Je werkt hierbij in jouw lokale omgeving en elke aanpassing heeft zijn eigen branch.
3. Commit en Push
   Zijn alle aanpassingen in de code klaar, dan commit je dit en push je jouw branch naar de origin (Bitbucket).
   Middels Smart Commits wordt de "Worklog" bijgewerkt en wordt de issue op "Done" gezet.
4. Pull-Request en Merge
   Je maakt een Pull-Request om jouw branch te mergen met betreffende develop of master branch.
   Daarna wordt de Pull-Request samengevoegd middels een merge commit.

Branch maken In een aparte branch werken

Als eerste haal je de laatste branches / aanpassingen van de origin op. De -p of prune optie zorgt dat branches die niet meer bestaan inde origin lokaal worden verwijderd, een soort van lokale schoonmaak.

git fetch -p

Vervolgens maak je voor elke aanpassing een branch aan waarin je zult werken. De naam van deze branch heeft altijd de vorm type/omschrijving , bijvoorbeeld fix/subscribe-button-broken . Er zijn 3 type branches mogelijk:

1. feature: ook feature branch, een verandering of nieuwe functie:
   1. bijvoorbeeld: feature/make-delete-button-red
   2. altijd op basis van origin/develop
2. fix: een bug of probleem dat opgelost moet worden, maar dat kan wachten tot de volgende release:
   1. bijvoorbeeld: fix/saving-form-slow
   2. altijd op basis van origin/develop
3. hotfix: een urgente bug of probleem dat direct opgelost moet worden en niet kan wachten tot de volgende release:
   1. bijvoorbeeld: hotfix/crash-on-homepage
   2. altijd op basis van origin/master

Maak een nieuwe branch en switch naar deze branch:

git checkout -b feature/make-delete-button-red origin/develop
git checkout -b fix/saving-form-slow origin/develop
git checkout -b hotfix/crash-on-homepage origin/master

Bovenstaande opdrachten zijn een samenvoeging van twee opdrachten die je ook los mag gebruiken: git branch feature/make-delete-button-red en git checkout feature/make-delete-button-red .

Om te zien in welke branch je op dat moment zit:

git branch

Aanpassingen committen & pushen

Alle aanpassingen die je maakt, maak je in de branch die je hebt gemaakt. Ben je tevreden met je aanpassingen dan kun je ze comitten:

git commit -a

Opnieuw is dit een samenvoeging van twee losse opdrachten, die je ook los mag gebruiken: git add . en git commit . Middels deze losse opdrachten kun je bestanden apart toevoegen aan je commit, bijvoorbeeld: git add src/Perfacilis/helpers.php .

Je krijgt nu de vraag om een commit message in te geven, dit is verplicht. Voor de opmaak van het commit-bericht wordt er van Smart Commits gebruik gemaakt. Hiermee kunnen jouw aanpassingen gekoppeld worden aan een issue in Jira. Hierdoor is een commit altijd 2 of 3 regels:

1. Het Jira issue-nummer en Jira issue omschrijving (kopie-pasta uit Jira);
   Dit komt in Bitbucket in het titel veld van de Pull Request terecht.
2. Het Jira issue-nummer en tijdnotatie (zie Smart Commit documentatie) hoe lang je er over gedaan hebt, inclusief wat je gedaan hebt.
   Dit komt automatisch in de Jira Worklog terecht;
3. Het Jira issue-nummer en de transitie: #in-progress of #done , deze regel is optioneel, bijvoorbeeld als het nog niet af is (een tussentijdse commit).
   De transitie verplaatst de issue in Jira naar de juiste kolom in de sprint.

FW-123 Make delete buttons red to make them better visible
FW-123 #time 1h 15m Changed button classnames from `btn-primary` to `btn-danger`
FW-123 #done

Uiteraard kun je meerdere commits aan jouw branch toevoegen, dit is handig als je je werk tussentijd wilt opslaan.

Daarna moet de branch middels de push opdracht gepusht of geüpload worden naar de origin, in dit geval is de origin Bitbucket. Op die manier wordt jouw branch — met jouw aanpassingen — beschikbaar voor iedereen die toegang heeft tot deze repository:

git push origin feature/make-delete-button-red

Branches Mergen Middels een Pull request (bij BitBucket)

Bovenstaande git push opdracht zal direct een link genereren waarmee je een pull-request kunt maken: een verzoek om jouw code op te nemen oftewel een verzoek om jouw code te mergen met de origin. Maak je gebruik van deze link, dan zal er meteen een pull-request worden gemaakt, maar jouw aanpassingen worden nog niet gemerged.

Vervolgens kom je op de pull-request pagina in Bitbucket. Daar kun je eventueel het doel of de target branch nog aanpassen, maar als het goed is is dit niet nodig. Ook het Title en Description veld zouden al goed moeten staan. Vervolgens klik je op "Create pull request" om de pull-request definitief aan te maken.

Vervolgens ligt het aan jouw rechten of de merge-knop toegankelijk is. Als je beperkte rechten hebt kun je een of meerdere mensen taggen die jouw code moeten goedkeuren middels de approve knop. Daarna kunnen jouw wijzigingen toegevoegd worden aan de betreffende doel-branch middels een merge commit (dat gebeurt automatisch als iemand op de Merge knop klikt).

Nu de pull-request is gemerged, is de develop of master branch van de origin (Bitbucket) veranderd, maar lokaal heb je nog steeds de oude versie van de  develop of master branch. Daarom moet je deze aanpassing binnenhalen uit de origin:

git fetch -p

Wanneer je nu git branch gebruikt zul je zien dat je nog steeds in de feature-branch werkt. Als er nog een aanpassing nodig is in deze branch, dan kun je een nieuwe commit en vervolgens een nieuwe pull-request maken. Is het werk in deze branch klaar, dan kun je een nieuwe branch maken voor de volgende aanpassing.

Aanpassingen na een merge

Een (lokale) branch verwijderen

Wanneer je een merge hebt gedaan blijft de branch standaard aanwezig in het systeem. Je kunt uiteraard de branch vanuit de interface van GitHub of Bitbucket laten verwijderen, maar hij zal dan alsnog op jouw computer aanwezig zijn. Als je zeker weet dat je geen aanpassingen meer aan deze branch gaat doen kun je deze eventueel handmatig verwijderen om alles schoon te houden:

git branch -D naam-nieuwe-branch

Hiervoor dient deze branch uiteraard niet meer de actieve working copy te zijn (gebruik weer git branch om dit te controleren).

Verder werken in een bestaande branch

Wanneer je meerdere branches hebt aangemaakt kun je natuurlijk schakelen tussen deze branches. Op die manier kun je jouw werk aan de nieuwe feature onderbreken voor een bugfix tussendoor; Je schakelt van je feature-branch over naar een nieuwe bugfix-branch en keert terug als je bug hebt opgelost.

Switchen naar een lokale branch

Wanneer de betreffende branch lokaal staat kun je daar zeer gemakkelijk naar switchen. Gebruik  git branch  om te zien of het switchen gelukt is. Na het aanpassen kun je de normale workflow vanaf het committen weer volgen.

git checkout naam-lokale-branch

Switchen naar een remote branch

Wanneer een branch alleen in de origin staat (die niet lokaal) dan kun je deze branch binnenhalen volgens onderstaande opdrachten. Je branch wordt dan naar je lokale machine gehaald waarna je de normale workflow vanaf het committen weer kunt volgen. Handig als je je branch gepushed hebt vanaf een andere machine of als je aanpassingen wilt maken in een branch van iemand anders.

git fetch -p
git checkout -b naam-remote-branch origin/naam-remote-branch