Hacker News Reader

Comment by peter_l_downs | Hacker News Reader

Who uses this? Is it an effective part of your daily workflow?

(Biased, I work at GitHub and helped design the original GHfM)

I use it every day, almost all of the time. I don't use a lot of it, but what I do use is tremendously useful. My workflow is usually:

1. Navigate to the folder in terminal (old habit, or starting servers) and type in `github .` which launches the client for this repo.

2. Sync to pull in new changes (cmd + s)

3. Create a new branch (cmd + b)

4. Commit as I code (visual diff helps me do light code review on the spot). This is definitely the core usage for me — seeing what uncommitted changes I have, selecting out partial commits, drafting up good commit messages, amending bad commits, etc.

5. When I'm ready to publish my branch, sync again (cmd + s)

The key for me really comes down to some really simple stuff: a visual editor for creating commits, and quick keyboard commands to common actions (branching, switching branches, push/pull). It's possible to do fast in terminal, but muscle memory serves me personally much better with real keyboard commands.

I don't get it. How in the world is that any easier than:

  cd /your/src/dir
  git pull

  <edit stuff>

  git diff

  <look at stuff; possibly edit more stuff>

  git commit -m "edited stuff"
 
  <oops...forgot something; edit another file>

  git commit -a --amend
  git push origin

Which, of course, has the added advantage that you're using git, instead of using a GUI obfuscation layer on top of git, and therefore learning your tools.

I mean...I sort of get why people do git integration in editors (even thought it tends to lead to ignorance of git), but opening up another, non-console, non-editing app, just for git?

Everyone uses software differently; brains work different. I've used Git on the command line for almost a decade now, and I find my current workflow much nicer.

You also left out a lot of the (again simple) commands I've included — switching branches and partial commits, where things like fuzzy autocomplete are very nice if your shell does not hook into Git and support fuzziness.

Good point. I left them out because there's more than one way to do it, and if you let a GUI tool do it for you, you become ignorant of those issues:

  git checkout -b new_branch
  <edit edit edit>
  git commit -a -m "i'll merge this branch"
  git checkout master
  git merge new_branch

vs:

  git checkout -b new_branch
  <edit edit edit>
  git commit -a -m "did stuff that i'll rebase this time"
  git fetch
  git rebase origin/master
  git checkout master
  git merge new_branch

vs:

  git checkout -b new_branch
  <edit foo.txt and bar.txt>
  git add foo.txt
  git commit -m "edited foo"
  git stash
  ...

People think differently, but nothing you've described is conceptually different than using the CLI. It's just a GUI, doing/obscuring the same stuff -- stuff that you need to understand to use git.

We have barely technical people on the team who use GitHub for Mac because they aren't comfortable in a CLI, but they are very comfortable using a regular application they can launch from their doc. That way GitHub gets to design around Git edge cases, and they don't have to get screwed when weird things happen in the CLI.

Yeah, that's the classic argument for wrapping a CLI with a GUI. The only problem is that with git, you can't design around the "weird things"...if the user is in a weird state in version control, they need to know about it.

In other words, it's the leaky abstraction problem. You can pretty up the UI, but ultimately, you have to communicate the concept to the user. It's how we got those "Can I copy The Internet?" questions in Windows 95....

I've found myself using a combination of both GitHub app, and CLI. Usually I'll checkout repos, make commits and push/pull using the GitHub app.

Then I'll switch over to the CLI for branching, merging, resetting and bitsecting (the latter two arent possible in the GitHub app)

for one thing, you are forgetting that people are human. this is what that workflow would more realisticly look like:

    cd /yor/src/dir
    bash: cd: /yor/src/dir: No such file or directory

examines closely to look for typo cd /your/src/dir

    <edit stuff>

    git diff

    git comit -m "edited stuff"
    Did you mean this? git: 'comit' is not a git command. See 'git --help'.

Did you mean this? commit git commit -m "edited stuff"

I think this is enough to get the picture.

> cd /yor/src/dir > bash: cd: /yor/src/dir: No such file or directory <tab> ?

And on anecdotal evidence, I've observed that people who use git intensively everyday often have aliases to these commands that have a low probability of typos.

eg gcom => git commit

Is there any way to revert a single hunk interactively in the client (like git checkout -p)?

