On 07/10/12 19:40, Earnie Boyd wrote:
> After Chuck's response I decided to go looking for other ideas. I
> found what I think will work and take care of Chuck's concerns at
Interesting read. A couple of comments:
* It advocates deleting branches, (even release branches), at certain
points in the work-flow. I completely agree with Chuck on this one;
this has to be a big no-no, for any branch which has ever been shared.
(FWIW, Mercurial branches are permanent; once created and committed,
they can *never* be deleted, other than by deletion of the repository.
OTOH, Mercurial also provides a bookmark feature, which is somewhat
similar to git branches, or CVS branch tags; these *can* be deleted).
* As it's written up, the model doesn't readily support any more that
one actively distributed release at any instance in time. Making each
release branch permanent would resolve that issue; it would also make
his use of "master", (as an exclusive progression of release points),
redundant, (since the tip of each release branch would represent its
associated release point). Thus, why not just use "master", as seems
more conventional, as the main development branch, and cut a permanent
release branch at each release point?
> Based on that write up I've created a develop branch from which all
> other branches are to be created. A release branch will be created
> for finalizing the release changes; things like updating the news,
> updating the version number, etc. Just prior to the release the
> release branch is merged to the develop branch and then the develop
> branch is merged to the master branch.
That's not what the article advocates. It says merge the "release"
branch to "master", and to "develop". I guess it should make little
difference either way, but if you do away with the redundant use of
"master", (or rather, use "master" as your main development branch), and
keep each release branch permanently, then you can simplify the
work-flow to a single merge from the "release" branch to the "master"
(development) branch, at each release point.
> A feature branch is usually a local branch but could be a public
> branch if more than one person is working the feature or the work
> plans to span a length of time. The feature branch is created
> directly from the develop branch and merged back to the develop
No issues there; this is effectively what my "gui-dev" branch in
mingw-get represents. The only caveat I wish to note: since it's
a published branch -- it exists in origin -- it should remain in
> A hotfix branch is done as an immediate release to fix a regression
> caused by a release. The hotfix branch could be created from the
> develop branch or the master branch
Hmm. Logically, a "hotfix" branch should be created from the release
branch to which it relates...
> but must always be merged to the develop branch and the develop
> branch to the master.
...and it should be merged back to the tip of that release branch, when
done. The tip of the release branch *could* then be merged back to the
development branch, if the issue which the "hotfix" addresses continues
to affect the current state of development.
> The feature branches would need to rebase after a release and hotfix
> are merged to the develop branch.
I find the whole concept of rebasing to be rather scary; if you do it on
a published branch, you're sure to cause grief for someone down the line.
> This brings us to ChangeLog entries...
See my comment in the "mingw.org-wsl .gitignore" thread.