I agree that for only one commit on the feature branch, merging it with --no-ff is a little excessive, but it does help if the name of the branch is valuable in the merge commit. I don't think there's any problem with rebasing the feature branch on develop before merging to keep the history cleaner. When there is more than one commit, then I think this comment from the same section is important:
"In the latter case, it is impossible to see from the Git history which of the commit objects together have implemented a feature—you would have to manually read all the log messages. Reverting a whole feature (i.e. a group of commits), is a true headache in the latter situation, whereas it is easily done if the --no-ff flag was used." Here's another good doc on the same Gitflow workflow: http://www.atlassian.com/git/workflows#!workflow-gitflow --Dasa On Mar 18, 2013, at 3:06 PM, Frédéric THOMAS <webdoubl...@hotmail.com> wrote: >> 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 > > > >
