git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Fast-forward able commit, otherwise fail

From
DLDavid Lightle <dlightle@gmail.com>
Date
Jun 21, 2016, 03:58 UTC
Message-ID
<CAP4gbxqjHzqHhPuNK8UOwPMa46g2=vcNSk1AvGjxN8s+ou-0Dw@mail.gmail.com>
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!
Next: Junio C Hamano
Message 1 of 9 in “Fast-forward able commit, otherwise fail”
  1. David LightleJun 21, 2016
  2. Junio C HamanoJun 21, 2016
  3. Junio C HamanoJun 22, 2016
  4. David LightleJul 8, 2016
  5. Junio C HamanoJul 8, 2016
  6. Jacob KellerJul 9, 2016
  7. Stefan HallerJul 12, 2016
  8. Junio C HamanoJul 12, 2016
  9. Philip OakleyJul 20, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.