Top 10 commands on source code management

The 10 Commandments of good source control management

If there are other tools that can be used without prejudice to various programming languages and are more necessary than source code management software, I would like to see them. Source code management software is an essential tool for our work and the blood of many development teams. So why do we all misunderstand it? Why is it difficult to understand the core value and basic principles of the version control system?

I have summed up 10 conventions (you can use "Precepts" if you like), which means you must obey it and it is hard to understand at first. They are associated with version control software for all types of programming languages. Here I have selected several examples of subversion and. net, but they are also widely applied to other technologies.

1st Note: If you are still using VSS, please stop immediately

It is dead. Of course it is not completely correct. It has survived for many years and is still living after being surpassed by brand new and more practical source code management tools. To be accurate, when Microsoft no longer provides support for it in a few months (it will still last for a while), it will actually die.

In all fairness, VSS is a good tool. In 1995, it was covered by distributed software like git and mercurial like subversion. Microsoft has been replacing it for many years.

The reason is that the series of defects caused by the lack of support for today's standards keep it optimistic. As we all know, it is Microsoft's tragic system, but somehow it can stick to it for so long, although it has so many minor faults, defects, and does not contain the necessary functions (as opposed to today's standards ).

Second, if the code is not put in the source code management software, it does not exist.

Repeat this sentence every day-"using source code management software is the only effective measure ". Unless you use the source code management library of the project to control the code version at work-otherwise the Code does not exist.

Obviously, you have noticed that running good code on your local machine is not very effective for others. Right? They can't get your latest version, they can't merge code files, you didn't deploy it correctly (refer to you're deploying it wrong), and if your SSD hard disk is broken, you will lose the fruits of your work forever.

As long as you maintain this mentality-the code is truly secure only after it is submitted, and it is the guarantee of other good programming habits. You can divide your tasks into many small units so that you can submit them one by one. You need to do this frequently. You don't have to worry about hardware issues.

But more importantly (at least for your team lead), you can see what you did through source code management software. Using charts and listing projects is a good way, but how do you know what they are actually doing? The use of source code management software can be clearly understood.

The third rule should be submitted early, often submitted, and should not be in trouble

The only way to avoid "phantom code" (that is, code that can only be seen on your machine) from the previous point is to submit your tasks frequently and do not bother with it. It can solve your problem, but this will also have other impact on your work:

1. Each submitted revision will provide you with a Restore Point.If you have completely screwed up the code (we have done this without lying to you), do you want to resume your work one hour ago or one week ago?

2. The risk of merging files will increase over time.Merging files is always troublesome. If you do not submit code every day, you will suddenly find that there are more than 50 conflicts between you and others. You will not be happy with this.

3. It prompts you to separate tasks into scattered units.People usually submit the code when it is completed quickly, because they want to make the code into a complete logical unit module. However, large tasks inevitably need to separate small scattered functions. Frequent submission of them will give you a better understanding of them, and you can build and submit them one by one.

If you do this, your submission history inevitably begins to look like a semi-regular style, where tasks are submitted every workday. Of course, this is not always the case. You may also stop to rebuild or test, or other reasonable activities may interrupt the standard development cycle.

However, when I look at an independent project, especially a complete project, every time I find that we do nothing in a standard development cycle, one day or several days, I am very worried. I am worried because it means something went wrong. Generally, no one is trying to solve the problem, or the project has no progress because it is stuck in a certain problem. No matter what the problem is, the source code management software will tell you that there is a problem.

Fourth, check what you changed before submitting

The process of submitting code to the source code management software is actually very simple (You may be confused why the previous article is so troublesome ). Generally, if the file content is changed, the file will be uploaded without any consequences. Like this -- "My project root directory has file content changed. I want to submit it soon !"

One or two things will happen: first, the programmer will upload the junk code files in the directory without consciousness. When some people see a window similar to the following, click "select all" and submit it. In this way, the source warehouse will be messed up by undebugged files and other junk files that should not exist.

Or, the programmer uploads the file without actually checking what they have changed. When you Process configuration files or project definition files at work, it is easy to upload those files that you do not want to submit, and those files may be used by other programmers. Do you really remember all your changes in the configuration file?

The solution is simple:You must immediately check where you have changed before submission.It is actually easier to do than it sounds. The "Ignore" feature provided by many systems can greatly reduce the risk of "inadvertently uploading files. You can ignore the thumbs. DB file because you don't want to upload it. You may have other files that you don't want to upload after each revision-ignore them!

