If you say what is the basic tool that software development projects must use, then the version control system should be the most important part. Whether you are developing individually or collaboratively in a team, you can get huge benefits from a version control system.
Without a version control system, the code may be accidentally overwritten or lost by others or yourself, and it is unknown who changed the code for what reason, and there is no way to restore the changes made a few days ago. With a version control system, developers only need to record (Commit) each code change and update through the version control system.
With the version control system, we can browse the history of all development, grasp the development progress of the team, and no longer fear to make any changes, because you can easily restore the previous normal version. We can also use the branch and tag function to release different versions of the software, such as stable version, maintenance version and development version.
Many project demanders have not yet understood the definition of development. Here I must tell you a common saying: "Development is always a process, not a result." Therefore, developers must use version control systems. Git or Mercurial are free and open source. Versioning systems, ubiquitous networks, cheap cloud servers, and even a ready-made third-party service Github.
If you are not already using it, it is recommended to establish version control for your software development project right away. Here are a few suggestions for using a version control system:
1. Put everything in version control
Yes, all the outputs of the project development process are placed in the version control system, which includes program source code, test programs, files, configuration files, various automation scripts, and so on. In addition to the fact that new members can easily pull the latest version and start working immediately, we also hope that in the test environment and the official environment, we can also update to the version we specify at any time, so it is very important to keep a record of all changes of.
For example, changes to the database must also be included in version control. First, record its current version number in the database. Then we performed each change through an automated script and put that script into version control, rather than manually modifying the outline with instructions. The advantage of this is that everyone on the team can see the change through the version control system and upgrade his database. Test and production server environments are also automatically upgraded through this script. Ruby on Rails, which I am familiar with, has such a built-in Migration mechanism, and other programming languages have similar database tools.
In addition, for server applications, it is still impossible to make the software work 100% just by having the source code. We also need to know the configuration settings of the server, including basic network settings, operating system settings, dependent package versions, and so on. So preferably these configuration settings can also be incorporated into the version management system. Advances in cloud technology in recent years have made it possible to treat these infrastructure settings as programs, seamlessly allowing every member and all environments to use the exact same settings, reducing the possibility of error.
2. Frequent and appropriately sized submissions
If it takes a long time to commit a change to the version control system, then you are only using the version control system as a backup tool without enjoying its real benefits. Frequent submissions can help make the team's development progress transparent and reduce code conflicts during multi-person development. When multiple people modify the same piece of code at the same time, it is very troublesome to resolve code conflicts. Also, we also want each commit to have an appropriate granularity, that is, the content of each commit should be highly correlated and independent. For example a small feature or a small improvement. If you are working on new feature A and fixing old bugs at the same time, then you should submit them separately. Programs that cannot be constructed due to syntax errors should not be submitted and cause confusion for the team.
The advantages of having a good size code submission habit In addition to the clearer version history, we can easily restore or transplant the code. Assuming that the above new function A has problems, we can only restore A without affecting the repaired Bugs, or just pick and fix bugs and port them to different branches.
3. Good submission information
Each submission programmer must include an explanatory message explaining what and why the changes were made. In addition to helping the team work, it is more important to make the software more maintainable for future reference. The following scenarios are believed to be familiar to developers:
The software finds a bug and assigns it to you to fix it.
You chase the code to a program that you don't understand, and there are no comments.
Through the version control system, you find that a colleague added this line a year ago, and the information submitted is a BUG or a simple error message.
The colleague is still in the company, but he doesn't remember which bug it was. Or he has already left work or left, and can't find it anyway.
You forcibly changed this line of code and released it.
This function is fixed, but another function has been found to have problems.
Continue to work overtime until the early morning, sadly ing....
A good submission should include a summary line describing why you made the change, possibly adding, removing, or correcting a feature, rather than describing which files were added or modified, and the emphasis should be on why the change was made and why. It's not as simple as this is a bug. Because which files and line numbers have been modified, we will know by looking at the version differences, so there is no need to repeat the description. If you find it difficult to summarise, it probably means that you have too many changes in one commit, try breaking them apart.