Git Foundations

Intro

In your tech journey, I am sure you must have come across the term Git.

Git stands as one of the most powerful and most used tools ever created.

In this article, we will deep dive into the world of Git, explore its history, and the reason it was created, will discuss the version control systems and more.

A little history of Git

Before Git, the Linux kernel development team used a proprietary Version control system called BitKeeper. However, a dispute arose between the BitKeeper creators and the Linux Kernel team.

As a consequence, the free-of-charge access to BitKeeper was revoked.

This incident led to the creation of Git by Linus Torvalds and Linux Kernel Development Team. They learned from their experiences with BitKeeper and set out specific goals in mind for the new system.

(Here is a quick meme 👇 you will get it If you know about Linus Torvalds)

The first public release of Git was in April 2005. It was made available for the public to download and quickly gained attention within the open-source community due to its performance and flexibility.

What is Version Control System and why do we need it?

• Version Control System is a very powerful tool that helps you track changes in your files over time. It is a software utility that manages changes to a filesystem.

• The concept of version control came some decades ago. In the early days of software development, programmers faced challenges when it came to keeping track of code changes and coordinating with team members. As projects grew larger and more complex, the need for a systematic approach to version control was needed.

• Early version control systems were primarily focused on file-level operations, where developers used to manually manage different versions of files by creating copies or using naming conventions such as v1.0 or v1.1 etc.

• However, these methods proved to be error-prone and not very efficient.

• In the 1980s, a Centralized version control system was introduced.

• After some time a distributed version control (DVCS) idea came up and one of these was BitKeeper.

• VCS tracks the addition, deletion, and modification actions applied to files and directories.

Types of Version Control Systems

• Centralized VCS: In a CVCS, there is a central repository that stores the entire history of the project. Developers check out files from this central repository, make changes, and then commit their changes back to the repository. Examples of CVCS include SVN and Perforce.

• Distributed VCS: In a DVCS, each developer maintains a local copy of the entire repository, including the complete history. Developers can commit changes to their local repository and share those changes with others by pushing them to a central repository or directly to other developers. Examples of DVCS include Git and Mercurial.

Benefits of using Git

• Fast: Git is designed to be fast and efficient.

• Keeps track of changes: Git maintains a complete history of all modifications made to the codebase, including the ability to view differences between different versions.

• Easy to use: Git is very user-friendly.

• Non-linear: Git supports a non-linear workflow, allowing developers to create multiple branches to work on different features or bug fixes simultaneously. This enables parallel development, where team members can collaborate on separate branches without interfering with each other's work.

• Distributed: Git is a distributed version control system (DVCS), which means that every developer working on a project has a complete copy of the repository, including the entire history of changes.

• Can handle large codebases: Git can handle projects of any size, including large-scale applications.

If Git is so powerful then why do we need GitHub?

• GitHub or similar platforms are used as a centralized place to distribute code from. While Git provides the core functionality for version control, these platforms allow more functionality making it easier to work on large-scale projects.

• You can have your repo stored on GitHub, you pull the code from the repo into your local machine, make some changes then make commits and then you can push those changes from your local machine to the remote repo on GitHub.

• There are more reasons people use GitHub, some of them include:

1. Backups
2. Better collaborations
3. Open Source Codebases
4. Issue tracking
5. PR tracking
6. Project management
7. Integration of more tools such as CI/CD tools, etc.

What is a Commit?

• In Git, a commit is a snapshot of the changes made to a repository at a particular point in time.

• It represents a set of changes made to the codebase, such as the addition or modification or deletion of the files.

• Each commit has a unique identifier, called a hash, that allows you to refer to it and track the changes made to the code over time.

• When you create a commit, you will also need to add a commit message that describes the changes you've made.

• You can think of a commit as a photograph that you take of a file every time you commit a change.

What is a Branch?

• Git branches are like those separate smaller branches on a tree.
• They're separate paths of development that come from the main branch. -Each branch can have its own set of changes and updates.
• The changes that you made on a branch will not affect the main branch.

Here is how commits and branches look like if you visualize 👇

And here is how it will look if you visualize them in a tree-like structure 👇

What is a Repo/Repository?

In Git, a repository is used as a place where you store and manage your codebase or project. It contains all the files, directories, and the history related to your work.

A repository is commonly called a repo in short. Repos can be divided into 2 types:

• Local Repository: A local repository is a copy of the changes on your local machine (your computer), and it contains the complete history and files of your work. You can create a local repository by initializing Git in a directory using the command git init. It sets up the necessary Git files to track changes to your files within that directory.

• Remote Repository: A remote repository is hosted on a remote server, such as GitHub, GitLab, or Bitbucket. It acts as a centralized location where multiple developers can collaborate on a project. You can push changes from your local repository to the remote repository and pull changes made by others into your local repository. Remote repositories allow for efficient collaboration, version control, and backup of your project.

Difference between Local and Remote Repo

The local Repo is in the computer saved locally while the remote repo is saved in the server as a central storage backup option. It also allows better collaboration, GUI features, project management features, issue tracking, pull request tracking and more.

What is a Fork? 🍴

• A Fork is a way to create a copy of a repository that belongs to someone else.

• When you fork a repository, you're essentially making a "duplicate" of that repository and creating your "own" version of it.

• Changes made in your forked repository won't affect the original project or anyone else's fork of it.

How to create a fork?

To create a fork, you will need to create a GitHub account first. Follow these steps to create a fork 👇

• Go to GitHub

• Create a new account and if you have one then log in.

• Click on the fork button of the repo of your choice (In this case I am forking the LinkFree repo)

• Now it will ask you to give it a name, the default name is also fine.

• Click on the Create Fork button and it will create a fork of that repo for you.

Notice how the forked repo says "forked from EddieHub/LinkFree" This is important to remind you that this is a fork, not the original repo.

Once you have forked the repo in GitHub, you can use the git remote add "URL" command to make a local copy of this fork on your computer.

We will discuss all these commands in the next article.

What is a Pull Request?

• A pull request is a report of all the changes made.

• Let's say that someone else wants to make a change in your repo. They can do that by creating a fork of that repo and make changes in their forked repo so that it doesn't interfere with your work.

• Once they are satisfied with their changes, they can merge their work in your repo from Fork to original repo by asking you if you want to pull these changes into your original repo.

• To do that, they can create a separate branch and commit their changes to that branch and then they can create a Pull Request to merge these changes into your original repo.

• These changes then can be merged once the maintainer of that repo allows.

Conclusion

With that said, I hope this article helped you in understanding the foundations of Git.

In the next part, I will discuss more about the advanced concepts such as setting up the git and working with the git commands, making commits and more.

More Resources to checkout

• Kunal Kushwaha Git YouTube Video
• Git for Noobs series on YouTube
• Wikipedia
• bitbucket.org