Skip to content

Development workflow

Rafael Reggiani Manzo edited this page Feb 25, 2015 · 2 revisions

Here is assumed that you already know how git merges and rebases do work. If not, have a look at http://randyfay.com/content/rebase-workflow-git.

The workflow described here supposes that there multiple features being developed at the same time and has the objective to minimize the amount of conflicts and make the commits tree as understandable as possible (by turning it into a straight line).

Workflow

Lets suppose that you're developing a new functionality called decide_halt (http://en.wikipedia.org/wiki/Halting_problem).

  1. Make sure you have the latest code

    git fetch -p git checkout master git pull origin master

  2. Create branch for you to work

    git checkout -b decide_halt # this creates a branch and changes to it

  3. Do some work, add the produced code, commit it and push your branch and go home have some rest

    git add halt.rb git commit -m "Halfway to solve the problem!" git push -u origin decide_halt

  4. On the next day, before you continue, check if there is nothing new on master

    git fetch -p git checkout master git pull origin master

  5. Supposing there is new things, get them:

    git checkout decide_halt git pull origin decide_halt git rebase master git push -f origin decide_halt

  6. Repeat 4, 5 until you're done.

  7. When you get finished open a pull request and we are going to thank you a lot for any contribution!

Feel free to contact us about any doubts.

Hints that something went wrong

The biggest hint is that we always expect for fast-forward merges. If git outputs any message for you telling that a recursive merge or any other kind of merge was made, probably something went wrong.

Previous workflow

Previously all the job done on the branch master was done on a branch called dev. This has been changed in order to make things more intuitive to contributors.