Since our team is using GIT heavily and members use GIT differently, it will be good if we draft, - something in common - have better defined good smells - allowed policies

1. By Walter Liu
WRS GIT branching model (draft)

2. Agenda
》 GIT Branches
》 How to work
》 Others
× Purpose behind
× Misc – Tips
× Misc – Troubleshooting
× RPM repo
× Versioning

3. GIT BRACHES

4. Overview

5. Private Personal Branch
》 Name: <account_name>
》 Set git remote branch to this
》 For developer daily work.
》 Promote to dev branch
》 Pull updates from dev branch

6. Dev branch (1/2)

7. Develop branch (2/2)
》 Name: dev
》 Require functional and unit test ready.
》 It’s best to have CI.
》 For dev build.
》 Promote to master branch
》 Update from
× Private branch
× Feature branch
× Hotfix branch

8. OUR master branch
》 Name: 1.0, 2.0 …..
》 Promote source from dev branch.
》 Release staging-candidate build.
× At the same time, tag it with
release version.
》 Update from
× dev branch
× hotfix branch

9. Feature Branch
》 Name: feature_<Feature_name>
× Example: feature_odin_authentication
》 Scenario:
× Feature that impact integration test
› Example: odin_authentication.
× Big feature
× Big project with many people
》 Promote to dev branch
》 Pull update from dev branch

10. Hotfix branch
》 Prefix:
× hotfix-<TT_number>-
<TT_number>.....
》 Scenario
× If your dev branch is working on
something.
》 Pull from master branch
》 Promote to
× master branch(s)
× dev branch
*Remember to prompt code to master and dev at the same time.

11. HOW TO WORK

12. So, how should we work.
》 For developers,
× Project start
› Create remote private branch.
› Set git remote branch to your private branch.
× Work on it, daily push source to private branch.
× Once finish a feature and it’s unit/functional test. Push to dev branch.
》 For RD lead,
× At project start, notify team members the git guidelines.
× START A NEW GIT PROJECT, see next slide
× [Recommended] Setup CI on dev and master branch.
× Use dev for developer development and test.
× For release a new build to OPS or staging test.
› Ensure the code quality is good enough.
› Promote code from dev to master branch.
› Git tag and master with release version.

13. Start a new git project
》 Create 1.0 or 2.0 .... For release
× Set it protected
》 Create dev branch
》 Set default branch to dev
》 Remove master branch

14. New Project
Set default branch

15. New Project
Set projected branch

16. Create a new remote branch
and track it locally
》 “Create branch on gitlab” or
》 git fetch origin
》 git branch --track <branch> origin/<branch>
》 git checkout <branch>
OR
# -b create new branch from dev branch
》 git checkout –b <new_branch> dev
# -u ,push source to remote and setup tracking
》 git push –u origin <new_branch>

17. Update source from dev
branch to private branch
》 git checkout <private_branch>
》 git pull
》 git merge dev
》 git push
OR
》 git pull origin dev <private_branch>

18. Promote source from private
branch to dev branch
》 git checkout dev
》 git pull
》 git merge <private_branch>
》 git push
OR
》 git push origin <private_branch>:dev

19. Promote source from dev
branch to master branch
》 Similar to last page
OR
# make sure local dev branch updated
#  git pull origin dev
》 git push origin dev:master

20. Promote source from hotfix
branch to dev/master branch
# make sure local dev branch updated
# git pull origin hotfix-<..>
》 git push origin hotfix-<..>:master
》 git push origin hotfix-<..>:dev

21. Git tag
》 When,
× Release a build from master branch
》 Format: v<version>
》 Command
× git tag –a <tag_name>
× Use gitlab to tag. (easier)
》 Integrated in CI is recommended.

22. OTHERS

23. Purposes behind
》 Private personal branch
× Daily push to remote (HD broken)
× Lazy to switch branch (:P)
》 Tagging
× Tag release version on master branch for
easier trace back and troubleshooting.
》 Why 1.0, 2.0 branch?
× For module development

24. Misc - Tips
》 Rebase  Merge
》 No-fast-forward for feature branch
commit to dev branch.
》 For bug fixes
× Use interactive rebase to squash commits
into one.
× Easier to
› code view
› Traceback/troubleshooting

25. Misc – Troubleshooting
Check local/Remote branch
》 git branch –a
Remote repository status
》 git remote show origin

26. RPM repo
》 dev branch build to dev-repo
》 1.0/2.0… branch build to int-repo
》 QA promote a rpm from int-repo to stg-repo
》 OPS promote a rpm from stg-repo to prod-
repo

27. Versioning
》 dev branch and master branch should
use different version.
》 Since they put into different rpm repos,
it’s not required to use different formats.

28. References
》 http://nvie.com/posts/a-successful-git-
branching-model/
》 http://www.slideshare.net/lemiorhan/git-
branching-model

29. Q & A