Manage your source code like a pro with best version control system!

Git Vojtěch Mareš

Vojtěch Mareš | vojtech@mares.cz

Download installer from https://git-scm.com or use package manager.

brew install git

# Debian/Ubuntu
apt install git
# Fedora and RHEL-family
dnf install git
# Alpine
apk add git

choco install git

I prefer global configuration (using --global) stored in your home directory applied to all repositories, the global config is located at ~/.gitconfig.

You can configure just one repo, you can call git config from you repository with flag --local. Or edit .git/config file.

git config --global user.name "Vojtěch Mareš"
git config --global user.email "vojtech@mares.cz"

To ensure the authenticity of commits and prove that the author is actually the author and that the commits are not spoofed, consider signing commits with GPG or SSH.

GPG commit signing:

# Tell Git, which GPG key to use
git config --global user.signingkey <key>
# Which program to use to sign commits and tags
git config --global gpg.program gpg
# Sign commits and tags
git config --global commit.gpgsign true
git config --global tag.gpgsign true

SSH commit signing:

# Tell Git to use SSH to sign commits and tags
git config --global gpg.format ssh
git config --global user.signingkey /PATH/TO/.SSH/KEY.PUB # Path is usually ~/.ssh/id_rsa.pub or id_ed25519.pub (depending on SSH key algorithm)

Signed-off-by:

From Git docs:

Add a Signed-off-by trailer by the committer at the end of the commit log message. The meaning of a signoff depends on the project to which you’re committing. For example, it may certify that the committer has the rights to submit the work under the project’s license or agrees to some contributor representation, such as a Developer Certificate of Origin. (See https://developercertificate.org for the one used by the Linux kernel and Git projects.) Consult the documentation or leadership of the project to which you’re contributing to understand how the signoffs are used in that project.

git commit -s
git commit --signoff

WARNING: Apply only if you want to use rebase workflow!

git config --global pull.ff only
git config --global merge.ff only
git config --global pull.rebase true

Git use by default Vim or editor from EDITOR environment variable. If you want to use different editor, you can configure it.

git config --global core.editor emacs

You can use GUI editors like VS Code too:

git config --global core.editor "code --wait"

See Associating text editors with Git on GitHub Help to use your editor on your platform.

If you want to see your branch in terminal prompt you have to use git-prompt.sh.

It works on Unix (ZSH & Bash). If you use Windows, it works by default in Git Bash and there is no way how add it into CMD or PowerShell.

Install On Unix:

wget https://github.com/git/git/raw/master/contrib/completion/git-prompt.sh
mv git-prompt.sh ~/.git-prompt.sh
echo ". ~/.git-prompt.sh " >> ~/.bashrc

You have to add __git_ps1 to your PS1 variable.

Bash Example:

export PS1="033円[01;32m\]\u@\h\[033円[00m\]:\[033円[01;34m\]\w\[033円[00m\]$(__git_ps1)\$ "

Save it to .bashrc:

echo 'export PS1="033円[01;32m\]\u@\h\[033円[00m\]:\[033円[01;34m\]\w\[033円[00m\]$(__git_ps1)\$ "' >> ~/.bashrc

https://ohmyz.sh/

Git plugin is enabled by default, no need to configure anything. It is ready to go.

Maybe configure a theme of your own choosing or create your own to suit all your wishes.

You can create own git aliases:

git config --global alias.<alias> <command>

Examle:

git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.cm commit
git config --global alias.st status

Usage of aliases is git co for git checkout, git cm for git commit, ...

Those aliases work on every platform (even Windows).

Saved inside global git config ~/.gitconfig

[alias]
 fetch = fetch -p
 f = fetch -p
 m = merge
 mom = merge origin/master
 p = push
 pf = push --force-with-lease
 st = status -s
 sts = status
 cm = commit
 cma = commit --amend
 fixup = commit --fixup
 unstage = reset HEAD
 br = branch
 co = checkout
 rh = reset --hard
 rs = reset --soft
 stash = stash --keep-index
 wip = !git add $(git rev-parse --show-toplevel) && git commit -m WIP
 su = submodule update --recursive
 df = diff
 dfc = diff --cached
 dfs = diff --staged
 l = log --graph --decorate --pretty=oneline --abbrev-commit
 ll = log --graph --decorate --pretty=oneline --abbrev-commit --all
 ld = log -p
 ls = log --stat
 test = push -f origin HEAD:test
 selenium = push -f origin HEAD:selenium
 stats = shortlog -n -s --no-merges
 review = !git ld 1ドル..HEAD --reverse
 rmb = !sh -c 'git push origin :1ドル' -
 rb = rebase
 rbi = rebase -i
 rbc = rebase --continue
 rba = rebase --abort
 rbs = rebase --skip
 rbo = rebase --onto
 rbom = rebase origin/main
 rbiom = rebase -i origin/main
 cp = cherry-pick
 optimize = !git prune && git gc --aggressive && git repack -a && git prune-packed
 fml = !git commit -m \"$(curl -s whatthecommit.com/index.txt)\"
 gone = "!git fetch --prune && git for-each-ref --format '%(refname) %(upstream:track)' refs/heads | awk '2ドル == \"[gone]\" {sub(\"refs/heads/\", \"\", 1ドル); print 1ドル}' | xargs git branch -D"

E.g.: git fml

You can configure git to ignore files (or paths) using the .gitignore file.

Example:

vendor
phpstan-local.neon
**/some-random-file.txt # file with such name will be ignored in every directory
log
temp
www/assets/dist

This goes hand to hand with .gitignore, just add an empty .gitkeep file to the directory you wish to keep.

touch directory-i-want-to-track-in-git/.gitkeep

A few years ago, GitHub and GitLab moved from master to main as the default branch. If you create a repository locally, configure Git to create correct default branch to save you some time.

git config --global init.defaultBranch main
git config --global init.defaultBranch master

This is not a git feature, but is really help full.

EditorConfig! Do not forget to commit it. .editorconfig

Example:

root = true
[*]
indent_style = space
indent_size = 2
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true
end_of_line = lf
max_line_length = off

The most important are charset and end_of_line. Since git is sensitive to those and it is really great to unify this behavior, so you won't have to deal with such issues in the future, for example related to CRLF vs CR vs LF issues. Since this is a huge trouble when mixed.

I personally use and recommend insert_final_newline and trim_trailing_whitespace set to true. It also helps with unifying the file format.

insert_final_newline make diffs easier to read, since the previous line is not modified (added new line).

There is a VS Code extension and Jet Brains plugin.

Initialize empty (with no history) Git repository in current working directory.

git init

Clone a remote repository from remote server and work on it locally and then push changes back to the remote repository.

For more see Remote Repository (GitHub, GitLab).

git clone <URL> [<target dir>]
# Clone via HTTPS
git clone https://github.com/vojtechmares/git-training.git
# Clone via SSH
git clone git@github.com:vojtechmares/git-training.git

Show status of repository. See which files are edited or want to be committed.

git status

Show all untracked files in status

git status --untracked-files=all

Add file to next commit

git add <path>

Examples

git add index.html
git add .

You can use -p to switch into interactive mode and select part of changed file, which you want to commit.

git add -p <path>

You can see changes before git add or git commit.

See new changes in files managed by Git (not in new files):

git diff

If you want to see staged changes (added, prepared for commit), you have to use:

git diff --staged

Remove changes from next commit:

# Unstage all changes
git reset
# Unstage file
git reset -- <path>

Save prepared changes to repository:

Create commit from all staged changes:

git commit

Create commit form all changes (not new files):

git commit -a

Commit one file (not new files):

git commit <file>

Specify message in parameter instead of open vim:

git commit -m "<message>"

Combination of -a -m params:

git commit -am "<message>"

How to write commit messages: https://cbea.ms/git-commit/

Commit messages and their format are explored later in chapter Conventional Commits.

Update latest commit:

git commit --amend

Fixup:

git commit --fixup

Empty commit (no changes):

git commit --allow-empty

Show history of commits

git log
git log --oneline
git log --oneline --graph --all

Simple terminal history browser for Git

Mac

brew install tig

Linux

apt install tig

# only actual branch
tig
# all branches
tig --all

Graphic commit log. Distributed with Git.

# only actual branch
gitk
# all branch
gitk --all

If you have clonned repository, git clone has added configuration of repository.

Check it by:

git remote -v

and you will see:

$ git remote -v
origin git@github.com:vojtechmares-training/example-repository.git (fetch)
origin
 git@github.com:vojtechmares-training/example-repository.git (push)

If you've created repository by git init you see nothing.

To add remote repository, you have to use:

git remote add <name> <url>

For example:

git remote add origin git@github.com:vojtechmares-training/example-repository.git

Now you can push & share your code with collaborators. Check git remote -v.

If you want to rename remote repository, use:

git remote rename <name> <new name>

If you want delete remote, use:

git remote remove <name>

git fetch --prune && git for-each-ref --format '%(refname) %(upstream:track)' refs/heads | awk '2ドル == \"[gone]\" {sub(\"refs/heads/\", \"\", 1ドル); print 1ドル}' | xargs git branch -D

Or use an alias

[alias]
 # ...
 gone = "!git fetch --prune && git for-each-ref --format '%(refname) %(upstream:track)' refs/heads | awk '2ドル == \"[gone]\" {sub(\"refs/heads/\", \"\", 1ドル); print 1ドル}' | xargs git branch -D"

Use like any other alias

git gone

Push your commits to remote repository (GitHub).

# Push new branch to repository
git push <remote> <branch> -u
# Push commit
git push

Pull new commits from remote repository (GitHub).

git pull

Pull changes from remote repository without applying the changes.

git fetch

Git stash is used for temporarily postpone your changes to make your working directory clean.

That's required by some Git commands like git rebase, ... or sometimes for git checkout, git cherry-pick, ...

If you want to stash changes, use:

git stash

And check status using git status.

If you want to see, which files are stashed, use:

git stash show

If you want to see patch, add -p:

git stash show -p

If you want to apply stashed changes and remove stash, use:

git stash pop

And check git diff and git stash show.

If you have multiple stashes you work only with the latest.

List all stashes:

git stash list

If you want to specify other stash you can use stash@{0}. For example:

git stash show stash@{1}
git stash show -p stash@{1}

More about stash in offical documentation - https://git-scm.com/docs/git-stash

# Show local branches
git branch
# Show all branches (with the branches of remote repository - on GitHub)
git branch --all

# Create branch (and dont switch to it)
git branch <new_branch> [<branch_from>]
# Switch branch
git checkout <branch>
# Create branch and switch to it
git checkout -b <new_branch> [<branch_from>]
# Create branch with switch and switch to it
git switch -c <new_branch>

git checkout <branch>
# switch
git switch <branch>

Switch is new feature to Git, added after checkout.

Switch is designed only to switch between branches and/or create one. Meanwhile checkout can do more. Switch is here to do only one thing.

# Push commits to remote repository (GitHub)
git push <remote> <branch> -u
# Pull new commits to my branch
git pull

You can merge branches locally or on GitHub / GitLab using Pull / Merge Requests.

Merge commit on master Merge commit on branch

A Czech article from Ondrej Sika: https://ondrej-sika.cz/git/rebase/

Rebase on master

Reset HEAD (current brach) to specific state.

Set HEAD to specific state, but don't change files in working directory.

git reset <commit>

If you want also reset files, use --hard:

git reset --hard <commit>

For example, you want to remove last commit but want to keep changes:

git reset HEAD~1

See git status and git diff, files from last commit are now in changed.

If you want remove last commit with its changes, use:

git reset --hard HEAD~1

If you want to reset to upstream master

git fetch
git reset --hard FETCH_HEAD

And see (git status, git diff), no changes.

Create some demo commits:

touch A
git add A
git commit -m A
touch B
git add B
git commit -m B
touch C
git add C
git commit -m C
touch D
git add D
git commit -m D
touch E
git add E
git commit -m E
touch F
git add F
git commit -m F
touch G
git add G
git commit -m G
touch H
git add G
git commit -m H

You rewrite history, join commits, update messages, reorder commits, ...

git rebase -i <ref>

Example:

git rebase -i HEAD~6

Copy commit (ref) to actual HEAD.

git cherry-pick <ref>

Example:

git cherry-pick v1.0.x
git cherry-pick 47bdfb7

Reflog shows a history of refference. By default shows a HEAD. You can undo any git operations even reset.

git reflog

git reflog <branch>

Create tag:

git tag <tag> [<ref>]

Example:

git tag v1.0.0
git tag v1.0.0 HEAD~1
git tag v1.0.0 master
git tag v1.0.0 075615a

List tags:

git tag

Push tag:

git push <remote> <tag>

Example:

git push origin v1.0.0

Push all tags:

git push <remote> --tags

Example:

git push origin --tags

Delete tag (not recommended):

git tag -d <tag>

Example:

git tag -d v1.0.1

Delete tag from server:

git push <remote> :<tag>

Example:

git push origin :v1.0.2

See authors of actual code

git blame <file>

See authors of code in specific revision

git blame <rev> <file>

See only lines from 1 to 10

git blame -L 1,10 <file>

Clone repository with submodules:

git clone --recursive <repo_url>

If you have cloned repository without --recursive you have to:

git submodule update --init
# for nested submodules
git submodule update --init --recursive

Add submodule to repository:

git submodule init
git submodule add <submodule_repo_url> [<path>]

Add submodule and track specific branch:

git submodule add -b <branch> <submodule_repo_url> [<path>]

Update tracked branch:

git submodule set-branch --branch <branch> <path>

Update remote repository:

git submodule set-url <path> <newurl>

Update submodule from remote repository

git submodule update --remote

Pull changes & pull submodules

git pull --recurse-submodules

Execute command for each submodule:

git submodule foreach 'git reset --hard'
# including nested submodules
git submodule foreach --recursive 'git reset --hard'

Conventional Commits are an opinionated way of writing commit messages.

Each commit message should adhere the following format:

<type>[optional scope]: <description>
[optional body]
[optional footer(s)]

Breaking changes:

Breaking changes are marked with a [type] followed by exclamation (e.g. feat! or with scope refactor(api)!: remove v1).

Or within [body] with BREAKING CHANGE: string.

Commit message example:

refactor(api): remove v1
BREAKING CHANGE: This marks removal of REST API v1. Endpoints return **404 Not found** from now on.
[optional footer(s)]

Conventional Commits itself are quite minimalistic, common approach is to use something like Angular convention.

Type:

• feat - adding new features/functionality
• fix - fixing a bug
• refactor - refactoring existing code without a change of it's behavior (then it would be fix or feat)
• chore - no changes to the program (changes to editorconfig, updating dependencies (chore(deps)),...)
• docs - updating/adding to documentation including README
• build - changes to how program is build (e.g. Dockerfile)
• ci - GitHub Actions/GitLab CI/... changes to running tests, automated builds,...
• style - running a code formatter (go fmt, terraform fmt, Prettier,...)
• test - changes to program tests, but no changes to the program (e.g. faulty test)

Types mentioned above are adopted from the Angular convention.

Scope:

Scope is optional information, like context. Providing additional information from the commit message in simple and structured way.

Thanks to the Conventional Commits types, it is easy to programmatically determine (generate) next version for Semantic Versioning.

This eliminates debates on the topic of what the next version should be. But the Conventional Commits must be followed thoroughly.

That's all, thank you for your attention.

Questions?

Let's go for a beer 🍻.

• email: vojtech@mares.cz
• web: mares.cz
• x (twitter): @vojtechmares_
• linkedin: /in/vojtech-mares

Did you like the course? Tweet a recommendation on X (Twitter) and tag me (@vojtechmares_) and/or add me on Linked In and I will send you a request for recommendation. Thanks!