What is the appropriate amount of changes to commit?

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

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

On the other hand, if you merge the X, Y, and Z features in the same commit and the Z functionality is not approved for release , you would not be able to roll back the by the tool itself. It would be necessary to create a new version of the system from the final version and remove Z. Or create a new branch and apply the same changes made to X and Y.

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

I do not know how far to take this, because in a pragmatic way you can even join features that are interdependent, but something that GIT savvy users always say is not to be afraid to create branches.

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

  

TL / DR : There are no rules. But open source projects - > presence of pull requests and patches - > smaller commits that can be easily reviewed by other developers. Commercial projects - > Larger commits to implement all aspects of a particular feature (even if the developer locally does multiple commits). Again, there are no rules, but I could see this difference in behavior in practice between the two types of projects.

While there are no rules defined, mature open source projects with multiple collaborators often work with finer granularity of commits . This is due to the very nature of the project. In open source projects, several external developers pull requests and / or submit small patches to fix small bugs or add small functionality to the project. The idea here is that commits are not only representative, more self-contained, and easily revisable by a project developer. Minor Commits are faster to review and give less headaches to who will integrate your code into the main repository (possibly long after you've submitted the patch ).

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

On commercial projects, it is equally common for a developer to make several small commits locations (say, a feature ), but before the push to the main repository, it is common practice to do a squash of those commits , giving the impression of a single large commit that solved a certain task / problem. The main point here is that the granularity of the tasks are larger, and there is an effort to make the repository "cleaner".

Each strategy has its advantages. Frequent and small Commits represent better the actual flow of development, however, thicker granularity and history rewriting make the commit tree cleaner. There are good arguments from the school "Make commit fast, always commit, never rewrite history" as well as school "Keep your central repository clean". The choice is entirely yours.

The simple answer is: You choose.

The complete answer would be: It depends on the versioning system you intend to use.

The most commonly used system is SemVer which uses 3 parameters separated by periods. Parameters correspond Major, Minor, Patch

   MAJOR new version when new API is incompatible with previous MINOR when adding new methods that respect and are compatible with previous methods < All patches, fixes that are exclusively to fix bugs or bugs in the code without adding new features / methods.

So if you are using SEMVER, ie Semantic Versioning, all minor patches should increase the patch parameter and have a new tag in git.

It has another aspect that is linked to the ease of perceiving and analyzing commits. A commit must have changes related only to a subject. Commits that handle n files and change many behaviors are confusing and undesirable.