Okay, it's working. All right, so the title of my talk is Git and GitHub for Windows Developers. Do you like that? I spent a lot of time on that transition. Okay, and before I start on that, I want to give you a little bit of information about me, my background,

and it will help put all this in context. So my name is Phil Hack. I'm on Twitter at AttaHack, and I also blog at Hack.com. Before joining GitHub, I worked at Microsoft, and I was part of the board collective there. But I recently took off the implants, put on some robot arms,

hang out with my friend Hubot, and joined GitHub. Now, as a former Microsoftie, it's almost required that we poke fun at the old company. All in good nature, of course. But if you really think about it, Microsoft's not the Borg.

There's this really great comic about the org charts of technical companies, and when you look at this, you think about the way the Borg is organized. It seems that Apple actually really fits that concept. A single leader, the queen Borg, and then all the little Borgs around them. This is more representative of Microsoft.

A collection of businesses pointing guns at each other. The reason why I find this slide interesting is, being on the inside, it just resonates that this is very true, and it also explains a lot of the decisions that you might be curious about at Microsoft, like, you know, why are they killing this technology or that technology? Well, someone pulled the trigger.

But enough about me. I want to take a moment and ask a question about you, learn about you. How many of you use Git day-to-day? Okay, quite a few. How many of you are stuck with subversion?

Okay, great. How many of you like subversion, that are stuck with it? Okay, we got a few of you. Cool. Today, what I want to talk about is three things. I want to give a brief background on GitHub the company and the way it works, because I think that it's interesting that when you understand how the company came about,

it tells you why the site is the way it is. I'll tell you a little bit about GitHub.com, give you a quick tour, some tips and tricks, and then we'll get into a little bit about Git and how Git works and what clients there are for Git. So GitHub was founded on this premise of social coding, this idea that if we can get people together

to collaborate on code, great things will happen. True story, GitHub was founded over some beers, or maybe it was Glog. My memory is hazy on this.

The point of that is that it's deep within the culture that when you get people out of the office and into a more social setting, great things happen, great ideas occur. So we have drink-ups and things like that where we get together and share ideas in an informal setting. I think conferences are also really good for that sort of thing.

So this may be a place, or tonight at the attendee party, might be a great place where new companies will be born out of just sharing ideas. So GitHub itself is structured as a flat hierarchy. We don't have this deep command and control structure.

It was interesting because I was listening to, I think it was Dan North talk about hierarchy, and why companies like hierarchy is because a lot of people really find it comforting to have a boss tell you what to do. And then that boss finds comfort having a boss tell you what to do.

I didn't find that so comforting because I had eight bosses if you went from me all the way up to Ballmer when I worked at Microsoft, whereas GitHub is organized more like an open source community. We formed teams, and someone might take the lead on that project, but we don't really report to each other for the most part.

We're distributed. Half the company works in San Francisco, and half the company works all over the world. I still live right near Redmond in Washington. We're bootstrapped. What that means is that we've never taken funding. We've been profitable pretty much from the beginning,

and that's allowed us to maintain control over what we build and what we do. And that's a really great thing when you're starting a company. It's often tempting to take the first round of funding that comes your way, but then you see a lot of control, and we've learned there's a lot of tricks VCs will do to take control from you.

So if you start a company, it's really nice to try to maintain control as long as you can. So that's a little bit about how we're structured. How we work falls under this real important principle that we want to optimize for happiness. You notice I didn't say profit. I didn't say productivity even,

because we feel all those things fall out of optimizing for happiness. For example, animated GIFs make us happy, so I like to show off animated GIFs, but that's not where we derive our productivity from. We derive our productivity from realizing things like meetings are wasteful.

For the most part, so one of my coworkers, Paul, wrote a tool when he was working at Microsoft, I forgot what you called it, a meeting bill. So it would analyze who's going to be in the meeting, looking at the exchange record of it, and figure out what their salary range is based on their title,

and then calculate for that hour how much that meeting is costing the company. And if you've ever been in a lot of meetings at work, you realize that most meetings waste your time, not everyone needs to be there, and then they typically end up scheduling a follow-up meeting to make the decision that wasn't made in the first meeting in the first place.

So we said, let's get rid of meetings, we don't need them. The reason we can do that is we've really focused on async communication. This is also important because if you're a remote worker, if you're not in the same office, you may be in a different time zone, you may not be able to work at the same time as others.

