Deze video vat het goed samen wat betreft rebase: https://www.youtube.com/watch?v=f1wnYdLEpgI
git workflow:
1. branch maken
2. developen met atomaire commits op feature branch. steeds pushen naar github na een commit
3. update master + rebase onto master (zie video)
4. pull request + code review !!! zie ##pull_requestHet basis idee is dat we nieuwe code ontwikkelen op een aparte branch. Eens de feature klaar is en de code stabiel, kunnen we met een pull request de master branch updaten. Hierdoor wordt het gemakkelijker om met verschhillende teams aan verschillende features te werken zonder de gemeenschappelijke code voor elkaar te breken. Een bijkomend voordeel is dat je per definitie nooit met oncompileerbare code op de master kan zitten. De commit history op de master branch kunnen we dan beschouwen als een logisch opgebouwd verhaal van hoe de applicatie tot stand kwam.
Samen met onze team-organisatie in Sprint cycles, het geautomatiseerd testen en geautomatiseerd deployen past dit in het grotere concept Continuous Integration/Continuous Delivery waar Jens Buysse het over had.
De video vat alles goed samen, maar toch nog een paar opmerkingen:
Je maakt de feature branch aan.
Als conventie zorgen we voor een duidelijke naamgeving: feature/<trello-idNr>-<trello-kaart-titel>
vb.
git pull
git checkout -b "feature/55-backend-geef-alle-rubrics-van-gebruiker"
op die manier kan de reviewer (zie ##pull request) het kaartje ook gemakkelijk terugvinden om te valideren.
in het ontwikkelingsproces doe je een aantal commits, één commit per logische stap om tot het resultaat te komen.
Vergeet na elke lokale commit niet om ook git push te doen zodat je code ook op github gebackupped is.
voorbeeld proces (in volgorde):
- //code schrijven
git commit -m 'repository voorzien om rubrics uit db op te halen'
git push- //code schrijven
git commit -m 'repository voorzien om users uit db op te halen'
git push- //code schrijven
git commit -m 'service methode implementeren om de rubrics van de huidige gebruiker op te halen'
git push- //code schrijven
git commit -m 'Rest endpoint implementeren die de data in JSON formaat terug geeft'
git push
In de praktijk gebeurt het meestal niet zo gestructureerd, maar dat is niet zo erg, beschouw het eerder als een streefdoel. Partial commits en achteraf eventueel interactive rebase met intellij kunnen hierbij helpen.
zie video: https://www.youtube.com/watch?v=f1wnYdLEpgI
De master branch updaten doen we dus via een pull request. Een pull request is een vraag naar iemand anders om de code te bekijken. Als de code voldoet, dan kan hij/zij mergen, anders rejecten met commentaar wat er moet veranderen.
In de regel is dit dus best iemand anders dan degene die de code heeft geschreven en een review doet, zowel op technisch als functioneel vlak. Als de commits goed gestructureerd zijn, word de job van de reviewer ook gemakkelijker.
- Code review:
- leermoment: we kunnen bijleren van elkaar's code / manier van oplossen
- code quality: bepaalde dingen die op termijn bugs kunnen worden kunnen we al vroeg opvangen
- shared code knowledge: je vermijd dat je na bepaalde tijd met een heel deel van de applicatie zit waarvan maar 1 persoon weet hoe die werkt.
- shared code ownership: als er iets verkeerd geimplementeerd is of bugs blijkt te bevatten, is dat niet enkel de verantwoordelijkheid van de schrijver, de reviewer heeft er ook een aandeel in.
- Functional review: de reviewer kan ook 'big picture' denken:
- komt wat er geimplementeerd is overeen met wat het kaartje vraagt?
- zijn er onderdelen die in het kaartje staan die ontbreken?
- functioneel testen: het gebruik testen
in professionele teams die groot genoeg zijn wordt de feature validatie gedaan door testers of analisten, kleine teams combineren de rollen vaak. Dit is een belangrijke mijlpaal in de ontwikkeling, en verdient dan ook voldoende aandacht van de reviewer.