Talk about source code control that thing (i)--source code Control 10 Commandments

Introduction:

I would like to see if there are tools that can be used without prejudice in various programming languages than the source code management software. Source control software is an essential tool for our work and is the blood of many development teams. Then why do we all misunderstand it? Why is it hard to understand the core values and fundamentals of version control systems?

The original author concludes that 10 conventions (if you wish to use "commandments") mean that you must obey it and that it is difficult to understand at first. They are associated with version control software for all types of programming languages. Here I have selected a few examples of subversion and. NET, but they are also widely applicable to other technologies.

English Original: The commandments of good source control management

The first commandment, if you're still using VSS, stop right now.

It's dead. Of course not exactly, it has survived for many years, and is still alive after being overtaken by a new and more practical source control tool. It is true that when Microsoft (or will persist for some time), it is really dead.

In all fairness, VSS is still a good tool. In 1995, its glow was obscured by distributed software like subversion, like git and mercurial. Microsoft has said it has been replacing it for years.

The reason is that the failure to support today's standards leads to a series of flaws that keep it from being bullish. It is known to be Microsoft's tragic system, but somehow it can persist for so long, though it has so many glitches, flaws, and does not contain the necessary features (as compared to today's standards).

The second commandment, if the code is not placed in the source control software, equals it does not exist

Repeat this sentence every day-"using source control software is the only effective measure". Unless you are working with the project's source control library for controlling the code version-otherwise the code is not there.

Obviously you've found that running good code on your local machine is not working well with other people. Isn't it? They can't get your latest version, they can't merge the code files, you don't deploy it correctly (refer to you ' re deploying it wrong) and if your SSD drive goes bad, you'll lose your labor forever.

As long as you keep this mindset-the code is only really safe after submission, it is the guarantee of other good programming habits. You can divide your tasks into very small units so that you will submit them one after the other. You need to do this frequently. You don't have to worry about whether your hardware will be a tricky problem.

But the more important point is that (at least for your team leader), you can see what you've done with source control software. It's a good idea to use charts and list items, but how do you know what they're actually doing? And with the source code control software to work can be seen clearly.

The third commandment, to be submitted early, often submitted, and do not feel trouble

The only way to avoid "phantom Code" (which is the code that can only be seen on your machine) is to submit your task frequently and not be bothered about the previous point. It can solve your problem, but doing so will have other effects on your work:

