In the context: news aggregator on Android with a backend. Version control system

→ Introduction (with links to all articles)

When I took the time to write an article about the experience of using the version control system, I talked with several people involved in the development (beginners and professionals) about version control systems - the pros and cons of use, especially their systems usage scenarios. The conversation always started in approximately the same way: everyone believed that he could answer all my questions and share his experience, but the conversation ended in different ways: someone directly said that he was not a specialist in subtleties, someone said that I would not need it - From this 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 convinces me of the need to use it, and you will write how you can solve this problem without it (if there are no people who want it, I understand ):

• Connecting additional team members to the project and starting work with a single repository - when using the version control system, questions have already been worked out: what kind of storage, what tools to work with it, how the project is structured according to repositories, how branches and tags are named. In the absence - you have to work out all these issues from the beginning and spend time on it;
• View changes (sometimes just for the concept of how much the class has changed lately);
• Evaluation of your own productivity in the number of lines of code (a subjective indicator, but sometimes it is important for me);
• Protection against accidental deletion of files or the introduction of unwanted results and the ability to return everything to its previous state;
• Checking the operation of the algorithm with the creation of a separate branch (within which not only a couple of classes are changing, but also configuration files) and the need to return to the previous option (in case the hopes did not materialize);
• The need for temporary submission of read access to the current version of the source texts;
• Additional scenarios that are rare for a single developer and are mandatory for a group or firm:
  
  
  • Integration testing systems that run tests after a commit is detected in the main or specialized branch;
  • Systems for constant delivery of updates, which also start their work after detecting the necessary changes in the branch for deployment;
  • Hierarchical systems for introducing code into the main branches, in which the prepared changes are checked by more experienced or specially designed specialists according to their criteria (security, simplicity, following standards, etc., etc.) - a good example of a description of such approaches is presented here (Distributed workflows) .

A small 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 now trendy DevOps direction) is not only the source code of the program, but also data for testing, setting up test benches, scripts for deploying stands, documentation and so on, which allows not only get 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 process of work some common settings, scripts and data are used that should be shared by the project participants, an appropriate place to store them and a way to control their timely updating is a version control system.

All the tasks that stood before 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 repositories;
• Ability to view work statistics (link);
• The ability to maintain a wiki on a project / project module;
• A decent interface for working with repositories and commits;
• There is already a certain number of repositories created during the course on Coursera.

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

For those to whom all this seems elementary and obvious questions, I left a couple of things, the analog of which I did not find for other version control systems and other git hosting:

• 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, storing the commits for this repository separately.
• GitHub's Deploy Keys - allow you to access the repository for reading / writing using ssh keys, while you can give each one your own key and, as a result, access can be revoked at will (simply removing the corresponding private key). In my case, this functionality is used for a sequential integration system to get the necessary access to the repository of the corresponding module. Functional description is also available here .

Thanks for attention!