GitHub adds new setup tutorials

This is just a quick update, but I noticed that GitHub added some awesome new introductory tutorials for setting up Git with GitHub and the basics of pushing / pulling / branching / merging.

Here’s links to the different articles if your interested.

Windows Setup For Git
Mac Setup For Git
Linux Setup For Git

Creating A Repository
Forking A Repository
Social Coding



Undo Forever – Version control for the rest of us

You’ve run into it before. You fire up a new project, write some code, leave, come back, and a week or two later decide the approach was all wrong. Code becomes a mess. We try one thing, then another, go back, try again, break things, experiment, wash rinse and repeat. You work on it for a few more days, and realize you were almost right the first time, and now you want to go back. What do you do?

This talk will focus on using GIT as a local SCM (Source Code Management) tool to help alleviate some of the problems we as developers face on a day to day basis in various situations. No cost, no server, no hosting, local versioning, undo forever.

Sanity is a good thing.

And so begins my talk on Git at the first SoCal CodeCamp of 2011.

I know most of you have run into one of the following situations before.

  • Your on a large project, and you hate checking in because you might break the build.
  • You work on small personal projects (Your in a programming class and have assignments to do) and setting up and or using subversion sounds like a complete waste of time, yet you wish you could never close visual studio so you could ctrl+z back to wherever you wanted.

Bear in mind, almost everything I talk about today can be replicated in some fashion by most of the Version Control Systems out there already. Regardless, my goal is to give you something you can take home today and use tonight to help relieve some stress from pain points you may never even knew existed because you were so used to it. Even just to take the ideas and apply them to your current situation and workflow.

Git was created in 2005 back when the Linux kernel lost their licensing for BitKeeper, and something was needed to replace it besides patches and tarballs. Linus, finding no good versioning system out there, created his own and released it to the community a few months later calling it git. It has several unique features:

  • Distributed (which means every repository is a full copy of the entire repository)
  • Efficient handling of large projects (Git is SUPER fast)
  • Cryptographic authentication of history
  • Snapshots entire tree’s instead of individual files

College Dev Story

Sweet. What does this mean for you? Ok, you’re a college student again. You have an project you already thought you completed but find out there’s a new requirement that require a bunch of changes to your code. You think you know what you need to do. If your like me (because this actually happened to me) you pull out the project, maybe make a copy of it, and start partying on the code to meet the new requirement. Two days later, you wish you could go back one day ago, because you introduced some code and made some refactors that are definitely not going the way you wanted. Trouble is, the last copy of your code (if you actually made the copy) was two days ago when you started. Fail.

If your also like me, you also find it a paint to set something up, I really don’t have any desire to install subversion, make a free account somewhere (or God forbid, setup my own server, configure the dns so I can access it offsite, deal with checkout / checkins) because its a school project. Who CARES about a small project when the setup to version it is a pain? So here’s where I wish I knew about something like Git, for this simple feature: I can version my files locally, without a server, without a network, without the version control system interfering with however I would like to edit my code. (Subversion adds a bunch of .svn directories, TFS makes all your files read only (Try saving a file with notepad, it sucks)) Creating a new repository with Git takes less than a second, doesn’t touch any of my files, and when I commit, it tracks all my changes by the cryptographic hash of the content (No more worrying about if my change accidentally got missed).

It would have made it much easier to track my assignments, all of them, even the little scratchpad apps I created to test things and experiment.

Enterprise Sized Dev Story

Now, the other story. In this story you’re a developer on a large project. Say there’s about 30 people working on the same project, broken up into 3-4 teams, each working on a different portion of the application, using a centralized version control solution like subversion or tfs. Everything is fine and dandy until someone checks in something that breaks the project. 29 developers get latest, hit ctrl+f5 in visual studio, and the build fails. So, management gets involved, and now there’s a build server, and a checkin policy that the project has to build using something like the build tools with VS team edition or something like Cruise Control. This goes well for a while until people start realizing that as the systems interact that functions that they thought were stable are suddenly being used by other people and returning values they didn’t expect. So e-mails fly, and now the build server has unit tests and a build validation with unit that must pass.

There’s nothing inherently wrong with having a central server to store all your code, nor is having unit tests or build validation. However, to you and me as developers, it does present a difficulty. How do I develop something without breaking anything while I’m building it? I get stuck between a rock and a hard place. On one hand, the code I’m working on is in an unstable state, some of the unit tests don’t pass, and I’ve been working on said feature for about 2 days. I can’t check-in my code because it’s unstable, but I also don’t want to lose the history of what I’ve been working on.