And as I'm going through these, you might realize that these are the same kind of themes you encounter when you work on an open source project. No set work hours. No one clocks me in, clocks me out. I work when I'm inspired. One of the things that a lot of people don't realize is that software development is a creative process.

It's not a rote, assembly-line manufacturing type of process. And so people aren't always inspired at the same hours of the day that everyone else is. So we like the flexibility to work when we feel most productive, or when it fits our lifestyle, you know, if you have kids.

We're big on automation, that's extremely important to us. Anything that you have to repeat over and over again, we try to automate. When I joined GitHub, one of the things that I was most excited about was our continuous integration processes, such that if you ever push any branches to a repository,

we automatically spin up a CI build for that, run all the tests on every single branch. Whereas before, that would require a lot of work, you know, oh, we've got a new branch, I've got to go and set all this config up. This might not be such a big deal in Europe, but trust me, in the U.S. this is a big deal,

because in the U.S. typically companies give you maybe two or three weeks of vacation, and if you've been there five years, you earn up to four. And I know in Europe you get like 50 or something like that. But, you know, the philosophy is if we hire people who are self-motivated and who are responsible,

then we don't need to baby them, we'll let them take vacation when they need it as much as they need. And when I tell people this, they think, this can't possibly work, and I respond to them, you're right, GitHub doesn't exist, it's all a figment of your imagination. It's worked so far, it'll be interesting to see how long it scales, in the form that it is.

So that's GitHub the company, and of course our primary product is GitHub.com. And so a lot of that stuff I told you should give you some insight into why GitHub.com is the way it is. So let me give you a quick tour of GitHub.com.

So this is the homepage, when you have an account and you log in, you get this activity feed here. And I'm going to, you can see your list of repositories on the right. And I like this because I like to see what some of my friends are doing. I see Steve Sanderson has commented on an issue, very interesting.

But let's do a search, I'm going to search for NuGet Gallery. This is an open source project near and dear to my heart. And when you go to a project page, the first thing we show you is the code. You can see here, I, you can iterate, sorry, navigate through all the code files.

If you scroll down, you can see the read me. So Paul had a talk yesterday about creating great open source projects. And one of the key tips he has is if you're hosting source code in GitHub, always have a read me. And if you give it the MD or markdown extension, then you can use markdown there and we'll render it nicely.

And it's great for anyone who wants to contribute to your project. So from the read me, I can navigate to the list of commits. So we can see here, I can easily see what's going on with commits. I can click to a specific commit and look at the changes. And then we can see here, we have this pull request.

So pull requests are sort of the, where we centralize our communication and our collaboration at GitHub. A lot of times, the basic concept of a pull request is I've made a bunch of changes in a branch and I want you to merge it to master here, take this set of changes.

But we sort of expanded on it and many times we will do a single commit in a branch, and send a pull request and say, don't merge this yet, I want you to give me some feedback and let's iterate on this. And each time you push commits to that branch, it updates the pull request. So it's an ongoing record of the collaboration you're doing on that set of commits or that branch.

And then let's take a look, let's just pick one at random and just take a look at it. So you can see here that we have this discussion tab and you can see there's this interesting ongoing discussion on this tab.

You can see the commits within and then you can look at the diff, and the discussion can be in line with the diff. So let's see if there's any comments in this one. Wow, this is a big one. So there might not be any comments, but I can always click here and say, hey, that's great, or something like that. Let's not do that because that would be irritating.

Okay, and then one new thing that we overhauled recently is graphs. So if you go to the graphs tab on a project, you can actually see interesting graphs of the contributors over time.

So for example, you can see that I had the second most commits to this project, but right about the time I joined GitHub in December, things stopped contributing. I hope to bring that back up. So let's go back to the code. One thing that I really like about the site is that it's heavily keyboard-oriented.

So if you hit question mark, we bring up the list of keyboard shortcuts. One of my favorites is if you are on the code page or code tab and you hit T, we bring up incremental search.

So for example, I can quickly search for authenticating controller. I can click blame, and I can say, oh, this guy hacked this line of code. And then I can see, well, let's see what changes he made on that line of code.

And then zoom out, and I can go right to that commit. So I often find that navigating a repository through the website is even faster than doing it through the command line and that sort of thing.

So this presentation I'm giving right now is actually also in GitHub. I have it in a private repository, and you can see I have a list of these presentations.

So right now, if I push this to a branch called gh-pages, it'll actually be published live. But before I do that, I can edit this file right here from the browser

