How to overcome discomfort when using version control systems?

How many times did not try to understand, does not work. How do people work with the version control system and find this approach to development convenient?

Made an edit to the code - entered a command in the terminal for pushing - everything was recorded. I have never met a version control system that would offer online development with something like this:

  1. Go to the online resource
  2. Create a project
  3. Specify the data of your remote server to store the code
  4. Getting started ...

In this case, when saving files, each edit automatically creates additional copies of the project with different versions of code. And there is an opportunity to return to any state of the project at any time.

Such version control systems, as I understand it, do not exist. I can not only understand why, because this approach is dozens or even hundreds of times more convenient (for me, perhaps for someone else). There is no need to set up, download, work in the terminal ... at least take it yourself and start a start-up project.

  • 2
    This is already there - gitlab. Even simpler :) it's like github. There files can be edited online. Each save will commit. And you can take something like c9.io - KoVadim
  • and right without a terminal everything will automatically be saved on my server and after saving all my edits will be immediately on the page? - Floyat
  • 2
    If you configure autodeploy, then yes. - KoVadim
  • I also do not understand - “ как люди работают с системой контроля версий и считают такой подход к разработке удобным ” (albeit for other reasons). Therefore, I mainly use tar for myself (from time to time playing with git (now) and trying to figure out how to actually work with it correctly (or convince myself that this is really convenient for me)). - avp
  • GitLab has integration with Koding, this is an online IDE. Allows you to conduct all development online, installing nothing and not customizing. - Nick Volynkin ♦

6 answers 6

The answer to the main question:

How to overcome discomfort when using version control systems?

The practice of working in a team will help first. Often there are abnormal situations that are difficult to handle without git:

  • need for rollback
    When using git, it is done in one command = 10 seconds, manual masturbation does not guarantee a correct rollback and is done longer, with long-running projects there are a lot of versions. It is equally easy to roll back both the file and the version as a whole.

  • development of a single project by a team I came to work very comfortably - I executed one command = 3 seconds, and you already have everything your colleagues have done. Leaving work - spent 3 seconds - all your changes in turnips.

  • view IDE code evolution history
    And this is generally megafish. The code in the brain becomes directly alive, three-dimensional) Everything is very beautifully displayed in NetBeans, for example - everything is immediately clear what's what. And it always helps to find the culprit of the crutch.

  • loss of sorts
    Like when I was in the first year and didn’t know about version control systems yet: the project was written for a month - a framework for 3D graphics. And then bang - picked up a virus from the VC, which I deleted it to hell. It was a shame - not to convey.

  • simple patch between servers
    Deploy a project to a combat server (if we are about server development and an interpreted server language) - done in one command ( git pull or git clone - as you like). No crap, dancing with tambourines and confusion with the rights to the file.

  • version branching
    It gives a functional so that your developments in the project and the development of the prog group do not affect the main course of development and merge only at the task completion stage into the main version. Given that the changes can still be calmly sent to the turnips (all the other advantages work).

  • development management
    Manual programmers can turn into hell without a version control system with commits. Because there is no quick way to see what a colleague has done, there is no qualitative presentation of his works, it is impossible to evaluate the correctness of works by sight. And when there is a system - in the history of commits, you can very quickly understand what has been done well, what has been done is not very good, what needs to be quickly corrected, where to hold an explanatory conversation. A beautiful display of the commit history in IDE, with highlighted changes / deletions / inserts - this is an additional strong bonus, it becomes very comfortable to evaluate work.

So, the need to handle these extraordinary situations 100 times outweighs any discomfort. And then, you quickly get used to the gita and already consider it the standard of logic. If we use git from the console, - do not forget about the console interface - the Tab button prints the command for you by the first characters, the up-and-down arrows enter the previous typed commands in the input field - very convenient.

Made an edit to the code - entered a command in the terminal for pushing - everything was recorded. I have never met a version control system that would offer online development with something like this:

But this is no longer a version control system, but an envelope UI.

