I hate all the visual clutter and unjustified complexity the new stylish iOS-like interfaces bring. Those interfaces are only good for Twitter and friends (and for screenshots).

Some feedback:. Get rid of huge spacing everywhere (for example here: ). Make animations go faster. History should have preview pane with diffs (see Mail) instead of making me click on commits. There are windows on Macs. You can use them instead of edit: or in addition to making me navigate inside a single window. Loading indicators are annoying.

Move them to bottom (there it won't distract me, but I'll know that it's still loading). Oh, and congrats on release.

Have you tried GitX? What you described seems a bit more like GitX than what GitHub is trying to do here. When I first fired this up, I made a tarball of one of the repos I'm currently working in (it has uncommitted changes) and started clicking around. I'd do something in the GitHub app, then go back to my bash prompt to see what happened.

Interview Questions Github

I was pretty confused when I switched branches and all my changes were gone. Then I went back and read the blog post. It auto-stashes when you switch branches. I also wondered what the heck the 'Synchronize' button does, so once again, I referred to the blog post. It performs what they call a 'smarter version of pull -rebase && push that reduces merge commits but doesn't rewrite your merges'. At that point I realized that GitHub has done the hard thing.

They haven't re-created the git CLI tool in a GUI, they've created something different. They've created a tool that makes Git more accessible. Little things like auto-stashing when you switch branches will confuse git veterans, but it will make Git much easier to grok for newcomers because of the assumptions it makes about your git workflow. I see great things in this app's future. It's probably not for everyone. If you're a proficient git cli user, and you like it that way, then you're probably best off sticking with what you've got. Maybe explore some of the more traditional Git GUI clients like GitK or GitX, but keep in mind, that's not what this is.

I think it is worth mentioning that while the GUI could use a few tweaks, the overall user experience was amazing. And got right a number of things that were hard or tempting to get wrong: 1. Let me enter an email address separate from my GitHub account. Automatically found git repos on my system. Let me pick which ones to use.

My only two requests are: 1. Show untracked files the way git does, where if a whole folder is untracked, it only shows up in the list once, rather than showing every subfolder and file inside it.

Handle submodules better: let me see the submodule changes in a commit, let me browse and commit submodule changes and the commit the parent. FWIW, I disagree that windows should freely proliferate. I prefer apps that stay in a single window.

I think there's a misunderstanding. I'm not against single windows, I'm against making me navigate through screens when it's unnecessary. Also, you should let some of that angst go, because it's clear that Apple is anticipating an iOS experience on the desktop for a long time coming. Apple is anticipating better GUI experience. It doesn't mean that they'll make all apps occupy a single window with a single task shown at a time. Notice the difference between iPhone Mail and iPad Mail clients. Floating inspectors drive me bananas unless they can be pinned in the app 'wrapper'.

I'm with you here, mostly. ICal's switch from sidebar in 10.4 to popups and floating inspectors in 10.5 is painful. On the other hand, Acorn's floating tools window is good. A new window for every document makes me crazy, because I like to use tools like Witch for doc-level tab switching.

I'm not so into tabs for documents, but can't live without them in browsers. The push away toward full screen apps and in-app file management is, IMO, a good thing. And yes, and no. It depends, as with other points.

I'm glad that now Mac apps are not locked into multiple windows/floating inspectors for everything, but 'you have a single window and you can look only at one thing at a time, deal with it' is also not the panacea. Ok, addressing a few points here:) 1. Floating inspectors: Inspectors in general are getting better and I definitely prefer when it is well integrated into the view without interrupting my flow. They have a good start; further work is needed (not sure what though) 2. I think even tabs are a mistake now.

We learned a lot from iOS about how to well integrate multiple views into a seamless interface. Tabs are kind of unnecessary imho now; we need something better. Full screen isn't what I think the best aspect is - we do want to be able to view different apps at the same time. Case in point: - I have this chrome tab open on the right hand side of my iMac monitor - 3 terminal windows on the left hand side - My vc pitch in PPT on my second monitor's right hand - My PPC ad management software open on the second monitor's left side. Restricting to one screen for an app isn't the right way I think, but an in-between method is.

Funnily enough, I think Windows 8 almost nailed it. As for in-app file management: YES. ICloud, Dropbox and a myriad of other systems all working together have such potential. I can't wait. I don't see what's changed in 10.7 regarding windows. Can you point the app that had multiple windows, but moved to something else?

But you're right that you can avoid using multiple windows in the app if it's good for usability. My point is that currently it's not possible to have two repositories opened simultaneously; especially since on OS X it's difficult to open two instances of the same application. (As an example, in Mail you have previews in a single window, but you can also double-click the message to open it in a separate window). I don't see what's changed in 10.7 regarding windows.

Can you point the app that had multiple windows, but moved to something else? Other than the APIs for fullscreen support, there's little that can be said without violating NDA. Other Apple applications have gone single-window over the years; Logic merged its windows two major versions ago, and Final Cut Pro X just did the same. Steve Jobs has always preferred single windows.

Before OS X 1.0, the toolbar button was instead a toggle for single window mode. I wonder why they've released a client for OS X and not another OS―if anything, Windows is pretty lacking in git love. Whose is its target audience and the desired function? New users, to reel them in with a shiny UI? Or established users who don't use it much, to make the experience simpler?

(And if it's established users who use it much―isn't the command-line faster for them?) If they want more users to use GitHub, surely a GitHub for Windows makes more sense (unless this is an employee's side-project gone primetime). Not that this contributes much to the conversation but: YES on both counts. I use GitHub's issue tracker in volume both for some fairly large projects (getcloak.com, walkscore.com, and wherebe.us) I've found that the Issues web interface leaves a lot to be desired. It's a fine v1 v2 technically, but somewhat painful in practice once you have more than a handful of issues. The 280 North issues app was interesting but hasn't kept up with the latest GitHub features. As for Growl: it would be great to have it built in. In the interim, there's this.

I have been using Tower almost daily since it was released in beta some months ago. The feature set it comparable, with the biggest missing feature being individual file rollback. Tags and stashes, as well, do not seem to be supported in github for mac. Perhaps I have simply not found them in the interface yet.

In terms of workflow, performing tasks in github for mac is more cumbersome. The gui, while nice, does not fit all that well to a fast git workflow.

You must wait for panes to load separately from one another, so one code review and commit may involve loading several panes. This is much different from Tower, which tends to keep most tasks present in the main window. In a dual-monitor setup, Tower works well when occupying a screen, while github for mac would be wasting space if used in that format. The history browser, too, is quite simplistic. Tower can render commit history in the way that github for mac has chosen to do it, but I prefer the way that gity and others have allowed a history list and commit tree. One thing I like about Tower is the ability to scroll down a commit history and instantly see the diffs of that commit.

With github for mac, you must click on a commit and bring up the diff in the whole window - which seems a symptom of its non-multitasking workflow. At this point, I could not see myself using this over Tower in any project scope, though this is of course tinged by my experience with working with Tower. It is very nice that github for mac is free, and having more offerings in the space is going to be great for innovation, but I do wish they had taken a different approach with their interface.

Perhaps more to like will come of further use. I've been using Tower for a few months, GitHub.app for a few minutes. Tower makes a lot of sense if you understand how Git works-it uses the same vocabulary (branches, remotes, fetc/push/pull, etc.) and encourages the same workflow. GitHub.app seems like it's trying to take some of the complexity out of Git for beginners. For example, I'm looking at the 'Changes' tab and don't see a distinction between staged and local changes. There's just a 'Sync Branch' at the top that presumably does a pull, you don't get to have multiple remotes, just a 'primary remote repository'. No -rebase on pull, either.

Basically it looks to me like GitHub.app is trying to make common scenarios a lot easier to understand, but you have to go elsewhere for anything even slightly outside the lines. Could be the right tool for getting Git newbies (or even VCS newbies) onto the Git/GitHub wagon, especially for those who don't aspire to ever be Git experts. But heavy Git users, I'm guessing, will not be tempted. This is huge, because for many people, the current interface to git is the command line, which is too much for people who want GUIs. Yes, there are other GUIs out there, but those are not controlled by GitHub.

In this case, they did something very similar to what Google did with Chrome; they wanted to provide a consistent and predictable end-to-end solution for users so they built their own desktop app. It also does not hurt that the app defaults to use GitHub, though it does seem like you can use remotes that are not GitHub (see repository - Settings). Though Xcode 4 does support git, I've stuck with using git from the command line mostly, as I'd had some issues with it in Xcode 4 (betas, mind you). My guess is it's a lot more stable now.

Having said that, I still use it from the command line just fine. And you're right, it's often the case where a version control tool like git requires something more visual (especially when dealing with out-of-sync branch merging). For that I've typically used GitX, but GitHub for Mac so far looks like a really nice alternative.

Well, for one thing, they both have very pretty UIs that are severely dysfunctional in exactly the same way: you can only have one window open at a time, which means you can't use the app to look at two repos at the same time. For seriously using git for development, I find that pretty nuts.

Every time I want to browse a different repository, I have to destroy all the work I did opening the window for the current repo and drilling down through the UI to get to the part I am interested in? I think more apps would do well to learn from the windowing strategy of Mail.app on Mac.

It too has a monolithic main window where everything happens-but Cmd-Opt-N creates a 'New Viewer Window'. Another complete window with all the power of the first. Search for foo in window 1, read mail list bar in window 2. This sort of arrangement would make Github for Mac (and Tower) worth looking at. As it is, if I have to throw away several seconds of work every single time I open another repo, those seconds are going to add up - and annoy me - very quickly. (By the way, just to check, I tried out making a few copies of the app and opening multiple repos that way. Just like Tower, the app started to puke modal error dialogs and show blank windows, so that doesn't work.).

A native app that works on as many platforms as possible The definition of native app has changed. It's no longer a synonym for compiled binary; or using native widget. It is not as simple as coding your UI in a cross-platform toolkit. In these days, a native app means something that feels like the built-in apps: it's beyond skinning and appearance and is more about how the app as a whole interacts with the user to get the job done. As the platforms diverge, it's now really hard - if not impossible - to make a cross-platform native app. Among Performance, Cost, Time, Scope, you can only pick three. GitHub sacrifices the scope.