Pure Version Control

Introduction

Hello everyone, Seryoga is with you again. I apologize for the long silence and absence in the comments. There was no time on the Internet at all. We released the next version of GPA . By the way, this is the fifth time this year - a record for our team.

At this pace, something else is very difficult to do. Especially when, in a short time, you need to port to OsX, give a “human” look to the version under Ubuntu and at the same time get inside the isolation of the Windows 8 Store application. Again there was a lot of controversy about the look and feel of the System Analyzer. It is very difficult to make a tool beautiful, simple and easy, and at the same time very useful.

By the way, about OsX - the impressions from it are ambiguous. At least the number of claims against it during porting surpassed that of Ubuntu. XCode, the Mac integrated software development environment, deserves special mention. She doesn’t even warn that I have some unsaved files left and she cannot save them. Just do not count how many times we had to re-set the build settings for all projects of our product. There are a lot of projects, the settings are completely intuitive and they take a lot of time to fiddle with - it is easy to be unhappy here.
')
Personally, I am sure that the IDE is obliged to save any changes as soon as possible, without any of these “are you sure?” And requests from the user. For many years of work, I have already developed a reflex to press Ctrl + S almost after each semicolon. Unfortunately, this does not work when the project or assembly settings are changed, which leads to annoying misunderstandings. If it becomes necessary to cancel a change, then in this case an experienced programmer always and everywhere adapts the source version control system.

Store codes in the version control system

Unfortunately, the culture of using the source version control system almost always comes from above. A programmer using such a system on his own initiative, even for his experiments, is a rarity. Therefore, the presence of the programmer and his use of such a system, the ability to create labels and branching is a bright sign of professionalism. A list of changes in this system - confirmation or denial of this feature. For example, the change “corrected the mistake of such and such, and such, replaced A with B, optimized it and accelerated the assembly time” immediately betrays a non-professional. If such a change reveals an error, it is not immediately clear where to look. And if due to an error it is necessary to cancel the change, then all the listed fixes and improvements will be canceled, although there was only one failure. Another similar description of changes may indicate a person who is unable to focus on one thing, but constantly jumping from one class to another, trying to do a lot of things at the same time and with difficulty completing what has been started to the end.

The correct approach to using a version control system is as follows:

• Changes to be made should be small and contain some one specific and complete action. Even the correction of some errors is sometimes better divided into several successive changes. However, it’s not worth much to get involved in the system and add each line of code to the system separately. Here you need to be guided by the voice of reason. With intensive development make 1 - 4 changes per day - normal. At one o'clock - bust. In a week - an obvious shortage.
• When working in a team at the time of making changes, each time it is necessary to synchronize with the changes of colleagues, so that changes are put into operation as quickly as possible and errors are found as soon as possible.
• When working on a change, you first need to decide what you are going to do now and do just that. All ideas of what else can and should be corrected should be entered into the TO_DO list, and not rush to implement them right here and now. You need to look at this list every time when the question “what to do next?” Arises. The entry from the TO_DO list is then usually transferred with minimal changes to the name of the change being made.

Version control system is also a system for generating reports on the work done. Take changes over a period of time; summarize some too detailed details; add common words and screenshots - and the most correct report of the programmer is ready. If a lot of work is done, and the changes made to the system are counted on the fingers, it means that the programmer is busy with something else: research, testing, drawing presentations, sitting on the Internet and much more. All this can be very important and necessary, but it does not replace the main thing - writing new code and developing the product.

I'm on my home netbook to manage all my experiments, including examples for these articles, using Git. Under Ubuntu, it is easily installed from the repository and you just need to create a database by executing one command. Pleasantly pleased with the fact that he does not need the operation “check out file”. You may not remember him until the changes are made to the database. In general, I recommend trying and practicing.