Git - Version Control System (VCS)

Introduction: Why Git Matters 🎯

Imagine working on a document with 10 people. Everyone makes changes. Conflicts arise. You lose track of who changed what. Chaos ensues! 😱

Git solves this problem for code (and any text files).

What is Git?

Git is a Version Control System (VCS) - software that tracks changes to your files over time, like an unlimited "undo" button with superpowers.

Real-World Analogy: Video Game Save Points 🎮

Git = Saving your progress in a video game

┌─────────────────────────────────────┐
│ Level 1 ✓ (Commit 1)                │
│   ↓                                 │
│ Level 2 ✓ (Commit 2)                │
│   ↓                                 │
│ Level 3 ✗ (Oops, made a mistake)   │
│   ↓                                 │
│ LOAD Level 2 ← Go back!             │
│   ↓                                 │
│ Level 3 (Try again with new approach)│
└─────────────────────────────────────┘

With Git, you can:

• Save "checkpoints" (commits) of your code
• Go back to any previous checkpoint
• Try experiments without breaking working code
• See exactly what changed and when
• Collaborate with others without conflicts

Git vs Google Docs

Feature	Google Docs	Git
Track changes	✅ Yes	✅ Yes
See who changed what	✅ Yes	✅ Yes
Go back in time	✅ Limited	✅ Full history
Work offline	❌ No	✅ Yes
Branching	❌ No	✅ Yes
Merge changes	❌ Auto	✅ Smart control
Designed for code	❌ No	✅ Yes

Why Git Was Created 📜

Created by: Linus Torvalds (creator of Linux) Year: 2005 Reason: Needed a fast, distributed VCS for Linux kernel development

Before Git, Linux used a proprietary tool called BitKeeper. When that became unavailable, Linus created Git in just 2 weeks! Today, Git is the industry standard.

What Makes Git Special? 🌟

1. Distributed System (Everyone Has Full History)

Traditional VCS (Centralized):
    Everyone ────→ [Central Server] ← Single point of failure!

Git (Distributed):
    Developer A [Full Copy]
    Developer B [Full Copy]  ← Everyone has full history
    Developer C [Full Copy]
    Central Repo [Full Copy] ← Optional backup

Benefits:

• ✅ Work offline (no internet needed)
• ✅ Faster operations (local!)
• ✅ Multiple backups (every copy is complete)
• ✅ No single point of failure

2. Branching & Merging (Experiment Safely)

main    ●────●────●────●──────●
             ↓         ↗
feature      ●───●───●  (Try new idea safely!)

Use cases:

• Try new features without breaking working code
• Work on multiple features simultaneously
• Collaborate without stepping on each other's toes

3. Lightning Fast ⚡

• Most operations are instant (local!)
• Handles small to massive projects equally well
• Performs 100x faster than older VCS tools

4. Industry Standard 🏆

• Used by 90%+ of developers worldwide
• Required skill for almost any dev job
• Integrated into all major tools (VS Code, IDEs, CI/CD)

Git in the Real World 🌍

┌────────────────────────────────────┐
│  Companies Using Git:              │
├────────────────────────────────────┤
│  • Google                          │
│  • Microsoft                       │
│  • Facebook                        │
│  • Amazon                          │
│  • Netflix                         │
│  • ...virtually everyone!          │
└────────────────────────────────────┘

Popular Git Platforms:

• GitHub - Largest code hosting platform (100M+ users)
• GitLab - Full DevOps platform
• Bitbucket - Atlassian's Git solution

Git vs GitHub: What's the Difference? 🤔

Common Confusion Alert!

Git	GitHub
Software on your computer	Website (online service)
Version control tool	Hosting service for Git repos
Works locally	Social coding platform
Free & open source	Free for public, paid for private
Created 2005	Created 2008

Analogy:

Git     = Microsoft Word (the program)
GitHub  = Google Drive (cloud storage & sharing)

You can use Git without GitHub, but GitHub makes sharing easier!

Benefits of Git

The benefits of Git are many.

1. Simultaneous development

Everyone has their own local copy of code and can work simultaneously on their own branches. Git works offline since almost every operation is local.

2. Faster releases and deployments

Branches allow for flexible and simultaneous development. The main branch contains stable, high-quality code from which you release. Feature branches contain work in progress, which are merged into the main branch upon completion. By separating the release branch from development in progress, it's easier to manage stable code and ship updates more quickly. This also makes it easier to roll back to a previous version if necessary.

3. Built-in integration

Due to its popularity, Git integrates into most tools and products. Every major IDE has built-in Git support, and many tools support continuous integration, continuous deployment, automated testing, work item tracking, metrics, and reporting feature integration with Git. This integration simplifies the day-to-day workflow.

4. Strong community support

Git is open-source and has become the de facto standard for version control. There is no shortage of tools and resources available for teams to leverage. The volume of community support for Git compared to other version control systems makes it easy to get help when needed.

5. Git works with any team

Using Git with a source code management tool increases a team's productivity by encouraging collaboration, enforcing policies, automating processes, and improving visibility and traceability of work. The team can settle on individual tools for version control, work item tracking, and continuous integration and deployment. Or, they can choose a single tool that integrates all of these features.

6. Pull requests

Use pull requests to discuss code changes with the team before merging them into the main branch. The discussions in pull requests are invaluable to ensuring code quality and increase knowledge across your team. Platforms like GitHub offer a rich pull request experience where developers can browse file changes, leave comments, inspect commits, view builds, and vote to approve the code.

