Figure: When trying to undo a change you will sometimes get errors. The answer is to exit Visual Studio and use the command line

Figure: use ‘git reset --hard HEAD’ to throw away all your uncommitted changes

That's where the new Visual Studio Online REST APIs come in. You can get a list of commits from your VSO Git repository with only a HTTP request.​

Figure: HTTPS GET commits from your VSO Git repository

​Using H​TTPS with basic authentication, make a GET request to a URL as below, substituting in your VSO details. A JSON object will be returned. To quickly create classes from a JSON response, see the rule Do you know how to easily get classes from a JSON response?

Figure: Using the Chrome extension Postman to execute our request with Basic Authentication

​For a C# implementation, see this blog post Getting Git Commits with the VSO REST API​​.​

(This is based on Get started with the REST APIs and VSO Integration Reference)​

** Level 1 - Understanding the basic principles

At this level, you need to have an understanding of the basic operations (including branching).​

Your workflow looks like this:

• init local repository / clone
• pull
• <code>
  
• commit
  
• push  
  

** Level 2 -  Working with Git on a team

Now that you know the basic Git commands you can start working on projects with more than one developer.

You should be using local feature branches for your work.

Your workflow involves:

• pull 
  
• merge
  
• push  
  

** Level 3 - Learning to use pull requests 

Pull requests can be used for code reviews within your team, or to accept suggested changes from people outside your team.

Pull requests should preferably be used with policies (TFS Git only  - harder with GitHub). 

** Level 4 -  Working with a team advanced - Rebasing (harder, but worth it) 

When working in a team, Git does a pretty good job of merging code together from different branches... but it can be very messy. 
True Git masters master rebasing​. It lets you keep a much cleaner project history.

Git process for Git masters:​

• pull master
  
• rebase feature branch on top of remote master
  
• push feature branch to remote or create pull request

Figure: Bad example – no protection – anyone can make unreviewed changes

Figure: Good example – the branch protected

• it eliminates the unnecessary merge commits required by git merge
  
• rebasing also results in a perfectly linear project history - you can follow the tip of feature all the way to the beginning of the project without any forks.

This makes it easier to navigate your project with commands like git log, git bisect, and gitk.

Figure: When merging: a messy merge commit is created any time you need to incorporate upstream changes from the master branch

Figure: Git Rebase moves your new commits to the end of the master branch. This ensure that you don't end up with messy merge commits and you have a clean linear project history

Warning: If you don’t follow the Golden Rule of Rebasing, you could end up in a ​world of pain.

The golden rule of git rebase is to never use it on public branches. (ie. never rebase master).

You should never rebase master onto a feature branch. This would move all of the commits in master onto the tip of  the feature branch (not the other way around). 

Since rebasing results in brand new commits, Git will think that your master branch’s history has diverged from everybody else’s. If you were to Push this to the server... expect lots of pain to fix it up!

Figure: Bad Example: Rebasing master onto a feature branch can cause project history to become confused.    

​

Figure: To get it wrong in Visual Studio you would need to change the current branch to master and then choose rebase. While this is possible, the VS team have done a good job making it hard to do the wrong thing

Figure: Good Example - Rebase your Feature branch onto Master

​Git pro tip

If you use console for fetching data use this command to fetch and prune remotes/origin folder at the same time!

git fetch -p

VisualStudio.com - Import Repository

VisualStudio.com gives you the ability to import from a TFVC repository into a new Git repository. 

Git -Tf 

TIP - Use Git-Tf if you don't have a Windows environment

Figure: Bad Example - Alternate  Authentication Credentials should not be used. When you change the password it invalidates all projects and can't be scoped to limit access to your Team Services data

Instead, you should use Personal Access Token. You can do this in two ways.

The first option is to make sure your Git for Windows is up-to-date and when cloning the repository, you use Microsoft Account to log in. Personal Access Token for Git will be created for you.

Figure: Good Example - Windows for Git credential manager will automatically create Personal Access Token for Git

Option 2 is to manually create Personal Access Token and use it as a password for Git login.

You can follow this blog post for full instructions: Using Personal Access Tokens to access Visual Studio Online.

Figure: Good Example - You can also manually enter Personal Access Token into password section if the credential manager doesn't work​

​

Delete files from TFVC

Go into the repository, delete any existing files. Add a new document saying "_Migrated_to_Git.md". This will stop people from getting the wrong code.

Note: All the source code is still there, it's just flagged as being deleted.

Lock down TFVC

In the TFVC repository, click Security

​

​​Then deny check-ins to Contributors, Project Administrators and Project Collection Administrators. This should stop anyone from committing new code to the repository.

Update the Dashboard

​Next step is to update the dashboard to let new developers know.

​​

​​

​Suggestions for the VSTS team

1. ​​Give us the ability to hide a repository
   
2. Give us the ability to set a repository as the default for all users
   
3. Give us the ability to delete a TFVC repository