Git Workflows

Noam Kfir | Sela Group | 2014

Workflows

Centralized

Feature Branch

Gitflow

Forking

Pull Requests

Adapted from Atlassian, experience and other sources

Centralized – Overview

Centralized by convention

One shared branch master

Central history is never rewritten!

Central repository is usually bare

Emulates a central VCS like TFS or Subversion

Local master tracks remote master

Local rebase often preferable to merge

Local repository is never bare

The Centralized Workflow

ma

ste

r

Centralized – Typical Sequence

git clone remote // copy the central repository to a local repository

// iterative edit/stage/commit process

git pull [--rebase] origin master // merge or rebase the latest central version

git push [origin master] // share your work with the central repository

Centralized – Ramifications

Suitable for small teams

Supports multiple atomic commits before sharing with the team

Risk losing local history if changes are not pushed often enough

Larger teams working on more concurrent features are more difficult to manage

Higher chance of merge conflicts

Harder to keep the central master history linear

Has limited support for communication

The Feature Branch Workflow

ma

ste

r

foo

ba

r

Feature Branch – Overview

Dedicated feature branches

Often combined with Centralized

Workflow

Feature branches are pushed to the

central repository

Devs never work on the master branch

Individual features built on dedicated

feature branches

Backup for feature branches too

Multiple devs work on the same feature

Feature Branch – Typical Sequence

git clone remote // copy the central repository to a local repository

git checkout -b new-feature // create a new local feature branch

// iterative edit/stage/commit process

git push [-u origin new-feature] // share the branch [and track it]

Feature Branch – Merge Into master

git checkout master

git pull [--rebase] origin new-feature // merge [or rebase] the latest central version

git push origin master // send the final version to the central master

Feature Branch – Ramifications

Suitable for larger teams working on multiple concurrent features

The central repository contains both master and feature branches

The master branch is easier to control and safeguard

Very flexible workflow but relies on responsible programmers

Supports:

pull requests

isolated experiments

efficient collaboration

The Gitflow Workflow

ima

ge

so

urc

e:

htt

ps:

//w

ww

.atla

ssia

n.c

om

/git

/wo

rkflo

ws#

!wo

rkflo

w-g

itflo

w

Gitflow – Overview

Focused on project release cycle

Similar to the Feature Branch Workflow

Uses a strict branching model

Uses a central repository

• Feature branches

• Individual branches

Each branch has a specific role

Strict rules on when branches can interact

Gitflow - Branches

master

hotfix

release

develop

feature

• official releases, tagged

• patches, bug fixes [ master]

• release targets [ master]

• feature integration branch [ release]

• dedicated feature branches [ develop]

Gitflow – The master Branch

The central authority

Sacred

Every commit represents a version

Every commit has a version tag

Branch from master: only hotfix and develop

Push to master: only hotfix and release

Gitflow – Hotfixes

Hotfixes are meant for critical maintenance issues only

Based on master, pushed to master

Usually numbered as a minor version

Sidestep the normal development workflow discouraged!

Numbered hotfix

branched from master

Merged back into

master

mastertagged with version tag

hotfixmerged

into develop

hotfixdeleted

Gitflow – Features

There is only one develop branch, based on master

Every feature has its own feature branch

feature branches based on develop, pushed to develop

feature branches named for the features

Named feature

branched from

develop

featureshared with

team

Concurrent local work on feature

featuremerged

back into develop

when ready

feature(optionally)

deleted

Gitflow – Releases

There is only one develop branch, based on master

Every release has its own release branch, based on develop

release named with version number (usually either major or minor)

release branches are merged into master and develop when releases are ready

Numbered release

branched from

develop

Bug fixes, docs,

preparation on release

releasemerged into

master when ready

to ship

master tagged with version tag

releasemerged

back into develop

releasedeleted

Gitflow – Ramifications

Intended for large projects

Feature teams can continue working while the current release is being prepared

Same advantages as Feature Branch Workflow:

pull requests

isolated experiments

efficient collaboration

Branch structure mirrors release process:

visually identifiable

easy to communicate

The Forking Workflow

ma

ste

r

foo

ba

r

ma

ste

r

foo

ma

ste

r

The Forking Workflow

A distributed workflow

Every dev forks the official repository

Official maintainer has ultimate control,

but only by agreement

Unrelated to the Centralized Workflow

Forks are private server copies

No shared centralized repositories

Central authority is arbitrary

and determined by policy or consensus

Forking – Branches

Multiple repositories:

“Official” public server repository

Forked server repositories

Cloned local repositories

Forking is different from cloning – forking creates a bare server copy, cloning creates a full local copy

Each developer has exclusive write access only to their own repositories

To integrate back into the official repository, developers push to theirs and then issue a pull request

Local clones of forked repositories usually define two remotes:

origin – points to the forked repository

upstream – points to the official public repository

Forking – Ramifications

Designed for large organic teams, including open source projects and distributed teams

Every dev can do their own private Feature Branch workflow with their own server

Official maintainer is very common in open source projects

Companies give write access to official repository/branch to responsible “maintainer”

Extremely effective with pull requests

Understanding Pull Requests

Safety net

Distributed communication mechanism

Effective code review platform

Not actually part of git!

When a feature is complete, it is not merged into master

The feature developer issues a pull request to the maintainer of the master branch

The maintainer reviews the changes and then merges them or rejects them

The pull request is a forum for discussion about the feature

Pull requests facilitate better communication and code reviews

The Pull Request Workflow

Feature is finished in

private branch

Dev issues pull request to source

repo

Maintainer reviews

changes

Maintainer and dev

discuss the feature

Maintainer merges or

rejects request

Summary

Git is a very rich distributed version control system

Its design supports many different types of workflows,including centralized and distributed workflowsand is suitable for:

individual programmers

small co-located teams

massive distributed teams

anything from open source projects to corporations

Its workflows have evolved over the years to popular, mature and proven guidelines

Thank You!