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
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
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
.gitattributes– first commit
- Project files (
– 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:
- git guess if file is a text file
- 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.
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 we can separate into global, which are all repositories on our machine and local or repository
settings which is only that one repository.
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
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
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) ,
after merge) and
Local (changes we have done locally). We can set merge tool as Visual Studio by clicking on
Use Visual Studio.
We can override global settings which are used to “sign” our commits. We can acces to files like
.gitattributes to modify them.
Remotes are the list of external servers to which we can sent (
push) our changes to or to download
origin is usually used for default
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.
Fetch– download commits from server (but do not merge them)
Fetcha and then
Push– sent your local commits to remote server.
After we do some changes on working files, which are staged in repository, for e.g. adding
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.
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
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.
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 is done in two steps:
- Checkout to branch you want changes to be pulled-in, in our case it is
masterbranch. To switch to other branch you need to got into Branches and then do double click on selected branch.
- Right click on feature branch and choose
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.
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.