git-commit

Commit staged files to the repository with a message

$ git commit [[-m|--message]] "[message]"

$ git commit [[-F|--file]] [path/to/commit_message_file]

$ git commit [[-a|--all]] [[-m|--message]] "[message]"

$ git commit [[-S|--gpg-sign]] [key_id] [[-m|--message]] "[message]"

$ git commit --amend

$ git commit [path/to/file1 path/to/file2 ...]

$ git commit [[-m|--message]] "[message]" --allow-empty

git commit [-a | --patch] [-m | -F ] [--amend] [--no-edit] [-v] [--no-verify] [--dry-run] [-s | --signoff] [-S[]] [...]

-a, --all
    Automatically stage all modified and deleted files before committing. New files are not staged unless added explicitly with `git add`.

-m , --message=
    Use the given message as the commit message. If multiple `-m` options are given, their values are concatenated as separate paragraphs.

-F , --file=
    Take the commit message from the given file. Use `-` to read from standard input.

--amend
    Amend the previous commit. This command is used to replace the last commit with a new one, combining the changes in the staging area with the changes from the previous commit. It rewrites history.

--no-edit
    When used with `--amend` or `--allow-empty`, this option prevents `git commit` from launching an editor. The commit message is taken from the previous commit or the provided `-m`/`-F` option.

-v, --verbose
    Show the diff of the changes being committed in the commit message editor. This can help in crafting a relevant message.

-s, --signoff
    Add a "Signed-off-by: Your Name " line at the end of the commit message, indicating that you agree to the Developer Certificate of Origin (DCO).

-S[], --gpg-sign[=]
    GPG-sign the commit. The `keyid` is optional and defaults to the committer's GPG key.

--no-verify
    This option bypasses the pre-commit and commit-msg Git hooks. Useful when you need to commit despite a hook failure.

--dry-run
    Do not create a commit, but show what would be committed and the proposed commit message. Useful for previewing.

`git commit` is a fundamental Git command used to permanently record changes from the staging area (also known as the index) into the Git repository. When you make modifications to files in your working directory, these changes are initially untracked or modified. To include them in the next commit, you must first move them to the staging area using `git add`.

A commit operation creates a new commit object. This object includes a snapshot of your project's files at the time of the commit, metadata such as the author, committer, and timestamp, and a pointer to the parent commit(s). The collection of these commit objects forms the project's history as a Directed Acyclic Graph (DAG).

Every commit requires a commit message, which serves as a concise explanation of the changes introduced. A good commit message is crucial for understanding the project's evolution and for collaborative development.

`git commit` only records changes that have been explicitly moved to the staging area (index) using `git add`. A common mistake for new users is to make changes but forget to `git add` them before committing, resulting in an empty commit or missing changes.

Using `--amend` rewrites the history of your repository. This is generally safe if the commit you are amending has not been pushed to a shared remote repository. If it has, amending and then pushing can cause problems for collaborators who have already pulled that commit, requiring force pushes and potential conflicts.

An empty commit (a commit with no changes from its parent) is typically not allowed unless you use the `--allow-empty` option.

A well-crafted commit message is crucial for project maintainability. Best practices include:
1. A short, concise subject line (50-72 characters) that summarizes the change.
2. A blank line separating the subject from the body.
3. A detailed body (wrapped at 72 characters) explaining what and why the change was made, not just how. Use imperative mood in the subject line (e.g., "Fix bug" instead of "Fixed bug").

In Git, a commit isn't just a record of changes; it's a pointer to a complete snapshot of your project at a specific point in time. Each commit object contains:
1. A pointer to a tree object, representing the exact state of the working directory at the time of commit.
2. Pointers to its parent commit(s) (one for a regular commit, multiple for a merge commit).
3. Metadata: author, committer, timestamp, and the commit message.

The `git-commit` command has been a core and indispensable part of the Git version control system since its initial development by Linus Torvalds in 2005. Its design reflects Git's fundamental philosophy of tracking content snapshots rather than differences, enabling efficient branching and merging. While minor options and behaviors have been refined over the years, the central concept of committing staged changes to build a Directed Acyclic Graph (DAG) of project history has remained consistent and foundational to Git's operation.

git add(1), git status(1), git log(1), git diff(1), git reset(1)