5

Every time I read Merge branch 'origin/master' into master, or Oops, forgot to commit changes, in a Git history, I die a little inside. Of course I know why it is bad to clutter your history with these types of commits. Mainly because I have worked with both horrible and clean histories, and clean histories are simply better to work with.

But I'm also having trouble coming up with concise and convincing arguments why it is a good thing to maintain a clean and readable history, especially when arguing with inexperienced Git users.

So: why Is it important to maintain a clean history in general? Under which circumstances is it especially important?

Improve this question
10
  • 1
    "clean histories are simply better to work with" - isn't that a concise argument?
    – Doc Brown
    Commented Aug 4, 2016 at 11:49
  • I think that you should differentiate between your two examples: Merge commits, even with the default message, are fine in a history because they truthfully record the history of development. Rebasing leads to lies, and those lies may break compilability/testability of commits, significantly reducing the value of git bisect. Ooops, forgot to commit changes, on the other hand, is indeed a sign that the author should have rewritten their history to avoid cluttering the public history with a commit that won't compile/test successfully.
    – cmaster - reinstate monica
    Commented Aug 4, 2016 at 11:57
  • @cmaster maybe i was imprecise. i didn't mean merge commits per-se. i meant merge commits from upstream, that result from a git pull when your local branch has diverged. a thing that is very typical and completely unnecessary.
    – thrau
    Commented Aug 4, 2016 at 12:21
  • 1
    @Doval The problem with rebasing long lived branches is, that you likely need to rebase the first commits several times onto different upstream changes. With the merge approach, you merge with upstream, and then you never need to touch the merged commits again. Even though later upstream work may conflict with some of your early commits, those conflicts are resolved in the merge commits and there is no need to retest your early commits several times. This allows for much more frequent updates from upstream than the rebase approach, where the updates slowly become prohibitively expensive.
    – cmaster - reinstate monica
    Commented Aug 5, 2016 at 12:33
  • 1
    @Doval Unfortunately, I'm forced to: I have to work on big features with an SVN upstream. And I loose quite a bit of time due to those increasing rebasing costs :-(
    – cmaster - reinstate monica
    Commented Aug 5, 2016 at 13:01

1 Answer 1

Reset to default
3

In layman's terms:

  • Git history is part of the documentation of the project. Do your project leader tolerate messy documentation?
  • It reflects your hard work
  • It makes it easy to understand the development history
  • All team members can follow progress easyly
  • It's easier to trace down problems when something goes wrong
  • Saves time when you have to find something
  • Makes it easier to understand design choices

Sources:

http://victorlin.me/posts/2013/09/30/keep-a-readable-git-history

http://megakemp.com/2014/08/14/the-importance-of-a-good-looking-history/

Improve this answer
4
  • 1
    "makes it easy to understand the development history", the question i often get is "why would i even want to understand history?"
    – thrau
    Commented Aug 4, 2016 at 12:23
  • @thrau Which is a really good question. I, for one, want exactly two things: 1. that git bisect does not stumble across unbuildable commits, and 2. that I understand the commit that git bisect points me at. I won't care what commits came before/after that, git bisect sorts that out for me...
    – cmaster - reinstate monica
    Commented Aug 4, 2016 at 12:38
  • 1
    History can explain why changes were made, which can help keep you from needlessly throwing away work done towards some goal. If I do a refactoring in order to prepare for planned new feature X, but after subsequent discussion X is permanently scrapped, you could consider scrapping my refactoring if it seemed inconvenient for feature Y.
    – CPerkins
    Commented Aug 4, 2016 at 14:01
  • 1
    @thrau "Those who don't know history are doomed to repeat it"
    – Tulains Córdova
    Commented Aug 4, 2016 at 14:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.