Version Control: SVN and git usage experience

Background:

When I was working on a project with my mentor at school, I had been using version management. It was mainly used to record project modifications and communication between project members. The used server is visual SVN and the client is tortoisesvn. the commonly used tortoisesvn commands are limited to SVN update and SVN commit. The former is used to update from the server to view modifications made by other students, the latter is used to submit the modifications to the server so that the team can share the modifications. Since there are few members in the project team and the main code modification is only completed by me, tortoisesvn is a tool to record my local code modification process. In fact, this is redundant with the habit of writing work logs (in Word format) and adding comments to codes (the reasons for modification, modifier, modification time, and remarks usually appear in comments.

After entering the workplace, there were more and more projects and developers, and they began to learn about other functions of tortoisesvn. For example, view the file modification log show log, roll back the submitted Modification Operation revert, create branch/tag, and create patch. When I gradually become familiar with and use it, I gradually feel that tortoisesvn still lacks some functions? For example, the following scenarios often occur: I copy my own code from the project SVN server to my local file, then, start to modify the module according to the Project Plan (just like local development and debugging at this time), but suddenly the higher-level instruction is received, there is an urgent bug to deal. At this point, I can only create a patch file, and then roll back the current changes to the initial state (that is, the version I copied from the svn server ), if so, I can start to modify urgent bugs. Wait until the patch is completed, and then apply the previous patch file back. Here, I will make corresponding work records (Word documents) at the same time, which will record the relevant steps and details when I initially modified the module, and record the bug fixing process, then, record the modification of the module. In this way, combined with tortoisesvn's submission log and my word work documents, I can precisely locate any time point in my development process-to facilitate the sorting and continuation of subsequent ideas, as shown in: if the time granularity of each tortoisesvn submission is shown by the yellow arrow, I can only view the red changes in the middle in my word work logs, but after all, the ideas are recorded in the word, I can only manually copy the specific code file to the corresponding location recorded in the word log, or create a patch file and save it to the specified location. If the time granularity submitted by tortoisesvn is indicated by the arrows on the way, this is almost the same as the work of word logs and can be used to locate and modify the log at will. However, it should be noted that in team development, such frequent tortoisesvn submission is absolutely impossible, first, the svn server requires that the entire function be submitted only after modification, but such frequent submission will increase the burden on the server and affect the functions of the entire project by making incomplete code modules.

If you see this, do you think it is complicated and troublesome? But for coders, good records and comments are necessary so that you can better take responsibility for your own code. I have been using this kind of development status for many years and have become accustomed to it. It wasn't until I got in touch with git one day that I suddenly found that there was a so-called distributed version management tool, you can record my local changes. I really like it.

The following describes how to use git to manage local code modifications.

Git manages local code modifications:1) differences between git and SVN:

The analysis and discussion of the two have already been carried out in various forums and posts. I do not comment on the advantages and disadvantages of the two. From the perspective of actual code development work and improving the efficiency of code development, let's look at my views on the two. As mentioned in the background, SVN has been used for many years. Simply put, a server will store your modifications to the code. The modifications here must be committed by you) to the server. The granularity of the two submissions depends entirely on the developer himself. If you only use SVN to manage your own code development records, you can submit it at will to view and record your complete development process (this method is definitely not allowed in teamwork ). SVN structures are divided into version libraries and Working Copies. Version libraries are the "databases" placed on the server to record each commit, the recorded content includes changes to files within the control scope of all version libraries. A working copy is the code project on your own machine. It is a copy of the code project on the server, SVN stores version libraries and working copies in different locations. The specifics are as follows (the direct embodiment of your own ideas may not necessarily fully comply with the svn work process, but the general idea is correct for your understanding ):

As you can see, the basic process of SVN version management is that the server stores the changes you make to the project each time. Of course, the initial project file is recorded when you submit the project for the first time. From the directory structure of the svn server, we do not directly see the project file we submitted, but use tortoisesvn (local server) and visualsvn (Remote Server) you can see the specific project file, such. So where are the submitted files saved? Some files in the DB directory should be directly guessed, because the file size also changes as the number of submissions increases. Search for relevant information and find the following answer:

"SVN has two storage methods: bdb and fsfs. Currently, the most commonly used is fsfs. In this method, it is usually stored in the \ dB \ revs folder, there are a bunch of files named after version numbers, such as: 0, 1, 2, 3, 4 ......, that is our project file. SVN first compresses the status of version 0 into one file, and then makes a compressed file for the changed part each time the version is updated. Each time an incremental package is added, finally, we can see a series of files with names starting from 0 to the final version on the server"

"The SVN server does not simply store uploaded files one by one. By default, the svn server uses the fsfs format to incrementally store the content of each commit, each incremental package is saved into one file, which contains all the data of this commit. That is to say, you cannot find a file you uploaded in the folder where the version library is stored on the server ".

Now we understand the structure of the svn server. As for the client, there is no difficulty. The server version library is downloaded to the local device through the network protocol and stored in. in the svn directory, it is your own project file (if you download someone else's project from the remote SVN server, it is someone else's project file ).. SVN records the status of the server project file when you download the file from the svn server. The next submission time will communicate with the svn server to check the modification status of the server and your local two ends.

From this we can see that to record local modifications, you must communicate with the svn server, instead of simply saving local modifications. This is also the main purpose of git. Baidu encyclopedia's description of git is: "Git is an open-source distributed version control system for effective and high-speed processing of project version management from very small to very large. The biggest difference between distributed and centralized systems is that developers can submit data locally. Each developer machine has a server database ." -- Git can complete the above local modification records.

2) git manages local code modifications

Step 1: The GIT version library is in the same directory as the working copy, which is called. Git. After installing git, right-click any directory and select git init here to create a git version library, that is, the. Git folder. (Remember: This is the version library we have built locally. The root cause is no server hair, ^_^ .)

Step 2: directly copy the local project to be managed to the same directory of. Git. Then we can open the project like normal development and operate on it until we want to save the modification status, we can go to step 3.

Step 3: Right-click the project folder and select git gui. The Management window is displayed. The changes we made are displayed. The files we modified are listed in the red box, you can see the changes in the orange box. The Green Box shows the modified buffer. After selecting a specified file in the red box to enter the green buffer, We can click the yellow button "Submit ", so far, we have submitted the modification record for the local file.

Step 4: Right-click the project folder and select git history to view the local modification record.

So far, we have easily implemented the modification record of the local code, and there was no server in the whole process. This is the biggest difference with SVN.

This is recorded today. We will introduce the scenario in the background in detail tomorrow and provide a git solution.

 

(To be continued ......)

[Email protected]

Time: 2014-09-06

Version Control: SVN and git usage experience