Familiar with Google Docs? Well if you are, it is safe to assume that you are aware with the little ‘Version History’ tab which allows the writers and the involved people to check and keep track of all the changes made in the doc. at any given point in time. A handy tool, isn’t it?
Now imagine instead of a sheet full of paragraphs, there are files full of hundreds of lines of codes. And unlike a single doc, there are tons of different files, constantly updated.
In a scenario like this, where there are thousands of line of codes at play and the end result i.e. The Mobile app is what a business’s future depends on, it becomes even more important to have a software that would keep a tab of all the changes made in the code files.
This is where a Version Control Software comes into the picture.
Why is Version Control Important in Software Development
As the name suggests, a Version Control Software enables the mobile app developers to track the different versions of the software development cycle and make changes in them. This ability to track all the changes happening in code and then the option of undoing the changes is what makes Version Control an important part of a mobile app development company’s process which involves multiple developers.
Now when it comes to Version Control, there are a number of software available in the market in the present time. Let us look at some of them –
Available Software for Version Control
Although in its GitLab Survey, the leader of distributed software found that 98% of the users make use of the Git open source tools and over 92% of the developers use Git as the version control language in the app development process, there are a number of reasons why developers might look at Git alternative. Some of those reasons can vary from – GitHub pricing structure and the fact that Github is launched on both iOS and Android, an aversion to Octocat, or a simple comfortability level with version control language which is not Git.
Whatever your reason might be, here are the alternative of Git for version control –
Now even when there are a number of alternatives available for Version Control and at Appinventiv, we have a first-hand experience on working on a lot of them, because of varying customer requirements, we are indeed partial towards Git. Let me tell you why.
Why Appinventiv Uses Git for Version Control
1. For its Lightning Speed
Out of all the version control software in the market, the speed at which Git log and Commit elements work is unmatchable with any other. And when your team of developers is working on a platform, it becomes absolutely necessary that the software is fast.
2. For the Ability to Work Offline
When you work on a software that relies on the internet, it can be risky when you are on the move and you lose connection with the central repository. But, this is not the case with Git. With Git, you can do almost all the tasks on your local machine – commit, browse the project history, create branch, or merge.
3. For the Undo Relief
Git comes with an ‘undo’ command that lets you correct and reverts the whole commit. In fact, it even gives you the option to restore the ‘deleted’ commit through its Reflog option.
4. For the Backup
When the team works on Git, every single clone that the team has on their machine comes with a usable backup. In addition to that, almost every single Git action only adds the data and doesn’t delete it.
5. For Making Useful Commits
When our developers’ team commit a set of unrelated changes – taking some features from A, making some bugfix in another – it can be very difficult for the other team members to make sense of what happened and it can be difficult for them to roll back A’s features if it is causing issues.
Git solves this mess by creating granual commit. Through its ‘staging area’ concept, one can easily find out what changes would be included in the next commit, even when you are down to looking at single lines.
So these were the five main reasons why we use Git here at Appinventiv. Now that we have looked at the why, it is time to look at the How. How we incorporate Git in our Version Control Process.
Let’s get to that now.
Process of Version Control When Using Git
Repository Creation
The aim of Git is to manage a set of files, a.k.a Project. In order to do that, Git saves all the information in data structure which is known as Repository. A repository consists of the app’s source codes, the resources, and the data sets. Basically, it has everything which defines the app project.
Now, there are two ways of getting a repository on Git. You can either use a local directory and convert it into a Git repository using the command line or you can copy an already uploaded Git repository into yours.
When you create a repository, you usually get two options – Public and Private. Public repository is the one which can be viewed by other developers using Git and the Private one, on the other hand, is one that can only be viewed by a few people.
Branching
Next to Repository Creation is Branching. In a company like Appinventiv, where at any given point of time over 15 – 20 developers are working on one project, it is not uncommon for the developers to share the same source code and work on it. What happens is that as some developers are busy fixing issues, others might be implementing some features.
In a situation like this, we need a system which makes it easy to handle different code versions in the same codebase.
This is where Gitflow comes into the picture. Gitflow is a framework used for branching systematically and efficiently.
Before we go on with how the Branching process works on Gitflow, let me explain the concept with an example.
Suppose there are 5 developers in your team and they are working on the development of an Instagram like app. Now the individual app features like suppose Feed and Notifications are denoted as Module 1, Module 2 and so on and so forth. Now these different modules are development branches, which after worked on are merged with the parent branch or Master.
The moment a developer adds a branch, they create an independent development line, which isolates their work from that of their team members. The different branches are then merged into the parent branch.
Branching is the method which allows the team members to identify which all changes they should expect and is what makes the backtracking easy.
In our projects, we usually keep these branches –
- Master Branch
- Development Branch
- Feature Branch
- Release Branch
- Hot Fixes and Bug Fixes
Commit
The changes that a developer makes in the individual file is known as Commit. The changes or commit is added in the local repository and not into the server. Next, our developers follow the habit of writing a commit message, wherein the description of the commit (changes made in the file) are posted, so that other developers also know the details of the changes made in the file.
Push
When you commit in the local Git repository, what happens next is that the changes are then sent to the server, which is known as the Push.
It is fairly easy to push the commit history to the server when you are the only one working on a file, but in case there are other developers involved in the process too, you will have to pull the changes before you can push your set of commit to Git.
Next, we will look into what is done in Pull Change step.
Pull Request
When more than one developer is working on the same file, what happens is that some commit might get pushed on the server by the other developer before you push them. And when that happens, conflict happens (more on that later).
To avoid uploading the same codebase twice on the server, developers first pull the changes from the repository and ensure that the codes are different. Now, generally, when two or more developers work on the same file and push their commit on the server, the option to ‘Merge’ comes.
Let’s talk about Merge next.
Merge
Merge is the step where developers club all the branches first with each other and then with the master or parent branch.
Everytime a deliver enters a Push command, they get a Merge option, which then asks them the branch with which they would like to merge the commit.
Now at the Merge stage, occurrence of Conflict is very common. Conflict usually occurs when the two branches that you are planning to merge got changed in the same part in the same file. What happens here is that Git is not able to figure out which version should be used.
When this Conflict issue comes, Git offers two resolutions – Automatic and Manual.
As the name goes, one is where Git finds out the issue itself and in the latter, the developers have to do it manually. At Appinventiv, we focus on Manual solving of Conflict as eliminates even the minute chances of bug occurrence.
While we are using Git to do version control of our app development process, what happens simultaneously is Issue Tracking.
Since, we are a big follower of Agile and trust Agile for our mobile app development process, we understand the importance of handling multiple development processes at the same time. And with the issue tracking feature, it becomes a lot easier for testers to keep a real time look out on the code written and pushed on Git server.
We make use of the ZenHub board to monitor the workflow in each repository. The board allows us to keep track of the priority of the suggested change and also help the developers update their comment on the board in real time.
strategies your digital product..