　　1. Each submitted revision will provide you with a restore point. If you screw up the code completely (we've done it all), do you want to get back to work one hours ago or a week ago?

　　2. The risk of merging files will increase over time. merging files has always been a hassle. If you don't keep submitting your code every day, you'll suddenly notice that you and other people have more than 50 conflicting changes. You're not going to be happy about this.

　　3. It prompts you to separate the tasks into scattered units. It's usually done quickly, because they want to make the code a complete logical unit. However, a large task inevitably separates smaller scattered functions, and submitting them frequently will give you a better understanding of them, and you can build and submit them one after the other.

If you do this, your commit history inevitably begins to resemble a semi-regular style, in which every weekday is committed. Of course not always, there are pauses to refactor or test, or other reasonable activities will interrupt the standard development cycle.

However, when I look at an independent--especially a complete project--when I find ourselves in a standard development cycle, one day or a few days without doing anything, I get very worried. I was worried because it meant something went wrong. In general, not someone is trying to get things done, it is because the card is on a problem and the project is completely out of progress. Whatever the case, the source code control software will tell you that something is wrong.

The four commandments, before submitting, to check what you have changed

The steps to submit the code to the source control software are very simple (you may be confused about why it is so troublesome). In general, as long as the contents of the document changes will be regardless of the consequences of the file to pass up. Like this--"My project root directory has changed the contents of the file, I want to quickly submit it up!" ”

So one (or two) things happen: First, the programmer will not consciously upload the junk code files in the directory. When some people see a window similar to the one below, they click "Select All" and then submit it-so the source repository will be confused by the non-debug files and other junk files that should not exist.

Or, programmers don't actually check what they've changed and upload the file. When you're working on a profile or project definition file, it's easy to accidentally upload files that you don't want to commit, and those files are likely to be used by other programmers. Do you really remember all the changes you made in the config file?

The solution is simple: You must check where you have changed before you submit. It's actually easier to do than it sounds. Using the "Ignore" features already provided by many systems can significantly reduce the risk of "inadvertently uploading files". You can ignore the Thumbs.db file because you don't want to upload it at all. You may have other files that you don't want to upload after each revision--then ignore them!

As for the changes in the file, you can usually use a popular text comparison tool to observe the differences. Why do I have to upload the Web. config file again?

Oh, I remember, I want to reduce the maximum number of attempts to fail the password from 5 to 3 times. Ah, I almost did not pay attention to a virtual login page to upload up. This practice of checking before submission can make it easier for you to understand what's in the next section.

The five commandments, write the submission information must be serious

This is an old proverb (unknown source), to the effect that "writing every submission is as if the person reading it is an axe murderer, and he knows where you live." If I was the homicidal maniac and I was researching your code to track bugs, the submissions were all "code updates", careful, I'll cut you!

My solution is to explain why the new code is being submitted. every time you make changes to your code, there's a reason. Maybe it's going to crash somewhere. Maybe the customer doesn't like the current theme color. Maybe you just need to tweak the build configuration. Whatever it is, it's for a reason and you have to keep the reason in words.

Why? There are many reasons for this, and they vary in different environments. For example, using a "attribution" feature or other similar function shows who changed the code in those places. If I don't remember where I changed my web. config file for the project 18 months ago or why I changed the settings of my application, it was because I didn't leave a proper submission at the time, and now it's very simple:

This is one of the software that can observe code changes at any time. Whether I want to know the full change history of a file like the following, or just what the team did yesterday, leaving a descriptive correlation record means that you can see what's going on with a casual glance.

Finally, it is not possible 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 of your integration environment. My example is very obvious, but the presentation of information can be a great solution to many tricky problems.

Keep this in mind, here are some examples of submitting information:

1. Hateful
2. I can run.
3. Fixed some of the problems with the mixed account
4. Resolves the
5. Improved a bit of bug
6. Uploaded the
7. Typographical errors
8. Revision 1024

OK, I'm from the stack Overflow website which is the worst submission you've ever written (the translator note: The post has been deleted, why is there a bad language?) Posts, but they are not the same as the submissions I've seen before. They do not tell you any valid information about the code changes, they are all junk information.

The last thing to note about submitting information is that the same programmer should never submit the information exactly as before. The reason is well understood: you are submitting files to source control software because something has changed for the previous version of the Code. Your current code is not the same as before, and if your submission is complete and accurate, you cannot theoretically be the same as the previous one. If it is the same (and may sometimes be true), the log will be difficult to read because there is no way to differentiate between two commits.

The six commandments, you must submit your changes yourself--Can't entrust others

It sounds strange, but it does happen, and I've seen it more than once, most recently last week. The situation is that the source code base is considered a very high position. For many reasons, the team will go after the perfect code for cleanliness and singleness. In order to maintain this divine state, the code can only be submitted by a leading programmer who carefully integrates, examines and (presumably) adjusts the code for improvement before committing.

It is easy to judge the plan even if it is far away. Less frequent submissions (maybe a few times a week), only one person out of the team's other programmers, and inevitably the work of someone in this lengthy, no-commit period will lead to a confusing project. Very, very bad.

There are two errors: first, the source control software does not mean that the code inside it is sacrosanct, at least throughout the development cycle. It should be where the team consolidates files frequently, reverting to normal and solving problems when things go wrong. This is not done all the time, but only when the application cycle is published in order to achieve a certain state.

Another problem-and really critical-is the programmer's point of view, which equals that you're not using source control software at all! it equals no companion code integration, no restore, no responsible for submitting information, nothing! You just have to write your own code in your own ivory tower and wait for the future to give it to the leader by the way.

Don't do that. No, never.

Seventh commandment, be sure to manage the version of the database

This is something we all know must be done, but many people find it troublesome. The problem is that many (or most) applications cannot run without a database. If you don't manage a database, you're actually doing an incomplete, completely useless application.

Almost all version control systems work by managing files within the file system. It is only useful for typical applications such as HTML pages, images, CSS, project profiles and other standalone units in file systems. The problem is that it really does not work on databases that are associated with programs. You can't replace a huge database by replacing all the old data files with a whole bunch of objects and data log files. This will make the version control system completely chaotic.

The intelligent SQL Source control developed by Red Gate has made this situation a reasonable solution. I wrote about this software in the post of rocking your SQL Source Control world and Red Gate last year, so I'm not going to say it anymore, but database management is now very easy!

To be honest, if you don't manage your database version, your development will be accompanied by a lot of problems. There is no source code management when changing the database, there is no restore point, and it is difficult to work closely with the team. Using a database versioning system can make development easier.

The eighth commandment, compile generated files do not put into the source code control software

Simply put: The resulting file automatically generated when compiling the run project does not go into the source control software. For. NET developers, primarily the. dll and. pdb files that are typically present in the "Bin" and "obj" folders.

Why? Because if you do, your coworkers will hate you. This means that whenever they remove the latest files from the version control system, they will let your compilation file overwrite them. This is a double nightmare (you can never do this), and it will be a problem when they compile next time. And as long as they recompile and then upload the compiled files again, the same problem will happen again in the opposite direction, but this time you are the victim. You certainly don't want to do that.

Another problem, of course, is that it is wasteful. This wastes the hard disk space of the source control server, wastes bandwidth and is always lurking over the network, and the unavoidable conflict that this creates can be extremely wasteful of your time.

So we continue to use the "ignore" scenario mentioned earlier. Just ignore the path like "bin" and "obj", and it's really easy. As long as you do it this way, everyone will feel happy.

In fact, when I wrote Pre-commit hooks, I was talking about the inability to submit such files on a version-controlled server. Of course, if there is a reason to do so, only in this case you can upload it. However, I prefer not to do so in the future to cause someone to conflict in the update.

The Nineth commandment, do not upload your own user settings

To be honest, I think a lot of people haven't noticed that they've uploaded their personal settings to the source code control software. The problem with this is that many tools produce files that only manage your own local configuration. They are only useful to you and often differ from other people's personal settings files. If you upload them to the source control software, you'll soon be overwriting the other person's private settings files. That's not good.

This is a typical. NET programs:

If you do not clean up immediately, the extra is to extend the file and type description, that is. Resharper.user files and. suo (solution user option, Solution users option) two files that belong to you and are not valid for others.

To understand this, let's take a look at the ReSharper file:

<Configuration>  <settingscomponent>    <string/>    <integer/>    <Boolean>      <settingname= "solutionanalysisenabled">True</setting>    </Boolean>  </settingscomponent>  <RecentFiles>    <RecentFiles>      <FileID= "F985644d-6f99-43ab-93f5-c1569a66b0a7/f:web.config"Caret= "1121"Fromtop= "+" />      <FileID= "F985644d-6f99-43ab-93f5-c1569a66b0a7/f:site.master.cs"Caret= "0"Fromtop= "0" />

In this case, I just recorded the solution analysis function in the user's file. This is only for me, I like this feature, others are not necessarily. Usually because they are using an aging cheap machine, I am a bit off topic. The point is that my settings will force other people to do the same. I do not mean that other people are going to do the same.

(Side note: The place where VSS is imperfect lies mainly in ignoring. Resharper.user files is a bit of a problem. Can look at this post)

This principle also applies to. suo files. But there's nothing inside (it's not an XML format, but a binary), which records the state of the solution browser, the release settings, and other things you don't want to force on other people's computers.

