Reproduced 8 Big considerations for TFS Source code management

Directory

1. Using TFS for source code control

2. If the code is not placed in the source control software, it does not exist

3. To submit early, often submit, and do not feel trouble

4. Check what you have changed before submitting

5. Be sure to write your submission carefully

6. Improve code quality with code reviews

7. Be sure to manage the database version

8. Integration of the necessary satellite files into source code control

Refer to this link for specific use of TFS: http://msdn.microsoft.com/zh-cn/library/ms181382.aspx

Source control software is an essential tool for our work and is the blood of many development teams. So how do you make better use of TFS for source code control?

1. Why use TFS 2012 for source Control

Why TFS is used, in terms of source control, TFS has the following advantages:

L Seamless integration with Visual Studio for developers to source code control

L Support code Review and discussion

L Support Email Notification

L Support Web Access and management

• Support for management of work items and bugs

L will not upload. NET development-generated junk files

L comes with version merging and comparison tools.

L Support Database version management

L comes with many management tools (test Manager, feedback client, interface design tools, etc.)

2. If the code is not placed in the source control software, 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.

3. To submit early, often submit, 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.

4. Check what you have changed before submitting

The steps to submit the code to the source control software are very simple. (You're afraid you'll be confused about why it's so troublesome.) Generally, as long as the contents of the document are found to be changed, 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 an SVN submission window like the following, they click "Select All" and then commit-so the source repository will be confused by the non-debug files and other junk files that should not have existed.

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.

5. Be sure to write your submission carefully

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 the "history" feature or other similar features shows who changed the code in those places.

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

6. Improve code quality with code reviews

Code reviews can improve code quality.

Visual Studio2012 contains a code review workflow that originates from Team Foundation server. For specific use please refer to this link: http://msdn.microsoft.com/zh-cn/library/hh474795.aspx#code-review-request

7. Be sure to manage the database version

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.

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.

Then, using the Visual Studio database project to manage the database, you can use TFS to manage the database version. For specific use please refer to this link: http://msdn.microsoft.com/zh-cn/library/vstudio/dd193266 (v=vs.100). aspx

Using the VS Database project has the following advantages:

L Support version Management

L Facilitate Team collaboration development

L support deployment to a database that cannot be versioned

L Support generation of test data

L offers a number of additional features and tools: Database schema Comparisons, data comparisons, build scripts, and more

8. Integration of the necessary satellite files into source code control

This is a particularly important point. 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.

For example, if our project typically references many third-party DLLs, then these DLLs should be integrated into source code control.

At last

• This document, Word edition:8 big considerations for TFS Source control. zip.
• This article refers to the source control 10 commandment and makes some changes.
• I hope that we will actively discuss and add.
  
  

Blog transfer from: "8 big considerations for TFS Source Control"

Reproduced 8 Big considerations for TFS Source code management