Enter Git once again. Remember what I said earlier about Git having both cryptographic authentication of history and that it snapshots the entire state of the tree? Well, here’s what this means: I can use Git on top of an existing version control system like SVN or TFS, without affecting what they do for source control, and still keep a history of changes, and backups of those changes either somewhere on my computer, an external drive, or a network drive. And that cryptographic history thing? All it means is that it hashes the contents of the file. It could care less if TFS changes the read only state or about checkouts or checkins, because git is tracking it by what has actually changed.

Last Remarks

Hopefully, this enough to get you on your feet and get you started, if you want to get started and play with it (which I’d highly recommend) this post I’ve written earlier should get you up and running with Git, Git Extensions (a UI layer for Git) and Visual Studio.

Up and Running with GIT and Visual Studio

Another resource I’d highly recommend is ProGit, a book that is also fully online that digs into the details of Git:

Speaker Slides and Info

Slides from the presentation: Undo Forever on Slideshare
Speaker Rate: Speaker Rate

GitHub 101 on Windows

This post is a continuation off of this post on Up and Running with Git and Visual Studio, if you have no idea what Git is, or how to setup git and git-extensions on windows I recommend you start there.

So you’ve installed git and git extensions, written a sweet hello world application, made some commits, split some branches and merged features in and out here and there, and now your looking to share that code with the world or you’ve decided that just having a local copy of your code isn’t good enough for a backup and don’t want or can’t go out and purchase another machine or setup remote hard drive. For whatever reason, you’ve decided to use GitHub to push a copy of your source code up to, either to share with the world, keep a local backup, or to share with a team.

First, you’ll need to create a GitHub account, which is free for public/shared repositories (example: Open Source Projects), and from $7-22 a month for private repositories, and $25+ for organizations and companies. Assuming you decide to go with a free account to try things out, you’ll land at a page that will look like this:

Pick a username, an e-mail address, and a password, click the signup button, and bam! You’re now a member of the GitHub community. You can now go explore, setup your profile, write a bio (Your picture is based on your e-mail address from the Gravatar service, the homepage explains it well enough)

Now, on GitHub your going to create a new repository, it’ll ask you for a project name, optional description and homepage. Enter all the details and click Create Repository (Note that Project Name doesn’t have to be unique in all of GitHub, just unique to the repositories and forks that you have on your user account)

Now obviously, if you have a paid account you’d have the option to create a private repositories that only you (and people you invite to see) can see, fork and access. Once you’ve created your repository, you’ll be greeted with instructions on how to set it up. If you’ve followed my previous post you should have already setup your e-mail address (assuming that it’s the e-mail address you used to sign up to GitHub) and name, and so any commits will automatically be associated to this account based on the e-mail address. Now, once you’ve created your account your going to have to add your public key. What the heck?

Ok, without getting into too much detail (You can read way more about transport layer security and public – private key encryption if you find it as interesting as I do…) GitHub is providing two way authentication by using an SSL key. Normally when you connect to a secure server over SSL the server identifies itself with the server name, certificate authority, and a public key, however, your computer remains anonymous and it wouldn’t matter what computer your using. By providing an SSL certificate, your telling the GitHub server “Not only do I trust that you are who you say you are, I’m also providing a strong encryption grade authentication method that proves who I am when I’m connecting to you.”

Details aside, the long and short of it is that you have to generate an SSL certificate and give the public key token to GitHub (obviously keeping the private key secret). Browse to your repository in GitExtensions and open “Generate or import key”.

Which will allow you to generate a key (You will need to save both the public and private key somewhere), by default I believe it generates an SSH-2 RSA 1024bit key which is what you need for GitHub as of this writing.

If you’ve already done this you can just use an existing key. Once you’ve saved it (optionally supplying a pass-phrase for the private key file), it’s time to tell GitHub what your public key is.

Log into GitHub, go to account settings, and go down into the SSH Public Keys section, in there, give your public key a title, and paste in the public key from putty. The text should look something like this:

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAIEAkn1Hp72xRMjYtfmaHRbtwTrNBEt2oPVKyGh8uU1b8BPw

And after saving it, you should have a new key:

These SSH keys uniquely identify you as a user.

