The main branches
- master
- develop
Types of branches
- Feature branches
- Release branches
- Hotfix branches
Feature branches
- May branch off from: develop
- Must merge back into: develop
- Branch naming convention: feature_EBZS-XXX_description
$ git checkout -b myfeature develop
...
$ git checkout develop
$ git merge --no-ff myfeature
$ git branch -d myfeature
$ git push origin develop
Release branches
- May branch off from: develop
- Must merge back into: develop and master
- Branch naming convention: release_version
$ git checkout -b release_1.2 develop
...
$ git checkout master
$ git merge --no-ff release_1.2
$ git branch -d release_1.2
Hotfix branches
- May branch off from: master
- Must merge back into: develop and master, and possibly the release branch
- Branch naming convention: hotfix_version_SWAT-XXX_description
$ git checkout -b hotfix_SWAT-3456_mybugfix master
$ git checkout master
$ git merge --no-ff hotfix_SWAT-3456_mybugfix
$ git checkout develop
$ git merge --no-ff hotfix_SWAT-3456_mybugfix
$ git checkout release_1.2
$ git merge --no-ff hotfix_SWAT-3456_mybugfix
$ git branch -d hotfix_SWAT-3456_mybugfix
Useful links
How it differs from gitflow
- all branches in the main repo, no developer's repositories
- merge of master into develop and into the release branch
- The release branch stays alive for long periods of time
Why it differs
- Our test coverage is very low and our applications are unstable
- We have a lot of hot fixes, and we have even urgent features developed on hotfix branches / master
- Our releases are tedious and incertain so we push to production many commits at once
So if we do a straight Giflow, it will result in
- Many more conflicts to resolve (HFB to master, HFB to release, HFB to develop)
- Many useless merge commits
About GRebaase
- Delphine is in charge of merges
- We need to know when to rebase our branches (please check regularely)
Propositions
- forker sur son propre compte?
- moins de commit par mep => aller vers le deploiement continue
- mep swat plus fréquentes?
- releases branches plus fréquentes
- merger les FB testées sur develop plus rapidement
- moins de hotfix et plus de features
- tests auto sur les FB
- tests auto d'intégration pour une release branch qui ne dure que quelques jours
non car deploy et QA
peut etre dissocier front back et api mais
Idée à étudier: scripts customs au client près
les PO et QA "débordés" 🍼 => met 1 à 2 semaines
tests auto sur release branch 🚕 mais surtout on la crée tard : on finit le sprint, on attend que tous les tickets soient mergés puis QA puis merge
=> cf problème d'avant, pas de prob avec la release branch
peut etre plusieurs de mep par sprint?