An introduction to Git and GitFlow

(& how we use Git at Marie Curie)

Mark Everard / @ev2000Technical Lead

What is Git?• Git is a revision control system• Originally developed by Linus

Torvalds (Linux Emperor!)• It is a distributed version control

system• Very very widely used

42.9% May 2014, 36.3% May 2013Full stats from https://en.wikipedia.org/wiki/Git_(software)

Its like SVN right?It is and it isn’t

• It serves the same purposeIt does it in a very different way

• Has a steeper learning curve than SVN • Different terminology

• Have to unlearn some SVN ‘knowledge’

Key differences• You checkout / clone a complete

source control repository• You have the entire history of the

repository on your machine• Simplifies merging – everything in

Git is a branch

https://git.wiki.kernel.org/index.php/GitSvnComparsion

Common git terminology

ORIGINYour centralised repository (for us

this is GitHub – though in true DVCS there isn’t one)

HEADWhere your current repository points.. Most of the time this is

the latest revision in your branch

Common git commandsCommand line FTW

Git command

> git status Review what changes you’ve made

> git add <files> Stages files for a commit (allows you to choose what to add)

> git commit <files> Commit file to your HEAD source control

Common git commandsCommand line FTW

Git command

> git pull Pull down and merge commits from a remote repository

> git push <remote> Push commits to a remote repository

> git remote Lists all remotes that you have configured. You will generally have one (from GitHub)

Common git commandsSh*t I’ve made a mistake – how to undo

Git command> git reset HEAD~2

(moves your head back two revisions)

Undo changes that haven’t been shared with anyone else. Git will GC the dangling commits

> git checkout HEAD~2

(moves your head back two revisions)

Inspect what the state was 2 commits ago. Will detach head (meaning it doesn’t have a branch - BAD)

> git revert HEAD~2 Reverting undoes a commit by creating a new commit (exactly what you’d do manually)

Tooling• One area where SVN is more advanced

than Git• If you understand the basic commands

GUI’s will make more sense• Pick one as a team, you can then

support each other.

My favourite is SourceTree

Principles• If it’s not in source control, it

doesn’t exist• Commit early, commit often • Always inspect your changes

before committing• Remember the axe-murderer

when writing commit messages

Work flows• Git’s power actually comes from

how you use it• SVN has a simple and rigid workflow (trunk, tags, branches)

• Git offers many different type of workflows to suit different sized

teams and release strategies

Simple FlowGood for small development teams

and definite schedules Branch name Usage Rules

master Represents the current code base that is deployed to production servers

• Releases are taken from master• master should only be committed

too directly in the case of a hotfix• Any direct commits should be up-

merged to develop

develop Represents the work-in-progress of all changes that are being made on the project

• develop should be merged to master for a release

• release should not be made directly from develop

Git FlowFor complex multiple teams projects

allowing flexible releases (feature branching)

Git FlowFor complex multiple teams projects

allowing flexible releases

• Strict branching model• Feature branching

GitFlow

https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow

Branch name Usage Rules

master Represents the current code base that is deployed to production servers

• Releases are taken from master• master should only be committed too directly

in the case of a hotfix• Any direct commits should be up-merged to

develop

develop Represents the current release candidate

• develop should be merged to master for a release

• release should not be made directly from develop

feature branches Represent a single in-progress feature

• Must branch from develop• Must merge to develop• Regular up-merging from develop should take

place• Only merged to develop when QA is passed• Branches should be deleted when feature is

merged

release branches Represents a finalised release candidate

• Must branch from develop• Must merge to master and develop• Bug fixes found during the UAT / Regression

periods should be committed here• When the branch is ready to release, it should

be merged to master and develop.• After the above merges / deployment the

release branch should be deleted

hotfix branches Represents a fix for an urgent issue found in production

• Must branch from master• Must merge to master and develop• Branch should be deleted post merge• Never release from a hotfix branch

Branch namingThe following conventions apply. General rules are to be

descriptive and to allow the team to understand the feature.

• release branches should be named release/{release-name}

e.g. release/sprint-28 or release/picturewall-phase-1

• feature branches should be name feature/{name-JIRA-story/epic-number}

e.g. feature/blog-bcweb-594 or feature/picturegallery-dam-4

• hotfix branches should be named hotfix/{JIRA-bug-number}

e.g. hotfix/bcweb-3601 or hotfix/dam-90