Hands-on: GitHub for Windows takes the pain out of using git

Get up and running with git without once having to use the command line.

GitHub uses the git distributed version control system originally created by Linus Torvalds to help manage Linux's development as its backbone. It provides project hosting, bug tracking, and more, all wrapped up in a powerful Web interface. GitHub's most important feature is perhaps its trivial ability to fork projects. It takes just a few clicks to create your own version of a project to hack on and develop. Thanks to these features, GitHub has become the go-to place for collaborative open source software development. It's the home of projects such as Ruby on Rails and Node.js.

However, one developer community has found GitHub harder to use than others. Though the situation has improved, git and Windows are not the best of friends. After all, git was developed for Linux; Windows isn't anything like Linux. But that's where GitHub's new application, GitHub for Windows, comes in. GitHub for Windows provides a simple way to install and start using git on Windows, along with neat integration with GitHub's hosting and forking infrastructure.

The application, released on Monday, is an attractive, Metro-styled program. In addition to the GitHub for Windows application itself, it includes a self-contained version of git, the bash command-line shell, and the posh-git extension for PowerShell. You don't even have to manage any of these individual pieces yourself. The application uses a ClickOnce installer so it keeps all the bits and pieces up-to-date automatically.

The traditional issue with using git on Windows has been that it's all rather command-line oriented. Many of us swear by the command-line; just as many of us swear at it.

All version control systems have a notion of a repository, a place where source code and all its history is stored. Distributed version control systems like git extend this idea to have a lot of repositories. Each developer working on a project will have his or her own private repository, and typically each project will also have a "master" repository to provide a central place for publishing the project. It's these centralized repositories that are hosted on GitHub. (Though git doesn't have to be used this way; every person using it on a project could put in place the infrastructure to serve up access to their local repository if they really wanted. It's just much easier to not do so).

Enlarge/ The dashboard shows all your repositories, both local and remote.

Usually, performing the basic operations for managing a repository—committing changes, copying changes from a local repository to a remote one ("pushing"), or from a remote one to a local one ("pulling")—are done at the command line. While delving into git's more esoteric corners will demand the use of the command-line client, a friendly GUI for bread-and-butter tasks is a welcome thing. Setting up GitHub also involves a few additional chores, such as configuration of ssh keys.

GitHub for Windows addresses both areas. It handles the GitHub settings and configuration automatically, and it provides a basic graphical front-end to handle the main version control tasks. The GUI can create new repositories, commit changes made to a local repository, and synchronize changes between a local and remote repository.

Enlarge/ GitHub for Windows shows you all the changes you've made to your local source that aren't committed to your local repository.

Enlarge/ Add an informative commit message when you make your commit, or else your fellow developers will hate you.

Enlarge/ Once committed locally, the changes can be synced to the remote repository just by hitting the sync button. Behind the scenes, this will do the necessary git push and pull operations.

For experienced git users, the terminology used in GitHub for Windows might be a little surprising. In GitHub for Windows, the "push" and "pull" operations are combined into a singular "synchronize" operation that will perform the appropriate pushes and pulls to make the contents of the local and remote repositories match.

One of git's biggest strengths is that it makes the creation of branches nearly instantaneous, and cheap in terms of disk space. This encourages a policy of regular branching. Each time you want to make a series of changes in order to, for instance, add a new feature, you can create a branch for that feature. You can then do all the work on the branch, a process that may take weeks or months if the feature is large, and finally merge that branch back into the "master" branch.

Enlarge/ It's not the most feature-rich interface imaginable, but it gets the job done in the common case. git's merging capabilities are pretty clever.

This would typically require the use of the command line. But again, GitHub for Windows provides a simple user interface for handling the common scenarios in a GUI.

There's also integration between GitHub's website and GitHub for Windows: projects on GitHub now have a "Clone in Windows" button that'll create forks of projects and clone their repositories with just a couple of clicks.

GitHub for Windows is not GitHub's first GUI. The company released GitHub for Maclast year, a decision that provoked a flurry of demand for an equivalent Windows application. Windows developers want to use git (even Microsoft has added git support to its CodePlex hosting service), and GitHub's hosting is one of git's big draws, making a Windows version highly desirable.

The result is a polished, if simple, application that has something to offer both experienced git users and newcomers. For the old hands, the automatically updated git installation is a great convenience; for newbies, the GUI makes getting started with GitHub remarkably painless. It doesn't do everything that a git GUI should do—visualization of branches, commits, and merges is a must-have for more complex projects—but for those wanting to make their first tentative forays into the world of GitHub, it's a great place to start.

"It doesn't do everything that a git GUI should do—visualization of branches, commits, and merges is a must-have for more complex projects"

Unless they've committed to adding these features later, I'm not convinced they've added enough to bring a significant number of additional users in. Having to fall back on a shell for essential features isn't going to do anything to mollify people who swear at the command line.

It uses the exact same styles as Zune in Win7. So yes, if you don't have any software that have the Metro look then this will look alien, but then again, so will any other style (such as Apple's) if you only have one of that program.

Has anyone posted a comparison between this and Mercurial with TortoiseHg?

I'd be keen to see this too, having just started using Bitbucket/Mercurial/TortoiseHg as my first dive into source control.

+1

Earlier in my developer-as-hobby, I tried Git. Hated it then. I trundled without any version control system for awhile, a bitter aftertaste after Git.

Then I stumbled on Bitbucket/Mercurial/TortoiseHg. And I fell in love. Then at the end of last year, I found RhodeCode, and after trying it out for several months, I'm ready to do a limited deployment in my department.

