A Version Control System (VCS) is a program or set of programs that allows you to track changes made to a set of files.
One goal of a VCS is to easily retrieve earlier versions of a file or the entire project. Another goal is to enable multiple team members to work simultaneously on a project—even on the same files—without interfering with each other’s work.

Another name for a VCS is Software Configuration Management (SCM) system. These terms are often used interchangeably—in fact, Git’s official documentation is hosted at git-scm.com.
Technically, version control is just one of the practices covered by software configuration management. A VCS can also be used for non-software projects, such as books or online tutorials.

With a VCS, you can:

• See all changes made to your project, when they were made, and by whom
• Add an explanatory message to each change
• Retrieve previous versions of the project or individual files
• Create branches to experiment with changes. This allows multiple people to work on different features or bug fixes in parallel, without affecting the main branch. You can then merge the desired changes into the main branch
• Add tags to a version, for example to mark a new release

About Git

Git is a fast, versatile, highly scalable, free, and open-source VCS.
Its principal author is Linus Torvalds, the creator of Linux.

Distributed Version Control

Early versions of VCSs—like CVS, Subversion (SVN), and Perforce—used a centralized server to store a project’s history. This centralization made the server a potential single point of failure.

Git is distributed, meaning the full history of a project is stored both on the client and the server. You can modify files without a network connection, commit changes locally, and then sync with the server once reconnected.
If a server crashes, you still have a local copy of the project. Technically, you don’t even need a server—changes can be shared via email or removable media—but in practice, no one uses Git that way.

Git Terminology

To understand Git, you need to know its terminology. Here’s a list of frequently used terms. Don’t worry about the details for now—you’ll get familiar with them through the module’s exercises.

• Working Tree: A set of nested directories and files containing the current project
• Repository (Repo): A directory at the root of the working tree where Git stores all project history and metadata
  • A bare repository is not linked to a working tree; it’s used for sharing or backup. It often ends in .git (e.g., project.git)
• Hash: A number generated by a hashing function representing a file or object’s content as a fixed-length string. Git uses 160-bit hashes. This allows Git to detect file changes by comparing hashes, regardless of date or time
• Object: A Git repository contains four types of objects, each identified by a SHA-1 hash:
  • Blob: Contains a file
  • Tree: Represents a directory (names, permissions, hashes)
  • Commit: A specific version of the tree
  • Tag: A name attached to a commit
• Commit: As a verb, means creating a commit object. It validates changes so they’re visible to others
• Branch: A named series of related commits. The most recent commit is called the head
  • The default branch is called main (or master in some cases). The head of the active branch is named HEAD
  • Branches allow independent work, then merging changes into the main branch
• Remote: A named reference to another Git repository. By default, Git creates a remote named origin for push and pull operations
• Commands, Subcommands, and Options:
  • Git operations are performed via commands like git push or git pull
  • git is the main command
  • push or pull are subcommands
  • Options are added with - or -- (e.g., git reset --hard)

These terms—and others like push and pull—will become clearer with practice. Feel free to revisit this glossary after completing the module.

Git Command Line

There are several graphical interfaces (GUIs) for Git, such as GitHub Desktop.
Many code editors, like Visual Studio Code, also integrate Git.
But none of them cover all Git features.

The exercises in this module use the Git command line, especially in Azure Cloud Shell.
The command line interface works the same across all operating systems and gives access to all Git capabilities.
Developers who rely only on a GUI sometimes get stuck with errors that can only be resolved by returning to the command line.

Git vs GitHub

While working with Git, you may wonder about the differences between Git and GitHub.

• Git is a distributed version control system (DVCS) that multiple developers can use to work on a project. It allows managing local branches and pushing them to a remote repository
• GitHub is a cloud platform built on Git. It facilitates collaboration through:
  • A web interface
  • Additional command-line tools
  • A simplified workflow

GitHub acts as the remote repository mentioned earlier.

Key GitHub Features:

• Issues
• Discussions
• Pull requests
• Notifications
• Labels
• Actions
• Forks
• Projects

To learn more about GitHub, check out the Introduction to GitHub module on GitHub Tutorial or the Getting Started with GitHub documentation.

✅ Next Step: Try Git for Yourself!