What is the appropriate amount of changes to a commit?

Question

I have noticed that in many public projects Github, the commits usually contain very small changes. There are several cases of commits with changes in a single line of code. In others, there are changes only in comments, not in code.

I don’t usually work like this. I use the Git locally and avoid doing commits of minimum changes are usually substantial changes. In some cases, my commits contains changes in more than 10 files. I’ve been wondering if this is ideal.

What is the appropriate amount of changes for a single commit?

Answer 1

It is not ideal to measure a commit by the amount of file or by your perception of the size of the changes.

In the ideal world, a commit should contain one, and only one, new functionality or a single correction. This enables impact traceability of each change and a possible rollback of that commit in case it breaks anything.

On the other hand, if you combine X, Y and Z functionalities into one commit and functionality Z is not approved for the release, it would not be possible to reverse the change by the tool itself. You would need to create a new system version from the final version and remove Z. Or create a new one branch and apply the same changes made in X and Y.

For this scheme to have an even better effect, it is interesting to use a branch different for each feature. After implementation, the commit is made in the branch and the final version of the system is merge of all selected features.

I don’t know how to take this, because pragmatically you can even add features that are interdependent, but something experienced GIT users always say is to not be afraid to create branches.

An important and practical principle is to use the tool as it is best for you and your team to organize the code. In other words: use the tool to help your work, do not work according to the tool.

Answer 2

The simple answer is: You choose.

The complete answer would be: it depends on the versioning system you want to use.

The most commonly used system is the Semver that uses 3 parameters separated by points. The parameters match Major, Minor, Patch

MAJOR new version when the new API is incompatible with the previous one,
MINOR when adding new methods that respect, and are compatible with, previous methods
PATCH all patches, fixes that are solely to fix bugs or bugs in the code without adding new Features/methods.

So if you’re using SEMVER, in other words Semantic Versioning all patchs for smaller ones should increment the patch parameter and have a new tag in git.

Looks different that is linked to the ease of perceiving and analyzing commits. A commit must have changes related to only one subject. Commits that touch on n files and change many behaviors are confusing and undesirable.

Answer 3

TL / DR: There are no rules. However projects open source -> presence of pull requests and patches -> minor commits trend, which can be easily reviewed by other developers. Commercial projects -> Trend of commits implementing all aspects of certain Feature (even if the developer locally does several commits). Again, there are no rules, but I could observe this difference in behavior in practice between the two types of projects.

While there are no defined rules, projects mature open source with several employees usually work with a finer granularity of commits. This is due to the very nature of the project. In projects open source several external developers do pull requests and/or submit small patches to fix small bugs or add small features to the project. The idea here is that the commits are not only representative, more self-contained and easily reviewed by a project developer. Commits are faster to review and give less headache to those who will integrate their code to the main repository (possibly long after you submitted the patch).

Even the "central" team of a project, with permission to do push in the main repository, usually works with a finer granularity of commits. Large work units are generally well subdivided among the various modules, and later subdivided into smaller tasks. The result is that there are more tasks, each one more "punctual"; soon more are done commits, each with less code.

In commercial projects it is equally common for a developer to do several small projects commits local (say, in a branch of Feature), but before the push to the main repository, it is common practice to make a squash of those commits, giving the impression of a single great commit that solved certain task / problem. The main point here is that the granularity of tasks is greater, and there is an effort to make the repository more "clean".

Every strategy had its advantages. Commits frequent and small represent better the actual development flow, however, coarser granularity and rewriting of history make the tree of commit more "clean". There are good arguments from the school "Do commit quick, do commit always, never rewrite the history", as well as the school "Keep your central repository clean". The choice is entirely yours.