0

I'd like to do no-ff merges by default. But am I giving up any safety, as is the case when using rebase?

Dogweather
  • 15,512
  • 17
  • 62
  • 81
  • What kind of safety are you thinking of? With the reference to `rebase` are you alluding to the work it makes for others who already have your existing commit history, when you "rewrite your history"? – torek Nov 12 '13 at 01:17
  • Fast forward merges afaik are the safest in that you will never lose data. I don't know the details of rebase, but I understand that used improperly, one *can* lose information. – Dogweather Nov 12 '13 at 01:18
  • 2
    I think you *are* referring to "history rewriting", then. In which case, not a problem: a non-ff merge simply adds a new commit and moves a branch label. A fast-forward merge moves the label to an existing (but forward) commit. Both are "safe" because they do not "remove commits". – torek Nov 12 '13 at 01:28

1 Answers1

1

I would suggest to always use --no-ff so history is retained, in fact, that is the standard we use at my job, take a look at this document where we explain our git workflow

And here is a another explanation given here in stackoverflow

Community
  • 1
  • 1
Guillermo Mansilla
  • 3,779
  • 2
  • 29
  • 34