Skip to content

Comment on Thou Shalt Not Lie: git rebase, ammend, squash, and other lies

Comments

I think this depends a lot on your team, your practices, and the way you use source control. At the old job, source control (mostly SVN) was essential for figuring out why a new change to the framework broke a customer-specific customization written six years ago by someone no longer with the company. The company culture was to keep commits and merges so clean they were almost releases in themselves. (It took me, ahem, quite some time to adapt to that style of working -- coming as I did from not using source control at all.)

If they had used git, they would totally have approved use of rebase for optimizing readability/understandability of commits for the beleaguered maintenance engineer in 2016 trying to figure out what why what we did today (in 37 separate incremental commits) just interacted with new code and blew up $MAJOR_UNIVERSITY's payroll system.

I follow very, very different practices when developing by myself. I largely leave the history as it is, warts and all. If in the course of trying to fix a bug I make five exploratory commits and on the fifth one finally find the magic that works, then history just happens to include five increasingly frustrated commit notes.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.