Now that you’ve added your public key into Git, you need to add the remote repository to your local repository and setup PuTTY with your SSH key. Open up Git Extensions, browse to your repository, open up the Remotes folder, and you should see the following:

From here, enter a name for the remote repository, and pull the URL from the repository startup page, it should look like this:

Brows to wherever you’ve saved your private SSH key file for PuTTY, and click the Load SSH Key. If you saved it with a password, you’ll be prompted to enter the passphrase you protected the public key file with:

Enter your passphrase and click ok.

Once done, click the Test connection. If this is the first time you’ve connected to GitHub, you’ll be notified that this server’s RSA fingerprint isn’t in the registry:

Check to make sure it’s the same as the one shown on the GitHub website, and hit yest to cache the GitHub server host key.

And you should then see that you can authenticate:

Save your configuration, close out of the dialog and select the up arrow icon (or go into the menu and select push) and push all or some of your branches to GitHub:

And there you go! Remote repository pushing and pulling. Just like that.

And now that you’ve pushed your repository up to GitHub, you can also pull other changes:

And that’s all for now, if you’ve got questions or comments, leave them in the comments for this post and I’ll respond to them as soon as I can.

Up and Running with GIT and Visual Studio

This is just a quick guide for those on windows using Visual Studio and wanting to start tinkering with GIT. If you want to know why Git is better than (Insert source control management system here), click this link. Or, if you more in the mood to hear why every other source control system in the world sucks, check out this video from Linus Torvalds who wrote GIT.

First, Git is new as of a few years ago and so the tooling support isn’t phenomenal. That being said, you need to start with by installing msysgit:

Obviously, windows version, download, install, all that good stuff. At this point, you could start using Git as this will install the windows command line tools to do so. However, a command line doesn’t completely cut it for me, and if your reading this, your probably not interested in what I’m writing anyways, so why are you here?

Moving on.

Now that the Git command line tools are installed, You’ll want to install GitExtentions, available here:

This will install tooling support into Visual Studio and also install windows explorer shell extensions and puts a few things into the explorer. Once you run it, you’ll quickly notice that your probably missing a diff tool. You can either install KDiff3 or your own diffing tool. Your preference. If you also don’t have a good text editor (Notepad doesn’t count) I recommend also getting Notepad++ and installing that as well.

Go into settings, and setup your settings to look something like this:

You now have GIT installed. Congradulations!

Now what?

Git 101.

Ok, I’m going to assume you’ve already had some experience with a source control management system of some kind or another (svn, tfs, etc…) before I jump into this. First, everything is local. When you start adding other people or services like GitHub, you realize that your local repository is a branch, and merging involves pulling in changes from other branches, but I digress.

Lets start off with a simple hello world project. Go into visual studio, create a new console project, give it a directory and start it up. Now, to create the repository find this little bar and click on the little folder icon that says ‘browse repository’. (Alternatively, you can simply directly select ‘Create new repository’ from the Git menu in visual studio)

Which will open this:


From here, select create new repository, if you allowed Visual Studio to create a directory for your project you’ll want to create the repository one directory down since every file in that directory and any sub directory (besides any listed in the .gitignore file) will be source controlled.

On the next page, I recommend clicking on ‘Edit .gitignore’ and copy the recommended list (this will cause git to ignore any files or directories that match this list).

You now have a repository, well on your way to rocking a Git controlled project. Finally, committing files. So go in make your project spit out hello world to the console, and hit commit. You’ll have the following window (Except that the changed files will be in the top left box, select which files you would like to commit, press add, and then it will look like the window below):

Select all the files in the Working Directory window, click stage, enter a commit message, hit commit, ok, and done! You’ve now made your first commit.

Now, this is something I didn’t understand right off the bat, when you open up this window everything that is different is listed in the working directory changes window, anything that has changed or is different from the previous version that isn’t in the .gitignore file. Now, to commit something, you ‘stage it’ which takes the current version of whatever file you select and puts it in the staging area (this allows you to make sure your only committing what you want to commit, because there’s many cases where you want to break up your commits into subsets of the entire change list) and commit will only commit those files that are in the staging area. If you go back to the ‘browse repository’ you’ll see something like this (I’ve added several commits):

There’s a lot more I could get into, and I may at some point, but this ought to get you on your way, feel free to leave questions in the comments, tell me where something in this post is wrong or outdated and so on.

Happy Git’ing