5 ms·

I wrote a similar suggestion in 2011: https://sandofsky.com/workflow/git-workflow/ https://sandofsky.com/workflow/git-workflow/ As far as I could tell, this wa

I wrote a similar suggestion in 2011: https://sandofsky.com/workflow/git-workflow/ https://sandofsky.com/workflow/git-workflow/ As far as I could tell, this was the recommended workflow from the earliest users of git. Look at the Linux kernel's public history. When git gained widespread adoption, it was sold as "Subversion, but with cheap branching." People don't realize that this power requires discipline, otherwise you end up with complicated history that makes change management a nightmare. In code review systems like Gerrit, you have to approve every single commit, and you can also enforce rules like "fast-forward merges only." It sure makes Github's pull-request model feel like an anti pattern.

ninkendo 5y ago
I love this quote: > Treat yourself as a writer and approach each commit as a chapter in a book. Writers don't publish first drafts. Michael Crichton said, "Great books aren't written-- they're rewritten." This is a more succinct and poignant way of describing my workflow, and why "just put a PR up with all your WIP commits" is so difficult for me. I don't want people to see how long I spent getting this one unit test to pass when the answer was staring me in the face the whole time. I don't people to see just how badly I wrote the first draft of my code, when my approach was basically "make it work e2e first, no matter how bad of a hack it is, then actually figure out how the code should be laid out later." Folks say "your PR can just be squashed when merging anyway", but it misses the point: My private commit history is very, very, intensely personal to me, and I don't want anybody seeing it, ever.