Develop your app in a Git repository (track, commit)
As you write your code, you can see, modify, and, as necessary, undo your changes. Commit as early and as often as you like. All your commits are local until you push them, so no Internet access is required.
To begin working in a Git repository, open it from the Team Explorer Connect page (Keyboard: Ctrl + 0, C).
The Team Explorer Connect page shows a list of repositories. Your repositories that have been published to Team Foundation Server (TFS are listed first. At the bottom of the page are the repositories that have not been published to TFS, including those with remotes hosted on other services such as CodePlex or GitHub.
From the Team Explorer Home page (Keyboard: Press Ctrl + 0, H), start coding in a new or in an existing solution.
After you open you solution, open Solution Explorer (Keyboard: Ctrl + Alt + L).
If you’re working in a solution that contains a lot of files, you’ll probably find it convenient to filter Solution Explorer to show only the files you have changed (Keyboard: Ctrl + [, P).
You can see changes you’ve made since the last commit, and if you want, you can continue to write code in the Diff window.
To see past changes, choose View History. To back out the changes you have made since the last commit, choose Undo. See View and manage past versions in Git
To open the Changes page with only those files in the Included section, select one or more files and choose Commit.
When you open and modify a file from Solution Explorer, the file is automatically checked out for you. Icons appear to indicate which files you have not changed , those you have checked out , and those you have added to the solution .
In most cases, you use Solution Explorer to add, rename, and delete items. In some cases, you might need to work with files that are not part of a solution.
For example, you could add a file, like the one in the illustration, to the Git repository on your dev machine.
As you develop your app in Solution Explorer, additions, edits, renames, and deletions are automatically tracked for you. But when you need to manage and eventually commit the changes you’ve made in your workspace, you can do it from the Changes page in Team Explorer (Keyboard Ctrl + 0, G).
Related Work Items: Add tasks here to help you identify your work. After you commit your changes, your team can view the related work items and see exactly which code changed to complete each task.
Use the controls on the page to associate work items. You can also associate work items by specifying them in your comment. For example you could associate the comment Add greeting #1 either on the Changes page or when using the git-commit command from the command prompt.
The association with the commit takes effect after you push.
Included and Excluded changes: Use these lists to control whether or not a change is included when you commit. If you want to:
Commit: You can commit your changes as often as you like. Your commits are stored on your local dev machine until you are ready to push them.
If you need to modify your last commit (for example, to change the comment or add a file), choose Actions and then choose Amend Previous Commit. See also: How do I alter or undo my committed changes?
Untracked Files: Lists files that are not in the repository and not ignored. In most cases you should move any item listed here into Included Changes. If the item is a transient file that you need but don’t want to add to the repository, you can ignore it.
Modify the view: To view your changes in a separate window, Undock from Team Explorer. You can also toggle between list view and tree view from the Actions menu.
Most developers use a .gitignore file to avoid cluttering their working environment and repository with temporary files such as locally compiled binary files. When ignored files or folders are added (for example, when Visual Studio locally builds your .dll files) to a folder in your local Git repository, they do not appear in the Changes page in Team Explorer, and these files are not committed or pushed.
One simple way to ignore a file, a type of file, or even a folder, is to do it from the Changes page:
You can also directly edit your .gitignore file from Git Settings:
The effects of the .gitignore file are recursive. You can create .gitignore files in sub-folders to override the effects of a .gitignore file in a parent folder. For details about .gitignore files, including their syntax, see Ignoring files and gitignore(5) Manual Page.
A: You have a couple of options:
You can create a new local branch and commit the changes there. For example, you make some changes in the master branch. You decide that you want to put these changes away and try a different approach. Create a possible_fix branch based on master, switch to possible_fix, and commit the changes in that branch. See Use Git branches to switch contexts, suspend work, and isolate risk.
You can stash the changes from the command prompt. See Work from the Git command prompt.
A: If the commit is the latest and only commit on your dev machine, you can amend it from the Changes page (choose Actions and choose Amend Previous Commit). Otherwise, after you have pushed the commit, open the work item in your web browser (Keyboard: Ctrl + 0, A), and link to the commit from there.
A: If you are an experienced Git user, you might have noticed that Visual Studio handles changes differently than the command prompt. You might have wondered if the Included Changes section contains your staged changes. In fact, Visual Studio usually bypasses the Git stage for you. When you commit changes, Visual Studio simultaneously stages and commits them. The one exception occurs when you add a file to your Git repository; Visual Studio does stage this kind of change.
A: In most cases, the author and the committer of a commit are the same person. One situation in which they differ is a commit that has been rebased. For example, if Julia rebases a commit from Peter, she becomes the committer of that commit, but Peter is still the author of the commit.
A: In general, you should avoid adding binary files to your Git repository, especially large ones that you change a lot. In many cases, you can use NuGet to dynamically download these kinds of dependencies. See NuGet.