Svn usage specification

1. The submission must be marked with notes

Submitting clear comments will help others understand your changes , Be able to quickly locate problems , It also helps the project manager grasp the development progress . therefore , When you submit the code , Fill in clear labels , Be able to briefly describe the information of the submitted documents , Let other members of the project team know your changes without looking at the code after seeing the annotation .

2. It is forbidden to submit uncompiled code

Before the code is submitted , First, make sure you can compile locally , Ensure that the trunk is always unblocked . If a new file is referenced , Make sure that all referenced documents are submitted together .

• The code passed unit tests
• The program starts normally

3. Don't submit code you don't understand

The code is being submitted SVN after , In this way, the code will be shared by project members . If you submit code you don't understand , You can't understand , Others can't understand it , This will become a hidden danger of project quality . So before introducing any third-party code , Make sure you have a clear understanding of the code .

3. Don't submit your own temporary test code

Submitted to the SVN The code of is more formal , Share with other members , Comment out your temporary test code before submitting , Do not affect the development of other members .

4. Do not submit local auto generated files

The development tool will automatically generate some project files , And the temporary files generated by the project compilation . After submitting such documents , Others may conflict with the local environment after updating, thus affecting everyone's work .

because SVN It's on the public network , So uploading these files will be too cumbersome , Affect the speed of submitting and other members' updating source code , Also wasted SVN The server Space resources .

5. Submit as a whole according to the function module , Don't submit too often

After completing a function module , Submit the relevant modifications of this module as a whole . Don't separate and submit too often , Lead to functional asynchrony .

6. Before submission , Update before submitting

Do an update operation before submitting , This can effectively prevent conflicts between locally modified files .

Another possibility is that the submission is successful , But it will overwrite the previous submission data of other members .

7. After submitting, you can let convenient colleagues update in time

Let colleagues update in time , Compile the code once , Make sure the program runs .

If there are questions , Correct the missing documents in time , And correcting errors , Avoid making mistakes that have too much impact .

8. Use the lock function with caution

Be careful with locking functions in projects , After you lock a file, others cannot continue to modify and submit the file , Although it can reduce the incidence of conflict , But it may affect the work of other personnel in the project team . Usually only when editing files that cannot be merged （ Non text files ）, To properly adopt the locking operation .