Repository navigation
Versiebeheer Conventies
Git kan via de console aangestuurd worden, of via wrapper applicaties zoals:
De main branch is de root van alle branches, alleen volledige versies worden hier op gezet. Deze versies moeten ook een full release in releases hebben.
De develop branch is de branch waar alle complete features/veranderingen op worden gezet. Deze branch mag geen errors bevatten, en moet een kandidaat zijn voor een full release.
In de feature folder staan alle branches waarin gewerkt word aan een feature. Na het maken van een feature wordt er een pull request naar develop aangemaakt.
Voorbeelden: feature/PlayerMovement, feature/EnemyAI
In de art folder staan alle branches waarin gewerkt word aan een art onderdeel (models, textures, etc). Na het maken van een feature wordt er een pull request naar develop aangemaakt.
Voorbeelden: art/Enemy, art/MainMenu
In de demo folder komen alle demo builds. Er word in deze branch niet gewerkt. Met een demo branch komt ook een beta release in releases.
Elk commit bericht is in het Engels en moeten goed beschrijven wat er veranderd is. We gebruiken het format <Type> [Scope]: Beschrijving.
Het type beschrijft wat het punt van de commit is.
| Type | Betekenis |
|---|---|
| Art | Veranderingen aan assets, textures, materials, etc. |
| Feature | Veranderingen aan een feature |
| Fix | Bug fixes en andere probleem oplossingen |
| Project | Veranderingen aan het project settings/plugins |
| Refactor | Optimalisatie en herstructureren |
| Rendering | Veranderingen die rendering, shaders, lighting aanpassen |
| Scene | Veranderingen aan scenes/levels |
De scope geeft aan wat er wordt veranderd door de commit.
Bijvoorbeeld: <Art> [Player] betekent dat de art van de speler is aangepast.
De beschrijving is een korte samenvatting van wat er veranderd is.
Bijvoorbeeld: <Art> [Player Character]: Added eyes to character material maakt duidelijk wat er in de commit is gebeurd.
Wanneer een taak af is kan er van de branch een pull request gemaakt worden. Dit doen we zodat andere teamleden de veranderingen kunnen testen en reviewen voordat het in een andere branch terecht komt.
Let op: Kijk goed of je de juiste branches geselecteerd hebt. Meestal is dit develop <- "jouw/Branch".
De titel van de pull request is de naam van de branch bijvoorbeeld: feature/PlayerMovement (Let op hoofdletters).
De beschrijving moet in het Nederlands beschrijven wat er getest moet worden en wat er waar veranderd/toegevoegd is.
Map locaties worden aangegeven in de markdown als: `/Locatie/Naar/Map`. Dit gaat er dan zo uit zien: /Locatie/Naar/Map.
Voorbeeld.
Nadat er feedback is gegeven en alle feedback is geïmplementeerd mag de branch gemerged worden met de target branch.
- Assets volgen de asset naamgeving.
- Code is non-repetetive en decoupled.
- Code volgt de code conventies.
- Assets volgen de asset naamgeving.
Als er een pull request aangemaakt is gaat iemand die reviewen in review doe je door alle aangepaste bestanden te controleren in de engine. Dan kan je een review comment maken.
Onder Files Changed staat een knopje Review changes.
Hier kan je een comment schrijven voor de hele pull request en heb je een keuze uit 3 opties Comment, Approved en Request changes. De Comment gaan we het minst gebruiken en is alleen voor extra info meestal op een specifiek bestand. De Approved is voor wanneer alle aanpassingen goed zijn, hierna mag je gelijk mergen deze comment heeft geen beschrijving nodig. De Request changes is voor wanneer er verschillende dingen aangepast moeten worden zet alle comments onder het juiste bestand en dan een lege comment met de Request changes check.
Rechst boven elk bestand staat een spraak bubbel icoontje hier kan je voor dit specifieke bestand een comment schrijven.