Links from the talk:

* Git homepage

* Msysgit (Git for Windows)

* GitExtensions (Wraps Git for Windows + Visual studio + more niceness)

* Github

* Gitblit (the windows friendly repository manager)

* Git for Human Beings mailing list where I hang out

* The giveaway book (thanks to Viaboxx, my employer)

* The free books online

Other links

* Git Cheat Sheet:

* German Cheat Sheet:

Does anyone use Git at work?

The tweets:

Before I start, let me give you the TLDR version:

Main Goal today: show you how Git works on Windows. More specifically, three things:

Act 1: Install Git (Extensions). In Visual Studio. Create a repo

Act 2: Show cmd-line action, git internals

Act 3: Push it to Gitub, and then to a “company repo” on Gitblit

Act 1: The basics, up and running

You’ll have to learn yourself Git. It’s hard.

First we’ll do the GUI way.

Now some quick git set up (from Visual studio)

  1. init
  1. Note how GitExtensions is helping us configure
  2. GitExt suggest to init inside the solution, but let’s check in the sln file too
  3. show in explorer what happened (.git folder)
  1. The repo still has no objects, so we’ll add a add a .gitignore file
  1. Git -> Edit .gitignore - Use suggested defaults
  2. Git -> Commit -> Stage the .gitignore file
  1. commit (only the .gitignore), do another commit with all changes.
  2. Show log
  3. Commit --amend, and show log again
  4. clone (metis-backup --bare in c:\backups)
  5. push (to the backup)
  6. Drop to cmd line to show log in backup repo

How about some command line action

Note that I use Console2, nothing fancy, it’s just a wrapper around the normal cmd line.

Set shell to be: %SystemRoot%\syswow64\WindowsPowerShell\v1.0\powershell.exe

and home to be c:\Users\tfnico

posh git

for some extra flair:

* cinst poshgit - this gives us nice state display, still a bit laggy. I’ll leave it out for now, but you might want to use this in your daily work, if you prefer cmd line.

To reset the ps1, see


  1. Delete the .git folder in Metis: del -recurse -force .git
  2. Git init
  3. Now show the contents of .git folder, no objects
  4. Commit .gitignore
  5. Have a look at objects (commit, tree and blob)
  1. git show --pretty=raw commit
  2. Note the commit itself, the tree, and the file.
  1. Talk a bit about the SHA
  1. note that in can have a short form
  1. Now commit the rest of the project skeleton
  2. Create a readme.txt, add it and stash it
  1. Create a stash “renaming to metis”
  1. branch
  1. Create and check out a branch “branding”
  2. Commit some CSS
  3. Apply the stash
  1. checkout (switch, revert)
  1. Back to master
  2. Create another branch: “about”, commit something
  1. merge
  1. Merge “branding” back, no problem
  2. Merge “about” back, notice the merge commit
  1. Show git log
  1. --oneline --decorate --graph

Remote repositories

Why even have a central repository in a DVCS?


Internet Explorer: Log in as tfnico-123

Create a repo “metis”, with initial commit. Clone it over https.

Use manual smart https auth 

Store username/password in $HOME/_netrc

Be careful with this file though, don’t think special chars in PW’s are allowed.


login tfnico-123

password bonn2code

Note the warning we get about config default push branches.

Do we have time to show off SSH right away?

Fork one of tfnico’s repos (guava)

Make a push request.


Awfully easy to set up. Just download, change the http port in the properties config, and start it:

C:\tools\gitblit\gitblit-0.9.3> .\gitblit.cmd


Create repo

Set auth on view and push

Store username and password in ~/_netrc

machine localhost

login tfnico

password bonn2code

Bonus part: SSH

Using SSH keys instead of smart-http username/password make sense for many reasons, but it’s kinda exotic for Windows users. The big minus with http is that you have to store the PW in cleartext on your machine (but hey, who cares).

We’ve already Installed putty along with Git Extensions (for ssh).

In order to make it work with normal Windows command line, you have to set the environment variable GIT_SSH to point at c:\program files (x86)\gitextensions\putty\plink.exe).

Have a look at Github’s help page for more hints:

Bonus part: GIt-SVN

git svn clone -s

Teardown (to restart the demo)

Remove gitblit repos

Uninstall putty

Uninstall git

Uninstall kdiff

Remove ~/keys

Remove github repo

Remove github keys

Delete ~/_netrc

Delete ~/.gitconfig

Delete metis project (also from github)

Remove c:\backup bare repos

Remove ps1 stuff in C:\Users\tfnico\Documents\WindowsPowerShell\...

Some more discussion notes

What’s wrong with TFS?

(will all files really be read-only if the network goes down??)

(merging support is pretty bad, like in SVN I guess)

(I’ve heard buggy, slow)

But “We don’t need distributed”

Answer: May be true, but distributed enables a few things. More over: The branch-intensive way enables some more things.

Integrates with Visual Studio:

Make sure you know .gitignore:

Integrates with VS and Explorer:

Migrating from other VCS:

TFS bridge:

Git implemented for .Net/Mono (based on JGIT):

GitSharp development is currently on hold because we believe that the libgit2 project and its C# bindings libgit2sharp are far more promising to work on.

Discussion point: Why Git?

How fast is it?

Even in the most agile of companies, doing kanban and whatnot, context switching happens.

Between versions of software

Between tasks

Between people (helping, pairing, reviewing)

Git makes this switching cheaper, easier, faster.

* Git is not easy, but it is simple: It all boils down to being three kinds of objects in a graph (commits, blobs, trees).

These are used together to store the code. At each point in time, there’s a snapshot of the whole codebase.

There are over a 100 git commands that do stuff on these objects, but only a handful of these you need to know. In the old days, there wasn’t a clear border between what you had to know and what not. Today that’s what’s known as plumbing vs porcelain.

Why is Subversion (or centralized) complex?

- Because the stuff on the server is something different from what you have locally. Your local checkout is just a thin skin. All the interaction goes over the network with a really thin and crappy API. It’s like looking reading a book using binoculars. The same information is there, but it’s horrible to get at it.

- Everybody is tangled together using the same repository. People start making mistakes like committing without updating first. Everyone misuse trunk as their own sandbox. This is complexity too (everything in one bucket).

- It mixes together committing, and pushing the changes to central. A commit should do one thing, and one thing well, and the reasoning should be in the commit message. Some are refactorings, others are feature-changes.

- Because branches are completely disconnected - there’s nothing that ties them together, except being a lot like each other. That’s how merging in Subversion works: “I assume that these two directories will be very similar”, and if they aren’t, BOOM.

* Git is much much more powerful than SVN and TFS (merging, local branching, stashes, reset)

* It puts you, the developer, in control (organize your own workflow)

* Git is safe, as long as one person in the team knows git well.

* You have to take it seriously. Command line fans rejoice.

* It brings RC up to be a first-class citizen among your developer tools. Becoming something you actually care about

        - make well-designed commits

        - analyze history (git bisect)

        - multi task

A lot of devs already have enough things they care about, so why should they care about RC?

* It’s a lot like Mercurial. I won’t be mad at you if you go home and play around with Mercurial instead of Git, as long as you try one of them. They are technically roughly equal,  tastebud-wise different. I think every developer will have to know Git at some point though, as it is the major part of open source projects.