and copy this entry and add an entry for NDC. So I'll just call it NDC, and then let me just get rid of this. And then I like to put the attendance number here. I won't do that now.

And then I can add a commit message, updating to add NDC, and commit the changes right from the browser. So it's great for editing your readme or files that you don't need to run compilation on, that sort of thing.

Another project that I'm going to show today is called Cget. And you'll notice here that we have this clone in Windows button now. If you're on a Mac, this would say clone in Mac. So this allows you to clone the repository using GitHub for Windows, which is a new product that we recently released.

And I'll show you that a little later. I won't do that now, though. Okay. Excuse me. So that's a brief tour of github.com, some of the things that are available on there. But I heard some of you love Subversion.

And it turns out that not many people realize this, but github.com is actually, I might consider, one of the best Subversion repositories around. How is that? Well, let me show you. So let's look at Cget here.

I'm going to copy this URL to the clipboard. I can either click that button or I can do it manually. And I have TortoiseSVN installed on my machine. The only reason I have TortoiseSVN installed on my machine is for this demo. But if you're familiar with it, you can go to SVN checkout.

You'll notice there that it's one thing I like about TortoiseSVN. I looked at my clipboard and realized that the URL had already populated that dialogue. And let's call this Cget and hit OK. I'll zoom out. Here's what I don't like about TortoiseSVN.

I clicked OK, but it didn't gray out the button, so I had no idea if it worked, and I keep clicking it, and then it breaks. But this time I knew what to do. And you see here that I'm actually checking out Cget using Subversion. What we have at github.com is a Subversion bridge that runs on the server

and is able to map Git to Subversion. So all the conventions that you're used to in Subversion are actually respected. So if I go to this directory, it's still cloning. But you'll notice here that the master branch, which is the Git terminology, is mapped to a trunk, which is what Subversion users would expect.

All the branches in my project are available under the branches directory of the Subversion repository. So I can actually use TortoiseSVN, and we support most of the features that you would need to do Subversion repository. So this is great, especially if you're a Git fan,

but your company still wants to use Subversion. You could convince them to host the code on github.com as a private repo or get the Enterprise product, but let them use Subversion while you use Git against the same repository. OK, let's see. All right, it worked.

So I go in here, and I won't actually change anything, but we can see that Git ignore wouldn't make any sense, but it looks like I need to upgrade TortoiseSVN.

But you can see here that I can make commits. It detected the changes. Everything works the way I would expect it. But I still believe Git is still better, and I'm not just trolling you.

There are several reasons why I feel Git is better, and I was a Subversion fan for a very long time, and I tried to ignore Git. But there's a lot of things that are beneficial by it being a distributed version control system.

One, it's local. So a lot of the operations like committing and merging and branching, all of that happens on your local machine. It doesn't require communication with the server to do all these operations. Whereas with something like Subversion or TFS, each of these operations are communicating to the server, and they end up slowing you down.

And what ends up happening is your beliefs and your attitude toward source control start to be shaped by how slow it is. I hear a lot of people say, well, I don't need branching, or I hate branching because it's slow, or I don't need branching. Why would anyone need it? And the reason why they don't need it is because it's painful because of their source control system.

It's slow. And if it's painful, you don't want to do it, and then you start making up reasons why you don't like doing it. So being local helps it be fast. It's not only fast because it's local. It's written in C. It's written by Linus Torvalds and his Linux hacking crew, and they are really big on making things fast.

It's small. It doesn't take up much space on your machine. As I mentioned earlier, branching is really fast. But more important than branching is merging. You can branch all you want, but if you can't merge those changes back together, then it's pointless. And they've done a really great job of making branching and merging

relatively painless for the most part. And it's distributed. And this is an important point, is that when you clone a Git repository, you get the whole repository on your local machine, and you can make changes local, commit local, and then you can always host it on a central repository like github.com, but you can also mail pull requests to people directly if you wanted to,

or you can pull from one repository, push to another, and everybody has the full history. So that distributed nature, for someone who's used to centralized source control like Subversion, it takes a little time to wrap your head around because it feels like there's this extra step.

I've got to make these changes locally, and then I've got to push it to a server. But once you understand why distributed is powerful, you realize that it all starts to make sense and click. So Git, how does it work? I'm going to show you a quick demo using the command line, and then I'll switch to GitHub for Windows,

which is a GUI client for Git. So I wrote this application I call C-Git, as in S-E-E-G-I-T.

And the point of this application is to visualize a Git repository, because I find that it's a nice way of helping people learn how Git works. So what I'm going to do here is start with the command line,

