Git Fundamentals

Git is the distributed version control system behind nearly all modern software. It tracks every change, lets teams work in parallel on branches, and preserves a complete history you can navigate, undo, and recover from. Fluency in Git is one of the highest-leverage skills a developer can have.

Most day-to-day Git is a handful of commands. The parts that trip people up — merge vs rebase, undoing changes safely, recovering "lost" work — are worth understanding properly, because that's where mistakes get expensive.

TL;DR

• Work on feature branches; keep main stable and releasable.
• Write meaningful commit messages and commit in logical chunks.
• Pull before push; never rebase shared/public branches.
• Prefer --force-with-lease over --force, and use .gitignore.

Quick Example

The everyday loop — stage, commit, push to a feature branch:

Core Concepts

• Commit — a snapshot of your changes with a message and parent.
• Branch — a movable pointer to a line of development.
• Staging area — what you've marked (git add) to go into the next commit.
• Remote — a shared copy (e.g. on GitHub) you push/pull against.

Branching

Merging vs Rebasing

On conflict: edit the marked files, git add them, then git commit (merge) or git rebase --continue. Bail out with git merge --abort / git rebase --abort.

Remotes

Undoing Changes

💡 On a shared branch, prefer git revert (adds an undo commit) over reset/history rewrites, so you don't disrupt others.

Stashing & Tags

Workflows

Feature branch (most teams): branch from main, commit, push, open a pull request, review, merge, delete the branch.

Gitflow: long-lived main + develop, with feature/*, release/*, and hotfix/* branches — heavier, suited to scheduled releases.

Trunk-based: short-lived branches merged to main frequently, often behind feature flags — favored for continuous delivery.

Recovery & Investigation

Best Practices

• Small, focused commits with clear messages (what and why).
• Short-lived feature branches merged via pull requests.
• git pull (or --rebase) before pushing to avoid surprise conflicts.
• .gitignore build output, dependencies, and secrets — never commit .env.
• Use Git LFS for large binaries.

Common Mistakes

Committing a secret

Force-pushing over shared work

FAQ

Merge or rebase?

Merge preserves true history and is safe on shared branches; it adds a merge commit. Rebase rewrites your commits onto a new base for a clean, linear history — great for tidying your own branch before merging. The golden rule: never rebase a branch others are working on.

How do I undo a commit?

To keep the changes but undo the commit, git reset --soft HEAD~1. To discard them, git reset --hard HEAD~1 (local only). To undo a commit that's already pushed/shared, use git revert <sha>, which records a new commit that reverses it without rewriting history.

I lost work / deleted a branch — can I recover it?

Usually yes. git reflog records where HEAD has been, including "lost" commits and deleted branches. Find the SHA and git switch -c recovered <sha>. Git rarely truly deletes commits until garbage collection runs.

How do I remove a secret from history?

Deleting the line isn't enough — it stays in history. Rotate the secret immediately (assume it's compromised), then scrub history with git filter-repo (or the BFG Repo-Cleaner) and force-push. Rotation is the real fix; history rewriting is cleanup. See Secrets Management.

What's git bisect for?

Finding the commit that introduced a bug via binary search. You mark a known-good and known-bad commit; Git checks out the midpoint for you to test, and you mark each good/bad until it pinpoints the culprit.

Related Topics

• CI/CD Pipelines — Triggered by Git events
• GitHub Actions — Automation on Git workflows
• Secrets Management — Keeping secrets out of history
• DevOps — Where Git fits in delivery

References

• Pro Git (free book)
• Git — Reference
• Atlassian — Git tutorials
• git-filter-repo