In modern software projects, a clean Git history is more than just an aesthetic choice – it is a cornerstone of maintainable, collaborative development. Practitioners across the industry (from Linux kernel maintainers to Google’s Angular team) advocate for atomic commits: each commit being a focused, self-contained change that can stand on its own.
This article outlines widely accepted conventions and best practices for writing such commits in a language-agnostic context, drawing on official guidelines and community consensus.
Read more here:
https://cleverthis.com/news/writing-high-quality-well-scoped-commits/
#Best Practices #CleverThis #ML #MachineLearning #AI #AGI #ArtificialGeneralIntelligence #ArtificialIntelligence #SemanticWeb
@cleverthis @freemo I would heavily recommend looking into git-compatible tools like jujutsu that let you tinker first and commit later without all the mental overhead required to pre-plan your commits in advance. Sometimes as you go down the rabbit hole when fixing an issue or adding a feature, the easiest thing to do is finish and worry about organization afterwards and tools like jujutsu, (and pijul/DARCS) give you more flexibility than hit in this regards (and it’s easier to keep track of and keep a clean history IMO).
Doc Freemo 
Its hard for me to see how that could work, but if the tool does what you say and does it well somehow that could be a game changer.
@freemo imagine having a tree of messy private commits. You can: merge them; split them; reorder them; branch them; move commits into different parts of the tree; improve their name or description; undo/redo some of these private operations; and so on.
You work in complete freedom because it is a private tree of commits. The structure of the tree is a first class citizien of the tool, and it is an ever changing structure.
When a commit is in good shape and ready to be published, it become a public commit, and you cannot anymore change it.
The public commits are a linear order of high-quality commits. The last public commit become the new root of the messy tree of your private commits.
Sounds a lot like how people work in git already... but thats my naive brain.. going to look at this now and see if there is any value here.
Thanks for bringing it up, im sure ill have an opinion questions and comments soon.
@freemo @cleverthis Basically, each change you make is logged as a micro-commit, and once you reach a state that you're happy with the current progress, you simply quash the micro commits into commits based on whatever best practices you prefer. In git, such a set of operations would be a nightmare, but jj uses first-class conflicts and a pseudo-theory-of-patches to make this the default way of interacting with your repo, and I have to say I much prefer it. And the fact that any valid jj repo is also a valid git repo means way less overhead in terms of integrating with your existing workflows.
Here's a the codebase and a few tutorial resources.
https://github.com/jj-vcs/jj
https://kubamartin.com/posts/introduction-to-the-jujutsu-vcs/
https://steveklabnik.github.io/jujutsu-tutorial/introduction/what-is-jj-and-why-should-i-care.html
Additionally, there are some Emacs extensions and CLI tools that exist. If you're interested, I'll link you :)
A Git-compatible VCS that is both simple and powerful - jj-vcs/jj
GitHub