Checkin Command
Commits pending changes in the current workspace to the server for Team Foundation version control.
Required Permissions
To use the checkin command you must have the Check in permission set to Allow. To use /author option, you must have Check in other user's changes permission set to Allow. For more information, see Team Foundation Server Permissions.
tf checkin [/author:author name] [/comment:("comment"|@comment file)]
[/noprompt] [/notes:("Note Name"="note text"|@notefile)]
[/override:(reason|@reasonfile)] [/recursive] [/saved] [/validate] [itemspec] [/bypass] [/login:username,[password]]
tf checkin /shelveset:shelvesetname[;shelvesetowner] [/bypass] [/noprompt] [/login:username,[password]] [/collection:TeamProjectCollectionUrl][/author:author name] [/force]
Parameters
Argument |
Description |
|---|---|
author name |
The user-provided value for the /author option. |
comment |
A user-provided comment about the check-in. |
@comment file |
The user-provided path of a file on disk that contains the comment for the check-in. |
NoteFieldName=NoteFieldValue |
Sets the value of the check-in note field. You can provide multiple, semicolon-separated "field=value" expressions. |
Notefile |
The user-provided path of a file on disk that contains check-in note field names and values in the format of "field=value" A semicolon separated note tile can span multiple lines, for example: field1=value1; field2=value that spans multiple lines;. |
Reasonfile |
A user-provided description of the reason why the check-in policy is being ignored. If a reason is specified, a notification of the policy override and this explanation is sent to Team Foundation administrators by e-mail. |
itemspec |
Specifies a file or folder to check-in. For more information about how Team Foundation parses a file specification to determine which items are within its scope, see Command-Line Options. |
username |
Provides a value to the /login option. You can specify a username value as either DOMAIN\UserName or UserName. |
shelvesetname [:owner] |
Identifies the shelveset that you want to check in. The optional owner argument is used to specify a shelveset that the current user does not own. |
TeamProjectCollectionUrl |
The URL of the team project collection that contains the files or folders that you want to check in (for example, http://myserver:8080/tfs/DefaultCollection). |
Option |
Description |
|---|---|
/author |
Identifies the author of the pending changes so that one user can check in changes on behalf of another user. Requires the CheckinOther permission. |
/comment |
Associates a comment with the changeset. |
/noprompt |
Suppresses any prompts for input from you. |
/notes |
Provides one or more check-in notes to associate with the changeset. |
/override |
Lets you override a check-in policy failure. This option is only needed when there is a check-in policy and you want to check in anyway. |
/recursive |
Checks in all items in the specified or implied working folder and subfolders. |
/saved |
When a check-in fails or is canceled by the user or when the user unshelves changes, the selected changes, comment, work items, check-in notes, and check-in policy override reason, if any, are stored on the computer. When combined with /noprompt, the /saved option checks in the changes with the comment, etc. that were saved, if any. |
/validate |
The /validate option lets you test checking in without actually doing it. The /validate options causes checkin to evaluate checkin policies, check check-in notes, and look for conflicts without actually checking in. Any problems, such as conflicts, that are identified by this option must be resolved before you check in the item. |
/bypass |
Bypasses a gated check-in requirement. For more information, see Check In Pending Changes that Are Controlled by a Gated Check-in Build. |
/login |
Specifies the user name and password to authenticate the user with Visual Studio Team Foundation Server. |
/shelveset |
Specifies the shelveset by name. |
/collection |
Specifies the team project collection. |
Remarks
A pending change consists of a file or folder addition, deletion, rename, edit, branch, undelete or filetype. You can apply some changes, such as edit and rename, to a single item at the same time. A pending change is one that has not been submitted for check-in. For more information about and a complete list of pending changes in Team Foundation, see Pending Changes.
The checkin command creates a changeset in the Team Foundation version control server from a dynamically defined set of pending changes, work items, user-defined comments, and system metadata and makes your changes available to other users. Other users can use the get command to retrieve your changes. The history and changeset commands show changeset information for the changes you have submitted.
Note
Because you can check in pending changes from the command line, the Source Control Explorer context menu might not always reflect the status of the pending changes.
For more information on how to find the tf command-line utility, see Tf Command-Line Utility Commands.
The Check-in Process
The check-in operation is performed atomically, which means that the operation either succeeds completely or fails completely. If any one of the changes in the list of pending changes cannot be submitted to the Team Foundation version control server, not one of the changes is committed and a changeset is not created. For example, if you lose network connectivity in the middle of the operation, the whole operation fails.
The first step in the check-in process is to evaluate the pending changes for compliance with check-in policies. You can override check-in policy failures at the command-line using the /override option. You must supply a reason why policy failures are being overridden. This reason is persisted in the Team Foundation version control server and becomes an attribute of the committed changeset. The /override option is primarily intended for use in scripts. For more information, see Override a Check-In Policy.
If a version of an item in the list of pending changes differs from the latest Team Foundation version control server version, Team Foundation prompts you to resolve conflicts between your version and the latest Team Foundation version control server version first. For example, if you checked out version 4 of stellar.cs and the latest Team Foundation version control server version is now version 6, you are prompted to resolve conflicts. Unless the **/noprompt **option is specified, the Resolve dialog box appears to help you investigate and resolve version differences. After you resolve differences and re-test your code, you can try to check in your changes again.
Examples
The following example displays the Check In dialog box that has pending changes pre-selected for a bulk check-in operation of all pending changes in the workspace mapped to c:\projects. If you click Check In, each item is individually submitted to a changeset in the server for Team Foundation version control and evaluated to make sure that the server version is unchanged because the item was checked out. If the check-in succeeds, Team Foundation creates a changeset and displays its number for later reference.
c:\projects>tf checkin
The following example submits all pending changes in the current workspace to the Team Foundation version control server together with the specified comment to create a new changeset.
c:\projects>tf checkin /comment:"Re-implemented Pi calculator" /noprompt
The following example submits pending changes to 314.cs and leaves all other revisions in the current workspace as pending.
c:\projects>tf checkin 314.cs /noprompt
See Also
Tasks
Reference
Command-Line Syntax (Version Control)