The question is relevant, because when encountering cvs / git, I also experienced some discomfort. Crumble patterns. But only then realized how git cool thing.

  • 2
    "simple deploy between servers" - set us up so that in one team? :-) - Pavel Mayorov
  • one
    Please do not confuse interpreted languages ​​with the general case. It would be so simple - no CI would have appeared. - Pavel Mayorov
  • one
    There is nothing to configure - we put git on the server. Strategy git pull: we do once a clone of the project, we create configs and once we configure (configs of course in .gitignore lie). After this warmth comes as a single git pull command. Strategy git clone: ​​Create a bash script / pkhp script, put it in the ~ / deploys folder, there is a clone command in it. Configs in the project itself, but there are several of them - an deploy script creates a symlink to configs and to static folders. With both strategies, database changes after pull / clone hooks are pulled. clone is more suitable for deploying several servers, as it works iron. - Goncharov Alexander
  • one
    I repeat: "Please do not confuse the interpreted languages ​​with the general case . " - Pavel Mayorov
  • 3
    That is, you reduced the deployment task to the file delivery task and say that the git "makes a simple deployment" :) Actually, the deployment problem is precisely that the lead does not need to compile everything with its hands every time how to upload changes to the server . - Pavel Mayorov

With this approach, one developer per day can generate (5-30) * 8 commits (this is about). Ten developers will generate (5-30) * 8 * 200 * 10 commits for the year. This is approximately 80,000 - 480,000 commits per average project in a vacuum. Moreover, in the future, such a detailing of the principle is not important and will interfere, because the main questions that are asked to the version control system "How did you fix this bug?" "What changes were made to implement this feature?" "Who was the last to edit this file and why? What else did he change at the same time?".

When answering these questions, it is not interesting to anyone that you saved the file 100 times introducing a new feature, rewriting some pieces over and over again to achieve the expected behavior. It is important that the state of the project was before the start of the work on the features and after. The rest will be informational noise.

