Commit often, perfect later, publish once: Git best practices (2013)
I kind of feel that this kind of git advice is way beyond the point of diminishing returns. As a conscientious developer we have a lot of work. We write code of good quality. We refactor that code regularly. We write automated tests. We test the program manually. We use linters and type checkers. We talk to people to find out whether what they requested is actually what they need. But the day only has 24 hours. At some point one has to say that enough is enough. I really want to put the &#x27;enough is enough&#x27; point before worrying about a good looking commit history. Some years ago we all went from svn to git and I am not really sure the improvement was worth it. Sure, git is objectively the better version control system. One can do a lot more things in git. But then the disadvantage is that one actually gets to think about all of these &#x27;a lot more things&#x27;. One thinks about questions like should one merge or rebase and so on. I seems like an activity that falls under what is commonly called &#x27;bike shedding&#x27;. But like I was asking before: is this really worth it?