3 ms·

I'd like to read a post about the optimal granularity of git commits in different situations. I don't think I'm experienced enough particularly when it comes t

• merlincorey 15y ago
  It depends somewhat on your perspective. Some people like to lie, and others do not[1]. Personally, I don't mind lying a bit in my personal projects. To lie, you simply make a new branch for each feature or otherwise related changeset such as a hotfix. Within that branch, you make as many commits as you want, the more the merrier. When the branch is ready to merge, you use "git merge --squash branchname" which will pull in the changes from branchname in an uncommited form. Then, you can use "git diff" to view the differences and make one single commit with an appropriate commit message detailing each change. The upside is that it is atomic without needing to use the git-workflow no fast-forward business. The downside is you're lying. [1] http://paul.stadig.name/2010/12/thou-shalt-not-lie-git-rebase-ammend.html http://paul.stadig.name/2010/12/thou-shalt-not-lie-git-rebas...
• inerte 15y ago
  My granularity is: Different things go on different commits. For example, you can include 30 files and hundreds of lines in one changeset if they are all related to the new feature X, but do not in the same changeset correct the indentation of a code block. The commit message is like a title. All diff lines must be related to it or they should be in another changeset.