Introduction
Version control systems allow us to store the entire history of changes that we have ever made to the project. This is very convenient, since we can always rollback to previous versions of our project. If bugs or some critical errors are found, we won`t need to completely rewrite the code, it is enough to roll back a couple of steps.
Master & commit
As we can see in the figure above, we have a certain timeline — this is a definite, large branch. It is usually called the “master” branch. In fact, this is the time period of how our project is developing. And every change that is made to the program code of our project, is displayed at a specific point on this master branch. These points are called commits.
What changes can we make? We can add some files or a new line of code, modify the code already written by us, or delete something, for example, delete some files that are in this commit. There can be a lot of such points, each of our changes will be made to this timeline as a separate commit. And it is recommended that these commits (changes) include as little as possible — for example, lines of code that change a certain, isolated functionality. This is done so that in the future we can easily roll back to the previous commit if we have any errors or conflicts, in order to avoid the need to rewrite most of our code.
For example, we find that at the last commit we have some kind of critical error that we cannot fix. But on the previous commit, everything worked fine, so we roll back to it, and work on it. And the rest of the code containing errors is deleted.
How to work with branches and conflicts
As you can see from the diagram, we have a specific branch. What does it mean? For example, some developer wants to work with a specific commit. In order not to get into the master branch (which contains the reference code), he creates a branch for himself to work with. This branch repeats a section of code before this commit. He makes himself a clone of the branch and works in it. He can also make some commits and changes here.
When the developer made the necessary commits, he can push his changes to the master branch. These branches, for example, might be called “dev” branches. After uploading it to the master branch, other developers can work on the master branch with these changes. Any developer on a project can do this.
Git also allows us to push changes from one dev branch to another, passing by the stage of transferring to the master branch. For example, a developer is working on some functionality and this functionality is used in a different requirement (different user-story), and another developer needs this change. Developer who made changes to the program code can upload the changes to the dev branch of another developer.
Let’s talk about conflicts. This happens, for example, when two developers make the changes to the same file. In this case, git doesn`t know which one to select. You need to manually change the file to resolve the conflict.
What is a repository
Our whole project (master and dev branches) is called a repository. There can be several repositories, depending on what is stored in them. For example, there may be a separate repository for a web or mobile version of application, a separate one for Android or iOS platforms.
Local & remote
Git is a distributed version control system. This means that we can copy our repository at any time locally to our computer and work with it on our machine.
This is necessary so that at any time, if something happens to the master branch, to our remote repository, we can copy the working stable version of the product from the local repository that is kept by the developer.
Process of transferring the repository to our computer is called cloning.
Imagine that on a project, test cases are stored in documents. We can contact them at any time. Git allows you to change this documentation in the local repository and then transfer it to our main repository in the master branch. This allows all employees to work even without Internet access. When we need to make a push (upload a case to the repository), we connect to the git and use certain commands to carry out the necessary.
Description of the work process in git
We have master branch (with a certain number of commits). First of all, we have to copy this master branch to our local computer in order to work with it and make changes to the code. We clone it to a computer and working on our computer with this branch.
After some changes, we make a commit so that the changes are reflected in our local repository. But we cannot easily commit to our master branch (it helps to avoid conflicts). Therefore, we need to implement a pull request — an add / change request to the master branch. We initiate this request, and another developer can review the code — he makes sure that everything is correctly written there, there are no extra lines, typos etc. Once approved, we can push our changes to our master branch. This is called merge.
After we have committed the changes to our master branch, all other developers can work with them.
How you can improve testing with Git
- We can increase the transparency of the testing process and make the reports much more structured by starting to keep changelogs of releases (mobile, backend or a big feature). The concept and structure of changelogs is well written here. For each item, we can add not only a description, but also links to the task.
- Simplification of the process of writing autotests. For example, GitLab introduced support for the Web IDE, so you can write tests and commit them to the desired branch right in the browser, spending much less time on it.
- Read from the code. For example, a developer has laid out a new screen filled with objects. To make sure that the colors used match the design system, we open its code and sequentially compare the html color codes directly with the list from the design system.
- We can setup automatic testing pull-requests. It is also knows as “continuous integration”. It helps to perform pregrammatic sanity checks and identify bugs on this stage.
Outro
We have a master branch — the timeline of our product, and we make each change in a separate commit. We can also have separate branches, for example, if the developers decided to do something directly in this particular period of time. All these branches will be called repositories — this is our entire project.
Also, the developer or tester can realize the review procedure, can clone the repository to the local machine and work from it. After he made the changes, he commits them and starts the pull request procedure. After the approval of another developer, he can merge the changes into the master branch. This process is repeated constantly.
