Once you are sure that your application builds with the latest version, you can check in your changes to Team Foundation version control and make the project visible to your teammates.
.gif) Note: |
|---|
If your application does not build because you did not have time to test it, or if you wanted to have your code reviewed by another developer, you can shelve your changes instead of checking them in. For more information, see
Working with Version Control Shelvesets.
|
You can check in pending changes in the following ways:
Use 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 check in all pending changes to the server
On the View menu, click Other Windows, and then click Pending Changes.
In the Pending Changes window, type a comment in the Comment box to explain the nature of your changes.
For example, you could type "added using directive" and, to indicate the reason, "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 add 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. They must be completed during the check-in process. The shaded color in the text box background indicates which fields are mandatory.
|
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 from the File menu, Visual Studio assumes that you only want to check in changes to the selected item. When you select a file container such as a project or solution, you are selecting for check-in that item and the items it contains.
A Team Foundation Server administrator can associate a set of custom check-in policies with a team project to ensure that all check-ins meet specific guidelines or requirements.
Individual team members can create work items to track product defects or feature requests. They can 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. When you associate work items with source changes, you guarantee accountability and careful 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 your check-in notes. The Team Foundation Server administrator can customize the template for your team. Categories of check-in notes can include performance impact, documentation requirements, test instructions, and build instructions.