as this article comes closest to what i'm looking for, can anyone recommend a good svn client for osx. unfortunately, developing for wordpress still requires using svn and the major clients for osx are way too expensive. using tortoise on windows, but i'm mainly developing on osx these days.

I tried several times different plugins for different version controls in different IDEs (basically intellij, eclipse and visual studio) and I must say in the end it's just so much less work with the CLI that I really don't see why anyone would waste their time with a GUI.

First of all we're not talking about your average computer illiterate, but programmers - so the "oh they can't figure out how to use the CLI" claim falls flat (slightly exaggerated: people who are too inept to get "git push" and co right, most certainly don't produce software that should be distributed anyhow).

So it's a manner of comfort and personally you really don't need many commands in your average work cycle and for the handful the CLI certainly is faster than clicking around. Now I could understand the use of a GUI for the less usual and more complex modes, because those you do less frequently and could profit from some visual helpers. The problem is that every plugin I've used isn't much of a help for that stuff anyhow (i.e. it's just as, if not more complicated than with the CLI), if it supports those things at all.

Miwa wrote:

git? on windows? lol...

I think I'll stick with something less Windows hateful. Like Mercurial.

What problems do you have with the current git under Windows? Works fine for me and I do use Win7 quite a bit.

What problems do you have with the current git under Windows? Works fine for me and I do use Win7 quite a bit.

Heh... "current". Maybe they've finally coerced it into something vaguely windows-like, but I see no reason to mess with it when Mercurial has always been better on Windows. (And hg treats history as sacred, which is what a vcs should do, dammit).

The real answer to your question lies in whether or not you think that cygwin is the abomination it is. (And anything MSYS is as bad). Git build in with cl yet?

The real answer to your question lies in whether or not you think that cygwin is the abomination it is. (And anything MSYS is as bad). Git build in with cl yet?

You mean for pre-commit hooks? Because otherwise I don't see why you'd want your versioning system to work together with the compiler - and then, well it allows to run scripts which is all I need for that purpose.

So you seem to be using the tools for quite different purposes than I, so I'll probably not be the right contact person there - though I'm interested where exactly you need git to work together with cl.

I do use mercurial a bit myself, but only sparely - but it seems to be much more like git (or git like mercurial) than svn, so I'm fine with it - heck compared to svn basically *anything* is a godsend, I think we can agree on that

Note that yes git works just fine in cmd/ps, but then so do all the other cygwin things.

Has nothing to do with integrating with cl, has everything to do with keeping anything cygwin-related far, far, FAR away from anything I want to work and be useful. If it need cygwin or (msys) on Windows, it sucks. (Yes, I know git was updated to compile with mingw on Windows, and that's only slightly better).

I'd rather use tools that have a *much* better history of Windows support.

Well, that and I like hg's simplicity over git's linux-like kitchen sink approach. Then again, this sort of religious discussion is off-topic for this thread anyway.

Is this any better than using egit from Eclipse?Also, Linus recently had a few comments about GitHub's inablity to suport proper commenting, does this application address that?

[shameless_self_promotion]If you're looking for those missing features, try out git cola. It has native clients for windows, linux, and mac, and is possibly the most feature complete git gui out there...

Has nothing to do with integrating with cl, has everything to do with keeping anything cygwin-related far, far, FAR away from anything I want to work and be useful. If it need cygwin or (msys) on Windows, it sucks. (Yes, I know git was updated to compile with mingw on Windows, and that's only slightly better).

I'd rather use tools that have a *much* better history of Windows support.

Well, that and I like hg's simplicity over git's linux-like kitchen sink approach. Then again, this sort of religious discussion is off-topic for this thread anyway.

Has nothing to do with integrating with cl, has everything to do with keeping anything cygwin-related far, far, FAR away from anything I want to work and be useful. If it need cygwin or (msys) on Windows, it sucks. (Yes, I know git was updated to compile with mingw on Windows, and that's only slightly better).

I'd rather use tools that have a *much* better history of Windows support.

What's so wrong about msys-git?

Yeah I'm not sure I can follow that either. I mean if I type "git commit" in powershell and the program does what I want it to, why should I care how it works in the background? As long as it works, I'm fine with it.

But Miwa is right that we're getting quite offtopic here - next point on the list of discussions is tabs vs spaces btw

Really nice looking program I have to say looks really slick. I only have 1 thing to say about this though and sorry if it sounds elitist but holy crap if you can't use git then how could you have anything that needs to be uploaded to github. Like it isn't a complex VCS to figure out.

Github for windows is hugely disappointing with some of its behaviors. I can't push when there's unstaged files? Really? Come on.Blindly creating a new ssh key and adding it to github, and not telling the user about said key's creation happening *ever*? Wow, that's ridiculous.

I ended up trying to push some commits to a private repository on my own server, only to discover it was using its own ssh key for this process - and that denyhosts had triggered and firewalled me out of my own system (because I'd failed authentication enough times).

Very irritated with how this client works. Back to git commandline for me in windows.

Ugtar wrote:

bug77 wrote:

Is this any better than using egit from Eclipse?Also, Linus recently had a few comments about GitHub's inablity to suport proper commenting, does this application address that?

[shameless_self_promotion]If you're looking for those missing features, try out git cola. It has native clients for windows, linux, and mac, and is possibly the most feature complete git gui out there...

And has one of the worst install processes on windows that I've seen of *any* git client for windows.Also never worked when I tried it; ended up having to sit through uninstallation of four different things afterwards. Maybe you should look into streamlining the installation?