Visual Studio and git. Build-in tooling.

(this article in Polish language – Polska wersja )

I already tried using Visual Studio git build-in provider, then I was disappointed. Now I try with open mind
if it is better and if it is usable for day-to-day use.  Post is dedicated for TFS users, which will be switching to git🙂

Visual Studio Configuration

If we was using TFS as our daily source control management system, then we need to change Source Control pluginin Visual Studio settings. To do this go to Tools -> Options -> Source Control and change Current source control plug-into Git.

New repository

Post is created in that way you can test git plugin with me. Create new Console Application File -> New -> Project...

(You need check check box with red outline.) Remember repository created that way is not empty, it contains two
commits (TFS – Check-ins)! It doing couple things first is doing git init and adding some files

• Adds .gitignore i .gitattributes – first commit
• Project files (.sln, .csproj, Program.cs, App.config, AssemblyInfo.cs)
  – second commit

.gitignore contains list of extensions and folders, which git ignores (duh!) and do not
recommends them to add into git index if they appear in git repository.. .gitignore is usually prepared for concrete
development environment, in our case our environment is Visual Studio. If you what that file consist of you
can go to GitHub, it is not exactly the
same but very close. One of functions .gitattributes is to set how git should handle end-of-line
(CRLF for Windows vs. LF for Linux). It have line like this * text=auto, which do this:

1. git guess if file is a text file
2. If it is then: after commit it will change CRLF to LF and file with LF will be stored in git repository. When user will
   get data from repository git will so smart and change end-of-line characters based on operating system we are using.

Team Explorer

When we open solution under git control when can manage repository by Team Explorer (Ctrl+\  Ctrl+M).
Comparing it with TFS we do not have so many options to choose from for example we do not use Source Control Explorer.

Let’s go through them in reverse order, I will start with Settings.

Settings

Settings we can separate into global, which are all repositories on our machine and local or repository
settings which is only that one repository.

Global Settings

User name and email are values used to sign our commits as us.

Default Repository Location is path used when you use File -> New -> Repository. I can ignore
it.

Commit changes after merge by default – When two branches are merged git auto-creates new commit which sum up
changes which ware applied. If you don’t want to this commit being automatically created by git you can uncheck this box.
For those who know various git commands by console, it is equivalent of --no-commit switch for git pull

Diff Tool sets application that will be used for showing differences between two commits. You can set diff tool
to Visual Studio by clicking on Use Visual Studio

Merge tool shows differences between Remote (file, we fetch) , Current (state
after merge) and Local (changes we have done locally). We can set merge tool as Visual Studio by clicking on
Use Visual Studio.

Repository settings

We can override global settings which are used to “sign” our commits. We can acces to files like .gitignoreand .gitattributes to modify them.

Remotes are the list of external servers to which we can sent (push) our changes to or to download
them (fetch/pull).

Name origin is usually used for default remote.

Sync

Let’s go to Home in Team Explorer, and next to Sync. In that tool we can sent
our changes to remote server.

First data sent are special one, because server do not know about our local branches yet. It is why git cannot tell what
are changes between our branch master and remote which do not have any branches yet.

master name is usually used for main branch in git repository. We can changed it to whatever name we choose.
git does’t care about names. We must click on publish to sent information about our local branches
and 2 commits, which was created by Visual Studio itself.

• Sync – do Pull and then Push
• Fetch – download commits from server (but do not merge them)
• Pull – do Fetch a and then merge
• Push – sent your local commits to remote server.

Changes

After we do some changes on working files, which are staged in repository, for e.g. adding

Console.WriteLine("Hello, World");

into Program.cs file. Change in file should be reflected on changes list.
By double clicking on it we can show our changes which we done to this file.

After clicking on Commit all we will receive information about commit being created locally

To share your changes with other developers you need to sent to remote.

Sync, again

This time git is tracking changes in branch master and can tell what changes are between local version and remote.

Let’s send them again by using push button.

Branches

There is a lot ways to organize your team work with git. One of more enterprise way is using something calledgit flow.
A will not be fully explaining and using git flow further, but one principals is creating separate branch for each new feature and they are called feature branch. It is small only local branch created for a time of development for single feature. Branch management in Visual Studio is done by Branches panel. Here we have list of all local and remote branches in our repository. Right-click on name of branch we will get some extra options to choose from.

• Checkout – switch to other branch
• New Local Branch From... – create new branch
• Merge From... – merges two branches into one, similar to TFS
• Rebase Onto... – merges two branches, but there is different result in git history. See this: Merge vs Rebase
• Reset – allows us to revert changes done on working copy.

Let’s create new branch np. foo_feature.

Checkout branch means switching to new branch after it is created. From now on new changes that are committed, are committed to new branch.

For changes from branch foo_feature being moved to master branch we must do a merge.
merge is done in two steps:

1. Checkout to branch you want changes to be pulled-in, in our case it is master branch. To switch to other branch you need to got into Branches and then do double click on selected branch.
2. Right click on feature branch and choose Merge From...

In result you sould see dialog which looks like this:

Last thing to do is to confirm merge by clicking on Merge. I am sure you want to share changes with others, to do so you need to go into Sync panel and push changes to remote server.

Conclusion

I think it is usable tool for day-to-day work load. I still think that knowledge of console based git usage is faster and more precised. I need look at this plugin, how it behaves when very thing is going wrong.