Git and GitHub Fundamentals

Engineering workflow pathAvailable

Build a mental model of commits, branches, remotes, and safe recovery instead of treating Git as a set of magic commands.

Difficulty: Beginner
Time: 70 min
Practice: Recover from a merge conflict
Assessment: Knowledge check

Before you start

Who is this for?

For learners who manage code, documentation, scripts, configuration, or infrastructure files.

Prerequisites

Basic command-line use

What you'll be able to do

Explain working tree, staging area, commit, and remote
Create focused commits
Use branches safely
Inspect history
Recover from a merge conflict without losing work

Practical outcome

You can make a small change, review it, publish it, and synchronize another checkout deliberately.

1. Four places where a change can exist

Working tree: files you have edited but not staged.
Staging area: the exact next snapshot selected with git add.
Commit: a permanent snapshot in the local repository history.
Remote: another repository, such as GitHub, that stores shared commits.

A file being visible on your computer does not mean it is committed, pushed, or deployed. Inspect the state before acting:

git status
git diff
git diff --staged
git log --oneline --decorate -5

2. A focused workflow

git switch -c docs-improvement
# edit and test files
git diff
git add src/content/docs/learn/example.mdx
git diff --staged
git commit -m "docs: clarify the troubleshooting example"
git push --set-upstream origin docs-improvement

A focused commit answers one question: what changed and why? Do not commit build output, secrets, credentials, or unrelated generated files.

3. Pulling without overwriting work

Before starting new work:

git fetch origin
git status
git rebase origin/main

fetch downloads references without changing files. rebase replays your local commits on the updated base. A clean working tree makes the operation predictable. If you have uncommitted work, commit it on a branch or save it deliberately; do not use a blind reset.

4. Merge conflicts are information

A conflict means two commits changed overlapping lines. Git marks the file with <<<<<<<, =======, and >>>>>>>. Resolve it by understanding both versions:

git status
# edit the file and remove all conflict markers
git add path/to/file
git rebase --continue

If the rebase is not the right operation, stop safely with git rebase --abort. The goal is not to choose “ours” or “theirs” automatically; it is to create the correct final content and test it.

5. History and recovery

git log --graph --oneline --decorate --all
git show <commit>
git restore --source=HEAD -- path/to/file
git revert <commit>
git reflog

git revert creates a new commit that undoes a published commit. Avoid rewriting shared history with reset --hard or force-push unless the team has explicitly agreed. The reflog can often find a commit that is no longer on a branch, but it is not a substitute for backups.

6. GitHub is not the deployment itself

GitHub stores commits. A CI workflow may build those commits and deploy the result to a hosting provider. A successful git push proves only that GitHub received the commit. Check the workflow and deployment status before assuming the public site changed.

7. Practical exercise

Create a branch, change one sentence, inspect the staged diff, commit it, and push it. On a second checkout, make a different change to the same line, commit it, then pull the first change. Resolve the conflict manually, run the build, and record why the final sentence is correct.

What you should be able to do now

You should be able to locate a change in the working tree, staging area, local history, remote history, or deployed output—and choose a recovery command that does not destroy unreviewed work.