What Is Git? Version Control Basics and Git vs GitHub
Version control records each change to your files, with when, who, what and why, so you can go back to an earlier state. The best-known tool is Git. It links snapshots of the whole project (commits) in order, and lets people work in parallel on separate lines (branches). GitHub is not Git. It is a web service that hosts Git repositories and helps teams review work.
What you'll learn
- What changes when you use version control
- What commit, history, branch, merge and conflict mean
- Centralized (Subversion) vs distributed (Git), and Git vs GitHub
- Pull requests and review, and how Git tells content apart (hash values)
- Why you must never commit passwords or API keys
Prerequisites: none. If you have saved files on a computer and sorted them into folders, you can follow this article.
In everyday life
Have you ever seen files like these in a shared folder? "proposal.docx", "proposal_final.docx", "proposal_final_v2.docx", "proposal_final_v2_latest.docx". Which one is really the latest? What was fixed in v2? The names do not tell you.
It gets worse when two people open the same file and edit it separately. Whoever saves last wipes out the other person's edits.
In software development, this happens on a far bigger scale. Dozens of people may change thousands of files at the same time. The answer they use is called "version control."
What is version control? A system that keeps a record of changes
Pro Git is a guide published on Git's official website. It describes version control like this: a system that records changes to files over time, so that you can recall specific versions later. Software that does this is called a "version control system."
Copying files into folders named by date is simple. But Pro Git calls it error-prone, because it is easy to overwrite a file in the wrong folder. A version control system also shows who made each change and when. That helps when you are hunting for the cause of a problem.
The best-known tool is Git. It is mainly used for programs, but it can manage any file written as text in the same way. The circuits of semiconductor chips are also often designed by writing them in a text-like form ("How Compilers Work").
How it works 1: commits, a snapshot with a note
In Git, the unit you record is called a "commit." One commit is a snapshot of all your files at that moment. It also stores who made it, when, and a short note on why. That note is called the commit message.
In practice, Git saves space. A file that did not change just points to the copy saved before. To keep things simple, here we treat each commit as a full snapshot.
The key point: committing is a separate step from saving a file. However many times you save, nothing is committed automatically. You commit yourself when a meaningful piece of work is done, such as "fixed the heading."
How it works 2: history, to view, restore and compare versions
Each commit remembers which commit came just before it. So by following the commits, you can line up every change from the start until now as one flow. This is called the "history."
With a history, you can pull out just the differences between two versions. These differences are called a "diff." If you fixed 3 lines in a 1,000-line file, you see only those 3 lines and a few lines around them.
You can also go back to an earlier state, for a single file or for everything. After a change has been shared with the team, the usual way to undo it is to add a new commit that cancels the earlier change. The history is not erased, so when and why you undid it is recorded too.
Git works best with files written as text. It can store Word documents and images too. But by default, the diff only says that the contents differ (Pro Git, section 8.2).
How it works 3: branches and merges, split off and join again
While you build a new feature, the files may not work yet. If you put them into the main line, everyone else's work could stop too. So in Git, you split the history into a separate line and keep working without affecting the main line.
This separate line is called a "branch." Inside Git, a branch is just a named marker that points to the newest commit in one line of work. It does not copy the files, so it is created instantly and takes almost no space. The main branch is often named main or master.
When the feature is ready, you bring the branch's changes into the main line. This is called a "merge." Git compares what changed on each side since the point where they split. If the changes are in different places, Git combines both automatically.
Git commands look like the examples below. Tools that do the same things with on-screen buttons are also widely used.
| Example command | What it does |
|---|---|
| git commit -m "Fix typo in heading" | Commits the selected changes with a note |
| git log --oneline | Shows the history, one line per commit |
| git switch -c new-feature | Creates a branch named new-feature and moves to it |
| git merge new-feature | Merges the changes on new-feature into the branch you are on |
How it works 4: conflicts, when one spot is changed two ways
Sometimes Git cannot combine the changes automatically. This happens when two branches changed the same part of the same file in different ways. For example, say Alex changed a meeting time to "10:00," and Sam changed it to "11:00."
Git cannot tell which one is right. So instead of picking one on its own, Git stops the merge. In that part of the file, it shows both versions side by side. Markers such as "<<<<<<<" separate them. This situation is called a "conflict."
Fixing it is a job for people. The two talk it over, rewrite the part correctly, remove the markers and then commit. A conflict is not a breakdown. It is a notice that "people need to decide on this difference." Merging often makes conflicts less likely.
Centralized vs distributed: Subversion and Git
Version control systems come in two broad types. In the first type, the whole history sits on one server. Each person takes the latest version from it and works on that. This is called "centralized." The best-known example is Subversion, whose development began in 2000. Its official site also calls it centralized.
With a centralized system, everyone looks at the same place, so it is easy to manage. But Pro Git also points out its weak spots. While the server is down, nobody can record anything. If the server's disk fails and there is no backup, the whole history is lost. A place where one failure stops everything is called a single point of failure.
The second type is "distributed," like Git. Each person's computer holds a copy of the whole history, not just the latest version. So most actions, such as committing or viewing the history, happen on your own machine and work without a network. Every person's copy is also a backup of all the data.
The two types also name versions differently. In Subversion, versions get serial numbers: 1, 2, 3 and so on. In Git, people commit separately on their own machines, so no one can hand out numbers. Instead, Git uses a value calculated from the contents.
How Git came about
Git was created to develop Linux, an operating system. According to Pro Git, from 1991 to 2002, changes to Linux were passed around as patches (sets of differences) and archived files. From 2002, the project began using BitKeeper, a distributed product made by a company, free of charge.
In 2005, the relationship between the Linux developers and that company broke down, and the free use ended. So the developers, led by Linus Torvalds, who created Linux, built their own tool. That tool was Git. Its goals included speed and handling thousands of parallel branches.
Remote repositories, GitHub and GitLab
In Git, the place that stores all the files and their whole history is called a "repository." The one on your own computer is your local repository. A repository placed on a server so a team can share it is called a "remote repository."
Committing on your own machine does not make your work visible to others. You send it to the remote with the git push command, and others bring it in with git pull. Until you push, you can stack up as many local commits as you like.
The best-known services that host remote repositories are GitHub and GitLab. GitHub describes itself as "a cloud-based platform" where you can store and share code and write it together with others. GitLab adds review and automated testing features to repository management. It can also be run on a company's own servers.
In short, Git is software that runs on your machine. GitHub and GitLab are services that host Git repositories. Git can also be used with only a company's internal servers.
Pull requests: get a review before you merge
In team development, people usually do not merge their own branch into the main line on their own. First, they send a proposal: "Please add these changes to the main line." GitHub calls this a "pull request," and GitLab calls it a "merge request."
The proposal page shows the diff and an explanation. Others read the diff and comment on lines they have concerns about. The author fixes things and adds commits. This checking is called "code review." Once the change is approved, it is merged.
Many teams also set tests to run automatically for each proposal. Merging changes into the main line often, and checking automatically every time, is called continuous integration (CI).
How does Git tell content apart?
From the contents of each file it stores, Git calculates a value of fixed length. The same contents always give the same value. If even one character differs, the value is completely different. This calculation is a hash function, and its result is called a hash value.
The hash function Git uses by default is SHA-1. Its values are written as 40 characters, using 0–9 and a–f. The table below shows the first 10 characters for two files that differ by one character. They were calculated the same way Git does it. The file contents are shown as in the original (Japanese), because the values depend on the exact bytes. They mean "The meeting starts at 10" and "The meeting starts at 11."
| File contents (ends with one newline) | Hash value (first 10 characters) |
|---|---|
| 会議は10時から | d7a6150543… |
| 会議は11時から | 3eec220ecf… |
Git uses these values as the names of files and commits. Identical contents get identical names, so Git never stores the same thing twice. If stored contents get damaged, the recalculated value no longer matches the name, so the damage can be noticed.
Commit names are set the same way. Each commit also contains the name of the commit before it. So if anyone quietly rewrites even one past commit, the names of all later commits change. Usually, Git shows names shortened to about the first 7 characters.
Hash functions used in cryptography are designed so that, in practice, nobody can create different data with the same value. That is a big difference from CRC, which finds errors in transmitted data.
In 2017, however, an attack was shown that actually created two pieces of data with the same SHA-1 value. Git added a way to detect that attack and chose SHA-256 as the successor. As of October 2026, Git's documentation says the default is still SHA-1. The next major version, Git 3.0, plans to make SHA-256 the default for new repositories, but no release date has been set.
Never commit passwords or API keys
The strength of version control is that nothing disappears. But this can backfire. Say you accidentally write a password, or a secret key for using a service (an API key), into a file and commit it.
Even if you notice, delete it from the file and commit again, it is still in the earlier commit. Anyone who can view the repository can follow the history and take it out. GitHub's documentation also warns that even after history is rewritten, the data can remain in other people's copies and elsewhere.
So treat any secret that has ever been pushed to a shared place as leaked. The basic fix is to revoke the key with its issuer and replace it with a new one. Better still, never write secrets in program files at all; keep them somewhere else. "What Is an API?" explains how to protect keys. If you list file names in ".gitignore", Git ignores those files as long as they are not yet tracked by Git.
Common misconceptions
Myth: Git and GitHub are the same thing
In fact, Git is version control software that runs on your own computer. GitHub is a web service that hosts Git repositories and adds features for working together, such as pull requests. You can use Git without GitHub. The names are similar and the two are often used together, so they are easy to confuse.
Myth: When you commit, your changes reach the whole team
In fact, a commit is a record in your local repository. To deliver it to others, you need to send it to the remote repository with git push. In the same way, other people's changes do not reach your machine until you bring them in. In centralized Subversion, the command that records a change sends it straight to the server. The same word "commit" then leads to this confusion.
Myth: Version control is only a tool for programmers
In fact, it can manage almost any kind of file. Pro Git even recommends it to designers who want to keep versions of images and layouts. Diffs are harder to see for Word documents and similar files, though.
By the numbers
| Item | Number or date | Note |
|---|---|---|
| Linux changes passed around as patches and archived files | 1991–2002 | Pro Git |
| Start of Subversion development | 2000 | Best-known centralized system |
| Birth of Git | 2005 | Linus Torvalds and others |
| Length of a SHA-1 hash value | 40 characters (160 bits) | Written with 0–9 and a–f |
| Length of the short form | From 7 characters | Made longer when 7 cannot tell names apart |
| Number of objects for a 50% chance of an accidental match | About 280 (about 1.2 × 1024) | Pro Git's estimate |
| Attack creating a SHA-1 match announced | February 2017 | SHAttered |
| Git chooses SHA-256 as the successor | Late 2018 | Default is still SHA-1. Git 3.0 plans to make it the default for new repositories (no date set, as of October 2026) |
280 is roughly a trillion times a trillion. An accidental match is almost nothing to worry about. The real worry is an attack that creates a match on purpose. That is why Git is moving to SHA-256.
Learn more
- Terms for your next step: CI/CD, SSH, agile development, test-driven development (TDD)
- Related articles: "What Is an API?" (how to protect secret keys), "What Is Encryption?" (how hashing differs from encryption), "How Are Passwords Cracked?"
- Read the basics: "How Compilers Work", "What Is a Database?", "What Is Cloud Computing?"