Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse-dev] Platform/JDT/PDE Committers Please Read: Git development process

Am 12.10.2011 20:18, schrieb John Arthorne:
> [...]git-flow [1]. I think a simplified form
> of git-flow would match our current development practices:
> - Two main branches called "develop" and "master"
> - All major feature work is first released to "develop"
> - Each team periodically merges "develop" into master after performing
> their appropriate checks and tests (similar to our current weekly tag
> and release process)
> - Integration builds automatically tag and build the contents of "master"

You may also want to read the introduction on

It's for Mercurial but at least the first two overview chapters are
generic. I've found the "Subversion re-education" especially useful
because distributed VCS solves many of the pains of the old, centralized

The hardest thing to forget is that merging is a pain. With DVCSs,
merging is so simple, you start to forget about it. To drive this point
home: Linux Torvalds merges *several thousand times every month*.

It took my current team some time to learn to trust the new tools. One
thing which we started recently are "feature branches". As John told
above, there is one master branch (or rather one master branch per
release) but each feature gets it's own branch.

The main advantage is that everyone can work pretty isolated from
everyone else for as long as they want/need/have to. They can merge from
the master branch from time to time (or not) to get the latest stable
features from other people.

This approach allows to work on features that take more than one major
development cycle to "ripe": You start a feature branch, the DVCS helps
you to keep it roughly in sync with the normal release train but you can
work for a year or longer on something complex without wasting your time
or blocking other people.

It also allows to risk something: Create a new branch, try something
out. If it doesn't work out, just let the branch starve. Or maybe you
get a new idea for a better approach - then you can resurrect the branch.

This kind of development would have been impossible with the old tools:
Branching would take too much time or pollute your repository or it
would block someone else or merging would be a pain.

With DVCS, branching is a constant time operation. It pollutes only your
local copy of the repo, it never gets in the way of anyone else and
merging usually happens without any manual intervention. Not to forget
that you have to commit your current work *before* you merge with
another branch - something that's impossible with Subversion and CVS.


Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."

Back to the top