Why is version control so important?

650) this.width=650; "src=" Http://img.mp.itc.cn/upload/20160712/c58a2e12b0eb4e6c8a11911a11d58c34_th.png "style=" border:0px;margin:0px;padding:0px;font-size:0px; "alt=" C58a2e12b0eb4e6c8a11911a11d58c34_th.png "/>

If what is the basic tool that a software development project must use, then the version control system should be counted as the most important part. Whether it's personal development or team collaboration development, there are huge benefits from a version control system.

Without a version control system, the code may be accidentally overwritten or lost by someone else or yourself, and you don't know who changed the code for any reason, or how to revert back to the last few days of modification. With a version control system, developers record each code change (Commit) and update it through the version control system.

With the version control system, we can view all the development history, master the team's development progress, and make any changes are no longer afraid, because you can easily revert back to the normal version. We can also perform different versions of the software distribution, such as stable versions, maintenance versions, and development versions, through the functions of branches and tags.

Many project demand parties have not yet understood the definition of development, and there must be a cliché to say: "Development is always a process, not a result." "So developers have to use the version control system, git or mercurial is a free open source version system system, anywhere available network, cheap cloud server, and even a ready-made third-party service GitHub.

If you are not using it, it is recommended that you build a version control for your software development project right away. The following are some suggestions for using the version control system:

1. Put everything in the version control system

Yes, all outputs from the project development process are put into the version control system, which includes the program source code, test procedures, files, profiles, various automation scripts, and so on. In addition to the new members can easily pull out the latest version to start work immediately, we also want to be in the test environment, the formal environment, or at any time to update to our designated version, so it is important to save the records of all changes.

For example, changes to the database must also be included in version control. First, record its current version number in the database. Then each of our modifications are executed through an automated script that puts the script into version control instead of hand-using instructions to modify the outline. The benefit is that everyone on the team can see the change through the version control system and upgrade his database. The test and the formal server environment will also be automatically upgraded through this script. I am familiar with Ruby on Rails with the built-in migration mechanism, and other programming languages have similar database Tools.

In addition, in the case of server applications, just the source code is still not 100% let the software work, we also need to know the configuration settings of the server, including the basic network settings, operating system settings, dependent version of the suite and so on. Therefore, it is best to include these configuration settings in the version management system. Advances in cloud technology in recent years have allowed these infrastructure settings to be used as programs, seamlessly allowing each member and all environments to use exactly the same settings, reducing the likelihood of errors.

2. Frequent and appropriate size of submissions

If you have to submit a change to the version control system for a long time, then you just treat the version control system as a backup tool and not enjoy its real benefits. Frequent submissions can help transparency of team development progress, and reduce code conflicts when multiple people develop. Resolving code conflicts is a hassle when multiple people are modifying the same piece of code at the same time. Also, we hope that each submission has a proper granularity, that is, each submitted content should have a high degree of relevance and independence. For example, a small feature or a small improvement. If you are doing a new function A and fixing the old bug at the same time, you should submit it separately two times. A program that cannot be constructed with grammatical errors should not be submitted and thus cause team trouble.

The benefits of good-sized code submission habits in addition to the version of the history of the more clear, we can easily do code recovery or porting, assuming that the new feature a problem, we can only restore a without affecting the fixed bug, or only choose to fix the bug to the different branches.

3. Good submission of information

Each time the submission of the programmer must be accompanied by an explanatory message explaining the content and reasons for the change. This is in addition to helping the team to work together, more importantly, to make the software better maintenance, for future reference, the following scenarios believe that developers are not unfamiliar:

The software discovers a bug and then assigns it to you to fix it.

You chase the code to catch a program that you do not understand, there is no comment.

Through the version control system, you find a colleague who added this line a year ago, and the information submitted is a bug or a simple error message.

My colleague is still in the company, but he doesn't remember which bug it was. Or he's out of work or left, but he can't find it anyway.

You forcibly changed this line of code and posted it.

This feature is fixed, but there is a problem with another feature.

Continue to work overtime to the wee hours, sad and urge ing ....

A good submission should include a line of summary information describing why you made the change, perhaps adding, removing, correcting a feature, rather than describing which files were added or modified, and focusing on why the notes were modified rather than the bug. Because of the changes to which files and rows we see the version differences we know that there is no need to repeat the description. If you find it difficult to digest, it may mean that you have too many changes submitted at the same time, please try to disassemble.

This article is from the "first to a cup of Java press yajing" blog, please be sure to keep this source http://maybeone.blog.51cto.com/11734094/1825840

Why is version control so important?