The Three Branches Strategy

Introduction

This document contains a summarized propostion regarding my view around the Carpago Software developing strategy. I was asked to create a document which helps Carpago Software to get more structure in the using of their development strategy.

Setting up

I will use a scenario which happens everyday to explain the flow.

Jim has to get working for Carpago Software. He graps his laptop and installs Git.

Clone

He than clones all the content of the Origin machine which is located now at GitHub using the command

$ git clone http://<link to github/

He than receives a clone of develop and master from the Github repo. He than checks out the develop branch using

$ git checkout develop

Start hacking

Jim starts working and commits his changes to his LOCAL develop tree with

$ git add .
$ git commit -a -m "Some progress for the world shaking life management platform regarding Contacts changed to View companies and Persons"

Stop hacking

Jim runs his local unittest which of course succeed and he decides to push his work to Github with

$ git push origin develop

Starting the develop build

Github receives his commits at develop and our Jenkins machine immediately starts building.

When the build succeeds Jenkins deploys the OO application to the TESTSTAND machine.

Releasing

After a while the CEO (Roel) decides it is time to release the very first version.

The integrator (Henri) will merge the develop tree to master. Will tag the master with "v1.0.0" Jenkins (yes, the same Jenkins) sees a change on the master machine and starts building the master branch version. When the build succeeds Jenkins deploys the OO application to the DEMOSTAND machine.

The process restarts / continues for developers to commit on the develop branch.

After a while the CEO (Roel) decides it is time to release the second version.

The integrator (Henri) will merge the develop tree to master. Will tag the master with "v1.1.0" Jenkins (yes, the same Jenkins) sees a change on the master machine and starts building the master branch version. When the build succeeds Jenkins deploys the OO application to the DEMOSTAND machine.

The process restarts / continues for developers to commit on the develop branch.

Summary

In this case we always have a stable DEMO machine for Roel to show his stock- and stakeholders. And we always have immediate feedback from the most recent developing changes.

Optional

You might install Git flow
$ sudo apt-get install git-flow (e.g.)

Optional - Some useful commands when working (for developers)

When in the local repo
$ git flow feature start <featurebranchname>

When done

$ git add .
$ git commit -a  -m "Done for now"
$ git diff develop..HEAD #to review your work
$ #more optional stuff see below
$ git checkout develop
$ git pull origin develop
$ git checkout featurebranch
$ git rebase develop  // rolls your commits on the start of your project
$ git flow feature finish <samefeature name>
$ git push origin develop

More optional stuff

When done your work you might have too many or naste commit descriptions
$ git reset develop // to reset head to develop to make one large commit (this step is optional but a nice feature)
$ git add .
$ git commit -a -m "Summarize your work"
$ git commit --amend  // enter -> and change your description.

Rule of thumb is one line for the coarse commit description. Than one blank line. Then some more indented lines for more detailed comment regarding the first line of your wonderful commit.

References

Some useful references

Image says more than 10 words

This is more for the right brained people

branchingoo

Happy coding!

Raymond Loman

raymond@carpago.nl