Notes #4 – Git vs SVN, git-flow

A comparison between Git and SVN. Git’s major features:

  • Git was designed to be fully distributed from the start, allowing each developer to have full local control
  • Git branches are simpler and less resource heavy than Subversion’s
  • Git branches carry their entire history
  • Branch merging is simpler and more automatic in Git.
  • Git is extremely fast. Since all operations (except for push and fetch) are local there is no network latency involved

git-flow – a successful git branching model

The main branches:

  • master – the main branch where the source code always reflects a production-ready state.
  • develop – the main branch where the source code always reflects the latest delivered development changes. The « integration branch » where any automatic nightly builds are build from.

Other branches, with a limited life time,  with a specific purpose, to aid parallel development:

  • feature  – it branches off from develop and it must merged back into develop. It exists as long as the feature is in development
  • release – it branches off from develop  and it must merged back int develop and master. Branch name convention: release-*. Use it for minor bug fixes and preparing meta-data for a release
  • hotfix – it branches off from master and must be merged back into develop and master. Branch naming convention: hotfix -*. Use it when you need to act immediately upon an undesired state of a live production version, when a critical bug in a production version must be resolved immediately.

Automate git branching workflow – use  git-flow library of git subcommands that helps automate some parts of the flow to make working with it a lot easier.

Issues with git-flow – The git-flow process is designed largely around the « release » but when you need to deploy regularly (every day), like GitHub does, a much simpler workflow is required.