and we'll just start with the basics. I'm going to create a repository. So typically, make dir Trollhunter. This is a project that I started working on at this very conference. We'll call it an API for trollhunters everywhere to locate and find trolls and share information about their best troll-killing equipment.

So the first command I'm going to run is git init dot. And that's just basically saying, let's initialize a Git repository right here. And you see that's pretty fast. It returned immediately.

Now, I need to browse for this here so that we can start visualizing it and seeing what happens. What am I? Oh, okay. So there's nothing to see yet, because we don't have commits. Let's add a file to our working directory. So I'm going to create a readme file.

And you'll notice here that my prompt changed.

I'm using a library called posh-git, written by Keith Dalby, who's giving a more in-depth talk on Git later today, I think at 4 o'clock in this very room. So if you want to learn advanced Git, I definitely recommend it. He's taught me everything I know about Git. So one of the things this is telling me is that in my working directory, I have one modified file.

I can also type git status. Let's maximize this. And I can see I have this untracked file. That means that this is just the file on this that Git doesn't know anything about. I'm going to add it.

And now my prompt turns green. And what I've done is I've added it to the index. So Git has this interesting concept of the index and then actual commits in the repository. So the index is a place to stage a commit.

So what's really nice about it, a lot of people are confused by it, but what's nice about it is let's say you just start working and you're in the flow and you just make a bunch of unrelated changes. Then at some point you're ready to commit all the work into the repository. But you don't want this one giant massive commit that everyone who comes later to review your changes

are looking at and saying, what the heck is this? You've changed everything. So what you can do is you can stage a set of changes at a time and then commit just those changes and have this nice logical history. It's really great when you're doing code review. So I'll go ahead and commit this. And dash m is to specify a message,

and I'll just call this initial commit. And you notice here that something happened over here. Let's try zooming in. So let's talk about what happened there. So I've created a commit. Those changes are now in the repository.

And the way Git stores things is it stores, for each commit, it stores basically a tree of all the files in that particular commit. Well, the basic structure, although the implementation details might vary,

it doesn't store diffs that then you have to piece together. Each commit is a tree, and it just uses what you call sim links so that it doesn't have to duplicate the files that didn't change. The important thing is that every commit has a commit message,

a pointer to what's called a blob or the tree, and typically a pointer to it that says what branch is it. So you notice here that I have this little green thing that says this is the master branch. And there's also this concept of head, of what branch am I currently on.

Since I'm only on one branch, it's easy to determine master. But let's make some more changes. It helps if you spell notepad correctly.

So now that the file is already being tracked, I can do git commit am. And a is just basically add this file to the index so that I can commit it. And then m is the message, adding more details.

So now you'll see something interesting happen. There's a new commit, and that commit points to the first commit. Every commit, except for the initial one, has one or more parent commits. So that was the set of changes or files that happened before that

that this commit is based on. So in this case, this commit would have this one change to the readme that I did. And you notice that this flag here, this master flag, is pointing to this new commit.

So this is saying that this is where my working directory is at right now. So let's try branching. git checkout dash b. So there's actually two different ways to create a branch. I could just use the git branch command, or I can check which would create the branch,

but I'll still be on the old branch. Or I can use checkout dash b, and dash b is create this branch and also change my working directory to point to this branch. So we'll call it experimental. Now you notice here in C get, what happened there?

I created a branch, so did a bunch of stuff get copied into another directory and I had to wait there while stuff gets processed? No, it was immediate, because a branch is just a pointer. So back in your computer science days, it's just a pointer. It's a pointer to a commit. And so all we needed to do was say, well, we're creating a new branch,

there's no changes yet, so I'm just going to create a pointer and point it to the same commit. And that's why creating branches are really fast. It's just creating a pointer. So let's make a change. We're going to add a new file. I'm going to go ahead and add that and commit it.

Now you notice here that because I'm currently on the exp branch, when I created a new commit, that pointer is now pointing to the new commit. So my head is now pointing to that new commit.

But the master branch is still pointing to the old commit, because we didn't change that branch. Now I can switch back to that branch. So git checkout master, so git checkout branch name.

And what I've done is I've switched to that branch. So now my working directory has all the changes that were in this particular commit. And switching it is very fast, as you see. And you notice here that all we did was switch what we're pointing to. So let's make another commit in the master branch.

So we've finally deviated.

Now we have these two commits who point to the same parent. Because in this case, I made a different change in master

