Dette er en side til at beskrive de standardiserede arbejdsgange der er aftalt i teamet. Tilføj gerne!
Git/GitFlow/branches generelt
Git bruges til versionsstyring. Remote repositories findes her: https://github.com/os2indberetning.
Vi følger metoden GitFlow, som er beskrevet her: http://nvie.com/posts/a-successful-git-branching-model og her: http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/ .
Kort om GitFlow
Når Git Flow følges er der to branches der lever hele tiden:
- develop - løbende udvikling
- master - ét commit per release
Der committes aldrig direkte på master branch men kun som et resultat af et trin git flow (hotfix eller release branch). Hvert merge-commit til master branchen skal bumpe versionsnummeret.
Feature branches
Som udgangspunkt oprettes til hver bid udvikling en såkaldt feature-branch. Selvom navnet kunne antyde andet bruges dette også til almindelige (ikke-panik) fejlrettelse og altså til alt udvikling inden for projektet. En feature branch hedder altid "feature/navn" hvor navn er et beskrivende navn for denne feature. Det er fint hvis navnindeholder f.eks. Jira issue navn men det er nødvendigt at det også indeholder andet. Stammer det fra et Jira issue kan dette issues summary passende bruges. Når feature branches altid starter med "feature" efterfulgt af en slash "/" vil det optræde som en folder (directory). Når en feature afsluttes og dermed merges ind i develop skal den tilhørende branch slettes. Intet går tabt ved denne sletning ud over dens navn, og vi undgår dermed et kaos af feature branches. Det er en god idé at slette featurebranchen med det samme den er merget ind i development.
Release branches
Som en del af git flow kan der benyttes release branches til at færdiggøre en release uden at forstyrre develop branchen. Typisk er dette dog ikke strengt nødvendigt men git flow værktøjer vil lave en alligevel men den ender med at være tom og blive slettet igen i næste trin af værktøjet.
Git tags
Enhver release lavet igennem git flow resulterer i en tag i git og denne tag tilhører en commit på master branch. Det skalderfor også være dette kode der bruges som udgangspunkt for build til release.
Versionering
Se Workflow for releases og nye opgaver.
Visual Studio
TODO i VS:
Visual Studio kan vise en liste over alle TODOs i koden. Gå til View–>Task List for at få vinduet frem.
TODOs skrives sådan:
// TODO: [Initialer eller navn] [YYYY-MM-DD] [Besked] eksempel: // TODO: RRO 2016-10-21 Denne TODO er oprettet af Rasmus Rosendal den 21. oktober 2016.