For changes in files, you can usually use a popular text comparison tool to observe the differences. Why should I upload the Web. config file again?

Oh, I remember, I want to reduce the maximum number of failed attempts to password from 5 to 3. Ah, I almost didn't pay attention to uploading a virtual login page. This kind of exercise for checking before submission makes it easier for you to understand the content of the next section.

The fifth rule is to be careful when writing and submitting information.

This is an old saying (the source is unknown). The general idea is: "When writing every piece of information, it seems that the person who will wait to read it is an ax killer, he also knows where you live ". If I am the killer and want to track bugs in your code, all the submitted information will be "code updated". Be careful, I will cut you down!

My solution is to explain why new code is submitted.Every time you make changes to the Code, there is a reason. Where may crash. The customer may not like the current theme color. Maybe you just need to adjust the build configuration. Whatever it is, there is a reason, and you need to keep the reason in text.

Why? There are many reasons for doing so, and they are different in different environments. For example, using the "ownership" feature or other similar features shows who changed the code. If I do not remember the web of my project 18 months ago. the config file has been changed somewhere or why I want to modify the application settings, because I didn't leave an appropriate submission information at the time, but now it will be very simple:

This is a software that allows you to observe code changes at any time. Whether I want to know the complete change history of a file as follows, or just want to know what the team did yesterday, leaving a descriptive record means that you will be able to know what the situation is.

Finally, it is hard to estimate the importance of submitting information when debugging encounters an error. For example, you can find the cause of the error in the last update in your integrated environment. My example is very obvious, but displaying the information can solve a lot of difficult problems.

Keep this article in mind. Here are some negative materials for information submission:

1. Hateful
2. You can run it.
3. Fixed some mixed account problems
4. Solved
5. Improved bugs
6. Uploaded
7. typographical error
8. Revision 1024

Okay. Which of the following is the worst submitted information you have ever written on the stack overflow website ?) The above content is selected in the post, but they are not the same as the submitted information I have read before. They do not tell you any valid information about code changes; they are all junk information.

Note the following;The information submitted by the same programmer must not be exactly the same as the previous one.The reason is understandable: You submit a file to the source code management software because something has changed in the code of the previous version. Your current code is different from the previous one. If your submission information is complete and accurate, theoretically it cannot be the same as the previous one. If it is the same (sometimes it is true), the log will be difficult to read, because there is no way to distinguish between the two commits.

Note 6: You must submit your changes by yourself-you cannot entrust others

It sounds strange, but it does happen. I have seen it more than once, last week. In this case, the source code library is regarded as a very high position. For many reasons, the team will pursue a clean and single perfect code. To maintain this sacred state, the code can only be submitted by a leading programmer. prior to submission, the code is carefully integrated, reviewed, and (probably) adjusted to improve the code.

This solution can be easily evaluated even if you are standing far away. The submission is not very frequent (probably several times a week), and only one person who is away from the team and other programmers can submit the submission, in addition, some work may inevitably lead to project confusion during this long unsubmitted period. Very, very bad.

There are two errors: first, the source code management software does not mean that the code in it is sacred, at least throughout the development cycle. It should be the place where the Team frequently integrates files and restores them to normal and solves the problem together when an error occurs. This is not always done from beginning to end. It is only done when the application cycle is released to a certain state.

Another problem-and really critical-is from the programmer's perspective,This means you are not using source code management software!It is equivalent to no code integration between peers, no restoration, no owner for the submitted information, and nothing! You just write your own code in your ivory tower and wait for the future to hand it over to the leaders one day.

Do not do this. Never.

7. You must manage the database version.

This is what we all know is necessary, but many people think it is troublesome. The problem is that many (or most) applications cannot run without databases. If you have not managed the database, what you actually do is an incomplete and useless application.

Almost all version control systems work to manage files in the file system. It only applies to typical applications such as HTML pages, images, CSS, project configuration files, and other independent units in the file system. The problem is that it does not work on the database associated with the program. You cannot replace a large database and replace all old data files and a large number of objects and data log files. This will make the version control system completely messy.

The intelligent SQL source control developed by red gate has properly solved this problem. This software is described in the rocking your SQL source control world with red gate post I wrote last year, so I will not talk about it now.Database Management is now very easy!

To be honest, if you haven't managed your database version, your development will be accompanied by a lot of problems. When changing the database, there is no source code management, no recovery point, and it is difficult to work closely with the team. The database version control system makes development easier.

