Mastering Git on Loaay Waheed

Git Notebook - Part 2

Sat, 27 Sep 2025 23:21:06 +0300

Prerequisites

To keep in your pocket

git commit --amend –> changes the last commit msg

git reset --soft HEAD~1 –> remove last commit but keep changes staged

Chapter 1 | fork

fork is a copy of a repo to your repos

on github instead of creator/megacorp to luvimsan/megacorp
using gh cli gh repo fork

PRs from a fork

can be seen as a merge of branch with permission in the remote

[!NOTE] the standard way to contribute to someone else’s open-source project

Fork their repo into your account

Clone your fork to your local machine

Create a new branch (let’s call it your_feature)

Make changes

Commit and push changes to your fork’s remote your_feature branch

Create a pull request to original_owner/repo main from your_username/repo your_feature

Chapter 2 | reflog

git reflog –> like git log but stands for “reference log”

format of a reflog

reflog	meaning
HEAD@{0}	where HEAD is now
HEAD@{1}	where HEAD was 1 move ago
HEAD@{2}	where HEAD was 2 move ago
HEAD@{3}	where HEAD was 2 move ago
…	…

HEAD is a reference to the branch you’re currently on.

Usage of reflog

reflog can be used to rescue a commit has been removed

git reflog to get commit hash
git cat-file -p commit
traverse till get the content of the commit

[!NOTE]

a better way of rescuing a commit will be like this

git merge commitish

or git merge HEAD@{1}

Chapter 3 | Merge conflicts

when two branches modify the same part since their common merge base

merging and rebasing is the common way of making conflicts
git modify the conflicted file with both changes separating them with » « ==

[!EXAMPLE]

first_name,last_name,company,title
 <<<<<<< HEAD (branch im in) (ours)
 karson,yummy,intercooler,ceo
 ======= (end)
 jayson,gross,htmz,contributor
 >>>>>>> main (the other branch) (theirs)

“ours” –> refers to the branch we are on (merging into)
“theirs” –> refers to the branch being merged
git merge their_branch

Checkout conflict

This will resolve a conflict without the need to edit the conflicted file

git checkout --theirs path/to/file

--ours will overwrite the file with the changes from the branch you are currently on and merging into
--theirs will overwrite the file with the changes from the branch you are merging into the current branch

Chapter 4 | Rebase conflicts

[!NOTE] rebase rewrites history which sometimes may be dangerous But it provies linear history, easier for reverting

git rebase main

it switch to the source branch main
replays the commits from target branch im in feat
it has a diff state called rebasing state

in conflict

ours means the source branch main
theirs means the target branch feat
git add . && git rebase --continue

RERERE to the rescue

The git rerere functionality is a bit of a hidden feature. The name stands for “reuse recorded resolution” and, as the name implies, it allows you to ask Git to remember how you’ve resolved a hunk conflict so that the next time it sees the same conflict, Git can resolve it for you automatically.

Recorded preimage for 'customers/favs.md'
Recorded resolution for 'customers/favs.md'
Resolved 'customers/favs.md' using previous resolution

Accidental commit after rebase

If you accidentally commit the resolution of a rebase conflict, just:

git reset --soft HEAD~1

The –soft flag will keep your changes, and just undo the commit.
Then you can simply --continue the rebase as normal.

Chapter 5 | Squash

To squash some commits in one commit

git rebase -i HEAD~n i : interactive n : number of commits to squash change pick –> s, squash

[!NOTE] Why Does Rebase Squash? Remember, rebase is all about replaying changes. When we rebase onto a specific commit (HEAD~n), we’re telling Git to replay all the changes from the current branch on top of that commit. Then we use the interactive flag to “squash” those changes so that Rebase will apply them all in a single commit

NOTES:

never squash on main branch
- squash on a feat branch
the purpose of squash is to allow you to make lots of commits and then leave the important ones and squash the other in a signle commit

Chapter 6 | Stash

Definition: Temporarily saves uncommitted changes and reverts the working directory to match the latest commit (HEAD). Command: git stash

stash stores the changes in a stack (LIFO) –> get the most recent changes first

git stash list example stash@{0}: On main: bad marketing stash@{1}: On main: good marketing

useful flags

git stash list –> (list all the stashes)
git stash pop –> (applay the most recent stash entry to the working directory)
git stash apply –> Apply a specific stash without deleting it
git stash drop –> Delete a stash without applaying
git stash -m 'message' –> multiple staashes with message

Chapter 7 | Revert

Definition: it’s a commit that remove another commit by replaying it in reverse and keep the full history of the change and the undoing Command: git revert commit-ish

git reset vs git revert

Mostly personal branches: git reset –soft: Undo commits but keep changes staged git reset –hard: Undo commits and discard changes

Mostly public branches: git revert: Create a new commit that undoes a previous commit

Chapter 8 | Cherry Pick

