WRS GIT Branching Model - draft

515 views
354 views

Published on

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

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
515
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
3
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • 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.
  • WRS GIT Branching Model - draft

    1. 1. By Walter Liu WRS GIT branching model (draft)
    2. 2. Agenda 》 GIT Branches 》 How to work 》 Others × Purpose behind × Misc – Tips × Misc – Troubleshooting × RPM repo × Versioning
    3. 3. GIT BRACHES
    4. 4. Overview
    5. 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. 6. Dev branch (1/2)
    7. 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. 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. 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. 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. 11. HOW TO WORK
    12. 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. 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. 14. New Project Set default branch
    15. 15. New Project Set projected branch
    16. 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. 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. 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. 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. 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. 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. 22. OTHERS
    23. 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. 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. 25. Misc – Troubleshooting Check local/Remote branch 》 git branch –a Remote repository status 》 git remote show origin
    26. 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. 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. 28. References 》 http://nvie.com/posts/a-successful-git- branching-model/ 》 http://www.slideshare.net/lemiorhan/git- branching-model
    29. 29. Q & A

    ×