than I did in exp, and we just created a new commit, pointed to the parent, and moved the pointer. And again, I can easily switch branches. And you'll see that when I do, that the green pointer just changes. Okay, now I'm on exp, now I'm on master.

So as I mentioned earlier, a branch is a pointer to a commit, and the history for that branch is all the commits that are reachable. So when people talk about git, you're going to hear this term, directed acyclic graph. That's sort of this data structure that underlines git.

And it sounds very complicated, and I usually say, why are you telling people directed acyclic graph? Because most people's eyes roll in the back of their head, and it doesn't process, right? But all that really means is that we have this set of nodes, or these commits, and they point to a parent. And so that pointing implies a direction.

And so the history of the master branch is all the commits that are reachable from that commit. And you notice that this one I did in exp is not reachable from that commit, so it's not part of that branch. Now I can merge these two branches at some point. So let's git merge exp.

So what did merging do? Merging creates a commit that points to both branches that you're merging together. So now I get all the changes from both branches

in the master branch now. And again, you notice that exp is still pointing to the original, the exp branch is still pointing to here. So I didn't merge the exp branch. It still hasn't been changed. I've merged exp into master, so that master has all the changes that it always had and all the ones that exp has.

And as I mentioned before, the master branch's history is all the commits reachable by that commit. And you can see here I can reach all commits now, so I get all the changes. So that's sort of the underlying what happens. Now, one of the things that, unfortunately, cgit is an open source project in GitHub,

and I welcome contributions. One of the things I've yet to visualize properly is rebase. And I'll talk about that in a second. One other thing I want to show is a lot of times people run into problems because they do something and then they get into the state and they don't know what to do because they feel like they've lost everything.

Most of the time, you almost never lose anything in git. It's all there. It's just that it may be harder to access. For example, you can actually check out any commit. Let's check out EC782 blah blah blah.

Now, you'll notice here that master and exp have gone gray. Right now, I've checked out this commit, and my working state is in that state. This is what people will call detached head.

I'm pointing to this commit that doesn't have a branch pointer to it. Let's go back to masters, or exp, because what I actually meant to do was git reset head tilde one. Let's do dash dash hard.

This is one of those funky commands. What this is saying is git reset is a way of moving the branch pointer back to some number of commits. I'm saying move it back from the head where it currently is pointing to. Tilde one is one parent commit.

There's also a caret one. You can also do caret one or tilde one caret one because you might have multiple parents, and you have to tell it which parent. In this case, tilde one will work because it only has one parent. You notice here that exp has moved back here.

The exp doesn't point to that commit. This is actually a bad example. Let's do this on master. Now master is back one commit. You notice here that nobody points to this commit.

If you were actually looking at this in a typical git viewer, like gitk or in GitHub for Windows, this top commit here, 6CD8, would appear to be deleted. As far as you're concerned, it's not part of your history because nobody's pointing to it. It's like an object waiting to be garbage collected in C sharp or Java.

The good news is it's still there. You can find it using a command called reflog, git reflog. Reflog is basically the log of all the changes that have happened. It takes a little getting used to to understand what's going on. The point of me showing you the reflog is

a lot of times if you get in a state that you're not sure what's happened, reflog is a good way to get back into the state you were before. For example, I can git reset 6CD8 DC,

and now my master points back to there. If I find the commit that I was at, I can actually point master back to it. Now I'm back in the state I was before. There's tons of commands within Git, so I don't have time to show you all of them.

What I'd like to show you now is GitHub for Windows. If you go to windows.github.com, you'll see this big green link. You can download it from there quickly.

GitHub for Windows is the product that, when I joined GitHub, this is what I've been working on with several of my coworkers. What we really want to do is create a client for Git that did two things. First, it was the quickest and easiest way to get Git on your machine, even for those who are really experienced with Git.

For example, this git shell that I've been using, we added this icon here, and I can launch this, and I can get to a shell, the command line for Git, very quickly. If you're using PowerShell, it's set up with posh-git, and it also is set up with all the environment variables

set with reasonable defaults. Whereas if you've ever installed msys-git, you have to go through a bunch of checklists of all these questions that, at the time, you may not know the answer to because, hey, I'm just learning this. We wanted to try to avoid that situation where we're asking you questions you don't know how to answer. The other thing we're trying to target

is people relatively new to Git. We have the GUI client. A lot of people on Windows aren't big fans of command line. They're not used to the Linux or Unix mindset. We wanted to provide this real nice, easy client, but you can still drop into the shell at any point to do things if you're well-versed with Git.

