Git Cheatsheet

Quick Navigation

• Common Commands
• Commit Convention

Common Commands

Most of the commands below are collected from it-tools.tech, supplemented with additional commands based on personal development experience.

Blue text inside code blocks can be edited for quick modification and copying.

Configuration

Set global username and email:

git config --global user.name "WaLudo"
git config --global user.email "[email protected]"

Starting a New Project

Initialize a new Git repository:

git init

Clone an existing Git repository:

git clone https://github.com/WaLudo/waludo-tools.git

Commits

Commit all tracked changes:

git commit -am "feat: add two cups of coffee"

Commit all changes:

git add .
git commit -m "feat: add five cups of coffee"

Append new changes to the last commit:

git commit --amend --no-edit

I Messed Up

Edit the most recent commit message:

git commit --amend

Undo the most recent commit but keep changes:

git reset HEAD~1

Undo the last N commits but keep changes:

git reset HEAD~N

Undo the most recent commit and discard all changes:

git reset HEAD~1 --hard

Reset local branch to remote state:

git fetch origin

git reset --hard origin/branch-name

Miscellaneous

Rename local master branch to main:

git branch -m master main

Commit Convention

Refer to the Conventional Commits v1.0.0 specification.

Validate Your Commit

git commit -m "feat(scope): description"

Type Quick Reference

Scope

A scope may be provided after a type to provide additional contextual information, enclosed in parentheses:

feat(parser): adds ability to parse arrays

Breaking Changes

A ! indicates a breaking change and can be applied to any type:

feat(api)!: send an email to the customer when a product is shipped

Alternatively, including BREAKING CHANGE in the footer achieves the same effect.

Multi-line Body and Footer

A commit with a multi-line body and footer:

fix: prevent racing of requests

Introduce a request id and a reference to latest request. Dismiss
incoming responses other than from latest request.

Remove timeouts which were used to mitigate the racing issue but are
obsolete now.

Reviewed-by: Z
Refs: #123

Full Specification

The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

• Commits MUST be prefixed with a type, which consists of a noun, feat, fix, etc., followed by an OPTIONAL scope, an OPTIONAL !, and a REQUIRED terminal colon and space.
• A feature implementation MUST use the feat type.
• A bug fix MUST use the fix type.
• A scope MAY be provided after a type. A scope MUST consist of a noun describing a section of the codebase surrounded by parenthesis, e.g., fix(parser):
• A description MUST immediately follow the colon and space after the <type>(<scope>) prefix.
• A longer commit body MAY be provided after the short description, MUST begin one blank line after the description.
• One or more footers MAY be provided one blank line after the body. Each footer MUST consist of a word token, followed by either a :<space> or <space># separator.
• A footer’s token MUST use - in place of whitespace characters (e.g., Acked-by). The exception is BREAKING CHANGE, which MAY also be used as a token.
• A breaking change MUST be indicated in the type/scope prefix with a !, or as a footer BREAKING CHANGE: <description>.
• If ! is used, BREAKING CHANGE: MAY be omitted from the footer, and the description SHOULD be used to describe the breaking change.
• Types other than feat and fix MAY be used, e.g., docs: updated ref docs.
• Tools that implement the Conventional Commits specification MUST NOT treat the units of information as case-sensitive, with the exception of BREAKING CHANGE which MUST be uppercase.
• BREAKING-CHANGE MUST be synonymous with BREAKING CHANGE when used as a footer token.