Questions about committing a transaction or "unit of work" to a database, application or version control system.
The usual context of this tag is application and/or database transactions but it is also applicable to version control software.
Within the application/database context, a commit means that all state changes made during the current transaction are made permanent.
Within the context of version control software, the "unit of work" being committed is the total change being written to the central store. Usually, "commit" refers to the command used to perform this action (e.g., git commit or svn commit).
The nature of different source control systems lead to different styles of committing. However, there are generally two agreed upon practices:
Commit only single units of work (fixing a single bug, adding a single feature, etc.) - this makes history easier to walk through. Conversely, avoid making large, sweeping commits, which pollute history.
Commit messages should be fairly concise and clear. This makes understanding who has done what (typically done using a command like
blame) easier. This practice is an extension of the first, because single units of work are easier to write clear commit messages for.
Beyond these two guidelines, the majority of workflow is determined by how distributed a version control system is. Generally speaking, what goes into a centralized system like Subversion is much more strictly controlled because it is harder to undo; most commits in a centralized system involve running a project's entire test suite.
Distributed systems like Git tend to be less strict about what is committed, because it is the author who chooses when to push commits to a remote repository and can run test suites before choosing to push their changes; also, any mistakes can be reversed by editing private history.
