[war1025]

I wonder how much overlap there is between the "staging area is useless" and the "never rewrite history" crowds.

Personally, I use staging area all the time to create a curated set of commits that make logical sense when putting them up for review.

My workflow is generally to keep a very messy history of `XXX` commits until I am happy with what I've come up with. Then reset back to the branch point and using the staging area to build up logical changesets.

I don't care about the history of my coming up with the solution, I care about presenting the solution in a way that makes sense to reviewers, including future me.

[ori_b]

Interesting, so you commit things that are different from the code that is sitting in your working directory at the time of the commit?

[war1025]

I use `git add -p` to selectively pick out chunks of code that fit together into commits.

Later on, if I notice that I messed something up, I'll create a fixup commit and do an interactive rebase to squash it back into the correct commit.

[e3b0c]

In my opinion, `git add -p` should be the default, and a `-a` or alike to forcibly commit the entire working tree. I have developed a habit that I wouldn't feel comfortable if I haven't reviewed the chunks I am going to make into the commit.

[Rychard]

While there are many people who don't understand git's staging area, there are far less that understand how to selectively stage/commit chunks, or even that such functionality is available at all.

It should be a crime for people to blindly stage everything. Cleaning up after my colleagues easily falls under the "lost cause" umbrella.

[erik_seaberg]

Whereas I don't feel comfortable with untested work, so "git checkout -p" (undo a change) and "git stash -p" (postpone a change) are how I get the workspace clean enough to commit.

[black-tea]

Magit, for emacs, makes this workflow a joy. The "instant fixup/squash" features are great.

[phs2501]

Yes, all the time. Stage individual hunks or individual lines in `git gui` to clean up history or avoid commiting debugging hash.

[ori_b]

How do you test these intermediate commits, given that they're different from what's on disk?

[war1025]

Usually I test the end result. Or the commits are disjoint enough that I am confident that they don't interfere with each other.

If I really care about things being fully correct at each commit, I'll do an interactive rebase and just stop and test on each commit.

[laughinghan]

In the case of console.log() and debugger breakpoints, that's not a concern.

Often they're disjoint enough that I'm confident that if the end result works, the intermediate commit works, as the sibling commenter mentioned. (Even if not, on many teams it all gets squashed anyway, the intermediate commit message just makes the Pull Request easier to review.)

I can also often easily comment out the uncommitted stuff.

Finally, if I'm really worried about it, after creating the intermediate commit I can just `git stash`, test it, then `git stash pop` and keep working.

[doublerebel]

CI/CD. I push, it tests, I keep staging and working.

[black-tea]

Absolutely. Every single day. Only the most trivial changes result in commiting everything in my working tree.

[black-tea]

I think many people (eg the "never rewrite history" crowd) don't understand what history is useful for. Ask yourself now: once a branch is merged into master, why do we even keep the history of master? The answer is simple: to track old versions and regressions. The answer is not so that some historian can come along and work out what you did each day of your career. That's not useful. Nobody cares. Git history is not history. It's a sequence of versions of software each of which you believe could be checked out and used.