[eclipse-dev] Platform/JDT/PDE Committers Please Read: Git development p

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

Now that we are becoming more familiar
with Git, we should have a discussion about our team development processes
and consider changes that are more suitable to our new tools. In particular,
our existing release process of tagging and map files were designed for
the CVS world where moving code between branches was painful. This process
is not adapting well to Git. For example, you can't reliably checkout a
branch or tag that matches what was in a given build, and there is no clear
way to apply release tags such as "R3_7_1" because no single
commit is guaranteed to represent the built contents of all bundles in
that repository.

If you think about it, our map files
effectively superimposed another branch on HEAD, with the precise contents
of that branch defined by the map tags for each project. This allowed us
to do things like proceed with new work in HEAD without disrupting rebuilds,
or revert a change by altering the map file (because backing out changes
that span multiple files in CVS is painful). With Git, the more natural
_expression_ of this setup is to have two branches: one for integration builds
and one for ongoing work that we want to test and share with other teams
but not submit to a build. It turns out that there is a popular Git development
process similar to this, called 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"

With this approach each tag on master
represents a build. This makes it easy for anyone to checkout the contents
of any particular build even if it spans multiple Git repositories. This
also allows you to revert a build submission or make a surgical fix for
a rebuild without disrupting the ongoing work in the develop branch. We
could also adopt other aspects of git-flow such as release branches for
our end-game period, although I'm not convinced we need it.

After that long-winded explanation,
my request is that all teams think about their development practices and
how they can be adjusted or improved in our new Git setup. Read up on git-flow
and think about how it applies to our development process. If you're interested
you might also want to look at other processes such as github-flow [2]
for an alternate viewpoint. Talk about it within your team, and we'll aim
to have a general discussion about it at next week's planning call (Wednesday
October 19th, 11am EDT). If you don't normally join that call, send feedback
to your team lead, or you're welcome to join next week's call to chime
in. I don't think we'll arrive at a perfect development process overnight,
but we can start to make changes and refine it as we go forward.

[1] http://nvie.com/posts/a-successful-git-branching-model/
[2] scottchacon.com/2011/08/31/github-flow.html

John