> I always twitch a bit when I see a 10-page blog post describing a "git workflow", with all sorts of complicated branching rules and heavy use of rebasing. That can make sense in certain specialized situations, but it shouldn't be considered a "best practice" that everybody needs to emulate.

I tend to justify this based on a simple observation: writing clean code that is easy for others to understand is also hard. If you could write a document that teaches others how to write clean code, what would it contain? How long would it be? How complex would it be? I'm betting you've built up a repertoire of wisdom on writing easy to read code, and I'm betting that document would be quite long, especially if you furnished it with examples.

I think it's the same for commit history. If you're rebasing, then you're probably trying to shoot for a clean history that other humans can understand. Maintaining a clean history can be just as hard (and just as rewarding) as maintaining clean code.

How is it rewarding? No one ever sees the history, honestly. Writing good code results in working code the people build off of. Maintaining clean, linear git histories does.. what exactly?

Uh, I read commit history all the time. (My initial comment assumes you believe the idea that a clean history is useful, because that's the context of ekidd's comment. So I really don't feel like debating that particular point, if that's what you're getting at. It's been re-litigated hundreds of times.)

Your git history is very important for working out what the rest of your team did, when they did it, and why. Having a clean and linear history, preferably with informative commit messages and maybe even references to bugs or features, lets you understand what was going on faster and with fewer mistakes and false starts.

Why would you want to understand what was going on? Maybe for fixing a bug, maybe for working out why a seemingly useless change was necessary, maybe to understand the context of a code review building on previously merged branches, or maybe just because you need to catch up on what happened while you were gone.

If that's not important to you, then don't bother, but it can be hard to understand what you're missing until you've tried both ways.

No one ever sees the history?

Really ? To me the need for checking history is extremely common. Many projects have multiple delivery, maintenance and other branches, patches need to be applied here and there. Bugs are found and the versions affected needs to be identified.

Not maintaining a clean history would cause severe pain.

How do you enforce a commit policy in your projects?

Do you automate it?

Or do you provide feedback by mail, IM, ... to the author when a commit mistake is detected?

Review-before-merge, maybe?

Obviously, for any old arbitrary project, there's going to be limits to what you can ask your contributors to conform to before they just leave, but we're discussing "Best Practices"[1] here.

I think these articles are useful because they spread the knowledge of "How To Be A Good Contributor"... for free.

[1] Ugh. Not a term I like, but really this is almost always(!) the best way to do it.

We have a GitHub integration that runs on every pull request and push, which triggers an AWS Lambda function that verifies that disables the big green "Merge" button if the branch could not also be fast-forwarded onto its parent.

> No one ever sees the history, honestly.

Then you wouldn't see value in rewriting. Unless you're not reading the history because it's a pain to read because it's messy.

I use `git blame` relatively frequently to understand the rationale and history behind the code I'm working on, or to track down bugs. Of course, this also requires writing decent commit messages---something that I encourage developers to do so that those maintaining their code in the future have some direction. Commit messages are a bit different than software documentation, not a substitute.

I bisect looking for bugs, where a clean history with small commits _that actually build_ is essential to quickly finding a bug. That can even be automated if you can create a script that can run a test suite or some other test to check for success.

This becomes increasingly important the more code and complexity you're dealing with. There are other cases where I look at history, but those are significant examples.

> 1. Projects like the Linux kernel which use frequently use 'git bisect' to perform a binary search on the history of project (to find when a bug was introduced), or where the patch series tell a story to code reviewers.

This seems like an instance of adapting development practices to bad tooling, whereas we could be fixing the tool itself. Shouldn't there simply be a "tree aware" git-bisect that can intelligently handle branches and merges? That would resolve this sticking point.

> 2. Open source projects, where some contributors have terrible git habits that the maintainers don't want to merge.

Then tell them to go away and come back with a cleaned up PR.

> Shouldn't there simply be a "tree aware" git-bisect that can intelligently handle branches and merges?

Afaik, git-bisect is aware of branches and merges.

But there are two drawbacks to not rebasing/squashing: 1) the number of extra commits. Although bisecting is O(log N), it still adds up if it takes a long time to run the tests. 2) if there are any commits that don't build or have to be skipped (git bisect skip) because of other reasons, the number of steps to bisect increases.

It's a good idea to ensure that any commit that goes to master branch will pass all tests or at least compile. Failure to do so will make git-bisect a lot less useful.

If true, the the whole claim that nonlinear histories break git-bisect is bunk.

Non-linear histories work just fine with git-bisect. What breaks git-bisect are histories where every commit doesn't work; for instance, if you have one commit that breaks something, and a second commit that fixes it, git-bisect won't work well.

It will work just fine, you just might have to call git bisect skip a time or two or run it more than once.

That's not "fine"; bisect takes long enough when you expect it to work consistently. And that assumes the code fails at build time, rather than mysteriously at runtime.

That also breaks the ability to do automated bisects.

I don't think it's at all unreasonable, at a minimum, to expect every individual commit to build and to pass tests.

Do people actually look at the history a lot? After a pull request has been merged I rarely look at the history and I am really not interested in it. This is for a small team with around 5 people. In larger teams is it more important to see the history?

I work as lead dev on a 5 year old web app I took over from a previous dev and his team of subcontractors about a year ago. It's very helpful to see into the past when there's no way to just ask the previous dev.

Even if not at the history directly, commit messages are associated with the lines they edit. This provides great granular documentation: https://vincenttunru.com/assets/img/Commits-are-documentatio...

(From my blog post about why history matters: https://vincenttunru.com/Spend-effort-on-your-Git-commits/ )

I work in a University setting where we have student's working in our various projects. While some stay with us for a number of years, some are with us for a semester or two.

Even with full-time staff, in the almost 6 years I've been here the rest of the dev and design staff completely changed (and grew).

In my opinion, if you're not using history/blame your code is relatively new, or you're the only one touching code. Or you have regular code reviews (paired programming, whatever).

Seven years at my last job was just full-time staff, but we had the same issues, once a version control system was actually implemented.

Resolving conflicts through a merge or a rebase is a different style (all-in-one vs piece-meal), and I find both have their uses in different contexts. Sometimes, a big merge with tons of conflicts is too daunting, where a patch-by-patch conflict resolution is more palatable. Other times, you're doing busy work on tons of patches which would be far more efficient just doing once on a big merge.

But, again, this depends on the situation, the code, the history, the patches, etc. It's just a useful tool to keep in mind come merge time.

You can do both. Squash your working branch to a single commit, then rebase. That way you still get a clean view of just the changes introduced in the branch, and don't have to resolve merge conflicts every step of the rebase.

is there a site that shows an animation for each git command?

Yep! http://learngitbranching.js.org/

Here's one for the most basic ones, except staging: https://agripongit.vincenttunru.com/

(Disclaimer: I made that :)

Not animations, but git-scm.com is excellent