How it works
A commit is the basic unit of history in Git. When you change files and run git commit, Git creates a snapshot of that state, with a unique identifier (hash), the date, the author and a descriptive message. That snapshot is stored in the repository and can be recovered at any time.
Good commits are small and focused on a single logical change. The message should explain why the change was made, not just what changed. Projects follow conventions like Conventional Commits, which standardize prefixes like feat:, fix: and docs:.
Commits form a chain: each commit points to the previous one, creating a linear or branched history. This allows you to go back in time, compare versions and identify when a bug appeared.
Before the commit, changes stay in the staging area, where you select exactly which changes to include. Best practices include atomic commits, messages in the imperative mood and referencing issues when applicable. Pre-commit hooks can run linters and tests automatically before confirming the commit.
Rewriting history with rebase or amend requires care on shared branches, as it can cause conflicts for other collaborators. Commits signed with GPG increase security and traceability.
Practical example
You fix a tax calculation bug and adjust two files. Instead of committing everything together with "fixes", you create two commits: one with "fix: correct tax calculation for corporate clients" and another with "test: add test for the corporate client scenario". This way, the history stays clear and easy to revert if needed.
What it's for
Commits organize work and enable safe collaboration. On teams, each person creates commits on their branch and sends them via pull request for review. CI/CD tools trigger tests automatically on each commit.
AI agents that code, like Claude Code and Codex, also create commits when they finish tasks. In bridgecode, each agent can work on its own branch and commit isolated changes, making human review easier before merge.