Do not put compiled files into the source code management software.

Simply put, do not put the results files automatically generated during project compilation and running into the source code management software. For. NET developers, mainly the. dll and. PDB files that often appear in the "bin" and "OBJ" folders.

Why? If you do this, your colleagues will hate you. This means that whenever they remove the latest files from the version control system, they will overwrite your compilation files. This is a dual nightmare (you must not do this), which will cause problems during their next compilation. And as long as they re-compile and re-upload the compilation file, the same problem will happen again in the opposite direction, but this time you are the victim. You certainly don't want this.

Of course, this is a waste of resources. This will waste the hard disk space of the source code management server, the bandwidth will be wasted, and it will remain lurking when sent over the network, and the inevitable conflict caused by this will be a waste of your time.

Therefore, we continue to use the "Ignore" solution mentioned earlier. It's really easy to ignore paths like "bin" and "OBJ. Everyone will be happy as long as they do it once.

In fact, when I wrote pre-commit hooks, I said that such files cannot be submitted on the version control server. Of course, if there is a reason for this, you can upload the file only in this case. However, I prefer not to do this to avoid a conflict in the future.

Do not upload your own user settings

Honestly, I don't think many people have noticed that they have uploaded their private settings files to the source code management software. In this case, many tools generate files that only manage your local configurations. They are only useful to you and are usually different from other people's private setting files. If you upload them to the source code management software, you will soon overwrite the private setting files of others. This is not good.

This is an example of a typical. Net Program:

If you do not clean up immediately, the extra is the extension file and type description, that is. resharper. user File and. suo (solution user option) files. They belong to you and are invalid for others.

To understand this, let's look at the resharper file:

<Configuration>  <SettingsComponent>    <string />    <integer />    <boolean>      <setting name="SolutionAnalysisEnabled">True</setting>    </boolean>  </SettingsComponent>  <RecentFiles>    <RecentFiles>      <File id="F985644D-6F99-43AB-93F5-C1569A66B0A7/f:Web.config" caret="1121" fromTop="26" />      <File id="F985644D-6F99-43AB-93F5-C1569A66B0A7/f:Site.Master.cs" caret="0" fromTop="0" />

In this example, I only recorded in the user file that I started the solution analysis function. This is only for me. I like this function, but not for others. Generally, they use aging and cheap computers, so I am a little confused. The key is that my settings will force others to execute them. This does not mean other people will do the same.

(Side note: The main disadvantage of VSS is ignoring. resharper. User Files is a bit of a problem. Check this post)

This principle also applies to. suo files. However, the content is not visible here (it is not in XML format, but binary). This file records the status of the solution browser, publish settings and other things that you do not want to force on other people's computers.

So we need to use the ignore solution again. Provided that you are not using VSS.

The Tenth Rule and ancillary documents should also be integrated

This is the last and most important one in the Ten Commandments. If the application can run normally only when external ancillary files exist,Put those files into the source code management software!People tend to make the mistake of uploading everything in an environment where they have their own files and Local affiliated files, then I thought it was okay. However, if other people cannot find the same ancillary file from the source code library, everything will return a tragic error.

I think of this because the following figure is displayed when I drag an old project from the source code library and run it:

I thought nunit was always on the machine, but this time it didn't. Fortunately, nuget can be used to quickly solve the problem, but if there is no attached file, it can not be easily solved in the same way every time. In some cases, they are not public, and it is difficult for you to obtain them all.

The reason why the project runtime I extracted from the source code management software reports an error is that the attached files are lost in the "C: \ Program Files..." path. I spent a lot of time contacting the person who finally changed the file (obviously he is far away in the world) and getting the file, put it in the "Libraries" folder and upload it to the version control system, so that the next person who extracts the file does not need to be so troublesome.

Of course, another important reason is that if you work in any integration environment, your build server may not have installed those libraries. You must have those files to run. Doug Rathbone recently wrote a good article about this. Third Party tools live in your source control (a third-party tool in source code management software ). It is not necessary to do that (we also evaluated the effect in good faith), but it is indeed a very convenient suggestion.

Therefore, we recommend that you put all the things required for running the program into the version control system on the first day.

Summary

None of them are hard to understand. To be honest, they are all very basic: submit them as soon as possible and frequently, confirm what you have submitted and what you have changed, and make sure that there are other things to be put into the version control system, explain your submission information clearly and make sure that you submit the information yourself. Do not forget the database or the attached files. Also, do not use VSS :)