Let’s look into the practice of applying the Git version control system in the collective development of solutions on the 1C platform

What is Git?

Git is now one of the most popular Version Control Systems. If you know this product, you can go directly to the next part of the article. But as practice shows among the 1C developers very few imagine what Git is and why it is needed. And those who know, perceive this software product as “something related to a console and old Linux”. And they are right. The Git interface, to put it mildly, does not have much interface. But it’s not for this that the developers are so fond of Git. Strictly speaking, this is one of the first and time-tested VCS. It is used, in particular, in the development of the Linux kernel.
Currently, Git has gained wide popularity thanks to the development of the GitHub project. In the modern world almost every software developer knows what is GitHub and why it is needed. It is somehow connected with programming languages of general purpose (C ++, Java, PHP, etc.). And many people who are not connected with the development of GitHub software are also familiar with it, because it is always possible to download the latest version of this free software from there, to the extent that GitHub is used as the site for the collective development of this software.
The main alternative to this resource is equally well known Bitbucket. But Bitbucket uses the JIRA stack to organize local developer depositories. Which one to choose depends on your your taste. You can find many discussions on this topic on the Internet, but it’s not the main purpose of this article.
I’m familiar with Git for a long time. In addition, 1C projects most often have a specific internal purpose, so placing their code in a public repository is meaningless, if not to say “wrong” in relation to the customer. Therefore, commercial software should be developed on internal closed repositories.

How does Git work?

It’s nothing special: choose a directory with source code of software or just files and execute the command Git that you need to create a repository for this directory (local and remote – that is why Git is a distributed version control system).
Then you work with the source files in the directory for which you created the repository. Once you have finished making certain changes that you can save as a version (compiled, run, checked that in some way it works, for example), you execute the command git commit and save changes to the repository. To transfer the changes to the remote repository, execute the command git push.
Actually, it’s quite logical that there should be a special feature of getting changes made by other developers in the local repository. To do this, there are operations like git pull – to get a full repository and git fetch to get the changes.
When receiving updates, there may be so-called “merge” process, when the same code file was corrected by several developers. Merge conflicts also appear in the case if different developers have corrected the same line in the source file. In this regard, different branches of development may appear. But these are more complex processes of using version control systems. In 1C there is a certain specificity, which makes the given Git functional unnecessary.
For a general understanding of how Git works and most of these version control systems, there is no need to understand all the subtleties. The main idea is to understand that there are local and remote repositories. The repository stores the entire history of changes made to monitored files. The changes are fixed in the repository with the commit command. The local repository is synchronized with the remote push and pull/fetch commands. Thus, you have the entire history of modifying the source module files, including changes made by other developers.

What do we need it for?

Advanced 1C developers probably think: why does the 1C developer need Git, if there is one’s own VCS built into the “Configuration store” platform? Many thanks to 1C for this functionality. It is also worth noting that VCS owns not all even more advanced modern ERP systems and platforms for developing business systems.
Unfortunately, the 1C configuration store has certain disadvantages:

• Extremely low comparison speed (comparing the two versions in the vault can take from 1 to 15 minutes), which makes this functionality almost useless.
• There is no branching. The entire development process in 1C is strictly linear.
• Lack of detailed historical information on the facilities. In fact, to obtain such information, you need to compare versions as many times as the object has changed, but then you will not be able to get generalized information.
• Lack of many “goodies” of modern VCS, such as activity statistics, built-in bugtracker, etc.
• Terrible interface.

Not all these shortcomings can be easily corrected. In particular, it will not be possible to add branches because of the specifics of most 1C projects. But at the current stage of its development, the 1C configuration store allows for collective development, preventing collisions, while not giving to the development manager any additional tools commonly used by developers of projects in general languages.

Code review

Perhaps the most important process, which due to a lack of tools in the development teams 1C is almost never practiced, is the so-called Code review. Volumes of literature have already been written on the topic, why it is needed and how to use it correctly. For example, you can view the translation of a popular provocative article.
In fact, Code review allows you to do better at the following aspects:

• The programmer, knowing that others will look at his code, takes more care about the quality of the code, writes it more correctly and accurately.
• In the process of discussing and adjusting the code after the audit, two useful actions occur simultaneously: the quality of the product and the qualification of programmers developing it

What do we need for Code review? There is a desire to answer this question: in an instant “only the code itself and nothing more.” But, unfortunately, this is not the case. A code review would be good only for recently written code. In addition, the specificity of the development in 1C is that in most cases the solution is not developed “from scratch”. There is a sufficiently large amount of initial code, which, as a rule, exceeds by several times the amount of development performed by the project team. Therefore, it does not make any sense to look at all the modules in their pure form.
Thus, we need a history of changes across all modules, with quick access and analysis of it. This is where the use of Git arises. It remains only to determine the means of presenting the summary information, so that it would be convenient to work with.

GitLab

GitLab is an open project for deploying an environment similar to GitHub for its own development team. Of course, there are many analogues, but GitLab is probably the most popular project of this kind. For commercial use, it is paid, but the amount is quite acceptable, even for a modest budget.
In general, everything is very similar to the GitHub interface, so it’s not difficult to get an understanding of it. You can download and install GitLab from the official site [4]. By the way, there are no Windows distributions (which is not surprising). But there are so-called Omnibus Packages, which make the process of installing GitLab under Linux a matter of two commands in the console.
There is an even simpler version of the installation – to download a ready-made virtual machine with pre-installed GitLab [5]. There is such on TurnKeyLinux. It once again confirms the popularity of the software product.

What is there to do?

So, we decided what we will use, how and why. Now only one more thing left ‒ put everything together:

1. Download and install Git for Windows. After installation, do not forget to assign the path to git.exe in the PATH variable, if this does not happen during installation for some reason.
2. Read the contents of the article on Infostart, then download OneScript from tge resource and install the engine and scripts.
3. Deploy the virtual machine with GitLab [5], create users and a project. When you create a project, GitLab will write you the path to the repository. SSL is not needed internally, most likely you will choose HTTP access.
4. Now we will configure the repository. It would be desirable to remove everything that does not contain the code, namely we add the following lines to the .git/info/exclude file:
5. Then type something like (at this step the initial GIT repository is initialized):
   Then the command:
   starts very long process of synchronizing the storage with Git. During this process each version of the configuration from the repository will be extracted and analyzed. The process is very slow, it took several weeks in my case.
6. After completing this difficult and long process, you can go to GitLab and enjoy the newly discovered functionality.
   For Code review, the functionality is shown in Fig. 1. Fig. 2 shows the so-called Blame View. It is the special feature of the system to determine the authorship of a particular line of code. Strictly speaking, it makes the favored by developers author’s commentary simply pointless.

In the end, having mastered this tool, you can bring the development to a new level, using the same capabilities that have long been at the disposal of colleagues who are developing in general-purpose programming languages field.
Do you need to install and configure git or transfer svn to git? Contact us.