Definition: a way to pick a commit or a range of commits from a branch to add to another branch without getting all the commits (if merging and rebasing is not needed) Command: git cherry-pick commit-ish

workflow

release has a b c commits
main has a b c d g h n
- instead of getting all the commits from main to release
we can just cherry-pick g commit and added to release

Chapter 9 | Bisect

a way to find where a change or a bug was introduced using binary search in O(log n)

how to bisect

start with git bisect start
select bad commit git bisect bad {commit-ish} or just git bisect bad for the current commit
select good commit with git by git bisect good {commit-ish}
Git will checkout a commit between the good and bad commits for you to test to see if the bug is present
Execute git bisect good or git bisect bad to say the current commit is good or bad
Loop back to step 4 (until git bisect completes)
Exit the bisect mode with git bisect reset

Automated bisect script

instead of selecting bad and good we can make a script to automate that such that
–> return 0 when it’s a good commit
–> return 1-127 except 125 when it’s a bad commit

if grep -q "SCANNING" "scripts/scan.sh"; then
    exit 1
else
    exit 0
fi

using this command git bisect run ./script.sh

Chapter 10 | Worktrees

A worktree in git is an additional working directory linked to the same Git repository.

[!NOTE] main worktree all that time we was working with the main working tree that was created by git-init or git-clone

all stored at .git/worktrees directory

pros

checkout multiple branches at the same time
no need for git commands just two directories each has it’s own branch
replace the continous stashing

cons

no duplicate branches

syntax

add –> git worktree add {path} {branch_name}

example -->   `git worktree add ../ultracorp` // using same worktree name for branch

list –> git worktree list

remove –> git worktree remove {path}

prune (remove the directory) –> git worktree prune

Chapter 11 | Tags

an immutable pointer to a specific commit

[!INFO] unlike branches tags can be created and deleted, but not modified

Syntax

list –> git tag create –> git tag {name}

flags name (-a) –> git tag -a {name} //default first parameter msg (-m) –> git tag -a {name} -m {msg}

push –> git push --tags

Semver

semver stands for “Semantic Versioning” for versioning software

two primary purposes:

To give us a standard convention for versioning software
To help us understand the impact of a version change and if it’s safe (how hard it will be) to upgrade to

v3.12.5

3 –> MAJOR (breaking changes)
12 –> MINOR (safe features)
5 –> PATCH (fafe bug fixes)

[!NOTE]

MAJOR increments when we make “breaking” changes (this is typically a big release, for example, Python 2 -> Python 3)

MINOR increments when we add new features in a backward-compatible manner

PATCH increments when we make backward-compatible bug fixes

References

Git course on boot.dev by The Primeagen

Git Notebook - Part 1

Sat, 13 Sep 2025 21:25:01 +0300

Chapter 1 | Introduction

Git is the distributed version control system (VCS). Nearly every developer in the world uses it to manage their code. It has quite a monopoly on VCS. Developers use Git to:

Keep a history of their code changes
Revert mistakes made in their code
Collaborate with other developers
Make backups of their code

Overview about the contents:

Porcelain: (most used)

git status
git add
git commit
git push
git pull
git log

Plumbing

git apply
git commit-tree
git hash-object

Chapter 2 | git repository (core concepts)

4 states:

Working Directory or “working tree”
- The actual filesystem
- Stored in desk
- by editing the file
Index (Staging Area)
- A snapshot of what you plan to commit
- Stored in .git/index
- by git add file (from tree to index)
Repository (Commits, HEAD)
- The database of snapshots
- Stored in .git/objects
- by git commit (from index to local repo)
Remote Repository
- a remote repo
- Stored mostly on the cloudin (github, gitlab …)
- by git remote add (from local to remote)

States of Changes

Untracked: file exists in working tree but not in index.
Modified (unstaged): file changed in working tree, not yet staged.
Staged: change recorded in index, waiting to be committed.
Committed: change saved permanently into the repo as a commit object.

Chapter 3 | git internals (Git’s Four Object Types)

Inside .git/objects/, Git stores content-addressed objects. The key is the SHA-1 hash of the content (with a header). There are four object types:

Blob

What it is: File contents (binary or text).
Internals: Stored as “blob and hashed with SHA-1.
Mental model: “Just the contents of one file, nothing else (no metadata).”

Tree

What it is: Directory (list of entries).
Mental model: “A folder structure mapping names → blobs/trees.”

Commit

What it is: Snapshot pointer.
Internals: Stores the SHA0 of a tree (root directory snapshot), parent commits, author, message.
Mental model: “A node in the history graph pointing to a tree.”

What it is: Named pointer to a commit (sometimes with extra metadata).

Chapter 4 | git config

git config <action> <scope> <section.key> "value"

action: –add, –list, –get, –unset, –unset-all, –remove-section
scope: –global, –local
section: user.name, user.email, init.defaultBranch
value: main, master

Chapter 5 | git branches

