WRS GIT Branching Model － draft
•Download as PPTX, PDF•
1 like•810 views
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
Recommended
More Related Content
Similar to WRS GIT Branching Model － draft
Similar to WRS GIT Branching Model － draft (20)
More from Walter Liu
More from Walter Liu (18)
Recently uploaded
Recently uploaded (20)
WRS GIT Branching Model － draft
- 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
- 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.
- 29. Q & A
Editor's Notes
- dev -> dev build Master -> int build E2E test (int build) [move int build to] staging build Or dev -> dev build Master -> staging build (E2E test, this more like staging-candidate. Need tagging)
- In a big project, dev branch needs to be more conservative: feature that need many people work with.
- git update-ref: Change default branch after clone a repo.
- Lazy to switch branch Most of time, we’re working on one thing only. Versioning Add git commit [X] Sep
- For troubleshooting
- Different version means they should not be continuous versions.