Git Commit

---

---

Git commit takes complete snapshots of our repository at specific times.

• Make frequent commits based on logical changes to effectively tell the story of our repository's history and current state.

• Along with the message and contents, every commit also contains metadata like authorship and timestamps.

We can safely and effectively rewrite the project's history due to commits.

We are able to decide which modifications to incorporate in commits made on various branches.

• To ensure its accuracy, always verify our current branch with git status before committing.

• Before committing, stage new modifications using git add [file].

• In Git, commits are thin SHA hashes that can easily handle any quantity or size of text files.

Committing in two phases involves preparing commits in a structured manner.

Commits should ideally represent distinct concepts and be rational, atomic units of change.

Git accommodates human workflow by allowing commits after solving multiple problems.

To properly prepare commits, stage files for commit using git add <FILENAME>.

• Git uses the staging area as a guide to decide what should be committed.

• The command line or Git interfaces such as GitHub Desktop can be used for staging.

• Select files or lines to stage for the commit process.

The most recent staged modifications are captured when a new commit is made.

• It has an informative log message attached.

• In the current branch, the new commit becomes the most recent.

• It represents the tip of the branch and comes immediately after HEAD.

• After then, the branch reference is changed to point to this most recent commit.

There are multiple ways in which we can specify content to be committed.

• Before committing, use git-add to systematically add changes, including modified files, to the index.

• Before committing, use git-rm to remove files from the index and the working tree.

• Provide a list of files as inputs to the commit command, which records the content as it is now known to Git, ignoring staged changes.

• To automatically add changes from all known files in the index and remove deleted files, use the -a switch. Then, commit the modifications.

• Index contents and files to be committed can be interactively chosen using the --interactive or --patch switches.

Based on supplied parameters (options and paths), the --dry-run option offers a preview of the changes that will be included in the next commit.

If an error is discovered immediately after committing, git reset can be used to roll back changes.

Options

The following options can be used with the git commit command.

-a

--all

• Use the command

  git add -u

  to automatically stage deleted and modified files for commit in Git.

• This command stages all tracked files that have been added, removed, or modified since the last commit.

• It has no effect on newly created files that Git is not yet aware of.

-p

--patch

• Git's -p or --patch option gives us complete control over which changes are included in the commit by allowing us to use a patch selection interface to interactively choose which changes to commit.

-C <commit>

--reuse-message=<commit>

• Git allows us to create a new commit utilizing the log message and authorship details including timestamp from an existing commit object by using the -C <commit> or --reuse-message=<commit> option.

-c <commit>

--reedit-message=<commit>

• In a similar manner to -C, but with the opportunity to make additional adjustments to the message before committing, the user can update the commit message by using -c <commit> or --reedit-message=<commit>.

--fixup=[(amend|reword):]<commit>

• We can create commits that alter an earlier commit in a variety of ways when we use git rebase --autosquash.

• fixup=<commit>: Generates a fixup! commit that modifies <commit>'s content while keeping its log message.

  The subject of the original commit is followed by fixup! in the commit message that is automatically created.

• --fixup=amend:<commit>: Generates a amend! commit that modifies <commit>'s content as well as its log message.

The log message of the original commit is replaced with the log message from the amend! commit.

• --fixup=reword:<commit>: Similar to --fixup=amend:<commit>, but only changes the <commit>'s log message; its content remains unchanged.

  This is a shorthand for --fixup=amend:<commit> --only.

• Extra commentary can be added to the fixup! commit using the -m option, but it will be removed after the commit is squashed.

• Unless --allow-empty-message is enabled, the log message is required for amend! commits.

--squash=<commit>

• To construct a commit message that works with rebase --autosquash, use Git's --squash=<commit> option.

• It uses the commit's subject line as a starting point, adds squash! before it, and lets us use other commit message choices in addition to it.

--reset-author

• It specifies that the committer is now the author of the resultant commit when used with -C/-c/--amend options or after committing after a conflicting cherry-pick.

• It also modifies the author timestamp accordingly.

--short

• Git formats the output cleanly when the --short option is used when combined with a dry-run.

• Git's --dry-run option is automatically implied by this option.

--branch

• Git's --branch option adds branch and tracking information to the short-format output, giving more details even in brief displays.

--porcelain

• Git's --porcelain option changes the output format during a dry run so that it is script and machine readable.

• It makes sure that Git outputs are consistently organized so that they can be automatically processed or parsed by other tools.

--long

• Git's --long option formats the output verbosely and in depth when used in combination with a dry-run.

• It suggests --dry-run, offering detailed data appropriate for a comprehensive review of possible courses of action without carrying them out.