Check In Your Pending Changes to the Server
After making sure that your application builds with the latest version, you can check in your changes to Team Foundation source control and make the project visible to your teammates.
.gif) Note |
|---|
| If your application does not build, if you have not had time to test it for some reason, or if you want to share your code for review by another developer, you can shelve your changes instead of checking in. For more information, see Working with Source Control Shelvesets. |
You can check in pending changes in the following ways:
-
Using the Source Control submenu of the File menu.
-
Right-click a checked-out file in Solution Explorer or Source Control Explorer.
-
Click Check In, in the Pending Changes window.
To quickly check in all pending changes to the server
-
On the View menu, click Pending Changes.
-
In the Pending Changes window, type a comment in the Comment box to explain the nature of your changes such as "added using directive" and why you made them for example, "to enable calls to the Directory class".
-
Open the Work Items channel and select any work items that are relevant to your pending changes. For more information, see How to: Associate Work Items with Changesets.
-
Open the Check-in Notes channel and fill in comments for the check-in notes for the Code Reviewer, Security Reviewer, and Performance Reviewer.
| Note |
|---|
| Check-in notes can be configured as mandatory fields by an administrator and must be completed during the check-in process. Mandatory fields are indicated by the shaded color in the text box background. |
For more information about how to create check-in notes and create custom work item transitions, see Walkthrough: Customizing Check-in Policies and Notes.
-
Click Check In.
The Team Foundation Server check-in process is designed for individual ease of use and team extensibility. To optimize ease of use, the Pending Changes window implicitly assumes that you want to check in all changes. However, you can easily exempt individual pending changes from being checked in. Check-in generally applies sets of related changes instead of individual ones. Conversely, when you check in from Solution Explorer or the File menu, Visual Studio assumes that you only want to check in changes to the selected item unless the selected item is a file container such as a project or solution.
A Team Foundation Server administrator can associate a set of custom check-in policies with a team project to make sure that all check-ins meet specific guidelines or requirements.
Individual team members can create work items to track product defects or feature requests and associate a work item with a specific project. When you complete a work item, you can associate it with the source changes by marking it as such on the Work Items channel in the Pending Changes window. Associating work items with source changes makes sure that you enable accountability and tracking of work status.
Finally, you and your teammates can add meaningful and consistent notes to each check-in. The process template used to create the team project determines the form and content of check-in notes and can be customized by the Team Foundation Server administrator. Categories of Check-in Notes can include the following: performance impact, documentation requirements, test instructions, and build instructions.