7. Branch policies

Teams can configure GitHub and Azure DevOps to enforce consistent workflows and process across the team. They can set up branch policies to ensure that pull requests meet requirements before completion. Branch policies protect important branches by preventing direct pushes, requiring reviewers, and ensuring clean builds.

Terminology and Concepts

Let's take a look at some of the most important terms and concepts in Git. These are the building blocks of Git and are essential to understanding how it works.

Repository

Repositories (or "repos") are the most basic element of Git. A repository contains all of your project's files and each file's revision history. It is a storage and communication mechanism for your project. It contains all of your project's commits, branches, and tags. You can have multiple repositories, and each one can have multiple collaborators.

Branch

A branch is a parallel version of a repository. It is contained within the repository, but does not affect the primary or master branch, allowing you to work freely without disrupting the primary branch (main codebase). When you've made the changes you want to make, you can merge your branch back into the master branch to publish your changes.

We create and use branches to develop new features, fix bugs, refactor code, or experiment with new ideas. By default, your repository has one branch named master which is considered to be the definitive branch. We use other branches to work on a particular feature or bug fix and merge them back to the master branch upon completion.

Commit

A commit, or "revision", is an individual change to a file (or set of files). It's like when you save a file, except with Git, every time you save it creates a unique ID (a.k.a. the "SHA" or "hash") that allows you to keep record of what changes were made when and by who. Commits usually contain a commit message which is a brief description of what changes were made.

Commits usually contain a commit message which is a brief description of what changes were made. Commit messages capture the history of your changes, so other contributors can understand what you've done and why.

Push

Pushing refers to sending your committed changes to a remote repository, such as a repository hosted on GitHub. For instance, if you change something locally, you can push those changes so that others may access them.

Pull

Pulling refers to when you are fetching in changes and merging them. If you and another developer were both working on a file and both made changes, you'll want to pull in those changes and merge them into your branch.

Merge

Merging takes the changes from one branch (in the same repository or from a fork), and applies them into another. This often happens as a "pull request" (which can be thought of as a request to merge), or via the command line. A merge can be done automatically via a "fast-forward" if there are no conflicting changes, or can always be done automatically via a merge commit.

Rebase

Rebasing is the process of moving or combining a sequence of commits to a new base commit. Rebasing is most useful and easily visualized in the context of a feature branch workflow.

Remote

A remote is a common repository that all team members use to exchange their changes. You can have several of them, and they are usually stored on code hosting services like GitHub or GitLab.

Local

A local repository is one that is located on your computer. It is your own personal copy of a project that you can use to experiment with changes without affecting the original project.

Clone

A clone is a copy of a repository that lives on your computer instead of on a website's server somewhere, or the act of making that copy. With your clone you can edit the files in your preferred editor and use Git to keep track of your changes without having to be online. You can push your local changes to the remote server to keep them synced when you're online.

Repository Hosting Services

There are many services that provide Git repository hosting, including GitHub, GitLab, Bitbucket, and SourceForge. These services provide a web interface to interact with your repositories, as well as access control and several collaboration features, such as bug trackers, feature requests, task management, continuous integration and wikis for every project.

But the concept of Git is same everywhere. You can use any of these services to host your repositories, or even host your own Git server.

Git vs GitHub

Sometimes popularly used terms Git and GitHub are used interchangeably. But they are not the same.

A quick aside: Git and GitHub are not the same thing. Git is an open-source, version control tool created in 2005 by developers working on the Linux operating system; GitHub is a company founded in 2008 that makes tools which integrate with git. There are many other alternatives to GitHub, such as GitLab, BitBucket, and "host-your-own" solutions such as gogs and gittea. All of these are referred to in git-speak as "remotes", and all are completely optional. You do not need to use a remote to use git, but it will make sharing your code with others easier.

Getting Started

To get started with Git, you need to install it on your system. Then you need to configure your username and email address. Finally, you need to create your first repository.

Installing Git

You can download Git from the official Git website. Git is available for all major platforms, including Linux, macOS, and Windows. The installer includes everything you need to get started with Git.

Configuring Git

After installing Git, you should set your username and email address. This is important because every Git commit uses this information, and it's immutably baked into the commits.

There is two types configuration in Git:

Local configuration:

This configuration is specific to a single repository. It is stored in the .git/config file in the repository's directory.

Setting a local username

git config user.name "Your username"

Then configure your email address:

Setting a local email

git config user.email "email@example.com"

Global configuration:

It is stored in the ~/.gitconfig file. You can use the --global flag to set it globally, which will apply to every repository on your system.

Setting a global username

git config --global user.name "Your username"

Then configure your email address:

Setting a global email

git config --global user.email "youremail@email.com"

Creating a Repository

You can create a new local repository with the git init command. This creates a new subdirectory named .git that contains all of your necessary repository files — a Git repository skeleton. At this point, nothing in your project is tracked yet.

Creating a new repository

git init

Cloning a Repository

You can also create a copy of an existing Git repository from a particular server by using the git clone command with a repository's URL:

git clone <url>

url is the location of the repository you want to clone.

What's Next?

Let's see what is GitHub and how to use it in the next section.

Conclusion

In this article, we learned about Git and GitHub. We also learned about the difference between Git and GitHub. We also learned about the installation and configuration of Git. We also learned about the creation of a repository and cloning a repository. We also learned about the basic Git commands. In the next article, we will learn about GitHub and how to use it.