Git Flow

Issue Management and Branching

Default Jira View

Where's the backlog?

You Start a Project

  • You have a series of tickets
  • Developer A begins work on ticket ENG-1
  • Developer B begins work on ticket ENG-2
  • Developer C begins work on ticket ENG-3
  • ENG-3 depends on ENG-1

The Branches

$> git checkout -b ENG-1 master

$> git checkout -b ENG-2 master

$> git checkout -b ENG-3 master

(ENG-3)
$> git merge developerC/ENG-1

The Problem(s)

  • What branch do you merge back into?
  • Who is responsible for the merge?
  • Who is responsible for handling conflicts?
  • How do you protect a release?

Our Goals

  • Protect a releasable product 
  • Develop efficiently
  • Maintain our sanity

Jira Kanban Board

Organization

  • Product Requirements become Features
  • The team (or specific members) define tasks
  • Features are prioritized
  • Features have owners
  • Tasks are executed in parallel

Benefits

  • Required work is understood
  • Co-dependent work is understood
  • A timeline may be established

Integrating Git Flow

  • A "develop" branch is created
  • Feature branches are branched from develop
  • The feature owner is responsible for that branch
  • Subtasks of features are branched from the feature

This is what we care about right now.

Demo Time!

Releasing with Git Flow

  • A Release branch is created
  • The branch is based off develop
  • Critical changes are made
  • The release is "finished"
  • a.k.a Tagged and merged to master and develop

This is what we care about right now.

Demo Time!

Benefits

  • A branch (layer) specific for hotfixes
  • A branch (layer) specific for features
  • A snapshot of the release

Jira Releases

Versions in Jira

Final Thoughts

  • Git flow is a method, not a piece of software
  • Jira and Stash work well with git flow
  • Code can be organized in a way that everyone can understand

Links

Questions?

Made with Slides.com