Git Introduction

Every software team, from a two-person startup in Pune to the people who build Linux, needs to answer the same questions every day: what changed, who changed it, why, and how do we go back if it broke? Git answers those questions. It is the tool almost every developer uses to save and share their work.

In this lesson you will learn what version control is, how Git works at a high level, how Git is different from GitHub, and what the rest of this tutorial covers.

What is version control?

Version control is a system that records changes to files over time, so you can see the history of a project and bring back any earlier state. Think of it as an "undo" that never forgets, that works across many files at once, and that many people can share.

Without version control, people invent their own system. You have probably seen folders like these:

project-final
project-final-2
project-final-really-final
project-final-priya-changes
project-final-USE-THIS-ONE

This breaks down quickly. Nobody knows which copy is the latest, what changed between two copies, or how to combine Priya's changes with Kabir's. Version control replaces the folder mess with a single project folder and a full, searchable history inside it.

What Git does for you

Git is a distributed version control system. "Distributed" means every developer has a complete copy of the project and its whole history on their own computer, not just the latest files. You can commit, browse history and create branches with no internet connection, and the project survives even if one computer or server dies.

With Git you can:

• Save a snapshot of your project at any moment, called a commit, with a message that explains the change.
• See exactly which lines changed between any two snapshots.
• Work on a new feature in a separate branch without disturbing the working version.
• Combine (merge) work from many people, and get help when two people changed the same line.
• Go back to any earlier version, or undo one bad change while keeping everything after it.
• Find out when a bug first appeared, even in a history of thousands of commits.

Here is a short preview of what working with Git looks like in a terminal. Do not worry about the details yet; each command has its own lesson.

git init
git add index.html
git commit -m "Add home page"
git log --oneline

Initialized empty Git repository in C:/Users/priya/projects/sweet-shop/.git/
[main (root-commit) dae5ca8] Add home page
 1 file changed, 11 insertions(+)
 create mode 100644 index.html
dae5ca8 (HEAD -> main) Add home page

dae5ca8 is the short ID of the commit. Every commit gets a unique ID like this, which you will use to refer to it later.

A short history

Git was created by Linus Torvalds in April 2005 to manage the source code of the Linux kernel, after the team lost free access to the tool it had been using. He wanted something fast, distributed and very hard to corrupt. Junio Hamano has maintained Git since later in 2005, and thousands of people contribute to it. New versions come out every few months; this tutorial is written for Git 2.56.

Before Git, many teams used centralised systems such as Subversion (SVN) and CVS. In those systems the history lives only on one central server, and you need a connection to it for almost every action. You may still meet SVN in older companies, but new projects almost always choose Git.

Git is not GitHub

Beginners often mix these up, so let us be clear:

Git works perfectly without GitHub. GitHub (and similar services such as GitLab and Bitbucket) add a shared online home for your repository plus team features: pull requests for code review, issues for bug tracking, and GitHub Actions for automatic testing. You will learn Git first, then GitHub, because everything GitHub does is built on Git ideas.

Key words you will meet

• Repository (repo): a project folder that Git tracks, including its full history. The history lives in a hidden .git folder.
• Commit: a saved snapshot of the project, with an author, a date and a message.
• Branch: an independent line of work, such as main or login-page.
• Merge: combining the work of two branches.
• Remote: a copy of the repository somewhere else, usually on GitHub, that you push to and pull from.
• Clone: a full copy of a remote repository on your computer.

How this tutorial works

Git is a command-line tool, so the examples show commands in a terminal block, followed by the real output Git printed. For example, this command asks Git for its version:

git --version

git version 2.56.0.windows.2

Your commit IDs, dates, folder paths and even the version text will be a little different (Git for Windows adds .windows.N to the number), and that is normal. There is no in-browser editor for Git lessons: install Git in the next lesson and type the commands yourself, because typing them is how you remember them.

The course goes from basics (commits and history) through branching and merging, to GitHub (pull requests, issues, forks, Actions), and then to advanced tools such as git bisect, git reflog and how Git stores data inside. It ends with a project where you contribute a pull request.

Common mistakes

• Thinking Git is only for teams. Git is just as useful on a solo college project: it gives you history, safe experiments on branches and a backup on GitHub.
• Thinking Git and GitHub are the same thing. You install Git; you sign up for GitHub. Many companies use Git with other hosts.
• Committing only at the end. Git helps most when you commit small, working steps often, each with a clear message.

Key points

• Version control records every change to a project so you can review history and go back safely.
• Git is a distributed version control system: every copy has the full history and works offline.
• Linus Torvalds created Git in 2005 for the Linux kernel; this course teaches Git 2.56.
• GitHub is an online hosting service built around Git, with pull requests, issues and Actions.
• Core words: repository, commit, branch, merge, remote and clone.

1. I deleted a working function and could not get it back.
   Feature: commits and history (go back to the last commit).
2. My friend and I edited the same report and emailed copies around.
   Feature: remote + merge (both push to GitHub, Git combines the work).
3. I wanted to try a new design without breaking the working site.
   Feature: branch (experiment on a branch, merge only if it works).