Let's take this repository I've been working on.

I'm just going to drag it into here. You notice that when I drag it down at the bottom there, it says drop anywhere to add. This is how I can add existing repositories into GitHub for Windows. The other cool way I can do it is if I'm working on a project on GitHub.

Let's go to C Git, for example. I can click this Clone in Windows button. You'll notice here, if I switch back to here, it's now cloning that repository in my existing instance of GitHub for Windows.

It's a nice, quick way to clone repos. Even if you are a Git kung fu master and you love the command line, the client has a lot of nice features that might be complementary to your current workflow. Another way you can create a new repo is you can click Add, and we can go in here

and type in a repo name, and we'll create a repo there in wherever directory you specify. I won't do that at this point. Let's go to Troll Hunter. Let me discard this change. We're on the master branch here. I can quickly switch branches, just as we did before.

Let's see what's happening in C Git while I do this. I'm on exp. You see that's turned green. If I switch back to master, that turns green. It's all the same commands that we're running. We're making the same operations on the Git repository as we did before.

This is the repository view. When I'm looking at a repository, I can click here and I can go to settings. You notice here that we examine your repository.

We notice you don't have an ignore file. An ignore file is a file of patterns, like regex style patterns, for files that you don't want tracked by Git. If you click this, we'll actually create a default one, and you can click update and save that one.

Let's go back and take a quick look at it. For example, temp folders, .sdf files. Let's see. Mac crap. You don't want any of those things checked in your repository, so you add this to your repository

and it'll ignore all those things. The other thing is Git attributes. If you've ever used Git on Windows, you've almost certainly run into this problem where you check out a repository that someone else created,

and all the files immediately show changes. They show that every single line in the file has changed. The reason for that is that Git tries to normalize line endings. By that, I mean that with the object store, how it stores those things, it stores all line endings as LF. But on Windows, we store things as CRLF.

When you get the files out, Git will actually try to convert the line endings to CRLF, and then you make all your changes, and then when you commit, it'll convert them back to LF. That's if you have this setting called AutoCRLF to true. The problem with earlier versions of Git, though, is that that required that everybody who ever worked on your repository

had the same default system setting. That's kind of bad because you can barely get two developers to agree on anything in this world. Getting them to agree on that or anything else is challenging. What they realize is that the proper place to put these kinds of settings

is within a file in the repository. The repository is the one true source of this sort of thing. The thing is, not many people know about it, so we try to put it in front of people. I can add this Git attribute file, and I won't go into explanation. I don't know if maybe Keith will cover this.

It does one of two things. One is it says, how do you want the conversion to happen or not happen? The other is, tell us what files are binary or text. Sometimes, certain IDEs will, when you create a file, instead of UTF-8, it will create it as UTF-16.

I don't know why it does it, but sometimes that happens. Git interprets UTF-16 as binary, so then it won't do the proper disk that you would expect, as it would with a text file. This ensures that you can say, well, if it has this extension, it's definitely text. Don't treat it as binary, and vice versa.

I'll click update. You notice here that on the left side here, we have working changes. I can go in here, and I can see the disk. I can expand that, see the disk. I'm going to go ahead and commit this. Let me zoom in here. Say, adding the gitignore and git attributes file like a good gitter would.

You notice there that something happened to my commit message as I started typing characters. It started getting grayed out at a certain point. We try to really encourage good git habits.

For example, we want to encourage good commit messages. If you're ever looking at a list of commit messages using git log in the console, we want to make sure that the heading is going to fit there. We'll let you type more characters, and we'll let you commit that, but we're just trying to highlight that if you stop right here,

you'll have a nicely formatted git message. Then I can add an extended description, doing what the speaker told me to do. You notice here that it added this to my history,

and go in here and look at all these different changes. It's a nice way to iterate and look at the history of your commits. Of course, at some point, you're probably going to want to share this code with other people. I mean, not this code, but code like this.

We have this Push to GitHub button here. I'll go ahead and call this Trollhunter, a demo at NDC Oslo. Just because I know people are watching mic repos, I'm going to make this private just for the purposes of the demo,

because there's not really anything interesting here. I'll go ahead and push this. You notice here that the name of the repo changed from hacked slash trollhunter. Now I have a repository on github.com that this local repository is tracking. I can go ahead and publish this branch up to there.

That's going to push all the commits to GitHub. What happened on the right here is now that instead of unsynced changes, that changed the history. Let's go ahead and open this directory in Explorer,

