In a section: the news aggregator on Android with backend. Version Control System

→ Introduction (with links to all articles)

When I set aside the necessary time for writing an article about the experience of using a version control system, I spoke with several people involved in development (novices and professionals) about version control systems - the pros and cons of using, the features of their systems, usage scenarios. The conversation always began in approximately the same way: everyone believed that he could answer all my questions and share his experience, but the conversation ended differently: someone just said that he was not an expert in subtleties, someone said that I would not need it - from here we can conclude that version control systems are not as simple a collaboration tool as many people think of it.

The issue of using a version control system for the generated code and artifacts when working alone is open. In this regard, I propose to play the game - I will write situations in which the use of the version control system helped me and convinced me of the need to use it, and you will write how to solve this problem without it (if you don’t find anyone, I will understand ):

• Connecting additional team members to the project and starting work with a single repository - when using the version control system, the following questions have already been worked out: which storage, which means to work with it, how the project is structured according to repositories, how naming branches and tags are performed. In the absence of - all these issues will have to work from the beginning and spend time on it;
• View changes (sometimes just to understand how much the class has changed recently);
• Evaluating your own productivity in the number of lines of code (a subjective indicator, but for me sometimes it is important);
• Protection against accidental deletion of files or the introduction of unwanted results and the ability to return everything to the previous state;
• Testing the operation of the algorithm with the creation of a separate branch (within which not only a pair of classes, but also configuration files change) and the need to return to the previous version (in case the hopes were not met);
• The need for a temporary presentation of read access to the current version of the source code;
• Additional scenarios that are rare for a single developer and mandatory for a group or company:
  ')
  
  • Systems of integration testing that run tests after a commit is detected in the main or specialized branch;
  • System of constant delivery of updates, which also start their work after the discovery of the necessary changes in the branch for deployment;
  • Hierarchical systems of introducing code into the main branches, in which the prepared changes are checked by more experienced or specially targeted specialists according to their criteria (security, simplicity, following standards, and so on ...) - a good example of describing such approaches is presented here (Distributed Workflows) .

A slight digression from the obvious things:

After some time working as a programmer, it comes to understanding that the result of the work of a modern developer (especially in the current DevOps direction) is not only the source code of the program, but also data for testing, setting up test benches, stand deployment scripts, documentation, etc., which allows not only get the executable code, but also configure the necessary environment for its execution, as well as generate documentation for the development and operation of the project by other participants. So, if in the course of work some common settings are used for all, scripts and data that should be shared by all project participants - a suitable place to store them and a way to control their timely updating is the version control system.

All the tasks that confronted me, and which I could imagine in the near future, were solved by the mainstream solution - git and the corresponding hosting for it - GitHub .

Interesting links about git: book | video from Yandex .

The choice of GitHub for me was determined by the following criteria:

• Reasonable prices for hosting private repository;
• Ability to view work statistics (link);
• The possibility of maintaining a wiki on the project / project module;
• A decent interface for working with repositories and commits;
• The presence of a certain number of repositories created during the course on Coursera.

As a client, I use the usual SmartGit and the command line client (knowing it at some points is just necessary).

For those to whom it all seems elementary and obvious questions, I left a couple of things, which I did not find an analogue for other version control systems and other git-hosting sites:

• Git submodules - Submodules allow you to contain one Git repository as a subdirectory of another Git repository. This makes it possible to clone another repository inside the project, keeping commits for this repository separately.
• GitHub's Deploy Keys - allow you to access the repository for read / write using ssh-keys, while each can give their own key and as a result - withdraw access at will (simply removing the corresponding private key). In my case, this functionality is used for a system of sequential integration to obtain the necessary access to the repository of the corresponding module. A description of the functionality is also available here .

Thanks for attention!