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
git checkout -b new-branch
We now know what commits are. Tags are ref's that point to specific points in Git history. Tagging is generally used to capture a point in history that is used for a marked version release (ex v1.5.1)
We can checkout tags like branches or commits.
git checkout v1.5.1
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
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.
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.
