Introduction to Git and GitHub

Imagine that you and three classmates are building a small website. Yesterday the home page worked. Today someone edits it and the layout breaks. You want to know what changed, restore a working version if necessary, and let everyone contribute without passing folders back and forth.

Git is the version-control tool that records intentional checkpoints of your files. GitHub is an online service that hosts Git repositories and adds tools for collaborating around those checkpoints. You can use Git on your computer without a GitHub account or an internet connection.

In this course, we will first learn what happens on one developer's computer, then connect that work to GitHub so a team can review and share it. For the moment, you do not need to know programming; you only need to recognize a file and a folder.

Version control means recording a project's changes over time so you can inspect earlier versions and understand how the project developed. Git is one version-control system. A repository (often shortened to repo) is a project with a Git-managed history. Your project's actual files are still ordinary files that you can edit.

A commit is a named-in-history checkpoint: it records a selected snapshot of the project, a message describing the change, and other metadata. A branch is a movable name for a line of commits; we will practice branches later. You do not need a GitHub account to create any of these locally.

GitHub can host a copy of your repository on the internet. That other repository is called a remote from your computer's point of view. A push sends your local commits to a remote repository; a fetch retrieves remote history. A pull request is a GitHub feature for proposing, discussing, checking and reviewing changes before merging them. It is not the same as the Git command git pull.

Illustration: what stays local and what goes online

For a closer look at Git's snapshots and history, see Version control and Git. Other hosting platforms exist, so GitHub is useful but not mandatory.

Consider a fictional example: Mira is updating the heading of a website. At the start, the project contains a file named index.html with the heading Welcome. Mira changes that text to Welcome to our club. The following walkthrough is a simplified illustration of the process, not commands you are expected to run yet.

1. Edit: Mira saves the new text in index.html. This changes a file on her computer but does not save anything into Git history.
2. Stage: She uses git add index.html to select the current file contents for her next checkpoint.
3. Commit: She runs git commit -m "Improve home page heading". Git now has a local commit. The text after -m is a human-readable commit message; the quotation marks keep its words together as one argument.
4. Share later: Once a remote is configured and she has access, she can use git push to send commits to a shared GitHub repository. A teammate can then review the proposed change through a pull request if the team uses that workflow.

Notice the important boundary: editing is not committing, and committing is not uploading. The new heading becomes part of local Git history at step 3, but it does not appear in the shared GitHub repository merely because she committed it.

Illustration: trace where the new heading exists

Before edit:   index.html → Welcome
After edit:    index.html → Welcome to our club
After staging: next commit contains → Welcome to our club
After commit:  local Git history contains the new checkpoint
After push:    remote Git repository receives the pushed commit

These are conceptual states, not terminal output. The next lessons will show the actual commands, file contents and results in a practice repository.

Let's check for Git without changing a project. Open Terminal on macOS or Linux, or Git Bash, PowerShell or Windows Terminal on Windows if Git is installed. The following example uses shell commands (commands entered in a terminal), not code written inside a programming language.

git --version
git help -g

git starts the Git program. The space separates it from an option or subcommand. --version asks Git to display its installed version. help -g asks Git to list its available concept guides; the short -g option tells git help to list guides.

Example output (illustrative; yours will differ):

git version 2.47.3

The common Git guides are:
   attributes   Defining attributes per path
   everyday     Everyday Git With 20 Commands Or So
   glossary     A Git Glossary
   ...

The first line tells you Git is installed and shows its version. The later lines are names and descriptions of help guides; the exact guides and formatting depend on your Git version. If your terminal reports git: command not found or says Git is not recognized, Git may not be installed or may not be on your command search path. Follow Install and configure Git before continuing.

Both commands only display information; they do not create a repository, make a commit or contact GitHub. You can repeat them safely.

Practice scenario: You are working on a class website, and Git is already installed. For each task below, predict whether local Git is enough or whether you need a GitHub feature. Also decide which task requires an internet connection.

1. Record the working home page as a local checkpoint.
2. See the difference between your edited file and the staged version.
3. Ask teammates to review an online proposed change.
4. Share committed work by pushing it to a GitHub repository.

Worked answer: (1) Use Git's git add and git commit: the checkpoint is stored locally, so it can work offline. (2) Use Git's git diff: comparing local file states does not need GitHub or a network. (3) Use a GitHub pull request: the discussion and review live on the hosting platform, so you must access the service. (4) Use Git's git push after configuring the GitHub remote and permission to access it: Git transfers the commits, and reaching GitHub requires network access.

Try a variation: Your Wi-Fi goes down immediately after a successful commit. Is the checkpoint lost? No. It remains in your local repository; only the remote sharing step must wait for connectivity.

“Saving a file means Git saved a version.” Saving updates your working file; a Git commit records a checkpoint in history. You will learn the intermediate staging step in Working tree and staging.

“I must sign up for GitHub before I can use Git.” Git can make local repositories and commits offline. GitHub becomes relevant when you want its hosting or collaboration features.

“A commit automatically appears on GitHub.” A local commit stays local until relevant commits are transferred to a remote. Also, a git pull command is not a GitHub pull request: the names sound similar but perform different jobs.

“GitHub is my only backup.” A hosted copy can help with recovery, but do not treat it as your complete backup strategy. Changes not committed or pushed may exist only on your computer.

• Git tracks a project's history and supports local checkpoints and comparisons.
• GitHub hosts Git repositories and supports shared work, pull requests and review.
• File edit → staging → local commit → optional push are distinct actions, not one automatic upload.
• You can check Git's installation with git --version without opening GitHub.

Self-check: Can you explain to a classmate why a commit can exist while the computer is offline? If so, you're ready to learn how Git records project history, then create a practice repository.

References: Git: About Version Control and GitHub: About pull requests.