Links from the talk:
* Msysgit (Git for Windows)
* GitExtensions (Wraps Git for Windows + Visual studio + more niceness)
* Gitblit (the windows friendly repository manager)
* Git for Human Beings mailing list where I hang out
* Git Cheat Sheet: http://zrusin.blogspot.com/2007/09/git-cheat-sheet.html
* German Cheat Sheet: https://github.com/esc/git-cheatsheet-de/blob/master/cheatsheet.pdf
Does anyone use Git at work?
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
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)
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
for some extra flair: https://github.com/dahlbyk/posh-git
* 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
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.
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:
Set auth on view and push
Store username and password in ~/_netrc
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: http://help.github.com/ssh-issues/
git svn clone -s http://svn2.assembla.com/svn/peekr/
Teardown (to restart the demo)
Remove gitblit repos
Remove github repo
Remove github keys
Delete metis project (also from github)
Remove c:\backup bare repos
Remove ps1 stuff in C:\Users\tfnico\Documents\WindowsPowerShell\...
Some more discussion notes
(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:
Git implemented for .Net/Mono (based on JGIT):
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 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.