wrs git branching model - draft
DESCRIPTION
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 policiesTRANSCRIPT
By Walter Liu
WRS GIT branching model (draft)
Agenda》 GIT Branches》 How to work》 Others
× Purpose behind× Misc – Tips× Misc – Troubleshooting× RPM repo× Versioning
GIT BRACHES
Overview
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
Dev branch (1/2)
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
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
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
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.
HOW TO WORK
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.
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
New ProjectSet default branch
New ProjectSet projected branch
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>
Update source from dev branch to private branch
》 git checkout <private_branch>》 git pull》git merge dev》git pushOR》 git pull origin dev
<private_branch>
Promote source from private branch to dev
branch》 git checkout dev》 git pull》git merge <private_branch>》git pushOR》 git push origin
<private_branch>:dev
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
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
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.
OTHERS
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
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
Misc – TroubleshootingCheck local/Remote branch》 git branch –aRemote repository status》 git remote show origin
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
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.
References》 http://nvie.com/posts/a-successful-
git-branching-model/
》 http://www.slideshare.net/lemiorhan/git-branching-model
Q & A