What Is Git?
This lesson assumes you already know why a version control system matters — see Version Control in the CSE fundamentals track if you need that grounding. Here, the focus is the day-to-day workflow: how Git is structured, the commands you'll actually type, and how a team of contributors branches and merges without stepping on each other.
Why Git Is So Popular
Three features explain most of Git's dominance:
- Speed — almost every operation is local, so it doesn't wait on a network round trip;
- Data integrity — every object is checksummed (SHA-1/SHA-256), so silent corruption is caught;
- Distributed workflows — every clone is a full repository, not just a checkout, so there is no single point of failure.
Main Terms
A few Git-specific terms carry different meanings than they do in other version control systems (Subversion, Mercurial):
Git stores source code as text files organized in folders and sub-folders — this structure is the working tree, the directory where you edit files, always part of a repository. A local repository has a working tree; a bare repository (used on servers as a central repository) does not.
Git Architecture
Git's architecture has three major parts: the repository, the working directory, and the staging area (also called the index).
Repository
The repository is where every change to the codebase is stored. Each change is a commit — a snapshot of the entire codebase at that point in time. The repository also tracks branches, tags, and remotes.
Working Directory
The working directory is your local copy of the repository. Git tracks the changes you make there and lets you commit them to the repository when you're ready.
Staging Area / Index
The staging area sits between the working directory and the repository. It lets you selectively add changes from the working directory before committing — so you can commit exactly the changes you want and leave the rest for a later commit.
Communication Protocols
Git supports several protocols for talking to a remote repository:
- HTTP/HTTPS — the default for public repositories on GitHub, GitLab, and Bitbucket; simple, but with more overhead than the alternatives.
- SSH — secure and efficient; encrypts all data between client and server, and is the usual choice once you've set up key-based authentication.
- Git — a fast, lightweight protocol with no authentication, mostly seen on private networks.
Everyday Git Commands
Every contributor needs these commands to work with a repository:
| Command | Description |
|---|---|
git init | Initializes a new Git repository in the current directory. |
git clone | Makes a copy of a Git repository and stores it on your local machine. |
git add | Adds changes in the working directory to the staging area. |
git commit | Records staged changes to the local repository with a message describing them. |
git push | Pushes local commits to a remote repository. |
git pull | Fetches changes from a remote repository and merges them into the local branch. |
git branch | Lists all local branches in the current repository. |
git checkout | Switches to a specific branch or commit. |
git merge | Merges changes from one branch into another. |
git status | Displays the current state of the working directory and staged changes. |
Git Branching Strategy
A branch is a lightweight, isolated line of development — a place to experiment without affecting the main code. A branching strategy is the team's agreed set of rules for how branches get created, named, and merged, so that changes stay organized and conflicts stay rare. The right strategy depends on the project's size, contributor count, and release cadence; there is no one-size-fits-all answer.
Feature Branching
Each new feature gets its own branch. Developers work on the feature in isolation and merge back into the main branch once it's complete — which prevents conflicts and makes it easy to trace a change back to the feature that introduced it.
Release Branches
Each release gets its own branch, holding the bug fixes and last-mile changes needed for that release, merged back into the main branch once the release ships. This keeps the release stable and makes a rollback straightforward if something goes wrong.
Advantages
- Improves code quality — bugs are easier to isolate and fix;
- Improves development throughput — multiple features move in parallel;
- Reduces conflicts — changes are isolated per branch;
- Makes history easier to read — a change traces back to the branch that made it;
- Makes rollback easier when something needs to be undone.
Challenges
- Choosing the right strategy for a given project isn't obvious up front;
- Many branches are harder to manage as the contributor count grows;
- Tracing a change across branches takes more discipline;
- A late rollback can still be awkward if branches have already merged.
Git Forking
Forking copies an existing repository into your own account, so you can change the code without touching the original. A pull request (PR) then asks the original repository's maintainers to merge your changes back in — once merged, your work becomes part of the upstream project. A development branch (commonly created from main) is where you actually build the feature or fix before opening that PR.
Advantages
- You can change the code without affecting the original repository;
- You get feedback on your changes from the project's maintainers and community, via code review — see Code Review;
- It's the standard on-ramp for contributing to open source projects you don't have write access to.
Challenges
- Tracking changes across many forks and branches gets harder as a project grows;
- Merging changes from multiple independent forks can produce real conflicts;
- Getting timely feedback depends on maintainer bandwidth, which you don't control.
Git Software
Using Git means installing the Git client for your OS, plus (optionally) a visual tool for browsing history and diffs.
Download Git for Mac, Windows, Linux, or Solaris: git-scm.com/downloads. Read the documentation: git-scm.com/doc.
Client
Git's command-line interface is powerful but not always the fastest way to see what's going on. A graphical client can help, especially when reviewing history or resolving a tricky merge: GitKraken, Sourcetree, and GitHub Desktop are common choices. See more GUI options at git-scm.com/download/gui/linux.
Server
You have two broad options for hosting a Git server: a managed cloud service, or your own infrastructure. GitHub and Bitbucket are SaaS (Software as a Service) — free for open source and small private projects, with paid tiers for more users and features. GitLab can be self-hosted, which supports very large, distributed projects with an unlimited number of users behind your own firewall.