The nvie.com<http://nvie.com> git flow actually advocates not squashing
your feature branches when you merge them to develop. From the section
entitled, "Incorporating a finished feature on develop".
The --no-ff flag causes the merge to always create a new commit object,
even if the merge could be performed with a fast-forward. This avoids
losing information about the historical existence of a feature branch and
groups together all commits that together added the feature.
Interesting model, after having collaborated on git projects, I don't use
the --no-ff flag as it quickly messes an history, especialy for bugfixes,
I'm more flexible regarding the no fast forward on important branch/features
done by a team, rarely by an individual, otherwise it makes the history
graph unreadable, I even heard "oh, nice, that's looks like to have been
done by geeks", personaly, I find that unredable and useless, rebasing is a
good pratice, it let you get a chance to clean your commits before merging,
making the history more readable.
Also, I think feature branches can be shared to the origin to allow for
collaboration, but they should eventually be deleted once they're merged
or abandoned.
Totaly agreed with that.
Feature branches typically exist in developer repos only, not in origin.
Except if it needs collaboration indeed.
Anyway, at the end, each one will do with it's own experience, collaborating
on a feature is the best way to learn Git but we do more bugfixes.
Thanks for having shared that,
-Fred
-----Message d'origine-----
From: Dasa Paddock
Sent: Monday, March 18, 2013 10:02 PM
To: <dev@flex.apache.org>
Subject: Re: nvie branch model
The nvie.com<http://nvie.com> git flow actually advocates not squashing your
feature branches when you merge them to develop. From the section entitled,
"Incorporating a finished feature on develop".
The --no-ff flag causes the merge to always create a new commit object, even
if the merge could be performed with a fast-forward. This avoids losing
information about the historical existence of a feature branch and groups
together all commits that together added the feature.
Also, I think feature branches can be shared to the origin to allow for
collaboration, but they should eventually be deleted once they're merged or
abandoned. This is from the section introducing feature branches:
The essence of a feature branch is that it exists as long as the feature is
in development, but will eventually be merged back into develop (to
definitely add the new feature to the upcoming release) or discarded (in
case of a disappointing experiment).
Feature branches typically exist in developer repos only, not in origin.
--Dasa
On Mar 18, 2013, at 1:07 PM, Frédéric THOMAS
<webdoubl...@hotmail.com<mailto:webdoubl...@hotmail.com>> wrote:
From what I understand of this model, you don't even develop on the dev
branch but on feature/bugfix branches, this allow you to cleanup your
commits (rebasing/squashing them first, sorry for the bad words, see [1] in
case) before merging the complete feature/bugfix on the develop branch, the
release branch is for RC, once ok, the final release is tagged on the
master.
-Fred
[1] http://www.atlassian.com/git/tutorial/git-basics
-----Message d'origine----- From: Gordon Smith
Sent: Monday, March 18, 2013 8:54 PM
To: dev@flex.apache.org<mailto:dev@flex.apache.org>
Subject: nvie branch model
My understanding is that we've decided to follow
http://nvie.com/posts/a-successful-git-branching-model/
but the first diagram looks like spaghetti to me. There are relatively few
people working in the flex-falcon repo, and I'd like to understand what we
have to do to be minimally compliant with the nvie model. Is it sufficient
to simply create a 'develop' branch in addition to 'master' and then do
development there? Would we delay merging to 'master' until we reach a 1.0
release?
- Gordon
