Git & Version Control.

Git is a distributed version control system, so every clone holds the whole history. Centralized systems like Subversion or CVS keep the history on one server, and each client holds a working copy of the current files.

Git's history is local. You can commit, read the log, and compare versions with no network.

The trade-off is that your commits stay private until you push, and teammates see them only after they fetch.

Git is the version control program on your machine, and GitHub is a service that hosts Git repositories online and adds tools around them.

It matters because Git works without GitHub. Your full history lives in .git on your disk, so you can work offline even when GitHub is down.

Switching hosts means pointing your remote, the address Git pushes to and fetches from, at a new URL. Git itself does not change, and hosts like GitLab or Bitbucket serve the same repositories.

The staging area, or index, is where you build your next commit. git add copies a file's current content into the index. git commit turns whatever is staged into the new commit.

The separation lets you choose what goes in: the fix, not the debug print. git add -p goes further and lets you pick single hunks of one file.

git add stages the content, not the file, so edits made after it stay out of the commit until you add them again.

git diff            # working files vs staging area
git diff --staged   # staging area vs last commit

git reset --soft HEAD~1 undoes the last commit and keeps the changes staged, ready to commit again. Reset moves the branch pointer back one commit. Your files on disk never change.

git reset --soft HEAD~1   # commit undone, changes stay staged
git reset HEAD~1          # same, but changes end up unstaged

The default mode, --mixed, keeps the work unstaged instead. The --hard mode throws away your edits, so avoid it here.

Reset only moves your local branch, so use git revert HEAD for a commit you already pushed. Revert adds a new commit that undoes the old one, and nobody's history is rewritten.

Use merge on shared branches. Use rebase to tidy your own branch before others pull it.

git merge records the join in a new commit and rewrites nothing, so merge is safe everywhere. The cost is a busier history, because every merge of diverged branches adds a merge commit.

git rebase replays your commits onto the other branch. The copies get new hashes, so they are new commits. Anyone who already had the old ones now holds a diverged branch, which is why you never rebase shared history.

A common workflow uses both. Rebase the feature branch onto the newest main, then merge it:

git switch feature
git rebase main     # replay my commits on the newest main
git switch main
git merge feature   # publish the finished work

Find the conflicted files, edit each one into the version you want, then git add them and commit. A merge conflict only means both branches changed the same lines. Git stops, keeps both versions in the file, and waits for you to decide. Nothing is lost.

Run git status first. It lists the conflicted files under Unmerged paths. Open each one. Your side sits between <<<<<<< HEAD and =======. The incoming side follows, up to >>>>>>> branch-name.

Edit the file into the text you want, then delete all three marker lines. Often the right result keeps parts of both sides.

git status               # which files are unmerged
git add src/config.js    # staging a file marks it resolved
git commit               # finishes the merge
git merge --abort        # bail out, back to before the merge

There is no separate "resolve" command. git add is the signal. Run the build and tests before committing, because a file with no markers left can still be broken. If it goes wrong, git merge --abort before the commit puts everything back as it was.

git fetch only downloads new commits, while git pull downloads them and then integrates them into your current branch. Fetch updates your remote-tracking branches, local copies like origin/main. Fetch never changes your working files or your own branches, so it is always safe to run.

Pull integrates the upstream, the remote branch your branch tracks, and how it does that depends on your settings. By default current Git only fast-forwards, moving your branch ahead when you have no new commits of your own. A pull fails when your branch has diverged. git pull --rebase replays your commits on top instead, and git pull --no-rebase runs a merge. Set pull.rebase once to choose a default.

Fetching first lets you see what arrived before you decide how to combine it:

git fetch origin
git log --oneline main..origin/main   # what arrived
git merge origin/main                 # the step git pull --no-rebase does for you