And yes, I assumed that people would
be using topic/feature branches for any significant work they want to backup
or share with specific people but not contribute to builds. I was mainly
focused in my note on the branches involved in our builds. But thanks for
emphasizing the point that branches aren't to be feared and can be used
liberally with Git.
Aaron Digulla <digulla@xxxxxxxx> Sent by: eclipse-dev-bounces@xxxxxxxxxxx
10/12/2011 04:48 PM
Please respond to
"General development mailing list of the Eclipse project."
Re: [eclipse-dev] Platform/JDT/PDE Committers
Please Read: Git development process
Am 12.10.2011 20:18, schrieb John Arthorne:
> [...]git-flow . 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
> their appropriate checks and tests (similar to our current weekly
> and release process)
> - Integration builds automatically tag and build the contents of "master"
It's for Mercurial but at least the first two overview chapters are
generic. I've found the "Subversion re-education" especially
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
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
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." http://blog.pdark.de/
eclipse-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit https://dev.eclipse.org/mailman/listinfo/eclipse-dev