Git Cracked: A Complete guide to Git and Github

johgr2585 0 views 8 slides Oct 10, 2025
Slide 1
Slide 1 of 8
Slide 1
1
Slide 2
2
Slide 3
3
Slide 4
4
Slide 5
5
Slide 6
6
Slide 7
7
Slide 8
8

About This Presentation

This book is a complete guide to git and github usage in day to day bases as a developer


Slide Content

Contents
Preface 1
Who this book is for. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2
How to use this book. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2
1. The Git Mental Model 2
2. Installing and First-Time Setup 3
3. Recording Changes Effectively 3
4. Branching Basics 3
5. Integrating Work: Merge vs Rebase 4
6. Remotes and Collaboration 5
7. Stashing, Cleaning, Maintenance 5
8. Exploring and Understanding History 6
9. Advanced Workflows 6
10. Git Internals, Briefly 6
11. File Formats and Hooks 7
12. Troubleshooting and Recovery 7
Appendix A: Command Quick Reference 7
Appendix B: Glossary (selected) 8
title: ”Cracking Git: from Noob to Ninja” subtitle: ”A Professional guide to mastering Git
from first commit to advanced workflows” author: ”Godfrey Josiah” date: ”2025-10-01” lang:
en-US rights: ”CC BY 4.0” keywords:
•Git
•Version Control
•Collaboration
•Branching
•Rebase
•Merge
•Workflow geometry: margin=1in toc: true toc-depth: 2 colorlinks: true linkcolor: blue
mainfont: ”DejaVu Serif” monofont: ”DejaVu Sans Mono”
Preface
Git is the de facto version control system for software projects of every size. This book takes
you from first principles to advanced workflows. It is narrative and practical: you will learn
the mental model, practice with small exercises, and understand why commands behave the
way they do.
1

Tip: You can read linearly, chapter by chapter, or jump to a chapter relevant to your current
need. Figures provide visual anchors you can revisit.
Who this book is for
•Developers learning Git for day-to-day work
•Team leads standardizing workflows
•Power users who want to understand internals and make Git work for them
How to use this book
•Skim the figures first for the big picture
•Type the examples in a scratch repository
•Keep the glossary handy and use the reference chapters as a toolkit
1. The Git Mental Model
At its core, Git manages snapshots of your project (commits) connected in a graph (a Directed
Acyclic Graph, or DAG). You edit files in your working directory, select changes into the stag-
ing area (index), and record them into the repository as commits.Working Directory Staging Area (Index) Repository
git add git commit
git restore --stagedgit restore
{#fig-
lifecycle width=100%}
Key ideas:
•Working directory: your checked-out files
•Staging area (index): a preview of exactly what will become the next commit
•Repository: your commit history plus supporting metadata (branches, tags)
•HEAD: your current position in the commit graph (usually the tip of a branch)
Practice:
1)Make a new directory and initialize it withgit init. Add a file, stage it withgit add,
then commit with a message. Observe how the file appears in each stage (working →
index → repo).
2)Modify the same file and comparegit status,git diff, andgit diff --staged.
2

2. Installing and First-Time Setup
Before your first commit, configure identity and defaults:
•git config --global user.name "Your Name"
•git config --global user.email "[email protected]"
•git config --global init.defaultBranch main
•Optional editor:git config --global core.editor "code --wait"
•Global ignore file: create ~/.gitignore_global and setgit config --global
core.excludesfile ~/.gitignore_global
Cloning and initializing:
•New project:git initthen add files → stage → commit.
•Existing project:git clone <url>.
Help on any topic:git help <command> orgit <command> --help.
3. Recording Changes Effectively
Great commits tell a story your teammates can follow. Aim for small, focused commits with
meaningful messages.
Workflow:
1)Edit files →git statusto see what changed
2)Review diffs →git diff(unstaged),git add -pfor interactive staging
3)Commit →git commit -m "Summarize the change"
Message style:
•Subject line in imperative mood, ≤ 72 chars
•Body: what changed, why it was needed, any side-effects or follow-ups
Common tools:
•Undo staged changes:git restore --staged <path>
•Restore a file from HEAD:git restore <path>
•Rename/move: git mv old new
4. Branching Basics
Branches are named pointers to commits. They allow parallel lines of development.
•Create:git branch feature/login orgit switch -c feature/login
•Move (checkout):git switch feature/login (preferred) orgit checkout feature/login
•List:git branch --show-current andgit branch --all
•Tag stable points:git tag v1.0.0
3

main
feature/login
merge {#fig-
merge width=100%}
Guidelines:
•One topic per branch
•Keep branches short-lived; merge or rebase frequently to avoid drift
5. Integrating Work: Merge vs Rebase
Merging combines histories, possibly creating a merge commit. Rebase replays your commits
onto a new base, producing a linear history.
Merge when:
•You want to preserve the true history of how branches came together
•The feature had parallel work and the merge documents that context
Rebase when:
•You want a clean, linear history (especially before pushing a feature branch)
•The branch is private and you can rewrite it safelyBefore
main
feature
Rebase
git rebase main
After
main feature (rebased)
{#fig-
rebase width=100%}
Conflict handling:
1)During merge or rebase, files may conflict
4