I too use it for light code review, but often find spurious whitespace/brace placement changes that I want to revert to make my eventual PR a bit less noisy..

I believe you can select the lines/hunk you want to revert, then right click the filename (on the left) and click "Discard Changes" — but I would definitely ensure that's the case on some throwaway diff before believing me! Discard changes is no joke. I usually commit everything I want, then discard changes when all I'm left with is the bad whitespace/files.

(shameless plug) git-cola can do that, and it's open source.

The GUI has dramatically increased the rate of contributions for web, content, and design work from our non-hardcore devs. I also use it when I want something really low friction.

I use this but I use it primarily as a diff'ing tool. It's very convenient for that and is also handy on the occasions I'm working on something and then look and realize I have several commits worth of uncommitted changes. Where the UI excels for this is easily just unchecking a couple files or highlighting a few lines from one file to commit only exactly what I want to and then quickly re-checking and committing the rest. This doesn't happen all that much but when it does it's great having a tool that makes it easy to deal with.

Other then that I just find the command line to be quicker for most things.

I used to use it just for the ability to individually stage chunks/lines, because I find "git add -p" incredibly hard to use. Now I tend to use GitX-dev for OSX [1] to do that instead, because I find it more powerful than Github for Mac. There's also a ncurses-based interface for git called tig [2] which can also do the chunk staging, but I only use it when I don't have a GUI.

[1] http://rowanj.github.io/gitx/ [2] http://jonas.nitro.dk/tig/

I've used the Windows version... When it isn't crashing it's extremely laggy.

Mind you I am working on repos in the several hundred mb size or at least double digit mb.

The mac version seems to be similar issues, for example if I look at a commit with more like then 150 file changes it pretty much either lags to the point where I force quit or crashes.

Maybe it's just me, but the command line still works better for me.

This is one of around 4 or 5 applications that I have open 100% of the time on my Mac. I still use the command line for some things, but for the most part I've saved massive amounts of time (and prevented a lot of bugs thanks to the visual code diff view) thanks to GitHub for Mac.

I don't use this, but have used GitHub for Windows. I can see it being useful for those less technically inclined, or 'afraid' of the command line.

Personally, I don't have an issue with using the command line for Git, but I get by just fine with SourceTree.

It's helpful in visualising Git concepts with its tree graph, and I don't have to remember commands. I also realise this goes counter to the command-line culture of HN :)

I use it occasionally, even though magit has largely taken its place. In part, I like the way it ships the command-line git program: inside its .app bundle. Very clean and convenient if you don't fell like pulling in Homebrew or polluting /usr/local. Many other graphical Git clients are not hygienic in this way (i.e., they pollute areas of the filesystem outside their .app bundles).

I use this every day basically for pushing and pulling to and from Github. For pretty much every other git function I use SourceTree.

I find the Github app too limiting for most git functions other than pushing and pulling (and the resulting rebase or merge) to the remote repositories, but the interface is much much better – simpler, quicker and easier – for those specific tasks than SourceTree.

I don't, but I do know that at my last job the documentation team started using it to bring writers into version control. It allowed a lot of them to grok what was happening without being scared of the command line.

Similar reason on my team: team members with zero source control experience use it as a way to very simply sync changes on their local drive to a branch (typically one we rarely if ever change) with files that they will probably only ever change. So the chance I merge conflicts are low, and they are in and using it very quickly. It works well for simple, beginner users!

I use it. My work git repo isn't github, so switching between this tool for github and cmd line for work has become part of my habit field. I still go back to cmd line for more complex stuff though.

You can use this tool for any repo, not just GitHub repos. We have a mixture of non-GitHub and GitHub hosted repos that I manage all within GitHub for Mac. When they first released this I was actually using Beanstalk, but still used the GitHub for Mac application to manage those repos as well.

Does it work with svn repos? i.e., if I've git svn cloned a repo on my machine. Can I interact with it with GhfM? Will sync do 'git svn dcommit'?

I use this. It's actually a nice client even for non-github repos.

I've seen designers on a team use it.

Since it was just released, I doubt many outside of github have an established workflow with this.

Maybe someone with the Windows client can provide more insight, given the similarities.

This is an update not a new release.

My mistake! Sorry!

The Mac client has been around since 2011 ...

Reply on news.ycombinator.com