make a change. When I switch back, you can see here that I have this uncommitted change. The uncommitted button showed that there's uncommitted changes, and I can show them, and it automatically detected that these changes were in my workspace.

A lot of people ask me, how do you integrate this into a Visual Studio workflow? Well, I'll just go into Visual Studio, make a bunch of changes, and then when I switch back to the app, it'll show me that, hey, we have changes that are not yet committed. Do you want to commit these? Well, we won't ask you that. We'll just show it to you. I can go ahead and commit this.

More changes. At this point, we can see that I have one unsynced commit. If you're a Git expert, you might be wondering, what is this concept of synced and unsynced? We did try to hide some of the complexities

of Git pull and push and all that stuff from people, for better or for worse. We had this concept of syncing. For a lot of people, this is really all they care about. I have these local changes, my local repository. How is it in relation to the one that's up on github.com?

I can highlight the sync button, for example, and it'll tell me that I'm ahead by one commit, and I'm not behind. Ahead means I have one commit locally that is not on github.com. If it's set up, I might also at the same time be behind. If other people have been pushing commits to github.com, I might be behind.

At this point, I can click the sync button, and we're going to take the local commit and push that up to github.com, but we'll also take the commits on github.com and pull them down as well. Then I'll be in the same state as the repo on github.com. Another thing you can do from any repo

is I can always open a shell there. There are certain cases where you might run into a state where you can't fix it through the GUI app, so you might need to drop in the shell and go do some Stack Overflow searches to find out what commands to run, but you always have that option. You can always click here to view the repository on github.com.

Let's create another branch. I'm going to call this test. This dialog here allows you to search for existing branches, so you can see I've found exp. In this case, there's not much to search. Or if you type something that doesn't exist, you notice that this label changes to create the branch.

If I do that, I've created the test branch. Let's go back to Seagate and see what that means. You notice here that we switched to the test branch, but there's this other thing here called origin slash master. What that means is that is a pointer to where,

since I now have an origin or a remote named origin, which is github.com, that's telling me where github.com is currently pointed to, where its master is pointed to. Let's make another commit here.

I'm going to actually switch back to master.

I made this commit locally. I have one local change that's not on the server. If we switch back to Seagate, we'll notice here that this is the actual representation of it in our repository. My master branch locally is pointing to here, but origin master, in other words the server,

is still pointing to this commit because I haven't yet pushed that commit up there. If I sync this again, we can switch back to here. When the sync is commit, we'll notice that the origin master is now pointing to the same commit.

Let's switch back to test here. I'm going to add a new file.

I can verify the diff, adding a file, commit. At this point, I have a deviation again. Let's make another change to make this branch look a little more interesting.

We can see here that I have test here,

which has two commits that master doesn't. Master has one commit, test doesn't. I'm ready to merge these. Before I show you the command line, we have a graphical way of merging within GitHub for Windows. I can click here to manage branches. I'll see a list of all my branches. I can see whether they're on github.com or not.

I can publish that to github.com. I can also delete them from github.com. A lot of times if I have a feature branch, which is typically the way I work, I'll create a branch, work on my feature, do a pull request, review with people, and then merge it back into master. Then I'll go ahead and delete that branch. I don't need it anymore.

One of the nice features I get is that branches aren't permanent. They only stick around as long as you need them or want them. But the commits are still there in the graph. I can always get back to it. What I'm going to do here is I want to merge this test branch into the master branch.

I don't know if you can see that easily at the bottom, but I drag the test branch here, drag the master branch here, and then I just click this merge. In Seagate, we can see that I created the merge commit. I merged these two branches together. I did it graphically. For some people, that's a lot easier way to visualize

how the merges work. A lot of times when I'm merging branches, like git merge, which branch goes where? The left one merges into the right one. It's pretty straightforward. It's a nice way to manage branches.

Again, you notice that I have yet to push those changes up to github.com, so origin maps are still here. Let's say I didn't like this commit, this blah-blah commit,

or this commit. There's a couple ways to fix mistakes that you made. One thing I can do is I can revert the commit. That's going to create a new commit that just sort of reverses all the changes made previously.

The reason why you might do that is if you've already published this set of changes to some remote server and shared it with other people, it's generally bad for them to change history. You don't want to actually modify commits in the past because they've already based their work on those commits.

