--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?