Git vs GitHub: Version Control Fundamentals for GitHub Foundations (GH-900)

Version control is a system that records every change to a set of files over time, so you can see what changed, who changed it, when and why, and get back any earlier version. Git is the version control system the GH-900 exam is built around.

Without it, teams fall back on shared folders, emailed attachments and file names like report-final-v3.docx. Files get overwritten, nobody can tell who made a change or for what reason, and two people editing at once lose each other's work. Version control solves four problems:

• History and accountability. Each recorded change (a commit) carries its author, a timestamp and a message describing it. Reading the history answers "who changed this, when, and why?" — the command is git log.
• Restore and compare. Every committed version of a tracked file is kept, so you can compare any two versions (git diff) or bring a file or the whole project back to an earlier state. A bad change can be undone without keeping separate backup copies.
• Parallel work. Several people can change the same project at the same time on separate lines of work (branches) and combine them later by merging, instead of locking files or taking turns.
• Safe experimentation. You can try an idea on a branch without touching the working version, then keep it (merge) or throw it away (delete the branch).

Version control can only return what was committed. The history is a series of committed snapshots, so for a tracked file you can compare or restore any version that exists in a commit — and nothing else.

The rule is general: work that was never committed — uncommitted changes, untracked files, and paths Git is told to ignore with a .gitignore file — leaves no trace in history, and a tracked file's history begins at the commit that first added it.

This is also why a cloud drive's per-file version history is not a substitute for Git. A drive can keep old copies of each file, give shared access and act as an off-site copy; what it does not give you is branches — separate lines of work across the whole project that develop side by side and are merged later.

Git is free, open-source, distributed version control software that you install and run on your own computer; GitHub is a cloud platform that hosts Git repositories and adds collaboration features around them. They are not two names for one tool, and Git does not need GitHub.

Git works entirely without GitHub: you can git init a repository, commit, branch and merge on a laptop with no internet connection and no GitHub account. A connection to a remote is needed only to share work (push, fetch, pull, clone). GitHub is one of several places a Git repository can live — a plain Git server on a company network or another hosting service works with exactly the same Git commands. What you lose off GitHub are GitHub's own features, such as its pull requests and issues.

Git is maintained as an independent open-source project and is used with many hosting services. GitHub also publishes its own client apps — GitHub Desktop (a graphical app) and GitHub CLI (gh) — which work with Git repositories and GitHub features but are separate from Git itself.

GitHub adds a collaboration and project layer — pull requests with review, issues, Actions, access control and a web interface — on top of the version control mechanics that Git already provides. A useful test is: "Could I do this on a plain clone with only Git installed?"

GitHub also shows diffs, blame views and a merge button in the browser, but those are views onto Git operations that run on any clone without GitHub. Merging is the classic trap: a pull request ends in a merge, yet the merge itself is Git's operation. Pull request reviews, approvals, status checks and who pushed a commit are GitHub data that sit around commits — they are not stored inside the commit objects.

Git is distributed, which means every clone holds a complete copy of the repository, including its full history — not just the latest files. This is the opposite of centralised version control, where the history lives on one server and each client checks out only the current files.

Consequences you need to know:

