Using Version Control (Team Explorer Everywhere)
You use version control in a team development environment to isolate changes, reduce conflicts, and improve the predictability of your development processes. Each developer can make and test code changes on local copies of files before those files are shared with the team. If problems occur, you can easily compare versions of files to isolate the cause of the change and can even roll back changes.
Common Tasks
Task |
Supporting Content |
|---|---|
Understanding version control concepts: When you work with files that are under version control, you work with workspaces for Visual Studio Team Foundation Server and with changesets. You can use Team Foundation Server workspaces to manage development of multiple versions of an application at the same time. Changesets are the groups of files and related information that you check in to version control. |
|
Add files to version control: To begin the development lifecycle for a new project, you must add that project to version control to share it with your team. |
|
Get local copies of files: To begin work on a project, you must get a local copy of the files for that project. If you added the project to version control, you might already have those files. You might retrieve the latest version, or you might need to retrieve a previous version to fix a bug in a previous release of the application. To make changes, you must check out files from version control. You can lock the files to prevent other users from changing those files while you work with them. |
|
Submit changes: After you make and test your code changes, you must submit them as one or more changesets into version control to make them available to your team. If necessary, you can revert pending changes or roll back changes that you have already submitted to the server. You can create a shelveset if you must set aside pending changes or if you want to make a set of pending changes available for a code review before you check them in. You might set aside pending changes if, for example, you must fix a high priority bug in the same files. |
|
Manage sets of files for releases: You can use labels or branches to more easily manage releases that comprise sets of folders and files. By using labels, you can retrieve the versions of files that correspond to a particular build of your application. By using branches, you isolate risks that multiple teams incur when they develop code in the same codebase at the same time. |
|
View changeset history: For any file or folder that is under version control, you can get detailed information about what changes have been made. |