Team standards og arbejdsgange

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.