This article is cited: http://developer.51cto.com/art/201005/202220.htm
-----------------------------
one. Update before submitting
1. The principle of SVN update is to update and submit at any time. When you have completed a small feature that can be compiled and tested by yourself, submit it carefully.
2. If others also change the corresponding file of svn during the modification, the commit may fail. If someone else changes the same file as yourself, the update will be automatically merged. If the same line is modified, a conflict will occur when merging. In this case, you need to contact the previous developer, and the two will negotiate and resolve it together. Conflict, after the conflict is resolved, two people are required to test together to ensure that after the conflict is resolved, the program will not affect other functions.
3. Pay attention to the list of updated files when updating. If there is an update during the submission process, you also need to recompile and complete some necessary tests yourself before submitting. This can not only understand which files have been modified by others, but also avoid SVN merge errors resulting in code errors.
two. Keeping commits atomic Keep
the interval between commits as short as possible, preferably a few hours of development work. For example, when changing the UI interface, you can submit it every time you complete the modification or design of a UI interface. When developing a function module, you can submit it once every time you complete a small detail function test. When modifying a bug, you can submit it once every time you modify a bug and confirm that the bug has been modified. We advocate more submissions, which can also add more insurance to the code.
three. When submitting SVN, be careful not to submit locally automatically generated files.
Generally, the configuration administrator will shield and submit some automatically generated files in the project or files related to the local configuration environment (such as .classpath files in eclipse, etc.). If there is no configuration in the project to forcibly prohibit the submission of such files, please consciously do not submit such files. After submitting such a file, others may conflict with the local environment after the update, thereby affecting everyone's work.
Four. Don't submit code that doesn't compile.
Before submitting your code, make sure you can compile it locally. If a third-party class library is used in the code, consider that some members of the project team may not have the corresponding third-party class library installed. The project manager needs to take this into account when preparing the project work area to ensure that the development team members can compile in a unified environment after checking out the code.
Fives. Don't submit code that you don't understand.
After submitting the code to SVN, your code will be shared by project members. If you submit code that you don't understand, you can't understand it, and others can't understand it. If there is a problem in the future, it will become a hidden danger to the quality of the project. So before introducing any third-party code, make sure you have a clear understanding of the code.
six. When SVN is submitted, coordinate the work plan of the project team members in advance. The
project manager should allocate the work plan reasonably. Before each member is ready to start modifying a certain function, if possible, talk to the members of the working group about their modification plan, so that everyone can understand your thoughts and the modifications you will make to the software, so that It can reduce the conflicts that may occur in the development process as much as possible and improve the development efficiency. At the same time, you can also discover the shortcomings of your previous designs in the communication with the members and improve your design.
seven. Use SVN to clearly label the information submitted by
SVN. If you use SVN in a project team, if you submit an empty label or an inaccurate label, other members of the project team will feel helpless, and the project manager cannot clearly grasp the work progress. The summary information of this submission cannot be clearly grasped. After the error is found, the file that caused the error cannot be accurately located. Therefore, when submitting work, you must fill in clear annotations, which can briefly describe the information of the submitted files, so that other members of the project team can understand the changes you have made without looking at the code in detail after seeing the annotations.
Eight. Use the locking function with caution. Use the locking function with caution
in the project. After you lock a file, others cannot continue to modify and submit the file. Although it can reduce the incidence of conflicts, it may affect the work of other people in the project team. Usually only when editing those files that cannot be merged (such as picture files, flash files, etc.), the locking operation is appropriately used. This article has explained some issues that should be paid attention to in SVN submission, please pay attention to other related reports in this section.