git-commit
Record changes to the repository
TLDR
Commit staged files to the repository with a message
Commit staged files with a message read from a file
Auto stage all modified and deleted files and commit with a message
Commit staged files and sign them with the specified GPG key (or the one defined in the configuration file if no argument is specified)
Update the last commit by adding the currently staged changes, changing the commit's hash
Commit only specific (already staged) files
Create a commit, even if there are no staged files
SYNOPSIS
git commit [-a | --interactive | --patch] [-s] [-v] [-q] [-n] [--amend] [--allow-empty] [-m
PARAMETERS
-a, --all
Automatically stage modified and deleted files, but not new (untracked) files.
-m
Use the given
-F
Read the commit message from the given file.
--amend
Replace the tip of the current branch by creating a new commit. The recorded tree state is the one found in the index. This option effectively undoes the previous commit.
--author=
Override the commit author. Use the standard 'A U Thor
-s, --signoff
Add a Signed-off-by line to the commit message.
--allow-empty
Allow creating empty commits (useful for specific workflows).
-v, --verbose
Show unified diff of changes to be committed.
-q, --quiet
Suppress commit summary message.
--date=
Override the author date used in the commit.
--no-verify
Bypass the pre-commit and commit-msg hooks.
--
Separates pathnames from options.
[
Commit only the specified files. If no files are specified, all staged changes are committed.
DESCRIPTION
The `git commit` command saves your staged changes to the repository along with a descriptive message. It essentially creates a snapshot of your project at that point in time, adding it to the project's history. This command is fundamental to version control using Git, enabling you to track changes, revert to previous states, and collaborate effectively. The changes must be staged using `git add` before committing. Without staging, only tracked files that have been modified will be committed without the new untracked files. Using a good descriptive commit message is crucial for understanding the changes later on. Commits are the building blocks of a Git repository, forming a directed acyclic graph (DAG) that represents the project's evolution. Commits include a pointer to their parent commits (previous state), and a SHA-1 hash computed from all the information that commit has.
CAVEATS
Forgetting to stage files before committing is a common mistake. If using `-a`, remember it only stages modified and deleted files, not new ones.
COMMIT MESSAGE CONVENTIONS
Good commit messages should be concise but descriptive, typically following the format: <type>(<scope>): <subject>. The subject line should be no more than 50 characters, followed by a blank line, and then a more detailed explanation (if needed). Common types include feat, fix, docs, style, refactor, test, chore.
DETACHED HEAD STATE
Be careful when committing in a detached HEAD state (not on a branch). These commits can be lost if not associated with a branch by creating a new branch from the HEAD or associating the commit with a branch that is already existing.
HISTORY
The `git commit` command has been a core part of Git since its inception in 2005, designed by Linus Torvalds. It is at the heart of Git's version control capabilities. Over time, features have been added to support various workflows, such as amending commits, signing off on contributions, and allowing empty commits.
SEE ALSO
git add(1), git status(1), git log(1), git reset(1), git revert(1)
