Why Version Control Matters

A project changes as you edit it. Without version control, saving over a file can erase a working version, and naming copies final, final-new, or final-revised makes it difficult to know which one is current. Version control records deliberate checkpoints in a project’s history. You can inspect what changed, when it changed, and which commit recorded it. If a later edit causes a problem, that history gives you a way to investigate and recover earlier work.

Git is a distributed version-control system. A repository contains the project’s tracked history on your computer, so you can make commits and inspect them without being connected to a hosting service. Git does not automatically save every keystroke: you choose when to record a checkpoint. This makes commits useful when they describe a meaningful, reviewable change, such as correcting a calculation or adding one focused feature.

How Git Tracks Changes

Git separates your current files from the history it has recorded. The working tree is the set of files you are currently editing. When you change a tracked file, Git can identify the difference between that file and its last committed version. A new file is initially untracked, which means Git sees it but has not yet been asked to include it in version history.

Before a commit, you select changes for the staging area, also called the index. Staging lets you include only part of your current work, or leave unfinished edits out of a commit. For example, if you fix a spelling mistake and begin a separate feature, you can stage and commit the spelling fix without recording the feature’s incomplete changes.

A commit records the staged project state along with metadata such as its author, time, and message. Commits connect to earlier history, allowing Git to show how the project developed. A typical local workflow checks the current state, stages selected changes, and then creates a commit. Committing does not, by itself, upload anything to another computer.

Git and GitHub

Git is the tool that tracks repository history. GitHub is an online service that hosts Git repositories and adds collaboration features such as pull requests, issue tracking, and access controls. A project can use Git without GitHub, and a repository on GitHub still uses Git’s commit and branch model. Similar services also host Git repositories, so GitHub is not required for Git itself.

This distinction matters when diagnosing setup problems. Installing Git makes its commands available locally; it does not create a GitHub account or sign you in. Configuring a commit author sets the name and email written into new commits; it does not provide a password, access token, or SSH key. Authentication and remote collaboration are separate topics that build on a working local Git setup.

Install and Verify Git

Choose an installation method for your operating system. On Windows, use the Git for Windows installer from the official Git website. On macOS, Git may already be available; if it is not, the Xcode command-line tools provide Git, or you can install Git with a package manager you already use. On Debian or Ubuntu, install the package through apt. Follow your operating system’s prompts and use the default installer choices unless your organization specifies otherwise.

After installation, open a new terminal window and ask Git to print its version. This confirms that the command can be found by the shell. The exact version number varies by installation, so check that a version is printed rather than expecting a particular number.

xcode-select --install

sudo apt update
sudo apt install git

git --version

If the terminal reports that git is not found, the installation may have failed or the shell may not yet have picked up the updated path. Reopen the terminal first. If the problem remains, confirm that Git was installed and follow the installer’s instructions for making its command available. On Windows, Git Bash is one terminal option installed with Git for Windows.

Configure Commit Identity

Git writes an author name and email into each new commit. Set a global identity if you want the same default for your repositories on this computer. Replace the example values with a name and email you intend to use. This configuration affects new commits; it does not rewrite commits you already made.

git config --global user.name "Alex Morgan"
git config --global user.email "alex@example.com"

Check what you configured by reading each value back. When a commit appears under the wrong GitHub account, check whether the commit email matches an address associated with that account. GitHub also provides account-specific no-reply email addresses for people who do not want their personal email recorded publicly. Use the address shown in your GitHub settings if you choose that option; the example email above is only a placeholder.

git config --global --get user.name
git config --global --get user.email

A project can use a different identity from your global default. Run the following commands from inside that repository to set its local identity. Local settings apply only there and take precedence over global settings. Git also supports system-level configuration, but beginners typically need only global and, when necessary, local settings.

git config user.name "Work Account"
git config user.email "work@example.com"
git config --show-origin --get user.email

The final command shows which configuration file supplied the effective email in the current repository. If Git says it cannot determine the author identity when you commit, configure the missing name or email and try again. If the commit was already created with incorrect author details, changing the configuration only affects future commits; changing existing history requires a separate, careful procedure.

Make a First Local Commit

A small practice repository connects the setup to Git’s change-tracking workflow. The commands below create a new directory, add one file, inspect its status, stage it, and commit it. Run them in a terminal where Git is available. The final command checks whether the working tree is clean after the commit.

git init git-foundations-practice
cd git-foundations-practice
printf '%s\n' 'First note' > notes.txt
git status
git add notes.txt
git status
git commit -m "Add first note"
git status

The first status should identify notes.txt as untracked. After staging, it should show the file ready to be committed. The commit command records the staged file; its output includes a summary, though wording and branch names can vary by Git version and configuration. The last status should report no remaining changes. No GitHub repository is created by these commands, and nothing is uploaded.

If a command fails, read the current directory and status before repeating it. A path error can mean you are not in the practice repository, while an author-identity error means Git needs a valid configured name and email. A failed commit does not usually mean the staged file disappeared: inspect git status, correct the specific issue, and commit again. These checks build the habit of understanding repository state before taking the next action.