Tools used at Droptica – part 3 – file repository

It is obviously necessary to look for and take advantage of tools which can be used when delivering Drupal development services. It's time for another dose of information about our work at the Droptica company. Today we'll cover file versioning and application testing.

Subversion

Initial projects implemented with Drupal (still as OPENBIT) used the Subversion system (also known as SVN, project website) for file versioning. One of these projects was the intranet system for the Telefonia Dialog S.A. company (case study).

SVN, like other versioning systems, allows you to keep a history of file changes. The main difference between SVN and GIT (at which we'll take a closer look in a moment) is that in SVN the repository is kept on one remote server to which everyone introduces changes. This forces you to commit only to the remote server, you can't only commit locally infinite changes. With SVN, difficult to resolve conflicts arose sometimes (for example, when two persons worked on the same files). Managing and merging branches was also inconvenient.

GIT

In 2012, we started our first trials using GIT to work on projects. The first "weird" thing was that in order to send changes to the server, the "commit" command was not enough, an additional "push" command was needed. This additional step was not present in SVN. This is due to the fact that GIT is a distributed system, i.e. the repository is not kept on one server, but in many places (e.g. on programmers' computers, test servers, etc.).

When using GIT, we commit to the repository that we have locally on the computer, and then synchronise our changes (commits) with another repository. Usually, one remote repository is established as the main place for pushing the changes. However, there's no reason for one programmer not to push their changes into the repository located on the computer of a second programmer (access needed, e.g. by SSH), the second programmer completes the task and pushes the changes to the remote main server.

GIT works very well when merging the changes made in the same file. It is also convenient to merge branches in the repository. Many users find GIT to be a very good versioning system, and we fully agree with this opinion.

GIT GUI

GIT is a console application, i.e. in order to use it, you must enter commands in a terminal. It can be difficult for beginners, so we recommend using a graphical overlay for GIT first. Some examples of such programs can be found below:

• Smartgit (Linux, Windows, MacOS), a paid program, but has a lot of options and a clear interface. Some people at Droptica use this program.
• GitKraken (Linux, Windows, MacOS)
• GitEye
• Giggle

There are many other programs of this type, just search using Google for GIT GUI. However, not all of these can work on Linux, Windows, as well as MacOS.

Git-flow

In GIT we can create branches. With these branches, it is possible to work on the task next to the main, already tested code. In short, the work goes like this:

• we're starting to work on a new programming task
• we create a new branch
• we perform the task in the branch
• we test the task in the branch
• after passing the tests and the code review, the branch is merged with the main branch

Such branch operations require several repeated commands. In order to streamline this, Git-flow – an extension for GIT, adding new commands – was created. A detailed description of the branch creation model used by Git-flow can be found at http://nvie.com/posts/a-successful-git-branching-model/

We use git-flow at Droptica and find it to be very useful. it allows us to eliminate errors in the tasks being implemented, before merging the code with the main branch. This way, we can be sure that the developer branch contains only the tested codes.

Github

We keep most of the project codes in private repositories on GitHub.com. We use Github because it provides stable servers for storing files and offers the "Pull request" option.

Pull request is a request to merge one branch with another, e.g. merging the branch of one programmer with the main branch of the application. During a pull request, we can see a summary of the changes between the two branches. If a programmer made a few commits in their branch, then all commits will be "merged" into one change. We will see then a clear comparison of changes in the code, that will be made after the acceptance of a pull request (a merge operation will be carried out).

 
This preview allows for a very easy review of the code. This way, the main programmer of the project can quickly verify whether the changes introduced by another programmer are correct and fit to be merged. Code review in a pull request carried out by another person ensures that the application code is always known by at least two persons.

If you want to learn more about Git, be sure to read the "Pro Git" book. A digital version of the book is available here. You can also order a physical copy of the book.

At our Drupal development agency, we can't even imagine creating websites using Drupal and other technologies without Git now.