Team Services | TFS 2015 & TFS 2017 | Visual Studio 2015 & 2017
Git does not automatically snapshot your code as you make edits to files in your repo. You must tell Git exactly which changes you want to add to the next snapshot by staging those changes. After staging your changes, create a commit to save the snapshot to your repo.
Git tracks file changes in your repo as you work, and separates the files in your repo into three categories:
- Unmodified files – These files haven’t changed since your last commit.
- Modified files – These files have changes since your last commit, but you aren't yet staged for the next commit.
- Staged files – These files have changes that will be added to the next commit.
When you create a commit, only the staged changes and unchanged files are used for the snapshot. Changes to unstaged but modified files are kept, but the commit uses the unmodified version from the previous commit in its snapshot.
Commits are created in your local Git repository, so you don't have to worry about your changes being perfect. Continue to create commits as you work, pushing your changes to then team when they are ready to share.
What's in a commit
Commits include the following information:
- A snapshot of the files saved in the commit. Git snapshots the contents of all files in your repo at the time of the commit—this makes switching versions very fast and helps Git merge changes.
- A reference to the parent commit(s). Commits with multiple parents occur when branches are merged together.
- A short and to the point message describing the changes in the commit. You enter this message when you create the commit.
Git uses the references between commits along with the file snapshots to maintain a complete record of development in your repo.
Stage your changes
Git does not automatically add changed files to the snapshot when you create a commit. You must first stage your changes to let Git know which updates you want to add to the next commit. Staging lets you to selectively add files to a commit while excluding changes made in other files.
Ignore temp files, logs, and other files that might change on your local machine but you don't want to add to version control.
Visual Studio 2015 (Update 2) and 2017
Visual Studio keeps track of file changes to your project as you do your work. When you are ready to stage changes, open up the Changes view in Team Explorer.
Stage individual file changes by right-clicking a file in the Change view and selecting Stage. Staging a change creates a Staged Changes section in Team Explorer. Only changes in the Staged Changes section are added to the next commit.
The Team Explorer Changes view had Included Files and Excluded Files sections before Visual Studio 2015 Update 2. The Changes view was updated in Visual Studio 2015 Update 2 for better compatibility with other Git tools.
Stage multiple files or folders by selecting them then right-clicking and choosing Stage or by dragging and dropping files from the Changes list into the Staged Changes list.
Ignore files by right-clicking and selecting Ignore this local item or Ignore this extension. This adds an entry to the the file to the .gitignore file in your local repo. If the ignored file was added
to your repo in an earlier commit, ignoring the file will not remove it from the Changes list. See excluding and ignoring files section for more information on how to ignore files already tracked by Git.
> git add --all > git status
--all flag stages all changes made in the repo since the last commit. Note that adding all changes might include files you don't want to commit to version control
such as IDE project files, build outputs, and editor autosaves. Tell Git to ignore stop tracking these files by setting up a
.gitignore for your repository.
You can find a large, up-to-date set of gitignore configurations for a variety of tools in the GitHub gitignore repository.
If you need to selectively stage file changes, you can use the Git
mv commands to add changes and updates, remove files, and move/rename files respectively.
See the tutorial command reference and the Git command line reference for more information on using these commands.
status command after you stage files to review your changes before making a commit. Checking
status before committing is a great way to avoid trouble.
Create a commit
Open the Changes view in Team Explorer.
Enter a commit message describing your changes and select Commit Staged to create a new commit that includes the changes listed in the Staged Changes section.
Skip staging files if you just want to commit all changes listed by entering a commit message and selecting Commit All when you have no staged changes.
> git status > git commit -m "short but descriptive message"
status command before
commit to review your staged and unstaged changes. Checking
status before creating a commit helps avoid trouble.
commit command runs with the
-m flag, which allows you to pass a message through the command line. If you don't provide this, Git will open up an editor in the
terminal so you can enter a commit message.
Update your last commit
Amend your last commit to correct small errors without making a new commit.
Visual Studio 2015 Update 2
- Open the Changes view in Team Explorer and stage your updated changes. You can amend just the commit message by leaving the staged changes empty.
- Enter the updated commit message and select Amend Previous Commit from the Actions drop-down.
- Stage your changes using
git addjust as you would if you were creating a new commit.
- Use the
--amendoption to the
commitcommand to update the most recent commit with the staged changes and updated description.
> git commit -m --amend "short descriptive message"