This document discusses Git branching models and conventions. It introduces common branches like master, release, production and hotfix branches. It explains how to create and switch branches. Feature branches are used for new development and hotfix branches are for urgent fixes. Commit messages should include the related Jira issue number. The branching model aims to separate development, release and production stages through distinct branches with clear naming conventions.

1. Branching Model --stupid-content-tracker
$ GIT init --bare --shared doc/branching-model.git
Initialized empty shared Git repository in /doc/branching-model.git/
$ GIT clone doc/branching-model.git
Cloning into 'branching-model'...
Done.
$ GIT checkout master
Switched to branch 'master'
Harun Yardımcı
Software Architect @ ebay Turkey
http://www.linkedin.com/in/harunyardimci/
5th Feb 2013

2. Why GIT? --stupid-content-tracker
- 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..

3. Branch!! What is it? --stupid-content-tracker
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
{

4. More About Branches --stupid-content-tracker
Default branch is master
Easy to create a branch
}
$ git checkout -b mybranch
Switched to a new branch "mybranch"
or Create and switch
$ git branch mybranch to the branch
$ git checkout mybranch
Switched to a new branch “mybranch”
For more about branching http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging

5. Main Branches --stupid-content-tracker
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.”

6. Supporting Branches --stupid-content-tracker
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.

7. Feature Branches --stupid-content-tracker
Time
ch er to
an st to
in er
br ma
te e g e st
ea th er a
Cr om M em
Feature 1 fr th
s er
ge st
an m a
h e
ll c th
Feature 2 Pu om
fr
Master

8. Release Branches --stupid-content-tracker
Time
ch er to
an st to
in er
br ma
te e g e st
ea th er a
Cr om M em
Feature 1 fr th
s er
ge st
an m a
h e
ll c th
Feature 2 Pu om
fr
Master
Release-0.1.2
Release-0.1.3

9. Production Branch --stupid-content-tracker
Time
ch er to
an st to
in er
br ma
te e g e st
ea th er a
Cr om M em
Feature 1 fr th
s er
ge st
an m a
h e
ll c th
Feature 2 Pu om
fr
Master
e
r th
te
af
te
le e
De erg
Release-0.1.2 m
rt
he
te
af
te
le e
De erg
Release-0.1.3 m
Production
Deploy and tag

10. Hotfix Branches --stupid-content-tracker
Time
ch er to
an st to
in er
br ma
te e g e st
ea th er a
Cr om M em
Feature 1 fr th
s er
ge st
an m a
h e
ll c th
Feature 2 Pu om
fr
Master
e
r th
te
af
te
le e
De erg
Release-0.1.2 m
rt
he
te
af
te
le e
De erg
Release-0.1.3 m
Hot Fix
Production
Deploy and tag Deploy and tag Deploy and tag Deploy and tag

11. Naming Conventions --stupid-content-tracker
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

12. Naming Conventions --stupid-content-tracker
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.

13. Wait a Minute! --stupid-content-tracker
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

14. The Circle --stupid-content-tracker

15. Commit Messages --stupid-content-tracker
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
Why we write issue
number in the commit
messages?
{
“Write Meaningful Commit Messages.”
- Albert Einstein. He would say that if he were alive today.

16. Thanks --stupid-content-tracker
That's all about branching model.
Any Questions?