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/
Når Git Flow følges er der 2 git 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.
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.
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
Endhver 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.
...