Your SlideShare is downloading. ×
0
WRS GIT Branching Model - draft
WRS GIT Branching Model - draft
WRS GIT Branching Model - draft
WRS GIT Branching Model - draft
WRS GIT Branching Model - draft
WRS GIT Branching Model - draft
WRS GIT Branching Model - draft
WRS GIT Branching Model - draft
WRS GIT Branching Model - draft
WRS GIT Branching Model - draft
WRS GIT Branching Model - draft
WRS GIT Branching Model - draft
WRS GIT Branching Model - draft
WRS GIT Branching Model - draft
WRS GIT Branching Model - draft
WRS GIT Branching Model - draft
WRS GIT Branching Model - draft
WRS GIT Branching Model - draft
WRS GIT Branching Model - draft
WRS GIT Branching Model - draft
WRS GIT Branching Model - draft
WRS GIT Branching Model - draft
WRS GIT Branching Model - draft
WRS GIT Branching Model - draft
WRS GIT Branching Model - draft
WRS GIT Branching Model - draft
WRS GIT Branching Model - draft
WRS GIT Branching Model - draft
WRS GIT Branching Model - draft
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

WRS GIT Branching Model - draft

207

Published on

Since our team is using GIT heavily and members use GIT differently, it will be good if we draft, …

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
207
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
1
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
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.
  • Transcript

    • 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

    ×