Disclaimer: This blog is just meant to give an understanding of what git is and how it can be useful for us. This blog is beginner-friendly so it doesn't contain many technical terms.
Git is a free and open-source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.
To understand this we must know what Version Control System is.
Version Control
Think of a large software project like the game pubg, if you have ever played that you'll know how back-breaking developing that game would be, and definitely, a single person cannot develop that. It requires a team and everybody makes some changes so, how could one know who made what changes? That's when a VCS comes into the picture. VCS keeps track of changes — and keeps every team member working off the latest version.
Here are a few of the most popular types of VCS:
- Helix Core
- Git
- SVN
- Mercurial
Benefits of Version Control
1. Easy modification of codebase:
Software development includes the continuous process of modifying programs and version control system makes this task easier. Version control software is used by software developers to maintain documentation and configuration files as well as source code. It helps developers to store different versions of software safely and in an organized manner. In pubg we often get updates.
2. Collaboration:
Programmers and developers can easily collaborate on a project through the version control system. Everyone can access the database simultaneously to view previous versions. It will be easier for them to work simultaneously as a team regardless of their location.
3. Reverting Errors:
Recall our previous pubg example, there is a chance that sometimes due to some bugs the game may crash! In such emergency cases, Version control can be an excellent help. When you need to troubleshoot an issue, you can easily access and compare the last working file with the faulty file, and decrease the time spent identifying the cause of an issue. One can even restore the older version of the file or project.
Even you might have used version control in some time. Have a look at the following lines and see if you could relate:
- Whenever I made any mistake in my presentation I undo it.
- If my mom calls me for dinner while I'm playing a video game, I'll save it and continue later.
- If I like a mission in GTA, I save those to load them later.
These are some of the real-life examples where you use version control.
Coming back to the topic, Git is one of the most popularly used version control systems (VCS). It is a distributed version control system, meaning your local copy of code is a complete version control repository. These fully-functional local repositories make it is easy to work offline or remotely. You commit your work locally, and then sync your copy of the repository with the copy on the server.
This paradigm differs from centralized version control where clients must synchronize code with a server before creating new versions of code.
You will understand all the terms used in the further topics.
Git Basics
Suppose you are working on a project where a group of 5 have to complete a task. You write some code and upload the files in a git repository (it's a collection of all project files). Now what you have is called the master branch.
1. Master:
The primary branch of all repositories. All committed and accepted changes should be on the master branch. You can work directly from the master branch, or create other branches.
2. Branch:
A version of the repository that diverges from the main working project. Branches can be a new version of a repository, experimental changes, or personal forks of a repository for users to alter and test changes.
So, imagine everything in terms of branches, and the master branch is the main one. If you want to experiment with any new things or make some changes which you're not sure about, you do it in other branches. (you can add those to the master later if you want to)
3. HEAD:
HEAD is a reference variable used to denote the most current commit of the repository in which you are working. When you add a new commit, HEAD will then become that new commit.
Now if the other teammates want to make some changes in the project they can also create a branch of it in their profile by using Fork
4. Fork:
If you need to take a copy of the main project repository to your own Git repository, you can fork the project which gives you all the permissions to make changes to the project.
why do we need fork:
- You may don’t have the write permission to work directly on the main repository. (Mostly this model is used for open source projects).
- If everyone clones and directly work on that main project repository/ branch then it’ll be very hard to manage.
This reminds me of the word clone
5. Clone:
A clone is a copy of a repository or the action of copying a repository. When cloning a repository into another branch, the new branch becomes a remote-tracking branch that can talk upstream to its origin branch (via pushes, pulls, and fetches).
Fork and Clone seem to be like same but, they are different from one another.
If you want to modify/contribute to the forked repo then clone comes into action
6. Repository (repo):
In many ways, you can think of a Git repository as a directory that stores all the files, folders, and content needed for your project. What it actually is, is the object database of the project, storing everything from the files themselves, to the versions of those files, commits, deletions, et cetera. Repositories are not limited by user, and can be shared and copied (see: fork)
Assume that everyone in your group forked the repo made their own changes, now they can't directly add them to your main repository (master) they have to send a request to the project maintainer called pull request.
7. Pull request:
If someone has changed code on a separate branch of a project and wants it to be reviewed to add to the master branch, that someone can put in a pull request. Pull requests ask the repo maintainers to review the commits made, and then, if acceptable, merge the changes upstream. A pull happens when adding the changes to the master branch.
8. Push:
It is used to upload local repository content to a remote repository. Pushing is how you transfer commits from your local repository to a remote repo.
9. Merge:
When someone makes a pull request and the project maintainers want to add those changes to the traditional master he will merge them.
These are some of the most common terms used in Git
Steps to contribute to the original repository:
- Fork the original repository to your own repository
- Clone it to your local
- Contribute to it
- Push it to your remote repo
- Send a PR to the main repo
- If the owner of the repo is okay with your contribution they will merge your changes with the original repository.
Now, you have a proper understanding of what git and version control is. To use Git in the command line there are certain commands you can learn here. Also, there is an awesome platform called GitHub which we can talk about later.
Thank you and Happy Learning!!