What is git and why should I use it?

What is version control?

When we write code in a team of developers, we can expect others to work on the same code base. How can we achieve that?

One way is - one person makes the changes and shares the project with next person, then they make more changes and share it with next person. But this way only one person can work on the code at a time. Another way could be - they all use the same base code and make their own versions. Then someone/everyone should sit and merge all the changes manually.

Above methods seem very tricky. So to solve these issues we make use of a version control system like git, mercurial etc.

With git we can make multiple versions of a code and put them in branches, and when it is ready we can raise a merge request (pull request) and get it merged in the main code base. This way, people can continue working on their feature and only merge the code when they think their code is ready. Finally all of the code will land in the main code base (master branch)

What is git?

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. It is nothing but a CLI tool which helps manage the versions of code on a machine.

Git serves as the foundation for many services, like GitHub and GitLab, but you can use Git without using any other service. This means that you can use Git privately or publicly. However, it makes sense to use github or gitlab if you want other people to be able to work on the code.

Basic concepts

clone

git clone is a Git command which is used to target an existing repository and create a clone. We usually clone a github or gitlab repo to our local system. try out -

git clone https://github.com/mridulganga/mg-bot

cd mg-bot
git status

fork

Git Fork means you just create a copy of the main repository of a project source code to your own GitHub profile. If you like a project and want to make modifications on it, you can make fork a copy of the repo in your github account and make whatever changes you like.

local repo & remote repo

In simple terms - local repository is a git repository on your machine and remote repository is a git repository on github or gitlab. We can perform various operations like push, commit and pull to sync the files between multiple repositories.

Another thing to note is - we can have multiple remote repositories connected to the same local repository. We make use of git remote for this, which we will learn in this series.

commits

Whenever we make any changes to the code, we stage those changes by using git add and then commit it using git commit. Commiting the code creates a snapshot of the code in form of a commit, you can checkout any commit to get that version of the code. This is like a history of all the changes in your repository. try using the command git log in a local git repo folder to see a list of commits.

git add .   # stage all the files which have been changed
git commit -m "what changes you made"

branches

If there are multiple people working on different features, they will have different versions of the code. To achieve this, they can make branches. Each branch can have a different version of the code. When one of the branches has a ready code, that branch can be merged with the master branch to integrate the feature in the main code.

Branches make it really easy for multiple people to work on a number of features at the same time. try -

git branch # tells the current branch

git checkout -b new-branch

pull and push

Two of the most important commands. Pull - git pull is a Git command used to update the local version of a repository from a remote. git pull gets the latest changes in the current branch and other metadata from the remote like - remote branches and tags.

git pull
git pull origin master  # pull a specific branch from origin remote

Push - git push is a command used to send the local code changes (commits) to the remote. git push will find all the commits present on the local branch which are not present on the remote and it will apply those commits on the remote branch. We generally do a git push when we commit some changes locally.

git push origin master

staging (git add)

Staging is like selecting a few files among the changed files. Following which we can create a commit.

To stage all files

git add .

To stage a particular file

git add <changed file>

pull request

When we want to merge changes in a branch to another branch (like master), we create a pull request. Pull request is called merge request in gitlab. We raise a pull request when we are ready to integrate changes of a branch into master or some other branch. When we raise a pull request, we can keep adding more commits to the branch and it will automatically get added in the pull request as well.

Below is the UI when we create a new pull request.

Extra

Code Reviews

When someone raises a pull request, others can review their changes and give approvals. More approvals mean that people think that the code is good and should be merged. If however someone finds issues in the code, they can put review comments, which the dev can fix in a new commit. This helps ensure that only good quality code gets merged in master.

Git Merge

When we have two different branches lets say branch1 and master. We want to merge the changes of branch1 into master. We make use of git merge. Whenever a Pull request (PR) gets merged - it internally calls git merge. There are different ways of merging a PR -

Copy all commits from pr while merging
squash all commits into one commit while merging
```
git merge master
```

Git Rebase

If we have three branches b1, b2, master and we want to apply all the changes in master. We merge the branch b1 to master. Now b2 has some commits not present in master, and master has some commits (from b1) which are not in b2. In this case we can rebase b2 to get the changes in master into b2 branch.

git checkout b2
git rebase master

Conflict

When we are rebasing or merging, we can get some conflicts. If two people worked on the same line of code, then git can't figure which code to keep and which to remove. This is when we get a merge conflict. To continue our merge or rebase, we must first resolve the conflicts and then continue.

NOTE: When merging code to the master branch, we normally make use of the pull requests.

These are some basic terms involved in Git. We will learn more about them in this series.

I'm thankful for all the times my audience has commented on this article.