The Problem Git Solves
Before version control, the standard practice for managing important files was to create copies — “project_final.docx”, “project_final_v2.docx”, “project_FINAL_actual.docx”. Every developer working alone on small projects has some version of this system. Every developer who has tried to work with others on a larger project knows why it fails: there’s no reliable way to know which version is current, who changed what and when, or how to merge changes made simultaneously by different people.
Git solves this. It tracks every change made to every file in a project, along with who made the change and when. It allows multiple people to work on the same codebase simultaneously without overwriting each other’s work. It allows you to go back to any previous state of the project, explore alternative versions, and merge work from different branches. It is, without question, the most important tool in modern software development.
The Core Concepts You Need to Understand
A repository (repo) is the database where Git stores all the history and versions of a project. A commit is a snapshot: a saved state of your files at a specific point in time, with a message describing what changed. Commits are the unit of history in Git — everything is stored as a series of commits, each pointing to its parent.
The staging area (also called the index) is a holding area between your working files and the committed history. When you make changes, you stage the ones you want to include in the next commit, then commit the staged changes. Branches are parallel lines of development. The main line is the stable version; feature branches let you develop new features or experiment without affecting it. When your feature is ready, you merge it back.
The Commands You Will Use Every Day
| Command | What It Does |
|---|---|
git init | Create a new Git repository |
git add filename | Stage a file for the next commit |
git commit -m "message" | Commit staged changes |
git status | Show what files have changed |
git log | View the commit history |
git branch name | Create a new branch |
git checkout name | Switch to a different branch |
git merge name | Merge a branch into current branch |
git pull | Fetch and merge changes from remote |
git push | Send your commits to remote |
GitHub, GitLab, and Remote Repositories
Git itself is a local tool — it tracks history on your machine. Services like GitHub, GitLab, and Bitbucket are remote repositories: cloud-hosted copies of your repository that serve as the shared central point for collaboration. When multiple developers work on a project, they each have a local copy, push their changes to the remote, and pull others’ changes down.
Write Good Commit Messages
Commit messages seem unimportant when you’re the only developer on a project. They become extremely important six months later when you’re trying to figure out why a particular change was made. The convention: start with a concise summary in the imperative mood (“Add user authentication”, not “Added user authentication”). If more context is needed, add it after a blank line. The goal is to make the history readable as a coherent narrative of what the project is and why it evolved the way it did.
A codebase with thoughtful commit messages is a codebase that can be maintained. A codebase with messages like “fix” and “stuff” is a codebase that eventually gets rewritten from scratch because nobody can understand it. The few extra seconds per commit compound into enormous value over the life of a project.
Watch: Related Video
Sources
- Chacon, S., and Straub, B. (2014). Pro Git. Apress. Available free at git-scm.com/book.
- Git Documentation. (2024). git-scm.com/doc.
- GitHub Docs. (2024). About Git. docs.github.com/en/get-started/using-git/about-git.