Use Team Foundation Version Control
Azure Repos | Azure DevOps Server 2019 | TFS 2018 | TFS 2017 | TFS 2015 | VS 2017 | VS 2015 | VS 2013
Whether your software project is large or small, using version control as soon as possible is a good idea. Version control systems are software that help you track changes you make in your code over time. As you edit your code, you tell the version control system to take a snapshot of your files. The version control system saves that snapshot permanently so you can recall it later if you need it.
Azure DevOps Services and TFS provide two models of version control: Git, which is distributed version control, and Team Foundation Version Control (TFVC), which is centralized version control. This article provides an overview and a starting point for using Team Foundation Version Control. If you're deciding which type of Azure DevOps Services/TFS version control to use, see Choosing the right version control for your project.
Why use version control?
Without version control, you're tempted to keep multiple copies of code on your computer. This is dangerous, as it's easy to change or delete a file in the wrong copy of code, potentially losing work. Version control systems solve this problem by managing all versions of your code but presenting you with a single version at a time.
Version control systems provide the following benefits:
- Create workflows - Version control workflows prevent the chaos of everyone using their own development process with different and incompatible tools. Version control systems provide process enforcement and permissions so everyone stays on the same page.
- Work with versions - Every version has a description for what the changes in the version do, such as fix a bug or add a feature. These descriptions help you follow changes in your code by version instead of by individual file changes. Code stored in versions can be viewed and restored from version control at any time as needed. This makes it easy to base new work off any version of code.
- Code together - Version control synchronizes versions and makes sure that your changes don't conflict with other changes from your team. Your team relies on version control to help resolve and prevent conflicts, even when people make changes at the same time.
- Keep a history - Version control keeps a history of changes as your team saves new versions of your code. This history can be reviewed to find out who, why, and when changes were made. History gives you the confidence to experiment since you can roll back to a previous good version at any time. History lets you base work from any version of code, such as to fix a bug in a previous release.
- Automate tasks - Version control automation features save your team time and generate consistent results. You can automate testing, code analysis, and deployment when new versions are saved to version control.
There are plenty of things that can take up your time as a developer: reproducing bugs, learning new tools, and adding new features or content. As the demands of your users scale up, version control helps your team work together and ship on time.
Team Foundation Version Control
Team Foundation Version Control (TFVC) is a centralized version control system. Typically, team members have only one version of each file on their dev machines. Historical data is maintained only on the server. Branches are path-based and created on the server.
TFVC lets you apply granular permissions and restrict access down to a file level. Because your team checks in all their work into your Team Foundation server, you can easily audit changes and identify which user checked in a changeset. By using compare and annotate you can identify the exact changes that they made.
What do you want to do?
Spend a few minutes to set up your dev machine to take advantage of all the benefits of a version-controlled codebase.
Server workspaces - Before making changes, team members publicly check out files. Most operations require developers to be connected to the server. This system facilitates locking workflows. Other systems that work this way include Visual Source Safe, Perforce, and CVS. With server workspaces, you can scale up to very large codebases with millions of files per branch and large binary files.
Local workspaces - Each team member takes a copy of the latest version of the codebase with them and works offline as needed. Developers check in their changes and resolve conflicts as necessary. Another system that works this way is Subversion.
You don't have to think about version control in most situations. The system supports you when you need to manage and understand your changes.
Sometimes you need to set aside some or all of the work you are doing. Your version control system can take away some of the pain and reduce the time wasted by interruptions.
Check in your changes so your team can build upon, test, and release the value you've created.
Use branches and locks to isolate risk introduced by work done by different teams.
One advantage of a version control system is that you can look back in time to get detailed information about what changes have been made to your files.
You can compare server folders and local folders to each other, and view the differences between the contents of each folder.
A big advantage of using version control is that several people can work concurrently on a file. One drawback is that sometimes you must resolve conflicts. Although it can be frustrating to encounter conflicts, the system provides information and tools to help you understand and resolve conflicts.
When you need to prevent a file or folder from being checked out and altered, you can lock it.
Install a bit of software to create a build server, and then fill in a few fields to create a Continuous integration (CI) or nightly build process that enables you to leverage the power, convenience, scalability, and reliability of an automated build system to build your app.
Provides information about naming syntax, conventions, and limitations.
We are not currently republishing the following sections. However, you can read the Visual Studio 2010 version of this guidance.
Send feedback about: