Git is a distributed version control system that tracks changes to files over time. Every clone holds the full history, not just the latest snapshot. You commit, branch, and inspect history entirely offline.

Centralized systems like Subversion or CVS keep the whole history on one server. Your working copy is thin. Most operations need a network round trip, and the server is a single point of failure.

That distribution changes daily work. Branching is cheap and local, so you experiment freely. If the server dies, any clone can restore the project. The cost is a steeper mental model: you juggle local and remote state, and pushing is a separate deliberate step.

GitHub hosts your repositories on the web, while Git is the software that tracks changes on your machine. They are often confused but do different jobs.

Git handles commits, branches, and history locally. GitHub stores a copy of your repository remotely and adds pull requests, issue tracking, access control, and code review. GitLab and Bitbucket play the same role.

The distinction matters because people blur them. You can use Git alone with no account anywhere, pushing to a plain server. You can also swap GitHub for a competitor without touching a single Git command. Treating pull requests as a Git feature, when they are really GitHub's addition, leads to confusion about what each layer provides.

The staging area, also called the index, is a middle layer between your working files and committed history. When you run git add, you copy a file's current state into staging. A commit then records exactly what is staged, nothing more.

Git separates it so you control what each commit contains. You might edit five files but commit only two related ones. You can even stage part of a file with git add -p, splitting messy work into clean commits.

The cost is one more step to remember. Beginners forget to stage and wonder why a commit missed their edits. The payoff is deliberate, reviewable history instead of dumping every change together.

Run a soft reset to move the branch back one commit while keeping your edits in place.

git reset --soft HEAD~1        # commit undone, changes stay staged
git commit -m "better message" # recommit cleanly

The commit disappears from history, but every file change stays exactly as it was. Soft leaves them staged, ready to recommit. Swap in --mixed if you want them unstaged instead, back in the working directory.

This is the fix when you committed too early, wrote a bad message, or forgot a file. Avoid --hard here, because that throws the work away, which is the one thing you are trying not to do. If you already pushed, reach for git revert or a follow-up commit instead; reset and amend both rewrite shared history.

Use merge when you want to preserve the true shape of history, and rebase when you want a clean straight line. Both combine work from two branches; they just record it differently.

Merge creates a new commit that ties two branch tips together. Nothing moves, so the record stays honest about when work diverged. Rebase instead replays your commits on top of the other branch, as if you had started from its latest state.

A simple rule works well. Rebase your own local branch to tidy it before sharing. Merge when combining branches other people already pulled. The danger is rebasing shared commits, which rewrites history others depend on and creates painful duplicates. When unsure, merge is the safer default.

Stay calm; a conflict just means Git could not decide between two edits to the same lines. Nothing is broken, and nothing is lost.

Work through it in order:

• Run git status to see which files conflict.
• Open each one and find the <<<<<<<, =======, >>>>>>> markers.
• Edit the region to the correct final result, deleting all three markers.
• Stage the fixed file with git add.
• When every file is done, run git commit to finish the merge.

The mistake people make is leaving a marker behind or picking one side blindly. Read both versions and keep what the code actually needs. If it goes wrong, git merge --abort returns you to the state before you started, so you can retry fresh.

Fetch downloads new commits from the remote but leaves your working branch untouched. Pull does the same download, then immediately merges those commits into your current branch.

Think of fetch as looking before you leap. It updates your remote-tracking branches, like origin/main, so you can inspect what changed with git log or a diff. Your own work stays exactly where it was.

Pull is the convenience combo: git fetch followed by git merge in one command. It is faster for routine updates but can surprise you with an unexpected merge or conflict mid-task. Many people fetch first, review the incoming changes, then decide whether to merge or rebase. That habit avoids pulling half-finished work on top of your own.