Version Control Systems: Git
Basics of Git
You’ve probably used or encounter an application with a Version Control System in your life. So, what is a Version Control System exactly? In this article, I will tell you what Version Control Systems are and the Version Control System that my team and I use.
What are Version Control Systems?
Version Control Systems are basically a tool that keeps track of the changes you’ve made. If a mistake was made, you can return to the earlier versions of your file before the mistake occurred. It is different from just saving your file where you only have the latest changes you’ve made. Due to this feature, version control systems are extremely useful for programmers to maintain the source code to their software.
Git
Git is the one of the most common version control system out there. Developed by the creator of Linux kernel, Linus Torvalds. Git has been used on numerous commercial and open-source projects. Git was a new type of version control system when it first launched. Git is a distributed version control system, where others was a centralized version control system. Being a distributed version control system means that it has no centralized code base to pull from. Working with a local repository is also made possible since the full history of all the changes are distributed.
Git Commands
Git has tons of commands that you can mess around with, but this time I’m just going to show you some of the common ones. There is something that you need to configure before you start using Git.
You need to set up your username and email using the following command:
git config --global user.name "[YOUR_USERNAME]"
git config --global user.email "[YOUR_EMAIL]"The above configurations are required for author information when you commit your changes.
Starting Out
There are two ways to start using Git, git init and git clone. Basically, git init creates an empty Git repository on the current directory and git clone clones an existing Git repository, creating a directory for the repository.
git init is usually used when you first start out a new project, where git clone is used to continue an existing one. Using git init doesn’t automatically set a remote to push your changes to an online repository, where git clone does (if you are given the access to modify the repository).
To set a remote, we use the following command:
git remote add origin [URL_TO_YOUR_ONLINE_REPOSITORY]After you initialize or clone a Git repository, you can start working on your project.
Staging Changes
After finishing your current work, you can see all the changes you’ve made using git status. Here I just modified the README.md file and then executed git status.
As you can see, it says that our changes are not staged. We use git add to stage them and we use git restore to discard those changes.
(Tip: we can use “.” to stage/discard all changes or a folder name to stage/discard all the files in that folder)
Once we’re satisfied with our changes, we can commit the changes.
Committing Changes
We use git commit to commit the changes that we made. Committing changes is similar to the traditional saving and staging changes is used to group those changes. We can commit our changes directly with a commit message using git commit -m “[COMMIT_MESSAGE]”.
We can see all the past commits using git log. You can see below that our changes has been committed and is ready to be pushed to an online repository.
Pushing Changes
If you don’t want to save your work on an online repository, then this step is not required. To push your changes to an online repository, we use the following command:
git push [REMOTE_NAME] [BRANCH_NAME]In my case, I would write it as:
git push origin masterBy pushing your changes into an online repository, someday you might as well want to pull from one.
Pulling Changes
The git pull command is the opposite of git push. We use this command to update our local repository with the ones in our online repository. Similar with the push command, to pull changes we use the following command:
git pull [REMOTE_NAME] [BRANCH_NAME]Like git push, the command would look like this:
git pull origin masterThough modifying the main (master) branch is not recommended as the main branch is usually used for production. You don’t want to destroy the whole software just by pushing your changes to the master branch. This is where branching comes in place.
Branching
The ability to create branches of the main source code has been the most useful tool of Git in working in a team. Git branches allow multiple people to modify the source code of your software simultaneously. My team and I created multiple branches based on the features we are making. By splitting up the work using multiple branches allow us to create software at a much faster rate.
In order to create a branch, we use the command git branch [BRANCH_NAME]. After the branch is created, we can change branches using the command git checkout [BRANCH_NAME]. I don’t really like this way of making branches. When I need to create branches, I use git checkout directly with a -b option which creates and changes to that branch in one go. Here’s how the command will look like:
git checkout -b [BRANCH_NAME]What to do after we finished working on our branch? Well it really is up to you. You could just make multiple variation of your source code. Though the main purpose of branching is splitting up work. We can combine the changes from multiple branches using git merge.
Merging Branches
The git merge command is used to merge the changes of a certain branch to the current one. For example, your friend had made a branch and you need the changes that he made in your branch. Assuming that you already have your friend’s branch locally, we can use the following command:
git merge [YOUR_FRIEND's_BRANCH]If it doesn’t have any conflicts, then the branch should be merged. Do note that when merging branches a new commit will need to be created.
Merge Conflicts
It is quite common to see merge conflicts when using multiple branches. Merge conflicts happen when two or more branches modified the same code, therefore it needs to be resolved. Usually Git is able to resolve those conflicts automatically, but sometimes you need to manually resolve them. After the conflicts have been resolved, a new commit will need to be created also.
Other Git Commands
There are plenty more of Git commands available which you can explore on the official Git page. There is also a good cheat sheet by Atlassian that you can look up here.
Gitflow
The workflow that my team and I use for our project is Gitflow. Gitflow is quite similar to feature branch workflow, but instead of just one main branch to pull from, we can have multiple ones. As you can see on the previous image (the list of branches on my team’s project), there are two branches that are marked as protected, master and staging. We have two main branches which acts as production and development branches, with the rest are feature branches.
The master branch can only be merged from the staging branch as we need to ensure that everything is working perfectly as intended. The master branch also can only be modified by the maintainer of the repository.
The staging branch can be merged from the feature branches only if at least two people have approved the changes. Here, we implemented what is called Code Review. Code review is where we review the code of each team member requesting for a merge request to the staging branch. The reason why we do code review is to ensure that the code being merged to the staging branch is bug free.
The feature branch is the branch each of us work from with a specific naming PBI-[PBI_NUMBER]-[FEATURE_NAME]. PBI here stands for Product Backlog Item which was determined during sprint planning.
Lastly, there’s a hotfix branch which is used to fix bugs in the main branch. This branch doesn’t have a long lifetime since it is just used to fix bugs.
I guess that’s all that I can tell you about Git and how my team and I use it on our project. I hope you might find this article useful and you are able to speed up your project development by using Git.
