Hello, I am trying to build a git workflow in our enterprise and am almost evenly torn between a "rebase workflow" and git-flow (which uses merge instead of rebase, obviously). We are using Bitbucket for pull requests as code reviews (right or wrong). I apologize if my inexperience with git shows through, but I'm wanting to achieve the following -- Maintain two long-running branches (develop as a stable pre-release, master as a deployed version), with short-term feature branches off of develop and short-term release branches that are based on develop and merge into master eventually (ie. a lightweight git-flow). However, as part of this, I would prefer to require/ensure that each feature branch is up-to-date and otherwise able to be fast-forwarded; we currently have this with the bitbucket server setting requiring --ff-only. The other half of what I would prefer is to still perform the merge commit, though, to ensure separate tracking of the feature branches (ie. --no-ff). I know that I have read that --ff-only and --no-ff are contradictory, but I believe that is somewhat ambiguously correct -- I believe the two flags contradict in the sense of "what to do with the merge commit", but not necessarily on the "when it can be done". I read an ancient post about on this list (which predates the tri-state of fast-forward) that I believe could have allowed this to work. I have also read a few articles and posts that achieve this more as a matter of practice than a workflow enforcement via git flags; for this to be something to potentially get absorbed into a Bitbucket workflow, I suspect it would need to a git flag (they now support merging via --ff, --no-ff, --ff-only, --squash, and --squash-ff-only for their hosted solution, for example). Here are a few articles that say they prefer this approach (rebase and then merge --no-ff): https://walkingthestack.blogspot.com/2012/05/why-you-should-use-git-merge-no-ff-when.html http://blog.differential.com/best-way-to-merge-a-github-pull-request/ http://victorlin.me/tags/rebase Can anyone share their thoughts on workflows that might achieve what I'm looking at here or opinions on adding the functionality I'm describing? Thanks! -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html