A branch is just a named pointer to a specific commit

Git Branch

git branch → list branches
git branch <name> → create branch
git branch -m <oldname> <newname> → change branch’s name

Git switch

git switch <name> → switch to branch
git switch -c <name> → create + switch
git branch -d <name> → delete branch

Chapter 6 | git merge

A process to merge the two branches with a merge commit

A - B - C - F    main
     \     /
      D - E      other_branch

git merge other_branch → in main branch

Chapter 7 | git rebase

git rebase stands for changing the base commit of two branch hence the name re-base

from this

A - B - C    main
   \
    D - E    feature_branch

A - B - C         main
         \
          D - E   feature_branch

[!HINT]

always rebase

squash to a single commit

revert when needed

[!IMPORTANT] Rebase your work onto others’ work → OK.
Your feature branch rebased onto main.}

git rebase main –> Rebase others’ work onto your work → Bad.

git rebase feature –> {Public branch rebased onto your feature.}

Chapter 8 | git reset

git reset <action> commit-ish

action: –soft, –mixed, –hard
commit-ish : commit-hash, HEAD~n

HEAD~ or HEAD~1 –> commit before this one

HEAD~2 -> two commits before

Git reset internals

1- all three modes do the exact same first step 2- move HEAD to the target commit

flags tell git what to do with (index, working directory)

git reset --soft

staging area: preserved, All differences between your old commit and the target commit are placed here
working directory: untouched
All the changes from the deleted commits are instantly placed right back into your Staging Area.
Use case: Squashing or editing recent commits without losing your work.

git reset --hard

staging area: wiped to match target commit
working directory: overwritten to match target commit -> wipes the staging area, overwrites your working directory to match target commit -> it only overwrites only unstaged but (untracked will not be touched)

Use case: Nuclear option to discard bad experiments and return to a known state.

git reset --mixed

wipes the staging area to match target comit
working directory: untouched, diff will be in unstaged state

Example:

main: A -> B -> C -> D

HEAD:                ^

if … is used:

git reset --hard HEAD~2 – goes to b (b commit-hash can be used)

-> C, D commit is gone (not forever “reflog”)
-> like you have just commit B

if you have staged and unstaged changes. you can’t recove it at all
but if they are commited git reflog may help you

git reset --soft HEAD~2 – goes to b (b commit-hash can be used)

-> C, D changes are staged in the index
-> like you have made all thea changes in c, d and only add them to index

git reset --mixed HEAD~2 – goes to b (b commit-hash can be used)

-> C, D changes are unstaged in the index
-> like you have made all thea changes in c, d and never added them to index

Chapter 9 | git remote

git remote <action> <name> <uri> action: add, rename, remove uri(uniform resource identifier): urls, relative path

Remote is just another repo that has branches

git fetch: downloads commits and updates remote-tracking branches does not change the current branch or working files.

git merge: merging branches between local ******

Chapter 10 | Github

[!EXAMPLE] git remote add origin git@github.com :userName/repoName // ssh
git remote add origin https://github.com/userName/repoName // https

git ls-remote: to list the rmeotes

git push

git push <remote-repository> <local-branch>

git push sends local changes to any “remote”

[!EXAMPLE] git push -u origin main
to push from current branch from local –> origin/main {remote}/{branch}
-u set the upstream between remote and local repos

Alternative Options

git push origin <localbranch>:<remotebranch>

git push origin main:main
push my main local to origin main
push with diff name: git push origin main:feature-grid
delete remote branch:
- git push origin :old-feature
- git push origin –delete old-feature

git pull

git pull [<remote>/<branch>] git-pull - Fetch from and integrate with another repository or a local

pull request

pull request is a way to propose changes, typically to the rest of your team,
or to the maintainer of a project you’re contributing to.

merge branches in remote

merges branches in remote: (by pull request)

Base: main <– compare: branch

git restore

discarding unstaged changes: git restore file unstaging a file: git restore --staged file

Chapter 11 | gitignore

a file named .gitignore that gives instruction to git internals on which to track

[!NOTE]

can be at root or in a specific folders

nested gitignore only applies to the directory it’s in and its subdirectories.

.git/info/exclude is local gitignore that doesn’t need to be commited

order matters in a .gitignore so be careful

pattern

a test rule with wild cards, let’s go over them

* –> anynumber of characters *.log
\ –> anchorying to the root directory not any sub \main.py
! –> negating an existing ignore *.txt !important.txt
# –> commenting any text # idk

[!IMPORTANT] some rules of thumb for coding projects:

Ignore things that can be generated (e.g. compiled code, minified files, etc.)

Ignore dependencies (e.g. node_modules, venv, packages, etc.)

Ignore things that are personal or specific to how you like to work (e.g. editor settings)

Ignore things that are sensitive or dangerous (e.g. .env files, passwords, API keys, etc.)

References

Git course on boot.dev by The Primeagen