Phew, so much text. :-)
On Sun, Apr 17, 2011 at 01:29:27PM +0100, Thomas Adam wrote:
> Workflow Ideas
> ==============
I've had very good experiences with this setup:
* There is a central fvwm release repository somewhere, maybe on
fvwm.org.
* The release repo has the branches release and devel plus any
additional number of topic branches. It may be a good idea to
prefix such branches with your initial, e.g. dv-menu-rewrite.
* The release branch is *never* rewound, rebased or merged with
any other branch. The *only* way to get anything committed to
the release branch is to apply patch sets (git-format-patch,
git-am, git-cherry-pcik etc.). Rationale: In the official
release branch the commit history must not be changed. Also, it
can become very difficult to maintain when long term branches
are merged into the master - this is something you usually want
to avoid. It is absolutely forbidden to publish changes to the
release branch with the force option of git-pull or git-push!
* On the devel branch, patches are collected prior to publishing
on the release branch. History of the devel branch may be
changed at any time to correct mistakes. Development must not
take place solely on the devel branch because it may be lost by
accidental parallel work of multiple developers. Usually this
should not be a problem in fvwm development. If need be, any
developer can make a short lived own devel branch e.g. dv-devel
or ta-devel. However, such problems should rather be solved by
communicating than by creating random branches. In the past
they happened very rarely with CVS.
The devel branch can be used to show all new features to the
public or other developers for testing.
When the devel branch is ready to go to the release branch, the
latter is rebased to the devel branch:
1. Make sure that the release branch is an ancestor of the
devel branch.
2. Check out the devel branch and set a temporary tag.
$ git checkout devel
$ git tag foo
3. Check out the release branch
$ git checkout release
4. Rebase the release branch to the devel branch
$ git rebase devel
If the devel branch is based on the release branch, this works
out of the box.
* The topic branches should usually belong to only one developer.
The owner of a topic branch is responsible for keeping it in
sync with the devel or release branch. The final result of a
topic branch is a well structured patch set that applies to the
release branch out of the box (with git-am or git-cherry-pick).
When a topic branch has been released or finally rejected, it
should be deleted from the release repository. If it has been
rejected, author may want to keep a local copy of such branches.
Note that by deleting a branch, its history is lost irrevocably
after a grace period (usually one month).
> I personally don't mind 1., above, if the number of branches are small, and
> well-maintained. Because at some point, once a given feature is developed,
> and tested in isolation on that branch, it will get merged to another
> branch. Let's call it "next". The branch "next" is always rewound off the
> HEAD of master at each release, and will form a "here's what I'm planning to
> merge to master for release" branch. It might look like this:
>
> o--o--o--o--o--o--o--o--o--o--o--o--o--o--o (master)
> \ \
> \ o--o--o--o--o--o--o (next)
> o--o--o--o--o-------------------------/ (ta/titleformat merged)
This is a situation to be avoided, if possible. Merge operations
are dangerous and hard to track. It is worthwhile to stick to the
CVS practive: In CVS before you can publish your work, you have
to update your working tree ("cvs up") and fix the merge
conflicts. Only a working tree that is up to date can be
published. The same can be done with git, although it's not
enforced, by using git-cherry-pick or git-am rather than
git-merge.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