2)Open conflicted files, resolve markers, stage resolutions
3)Continue:git merge --continue orgit rebase --continue
Rolling back:
•Abort:git merge --abortorgit rebase --abort
•Undo a bad merge commit on main with a new inverse commit: git revert -m 1 <merge-
sha>
6. Remotes and Collaboration
Remotes let you share and synchronize work. The default upstream is often named origin.
•Add:git remote add origin <url>
•Inspect:git remote -v
•Fetch without changing your working branch: git fetch(updatesorigin/*)
•Pull changes into the current branch:git pull --ff-only orgit pull --rebase
•Push:git push -u origin main (sets upstream for futuregit push)Local
main
origin (Remote)
origin/main
git fetch
git push
{#fig-
remote width=100%}
Branch tracking:
•A local branch can have an ”upstream” branch; thengit pullandgit pushknow where
to sync
•See upstream:git branch -vv
Review and integration:
•Use Pull Requests for review; ensure commits are clean and messages explain the why
•Prefer fast-forward merges for simple branches, or merge commits to keep context
7. Stashing, Cleaning, Maintenance
Temporary shelving:git stash push -m "WIP: refactor" then latergit stash pop.
Working tree cleanup:
•List what would be removed:git clean -nd
•Actually remove untracked files:git clean -fd
5

Repository health:
•Prune unreachable objects:git gc(auto most of the time)
•Periodic maintenance:git maintenance run --task=gc --task=pack-refs
8. Exploring and Understanding History
Reading history:
•Summaries:git log --oneline --graph --decorate --all
•Deep dive:git show <sha>
•Who changed what and when: git blame <file>(use with empathy)
Searching:
•In history:git log -S <string> orgit log -G <regex>
•In working tree:git grep <pattern>
Bisecting regressions:
1)git bisect start
2)git bisect bad(current broken revision)
3)git bisect good <sha> (a known good revision)
4)Test each suggested commit until Git identifies the first bad one
9. Advanced Workflows
•Patch series:git format-patchandgit am
•Cherry-pick selective commits across branches:git cherry-pick <sha>
•Worktrees for parallel checkouts:git worktree add ../build main
•Submodules: nest repos; pin external dependencies to exact commits
10. Git Internals, Briefly
Objects:
•Blob: file contents
•Tree: directory listing mapping names to blobs/trees
•Commit: points to a tree (snapshot), parents, author, message
•Tag: a named, optionally signed pointer
References (refs): branches and tags are human-readable names that point to commits. HEAD
points to your current branch (symbolic ref) or directly to a commit in a detached state.
Reflog: a local history of where HEAD and branch tips have pointed. It lets you recover from
mistakes.
6

mainfeature
HEAD → main {#fig-
dag width=100%}
11. File Formats and Hooks
•.gitignore: declare what not to track (patterns)
•.gitattributes: per-path behaviors (e.g., text normalization, merge drivers)
•.gitmodules: submodule configuration
•mailmap: unify author names/emails for history rendering
•Hooks: scripts triggered by Git events (pre-commit, pre-push, etc.)
12. Troubleshooting and Recovery
Common scenarios and antidotes:
•I committed to the wrong branch → create a new branch at that commit, reset the original
branch to its previous tip
•I rewrote history that was already pushed → coordinate with teammates; usually prefer
git revertto repair public history
•I lost a commit → search the reflog:git reflog, thengit branch rescue <sha>
Safety checklist:
•Prefer--ff-onlypulls on protected branches
•Use branch protection on the server
•Avoid rebasing public branches; rebase private topic branches freely
Appendix A: Command Quick Reference
•Create:git init,git clone
•Stage/commit:git add,git commit,git restore,git rm,git mv
•Inspect:git status,git diff,git log,git show,git blame
•Branching:git branch,git switch,git checkout,git tag
•Integrate:git merge,git rebase,git cherry-pick,git revert
•Remote:git remote,git fetch,git pull,git push
7

•Maintenance:git stash,git clean,git gc,git fsck
Appendix B: Glossary (selected)
•Branch: named pointer to a commit
•Commit: recorded snapshot with metadata and parent(s)
•Fast-forward: moving a branch pointer forward without creating a merge commit
•HEAD: current position; typically the tip of the checked-out branch
•Index: staging area; the next commit’s exact contents
•Rebase: rewriting a branch to start from a different base
•Reflog: local log of ref changes; enables recovery
•Remote-tracking branch: local read-only pointer of a branch on a remote (e.g., ori-
gin/main)
•Tag: named pointer (often for releases)
8