git branching model
DESCRIPTION
A successful branching model using GitTRANSCRIPT
--stupid-content-tracker
Branching Model
Harun YardımcıSoftware Architect @ ebay Turkeyhttp://www.linkedin.com/in/harunyardimci/5th Feb 2013
$ GIT init --bare --shared doc/branching-model.gitInitialized empty shared Git repository in /doc/branching-model.git/
$ GIT clone doc/branching-model.gitCloning into 'branching-model'...Done.
$ GIT checkout masterSwitched to branch 'master'
--stupid-content-tracker
Why GIT?
- Easy to learn
- Fast and small
- Distributed
- Convenient staging areas
- Cheap and multiple local branching
- Multiple workflows
- Data Assurance
- Huge community
These are not enough to love it? - It is free and open source..
--stupid-content-tracker
Branch!! What is it?
Separate line of work.. Branch is a simply a movable pointer to a commit.
}A commit data
one blob for the contents of each of your three files
one tree that lists the contents of the directory and specifies which file names are stored as which blobs,
one commit with the pointer to that root tree
all the commit metadata
{Multiple commits
the next commit stores a pointer to the commit that came immediately before it
--stupid-content-tracker
More About Branches
Default branch is master
Easy to create a branch
For more about branching http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging
} Create and switchto the branch
$ git checkout -b mybranchSwitched to a new branch "mybranch"
or$ git branch mybranch$ git checkout mybranchSwitched to a new branch “mybranch”
--stupid-content-tracker
Main Branches
Master Branch(origin/master)
to be the main branch where the source code of HEAD always reflects a state with the latest delivered development changes for the next release
Release Branches(origin/release-*)
HEAD always reflects a production ready state. Also called Release Candidate (RC) or staging branch.
Production Branch(origin/production)
HEAD always reflects a state with the current release on the production. “Never and ever make any changes on this branch.”
--stupid-content-tracker
Supporting Branches
Feature Branches(origin/feature/*, origin/fix/*, origin/fun/*)
used to develop new features for the upcoming release or a distant future release
Hotfix Branches(origin/hotfix/*)
arise from the necessity to act immediately upon an undesired state of a live production version
Each of these branches have a specific purpose and are bound to strict rules as to which branches may be their originating branch and which branches must be their merge targets.
--stupid-content-tracker
Feature BranchesTime
Master
Feature 1
Feature 2
Create
branch
from
the m
aster
Merge in
to to
the m
aster
Pull changes
from th
e maste
r
--stupid-content-tracker
Release BranchesTime
Master
Feature 1
Feature 2
Create
branch
from
the m
aster
Merge in
to to
the m
aster
Pull changes
from th
e maste
r
Release-0.1.2
Release-0.1.3
--stupid-content-tracker
Production BranchTime
Master
Feature 1
Feature 2
Create
branch
from
the m
aster
Merge in
to to
the m
aster
Pull changes
from th
e maste
r
Release-0.1.2
Release-0.1.3
ProductionDeploy and tag
Delete afte
r the
merge
Delete afte
r the
merge
--stupid-content-tracker
Hotfix BranchesTime
Master
Feature 1
Feature 2
Create
branch
from
the m
aster
Merge in
to to
the m
aster
Pull changes
from th
e maste
r
Release-0.1.2
Release-0.1.3
Production
Deploy and tag
Hot Fix
Deploy and tag Deploy and tagDeploy and tag
Delete afte
r the
merge
Delete afte
r the
merge
--stupid-content-tracker
Naming Conventions
Master Branch: - Name is master
Release Branches: - All branch names start with “release-” followed by a release number
$ git checkout master -b release-0.1.2
Production Branch: - Name is production
$ git checkout production$ git merge --no-ff release-0.1.2$ git tag -a v.0.1.2
Hotfix Branches: - Hotfix branch name standart is as follows “hotfix/[JIRA-NUMBER]”
$ git checkout master -b hotfix/GG-13544
--stupid-content-tracker
Naming Conventions
Feature Branches: - have couple of standards depends on issue types
If your Jira issue type is one of the followings then start the branch name with “fix/”
- Bug, Defect, Fix
If your issue type is one of the followings then start your branch name with “feature/”
- Improvement, Feature, Task
If the issue type is none of them or it is an experimental branch, name it with the “fun/” prefix unless it is just a local branch which you never push to remote.
--stupid-content-tracker
Wait a Minute!
Everything if clear and perfect up to now. But I don't have a production branch in my repository. What should I do?
Following will create remote branch in the repository$ git checkout master -b production$ git push origin production
If someone else already created that you just track the branch$ git checkout --track origin/production or$ git checkout -b production origin/production
--stupid-content-tracker
The Circle
--stupid-content-tracker
Commit Messages
Commit messages has to include Jira issue number as a prefix
$ git commit -m “GG-1307 new banner added to left bar of homepage” -a
“Write Meaningful Commit Messages.” - Albert Einstein. He would say that if he were alive today.
{Why we write issue number in the commit messages?
--stupid-content-tracker
Thanks
That's all about branching model.
Any Questions?