4

In order to make it easy to see when feature branches are merged to master, one can use Git's --no-ff option when merging their feature branch into master.

One way to accomplish this without needing to type --no-ff is to disable fast-forward merges into master entirely:

git config branch.master.mergeoptions --no-ff

However, this is clumsy since it also prevents fast-forward merges when simply merging upstream changes in master to a local copy of master (merge commits are created for normal git pulls.)

Is there some way to configure Git to prevent fast-forward merges into master only when merging feature branches into master, so that fast-forwards are allowed when doing git pulls from master, but merge commits are always created when merging feature branches? Or is explicitly using --no-ff the only way to accomplish this?

segfault
  • 572
  • 1
  • 7
  • 20
  • How will git know the difference between a feature branch and upstream? It's all just branches to git, doesn't matter what the name is. The only thing that I can think of that may work is doing something with tracking branch and have `master` track `origin/master`. Possibly implemented with a pre-merge hook? – asm Oct 11 '12 at 00:13
  • I was just hoping there was some special config option I may have missed reading through the man pages, thinking (as you hinted) that Git may be able to tell the difference between merging from 'inside' a tracking branch (merging changes from origin/master -> master) vs merging in a different branch. – segfault Oct 12 '12 at 15:07
  • @segfault Pondering this very thing myself right now. You haven't happened upon a solution in this passed month? – SilverSnake Nov 12 '12 at 14:36
  • Nope, no solution yet, unfortunately. – segfault Nov 12 '12 at 21:16
  • VonC provided an [updated answer](http://stackoverflow.com/a/12798995/1936123) to a similar question in Q2 2014 – user1936123 Mar 01 '16 at 21:01

1 Answers1

2

Note: a pre-merge hook doesn't exist.
It was introduced in 2008, and criticized then (because the control had better be implemented on the server (using an update hook).
It is in the process of being re-introduced (September 2012)

And a pre/post-commit hook isn't run on the auto-commit done by a git merge.

So:

  • either you put in place an update hook on a git server where developers are pushing (but that may be too late by then for them to realize they fast-forwarded a feature branch)
  • or you write (and distribute, and maintain...) a git-merge wrapper which will do that control at the local repo level.

That being said, as I mentioned in "fast forward when using pull and no-ff when pull", not using --no-ff has its advantages, as it won't break git bisect and git blame.
So a developer for a feature might want to reorganize his/her feature commits (squash them a little if there are too many of them) before fast-forward them in master branch (instead of creating one giant commit).
See "Understanding the Git Workflow" for more.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • So it sounds like you're saying there's no elegant way to do what I'm looking for. I'm trying to figure out a proactive workflow for this that all developers can configure easily, instead of something like the update hook you mentioned where developers could only be told about their mistake after they've already made it. The simplest thing would probably be to tell developers to just use --no-ff when they merge feature branches into master. – segfault Oct 12 '12 at 15:10
  • @segfault I agree (on the `--no-ff`). And that (enforcing policies with a DVCS) is generally done on a central repo (to avoid having to deploy said policy on each downstream repo). – VonC Oct 12 '12 at 15:47
  • The whole reason I created this question is because I don't want people to have to remember to either type --no-ff or to download/configure a proprietary wrapper when they first clone. I'm looking to minimize the possibility of everyday human error as much as possible. :) – segfault Oct 12 '12 at 22:29