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