So we're going to use the ignore scheme again to handle it. The premise is that you're not using VSS.

The tenth commandment and the accompanying documents are to be integrated together.

This is the last and the most important of the Ten Commandments. When an application requires an external subordinate file to exist to function properly, put those files into the source control software! The mistake people tend to make is that they upload everything well in an environment where they have their own setup files and local affiliate files, and then feel no problem. But other people can't find the same accessory file from the source code repository, everything will be tragic error.

I thought of this because there was a picture of dragging an old project out of the source code repository and running it today:

I thought NUnit had been on the machine, but not this time. Fortunately, using NuGet can solve problems quickly, but without collateral, it can be easily solved in the same way every time. In some cases, they are not public, and it's hard to get them all.

The project I removed from the source control software ran an error because I found that the attached file was missing under the "C:\Program files ..." path. I spent a lot of time contacting the person who finally changed it (apparently he was in another far place in the world), took the file, put it in the "Libraries" folder and uploaded it to the version control system so that the next person who extracted the file would not need to be so troublesome.

Another important reason, of course, is that if you work in any kind of integration environment, your build server doesn't necessarily have those libraries installed. You have to have those files to run. Doug Rathbone recently wrote a very good article on this point third party tools live in your source control (third parties tool in source control software). It's not that we have to do that (we also have a good look at the effect), but it's really a handy suggestion.

So it's recommended that everyone put everything they need to run the program on the first day into the version control system.

Summary:

No one is hard to understand. To be honest, they are all very basic: submit as quickly and frequently as possible, confirm what you have changed, and make sure to put it in the version control system, explain your submission and ensure that you submit it yourself, don't forget the database and do not forget the attached file. And just don't use VSS:)

Summarize:

The scientific and orderly management of the source code, whether for individuals or teams, is a very valuable thing. What tools should we use to manage such important things? Please see a blog: "Svn-tfs, Thunder clock meaning bingo more points?" 》

Talk about source code control that Thing (a)-source code Control 10 Commandments (ext.)