Develop your app in a Git repository (track, commit)
Many people find that they can develop their app more efficiently and effectively under Git version control. As you write your code, you can commit as early and as often as you like. You have a detailed view of exactly what you changed, when you changed it, and the ability to undo your changes. All your commits are local, so no Internet access is required.
From the Team Explorer Connect page (Keyboard: Ctrl + 0, C) view and connect to your work, whether it is in TFVC or in Git version control (local, in TFS team projects, or on other services such as CodePlex and GitHub).
If you work in a local repository that’s associated with a remote repository in a Git team project, this repository is listed under your Team Foundation Server, not in the Local Git Repositories section. If the local repository is associated with a remote repository that is not in TFS (for example, in CodePlex), then the local repository is listed.
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, as explained earlier. Occasionally you might need to work with a file that is 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.
In most cases, all you need to do is 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.
Included vs. Excluded changes: Use these lists to control whether or not a change is included when you commit. The Included list is not related to the Git stage. See below for details.
Tracked vs. Untracked changes: Move files that you don’t want to manage under Git version control to the Untracked section.
Commit: You can commit your changes as often as you like. Make sure you specify a comment before you commit because you cannot do it afterward. Your commits are stored on your local dev machine until you are ready to push them.
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 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.