1. Main Approach

Taken from a discussion on mihini-dev mailing list, kudos to ffleutot.

There are 3 families of Git workflows: merge, rebase, and pull requests.

Merge workflows show branching and merging in the public repository. They represent the way we develop more truthfully, but they tend to turn into an unreadable spaghetti mess.

In rebase workflows, before committing a set of changes, we graft them onto the top of the master branch *at commit time*, rather than when the feature's development started. It forces to rewrite history, but rewritten history is more readable.

Finally, pull requests is the Linux way: there's only one integrator per authoritative repo, he pulls changes from development repos when he receives pull requests. To me, it seems both over-engineered for a project of our size, and at odds with Eclipse's habits of trusting several committers on a project.

Our Choice:
We want our Git history to be welcoming to other people, i.e. readable. The normal workflow should be the rebase one, and each commit should make sense by itself functionally (fixing one bug, providing one feature). In exceptional cases, where long developments went on in parallel for a long time, it makes sense to show the parallelism through a merge, but this should be the exception, not the rule.

2. Concrete Examples

# create and switch to a new branch to develop a new feature, fix a bug etc> git checkout -b newfeature
# do your dev in the new branch
...
# fetch the changes which occurred on master> git fetch origin
# graft our commits on top of updated master state:# first, in branch newfeature, import the new commits from master (our commits will be applied on top of it)> git rebase master
# switch back to master> git checkout master;
# get our new commits from newfeature branch in master branch> git merge newfeature
# send the new commits to the repo> git push