• Local work needs no server. Viewing history, committing, creating branches and merging all happen on your own clone, offline.
• Sharing does need the remote. If the shared server is down, push, pull, fetch and cloning from that server wait until it is back; everything local keeps working.
• Any clone is a backup. If the server's repository is lost, an up-to-date clone holds every commit by every author up to its last fetch. The team can create a new remote and push that clone's branches to rebuild it (other people's branches are held as remote-tracking refs such as origin/feature, so they must be pushed explicitly, for example with a mirror push); only work that never reached that clone is missing.
• Nothing is broadcast. A commit is not sent anywhere automatically; you share it explicitly by pushing, and others receive it by fetching or pulling. Every copy is complete in itself.

A Git repository is a project's files together with the full history of changes to them. It is the unit Git manages: one repository contains many commits (snapshots) and branches (pointers to commits). A repository on GitHub is simply one place a repository can be hosted.

On disk a repository has two parts:

• The working directory — the project files you see and edit.
• The hidden .git directory — Git's database: every commit and snapshot, branches, remotes and configuration.

The history lives in .git, not in your files. Delete .git from a copy of the project and the current files are untouched, but the folder is now a plain, untracked copy with no history, no branches and no remotes; Git does not rebuild it. You create a repository either with git init (a new, empty history in the current folder) or git clone <url> (a copy of an existing repository with all its history).

Git moves a change through three local areas: the working directory where you edit files, the staging area (also called the index) where you choose what goes into the next commit, and the commit history where git commit records what was staged.

edit file        ->  modified   (working directory)
git add file     ->  staged     (staging area / index)
git commit       ->  committed  (local history)
git push         ->  pushed     (remote, e.g. GitHub)

The staging area is what lets you commit only part of your work: edit three files, git add two of them, commit, and the commit contains just those two changes while the third stays modified in the working directory.

Two details catch people out:

• git add stages a snapshot, not the file name. It copies the file's content at that moment into the index. If you edit the file again and commit without adding it again, the commit contains the version from when you ran git add; the later edit shows as a modified, unstaged change.
• Committing is local. After git add alone the change is only staged; after git commit it is in your local history; teammates see it only after git push.

Use git status to see which files are modified, staged or untracked at any moment.

A commit is a snapshot of all tracked files at one moment, plus metadata: the author and committer with their dates, a message describing the change, and the ID of its parent commit (or commits). The first commit in a repository has no parent; a merge commit has two or more. Parent links are what chain commits into a history.

A commit is not a push and not a review request. It is recorded in your local repository only; GitHub pull requests, reviewers, approvals, status checks and pull request numbers are platform data outside the commit.

Each commit is identified by a hash that Git computes from the commit's data — its snapshot, parents, author, committer, dates and message (SHA-1 by default; Git can also use SHA-256). That hash, often shortened to its first seven or so characters, is what commands and GitHub URLs use to refer to a specific commit. A message or a timestamp does not identify a commit uniquely.

Because the ID is derived from the content, a commit cannot be edited in place. Changing anything — even just the message with git commit --amend — makes Git write a new commit with a new hash and move the branch to it. That is why rewriting commits that others already have causes trouble, and why amending is normally done before pushing.

A branch is a lightweight, movable pointer to a commit that advances automatically each time you commit on it. It is not a copy of the files in another folder, which is why creating and switching branches is fast and cheap. Most repositories have a default branch, usually main.

To try an idea without affecting main while keeping the work in the same repository, create a branch from main, commit there, then merge it if it works or delete it if it does not.

Branches are independent: commits on feature advance only the feature pointer and are not on main until merged. Pushing is per branch too — git push origin main sends only main, so commits on an unpushed, unmerged feature branch stay invisible to teammates. Switching branches changes which commit your working files reflect; the commits on every branch stay in the repository.

Merging and merge conflicts

Merging combines the work of one branch into another. Git compares each branch with their common ancestor and applies both sets of changes; when the two branches changed different lines — even in the same file — Git combines them automatically.

A merge conflict happens only when both branches changed the same lines (or one edited a file the other deleted). Git cannot know which version is right, so it stops the merge, marks the conflicting sections in the file and waits for someone to edit the result and commit it. Resolving a conflict is always a human decision recorded in a new commit; both branches remain intact.

<<<<<<< HEAD
the line as it is on main
=======
the line as it is on the branch being merged
>>>>>>> feature

A remote is another copy of the repository that you synchronise with, usually hosted on GitHub; origin is the default name Git gives the remote you cloned from. Four commands move commits between your clone and a remote:

Fetch is the cautious choice: you can inspect what arrived (for example git log origin/main) before anything touches your branch. After a fetch, the new commits are on your laptop but in origin/main, not your local main, so git log main will not show them until you merge origin/main into main (or run git pull).