This is why you might revert a commit. Let's revert blah-blah. If we look at that, we'll notice that the change is actually sort of the exact opposite of the previous commit. That's a commit that reverts the changes we made previously. But if you haven't shared the commits yet, if you're still working on this set and they're all local,

nobody else has these commits, you can also just roll back to a commit. One of the things we do when we roll back to a commit is we take all the changes in the commits that we're deleting, so to speak, and we move them into your working directory.

The reason we do that is that maybe the reason you're rolling back is you committed the wrong text in the file and you just want to tweak it and then recommit it. You can do that. But if you really meant to roll back and just discard all those changes, you can just right-click and discard Changes.

And now I've rolled back. If we go to C-Git, we can see that my graph is starting to get a little crazy, but the test branch is rolled back all the way here. Now, you know those commits are still in the tree, but we've just rolled back the test branch to this point in time,

and I can now start making new commits and deviate and create a really ugly graph. Most of the time, what I'm showing you here is not what you typically see in most UIs because we only typically show you the commits out of the current branch. This is just a way to visualize the entire repository and what's going on.

And to reassure you that if you reset, and when you reset and you think you're deleting commits, they're still there. They're still in the repository. You can still access them. It just gets a little harder. Unlike C-Sharp, Git is not too aggressive on collecting unreachable commits.

There are commands to prune or get rid of them and compact the repository, but you have to actively do that for the most part. Okay. One last thing I want to show.

We have the options dialogue. When you first launch it, we try to populate this based on your GitHub info if we know it. Typically, Git requires a name and an email. You can also configure your default shell here. I chose to use Console 2.

It's one of my favorites. By default, when you first install, it's PowerShell. You can also search a directory for existing repositories if you have them. And you can specify the default directory for your repository. This is where we'll clone everything too. I want to give a call out to all the open source products

that we leverage to build GitHub for Windows. So if you go to the licenses, you can see we use things like Caliburn Micro, Chromium Embedded Framework, .NET zip, blah, blah, blah, Posh Git. Lots of really cool open source projects. Worth checking out.

We use click once technology to keep updates constant and fresh. Since we released this a week or two ago, we've had, I think, it looks like seven updates, so we're already on 1.0.7. Updates are downloaded and ready, installed, sort of like Chrome style, behind the scenes, quietly.

Sometimes you'll see a little arrow here that says an update's available. Just go ahead and restart the app and then it will be installed. And then if you ever have a problem with GitHub for Windows, you find a bug or something just doesn't go right,

you can click here to contact support, or you can just email support at github.com And we read every single one of those emails and we try to respond as promptly as possible. Oh, sorry, one last thing about GitHub. Also, when you create a new repository,

you can also choose to push it to GitHub at the time that you create it, and you can choose which account it goes under. So I happen to be a member of multiple organizations, so I can choose which one it goes into. I have a blog post. If you want to use GitHub for Windows with other repositories,

you can't necessarily clone them from GitHub for Windows, but if you clone them using the shell, you can drag them in here and use GitHub for Windows with Copelux, Bitbucket, whatever you might have. So that does work. So resources.

Go to windows.github.com to get GitHub for Windows and see some screenshots and learn more about that. If you want to understand, Git is one of these products that sort of really puts its internal structure in front of you. And it's often intimidating for people new to Git,

which is why we created the client. But if you're really interested in how it works internally, I highly recommend the parable of Git. It's sort of a story about two developers who are trying to work together on some code and they don't have any source control, so they start inventing one using folders and copying files back and forth and such. And at the very end of the story, you realize...

that they've just invented Git. And it sort of highlights that, despite all these utilities and command lines and such, that at its very core, Git is really, really simple. It's just based on a very simple data structure. ThinkLikeAGit.net, this is a site that really helped me understand what rebase is, which I did not cover at all.

And I assume if you want to learn about that, you can go check out Keith's talk at 4 o'clock. But it really helps you understand how Git works. And it was the inspiration for C-Git, because he has all these really cool diagrams of Git repositories. Better Git with PowerShell, this is a blog post I wrote,

but it's sort of now superseded by GitHub for Windows, because when you install GitHub for Windows, you have everything set up for you. You don't need to go through all the steps I write about. Posh Git is the PowerShell library that we use that gives you all these tab completion and all that really cool status updates within the shell.

And then C-Git is the open source project that I'm working on as a means of teaching people Git and visualizing a Git repository. So thank you very much. If you have any questions, I think I'm out of time. So feel free to come ping me during lunch or afterwards, and I'll be happy to answer questions.

Thank you.