Commits and branches help to correctly mark these stages of work on the code in the version control system. All these tools allow you to structure the history of software changes so that it is more convenient to analyze. To make this story even more convenient to analyze, the developers in the team agree exactly how they will use the hard currency (at what moments to create branches, what commits, whether a new commit can include fixing a bug and developing a new feature (sic!), How branches will merge or changes between branches, etc.). All this requires additional manual or semi-automatic work (IDEshki help to do something with the mouse for example). Yes, it distracts from the uncontrolled flight of the thoughts of the programmer when writing programs, but it helps a lot if the programs live and support for a long time.

    The version control system that you propose would have one serious flaw — it does not involve atomic operations — commits, changesets . Those. it will save changes in files, but there is no guarantee that the project will be complete and operational at the time of this saving.

    This was quite a serious and relevant problem in the days of CSV / VSS - the then version control systems, although they learned how to save changes to files, but they have not yet grown to the concept of changeset.

    The search for, for example, the “stable version of yesterday morning” turned into a difficult quest — one had to literally guess the time to take the fortune. In some cases, there was no stable condition at all - everything was mixed in a pile while several people were working simultaneously.

    Since then, version control systems have begun working with atomic changesets — changesets. The developers are so tired of the jumble of individual files that the presence of changesets has caused a sharp increase in the popularity of SVN as a replacement for CVS.

    Only the developer himself can decide what should be included in the changeset — the version control system is simply unable to assess the need to create a changeset.

    Therefore, the commit operation still requires manual button presses.

      What you want is achievable in theory. And for this you do not need to implement a new version control system, you can be based on the existing one. For example, on Git. The technical process you need is completely realizable in the new client and does not even require other developers to adapt to its way of working.

      It might look like this:

      1. You create a project on the online service, get the repository URL
      2. You run a client, make branches (for a long-term history, where you don’t need to send small rooms without a great need), for example master and development . The branches created in this way are considered to be the main ones.
      3. You go to the branch in which you will work ( development )
      4. You make a change and ... Magic begins. The client detects changes, sees that he is in the main branch, you cannot write there. He makes a separate, your personal feature-branch, which will only be local, and writes a commit to it.
      5. You make another change. The client finds him, sees that he is in the feature branch and adds a change to it.
      6. When it comes time to merge changes into the main branch (and the corresponding button is pressed), all changes of the feature branch are reduced by the client into one commit (squash through a separate branch), sent to the main branch (fast-forward) and the switch to the main branch takes place. The feature branch is deleted (but due to the nature of Git, a couple of weeks will still be available, the client can remember the hash of its top).

      This is achieved:

      • The simplicity of the interface outside. Like.
      • Compatibility with accustomed colleagues.
      • The ease of searching through history, without a heap of minor changes, which, except for their author, do not benefit anyone. Yes, and the author a month later, such detail will only interfere.

      That's just such a client yet. No one did.

        While you are working alone, the version control system may need a maximum to roll back to a point, when everything worked. In general, the svn system developed in this way - each branch is just a single daddy, greatly simplifying, we can say that the guys just got tired of copying these daddies.

        Problems begin when you already have a team of developers and send projects to the zip archive by email and manually copy the changes you are tired of (fu, what an abomination). This is where mergetool and other tools of a modern developer come to the rescue - you need to combine your efforts to work on the project, and not on how to launch it after the change of the conditional Vasya.

        Another undoubted advantage is commits. A commit is a state with text that describes changes. This again helps with teamwork. We looked at what's new in the dev branch, leaked to ourselves, sit contented, everything works (although “everything works” is more a task of tests). Your sequence "each edit automatically creates additional copies of the project with different versions of code" in fact is a commit. Only not for one edit, but for several as part of the task. And with the description.

        Another advantage in teamwork is the answer to the question "who is the head of the code". You write git blame , specify the file - voila, everything is immediately visible. No one will hide from the tester.

        Want statistics on who wrote how much code? Also all out of the box.

        Logging changes? Everything is

        Well, let's say, I have about a dozen projects. I return to what I did a year ago. I scratch my beard, trying to remember what I was doing here at all .. git log and all the secret becomes clear!

        Or I forgot that I tried to fasten and finish it there. git branch - all branches with all modifications

        In a large company, when a lot of things are lost, the code that someone wrote, but forgot to fill in the master branch will never be lost - git branch --no-merged . And that's all.

        • "In general, the mercurial system developed in this way" - not mercury, but svn - vitidev
        • @vitidev exactly lured. Thanks, corrected - FeroxTL

        For me, the version control system is like a return to the past where at that time everything worked. With your method:

        this, when saving files, each edit automatically creates additional copies of the project with different versions of code. And there is an opportunity to return to any state of the project at any time.

        For example, it is not clear to me where to return (I mean at what point) ... and it will not work to automate everything.

        • That is, the whole thing is exactly what the title has - “changed it, changed that” and this is fundamentally for you? It seemed to me that it was enough to have a timeline on which all versions of the file are represented, they can be opened, viewed, rolled back. But no one bothers to save next to the button to add an optional comment field for editing, and now you have the same thing as the standard repository, but without wasting time on the terminal and so on. - Floyat
        • @Floyat, you just need to grow to version control. Rather, your projects should grow. When I decided to learn GIT, I downloaded it and ... did not master it. My code was still fairly simple, and using GIT was difficult. Then, when I began to make several changes a day in different files of my old code, I realized: this is the HRC. I downloaded Tortoise SVN (a graphical client embedded in Windows Explorer), installed, created the necessary branches there (stable and development, plus some new features) and ... Now I am working on the code itself, and not the organization of its versions and backups for different dates. - Ildar Khairullin
        • @Floyat, the version control feature is not so much in the comments to the changes, but in that ALL versions of the sources, as well as all the development branches, are in one place. Moreover, branches often make sense even for an individual developer, allowing at different times to work on different functionalities, abstracting from other changes. It would seem that incompatible edits — edits of different files in different places — merge into one operation when merging branches. In such cases, but without such a system, with manual control, you would spend an indecent amount of time merging the changes. - Ildar Khairullin