Version control systems. Handbook for engineers, artists and writers
Hi, Habr. I decided to touch upon the topic that was exhausted in many articles, more specifically, to describe in many respects non-standard (I would say, disproportionate) use of version control systems (hereinafter - SCR). Comrades, programmers, let's hide the rotten tomatoes and pass by, because this article is not for you. Yes, all of you have already learned all the subtleties of Git, SVN, CVS, and you know many other clever words. Let us, mere mortals, familiarize yourself with all the advantages of using hard currency.
I invite everyone to get acquainted with hard currency as well as all those who, one way or another, deal with rapidly changing data.
I myself am a student at a technical university and almost constantly work with documents (texts, drawings, drawings), changing them three (ten, one hundred) times a day. Sometimes it turns out that edits made during the last week must be canceled and returned to documents in the state of a week ago. Well, if the changes were made a little, in this case, can help fifty strokes on Ctrl + Z. However, if during this week there was more or less active work with the document, it would be impossible to simply restore the status “before an important revision made a week ago”. This requires a copy of the document at the time of "before important edits", as well as a dozen more copies of "before another important edits", "before dubious edits" and "before edits, which most likely will have to be canceled." In principle, this approach is possible and practiced by many. Until recently, I myself kept important versions of files, preserving them with “date_time” prefixes, and, it seems, was pleased. The advantage of this method is simplicity, the disadvantage is the “swelling” of working folders and inconvenience of use. And, if you can somehow fight the first of them (large hard disks and 7zip), then something had to be done with the inconvenience.
We tear out a paragraph from Wikipedia: “Version control system (from the English. Version Control System, VCS or Revision Control System) - software to facilitate the work with changing information. The version control system allows you to store multiple versions of the same document, if necessary, return to earlier versions, determine who made this or that change and when, and much more. ” It looks like the principle of the work of Wikipedia itself - all versions of articles with all edits are available for study.
Thus, using SCR in a situation where you need to store multiple versions of files is what you need. The advantages of this approach include ease of use and savings in free disk space due to so-called delta compression (when not the files themselves are saved in different versions, but changes from version to version, which reduces the amount of stored data). Let's try.
The same Wikipedia suggests that SLE can be centralized and distributed, large and small, with and without lotion. We are not particularly interested in this, since we will use (at least, at first) only a part of the hard-ware functionality. This is the most functional and consider.
Almost all hard currency are a kind of storage in which all versions of the files with which we work are stored. Here it is necessary to clarify that the versions of stored files are most often determined by the user. We made, let's say, a dozen minor edits and decided that it was time to save the results of our activities in the repository. An analogy with the periodic pressing of Ctrl + S comes to mind, with the only difference that this version of the file can be accessed in the future. Naturally, in one fell swoop in this way you can add an arbitrarily large number of files to the version repository. This action is called "commit", or "commit changes" in a simple way.
At any time you can add a new file or delete an existing file to the repository (that is how the storage is cleverly called), and the hard currency will “remember” when and what we added / deleted. And thanks to the comments in commit'ah, you can also describe why the commit itself is executed (“added a bauble to there” / “removed perhaps the necessary piece from there”).
When we finally understand that it is time for us to return to the version of a week ago, we have the whole history of changes. And here we can choose what to do. If you need to copy the necessary piece from the old file and paste it into the current version, simply extract the old file from the storage and copy the necessary one from it. If it is necessary to completely roll back and continue working with the old version, SLE comes to our rescue again - you can go back to the earlier version and create a so-called new branch (“branch”), while retaining everything that we “refused”, rolling back to versions a week ago. Thus, the project version history can be represented graphically in the form of a tree - from the “roots” (the beginning of the project) to the “branches” (successful and unsuccessful edits). In addition, the “branch” can also be created artificially, for example, in the case when we decide to develop two different versions from some source files - in the first we work on some baubles, in the second - on others. Moreover, in case the working files are text documents (and in some others), it is possible to merge different branches into one - the so-called merge (“merge”). Now imagine that there are several people working on the project, and each of them is engaged in such a “little bauble”. Having a common repository in this case greatly simplifies development.
')
So, I hope, I convinced you that using hard currency is good. It remains only to learn how to use SLE. And this will do.
There are various version control systems, differing from each other in various aspects of use. Since we are not interested in (at least at first) the subtleties of the work of various systems, let us dwell on the simplest and most friendly of them. In my humble opinion, this system, oddly enough, is Mercurial - “cross-platform distributed version control system designed to work effectively with very large code repositories” with the TortoiseHg GUI. Working with the system is possible under Windows, Linux and Mac OS X.
Immediately make a reservation that I will describe the work with the system in Windows. Masters of Linux will not be difficult to learn everything by analogy.
In addition, at the same time we will learn how to work with free hosting of Mercurial repositories - bitbucket.org, necessary if you are working on a project not alone or, which is very convenient, you want to have access to all versions of the project via the Internet. In fact, this is a convenient Dropbox replacement if you used it before.
First, install Mercurial + TortoiseHg from here: tortoisehg.bitbucket.org.
This system works in the console, so for ease of use later we will write some *. Bat files for typical operations.
All operations are performed with the hg command. Called without parameters, it displays a list of basic commands.
As a repository, there is any directory we choose (I will use the “C: \ project \” folder), in which all files of our future project should be stored. Of course, no one forbids having multiple repositories on the same computer.
To make the system “understand” that we want to create a repository, execute the command:
after which the folder “c: \ project \” will be created if it has not been created earlier and the folder “c: \ project \ .hg \”, in which Mercurial will store all the service information.
We also remember that we want to receive not only a local repository on our computer, but also a remote repository, to which we will send all our changes (or, as the smart guys say, push the changes to the remote repository, from the English. "Push"). To do this, go to bitbucket.org, register, and create your first repository (Repositories - Create new repository). Give the repository a name (for definiteness, I’ll call it remote_project) and click on Create repository.
Now we have two repositories - local, located in the “c: \ project \” folder and remote, located at “bitbucket.org/your_name/remote_project/”, where your_name_name is specified at registration on bitbucket, remote_project is the name of the repository, selected when creating it.
In order to continue the study, we need to put something in our local repository. Just create in it (in my case - in the folder “c: \ project \”) any file of your future project or copy your current project there.
Now, strictly speaking, we need to specify Mercurial: “we added such-and-such files and a couple of new folders to the project folder”, for this the “hg add” command is provided. However, another approach is more convenient - at the next commit, we will order Mercurial to pick up all the newly created files from the project folder and forget about the deleted ones, which is much easier than every time you create a new document, perform “hg add c: \ project \ new_document.doc ".
So, we proceed to our first commit. It is executed by the following command:
Let's sort everything in order. The command should be entered when we are in the repository (that is, you must first run “cd c: \ project”). The “-A” option is necessary for Mercurial to “pick up” newly created files (see above), the “-m” option allows you to add a comment to the commit. These comments will be displayed when viewing versions (or changesets - change lists) in TortoiseHg and on the project page in bitbucket.org. It is very important to give meaningful comments, so that you do not suffer, remembering when this or that revision was made.
Now the initial version of our project is stored in our repository. All further commit'y are performed similarly after we decide that it is time to save the current version.
A commit can be “pushed” into the remote repository with the command:
At the same time it is also necessary to be in the folder corresponding to the repository. After entering the command, the name and password of our account on bitbucket.org will be requested, in order not to enter them with each push you can replace the command with the following:
Since we will score all the commands in the * .bat file, in this case the password will be stored unencrypted, which poses some security risk, but for me this is acceptable.
So, for convenience we create commit.bat, push.bat and commit & push.bat files with the following content in the direct reach zone:
[content of commit.bat]
This file, invoked with arguments, will commit the project with the entry of arguments in the commit comment. Example: we execute “commit.bat my first commit” and we get commit with the comment “my first commit”. In FAR, it is convenient to use the combination Ctrl + Enter for this.
[content of the push.bat file]
This file will push to the remote repository.
[content of the commit & push.bat file]
This file, invoked with arguments, will perform a consecutive commit and push project with entering arguments in the commit comment.
In addition, for small intermediate commit I recommend creating a file commit_date_time.bat:
[content of commit_date_time.bat file]
This file will produce a commit indicating the current date and time as a comment, which is often convenient.
The question of the frequency of commitments and pushes is decided individually, depending on the intensity and complexity of the edits made. Although it is recommended to follow the rule "more often - better."
By right-clicking on the file / folder of the repository, you can start the Repository Explorer (TortoiseHg - Repository Explorer), in which all of our commit'y with comments to them are presented. In this window, the tree structure of our repository is displayed, from here you can perform commit'y, push'i, rollbacks to previous versions (backout'y) and other operations.
At bitbucket.org/your_account/remote_project there is a similar set of changesets, and you can download any version of the project in one archive, which is sometimes also very convenient.
In general, I consider the initial acquaintance with Mercurial to be over. For more information, please contact: translated.by/you/mercurial-the-definitive-guide/into-ru/trans/
I will finish, perhaps, with what I should start with - for whom is this article? The answer is simple - for those who want to learn how to use SLE. I managed to get some designers, engineers and even a writer on the hard currency. Try it and you - that you may greatly facilitate your work.
PS Transferred to the version control system blog.
I invite everyone to get acquainted with hard currency as well as all those who, one way or another, deal with rapidly changing data.
Why do you need it
I myself am a student at a technical university and almost constantly work with documents (texts, drawings, drawings), changing them three (ten, one hundred) times a day. Sometimes it turns out that edits made during the last week must be canceled and returned to documents in the state of a week ago. Well, if the changes were made a little, in this case, can help fifty strokes on Ctrl + Z. However, if during this week there was more or less active work with the document, it would be impossible to simply restore the status “before an important revision made a week ago”. This requires a copy of the document at the time of "before important edits", as well as a dozen more copies of "before another important edits", "before dubious edits" and "before edits, which most likely will have to be canceled." In principle, this approach is possible and practiced by many. Until recently, I myself kept important versions of files, preserving them with “date_time” prefixes, and, it seems, was pleased. The advantage of this method is simplicity, the disadvantage is the “swelling” of working folders and inconvenience of use. And, if you can somehow fight the first of them (large hard disks and 7zip), then something had to be done with the inconvenience.
What can be done with this, or what is SLE
We tear out a paragraph from Wikipedia: “Version control system (from the English. Version Control System, VCS or Revision Control System) - software to facilitate the work with changing information. The version control system allows you to store multiple versions of the same document, if necessary, return to earlier versions, determine who made this or that change and when, and much more. ” It looks like the principle of the work of Wikipedia itself - all versions of articles with all edits are available for study.
Thus, using SCR in a situation where you need to store multiple versions of files is what you need. The advantages of this approach include ease of use and savings in free disk space due to so-called delta compression (when not the files themselves are saved in different versions, but changes from version to version, which reduces the amount of stored data). Let's try.
What are SLE
The same Wikipedia suggests that SLE can be centralized and distributed, large and small, with and without lotion. We are not particularly interested in this, since we will use (at least, at first) only a part of the hard-ware functionality. This is the most functional and consider.
Almost all hard currency are a kind of storage in which all versions of the files with which we work are stored. Here it is necessary to clarify that the versions of stored files are most often determined by the user. We made, let's say, a dozen minor edits and decided that it was time to save the results of our activities in the repository. An analogy with the periodic pressing of Ctrl + S comes to mind, with the only difference that this version of the file can be accessed in the future. Naturally, in one fell swoop in this way you can add an arbitrarily large number of files to the version repository. This action is called "commit", or "commit changes" in a simple way.
At any time you can add a new file or delete an existing file to the repository (that is how the storage is cleverly called), and the hard currency will “remember” when and what we added / deleted. And thanks to the comments in commit'ah, you can also describe why the commit itself is executed (“added a bauble to there” / “removed perhaps the necessary piece from there”).
When we finally understand that it is time for us to return to the version of a week ago, we have the whole history of changes. And here we can choose what to do. If you need to copy the necessary piece from the old file and paste it into the current version, simply extract the old file from the storage and copy the necessary one from it. If it is necessary to completely roll back and continue working with the old version, SLE comes to our rescue again - you can go back to the earlier version and create a so-called new branch (“branch”), while retaining everything that we “refused”, rolling back to versions a week ago. Thus, the project version history can be represented graphically in the form of a tree - from the “roots” (the beginning of the project) to the “branches” (successful and unsuccessful edits). In addition, the “branch” can also be created artificially, for example, in the case when we decide to develop two different versions from some source files - in the first we work on some baubles, in the second - on others. Moreover, in case the working files are text documents (and in some others), it is possible to merge different branches into one - the so-called merge (“merge”). Now imagine that there are several people working on the project, and each of them is engaged in such a “little bauble”. Having a common repository in this case greatly simplifies development.
')
From theory to practice, or starting to use hard currency
So, I hope, I convinced you that using hard currency is good. It remains only to learn how to use SLE. And this will do.
There are various version control systems, differing from each other in various aspects of use. Since we are not interested in (at least at first) the subtleties of the work of various systems, let us dwell on the simplest and most friendly of them. In my humble opinion, this system, oddly enough, is Mercurial - “cross-platform distributed version control system designed to work effectively with very large code repositories” with the TortoiseHg GUI. Working with the system is possible under Windows, Linux and Mac OS X.
Immediately make a reservation that I will describe the work with the system in Windows. Masters of Linux will not be difficult to learn everything by analogy.
In addition, at the same time we will learn how to work with free hosting of Mercurial repositories - bitbucket.org, necessary if you are working on a project not alone or, which is very convenient, you want to have access to all versions of the project via the Internet. In fact, this is a convenient Dropbox replacement if you used it before.
First, install Mercurial + TortoiseHg from here: tortoisehg.bitbucket.org.
This system works in the console, so for ease of use later we will write some *. Bat files for typical operations.
All operations are performed with the hg command. Called without parameters, it displays a list of basic commands.
As a repository, there is any directory we choose (I will use the “C: \ project \” folder), in which all files of our future project should be stored. Of course, no one forbids having multiple repositories on the same computer.
To make the system “understand” that we want to create a repository, execute the command:
hg init c:\projectafter which the folder “c: \ project \” will be created if it has not been created earlier and the folder “c: \ project \ .hg \”, in which Mercurial will store all the service information.
We also remember that we want to receive not only a local repository on our computer, but also a remote repository, to which we will send all our changes (or, as the smart guys say, push the changes to the remote repository, from the English. "Push"). To do this, go to bitbucket.org, register, and create your first repository (Repositories - Create new repository). Give the repository a name (for definiteness, I’ll call it remote_project) and click on Create repository.
Now we have two repositories - local, located in the “c: \ project \” folder and remote, located at “bitbucket.org/your_name/remote_project/”, where your_name_name is specified at registration on bitbucket, remote_project is the name of the repository, selected when creating it.
In order to continue the study, we need to put something in our local repository. Just create in it (in my case - in the folder “c: \ project \”) any file of your future project or copy your current project there.
Now, strictly speaking, we need to specify Mercurial: “we added such-and-such files and a couple of new folders to the project folder”, for this the “hg add” command is provided. However, another approach is more convenient - at the next commit, we will order Mercurial to pick up all the newly created files from the project folder and forget about the deleted ones, which is much easier than every time you create a new document, perform “hg add c: \ project \ new_document.doc ".
So, we proceed to our first commit. It is executed by the following command:
hg commit –A –m “comment to commit”Let's sort everything in order. The command should be entered when we are in the repository (that is, you must first run “cd c: \ project”). The “-A” option is necessary for Mercurial to “pick up” newly created files (see above), the “-m” option allows you to add a comment to the commit. These comments will be displayed when viewing versions (or changesets - change lists) in TortoiseHg and on the project page in bitbucket.org. It is very important to give meaningful comments, so that you do not suffer, remembering when this or that revision was made.
Now the initial version of our project is stored in our repository. All further commit'y are performed similarly after we decide that it is time to save the current version.
A commit can be “pushed” into the remote repository with the command:
hg push https://bitbucket.org/__/remote_projectAt the same time it is also necessary to be in the folder corresponding to the repository. After entering the command, the name and password of our account on bitbucket.org will be requested, in order not to enter them with each push you can replace the command with the following:
hg push hg push https://__:__@bitbucket.org/__/remote_projectSince we will score all the commands in the * .bat file, in this case the password will be stored unencrypted, which poses some security risk, but for me this is acceptable.
So, for convenience we create commit.bat, push.bat and commit & push.bat files with the following content in the direct reach zone:
[content of commit.bat]
IF !%1==! goto exit1
cd C:\project
hg commit -A -m "%*"
goto exit0
:exit1
echo "NO COMMAND-LINE ARG!"
:exit0This file, invoked with arguments, will commit the project with the entry of arguments in the commit comment. Example: we execute “commit.bat my first commit” and we get commit with the comment “my first commit”. In FAR, it is convenient to use the combination Ctrl + Enter for this.
[content of the push.bat file]
cd C:\projecthg push https://__:__@bitbucket.org/__/remote_projectThis file will push to the remote repository.
[content of the commit & push.bat file]
IF !%1==! goto exit1
cd C:\project
hg commit -A -m "%*"
goto exit0
:exit1
echo "NO COMMAND-LINE ARG!"
:exit0
call ./push.batThis file, invoked with arguments, will perform a consecutive commit and push project with entering arguments in the commit comment.
In addition, for small intermediate commit I recommend creating a file commit_date_time.bat:
[content of commit_date_time.bat file]
cd C:\project
hg commit -A -m "%DATE% %TIME%"This file will produce a commit indicating the current date and time as a comment, which is often convenient.
The question of the frequency of commitments and pushes is decided individually, depending on the intensity and complexity of the edits made. Although it is recommended to follow the rule "more often - better."
By right-clicking on the file / folder of the repository, you can start the Repository Explorer (TortoiseHg - Repository Explorer), in which all of our commit'y with comments to them are presented. In this window, the tree structure of our repository is displayed, from here you can perform commit'y, push'i, rollbacks to previous versions (backout'y) and other operations.
At bitbucket.org/your_account/remote_project there is a similar set of changesets, and you can download any version of the project in one archive, which is sometimes also very convenient.
In general, I consider the initial acquaintance with Mercurial to be over. For more information, please contact: translated.by/you/mercurial-the-definitive-guide/into-ru/trans/
Who is this article for?
I will finish, perhaps, with what I should start with - for whom is this article? The answer is simple - for those who want to learn how to use SLE. I managed to get some designers, engineers and even a writer on the hard currency. Try it and you - that you may greatly facilitate your work.
PS Transferred to the version control system blog.
Source: https://habr.com/ru/post/122060/
All Articles