5 ms·

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

kkamperschroer 12y ago
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.
- benologist 12y ago
  This is an update not a new release.
  - kkamperschroer 12y ago
    My mistake! Sorry!
- agildehaus 12y ago
  The Mac client has been around since 2011 ...
lbotos 12y ago
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.
- karmelapple 12y ago
  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!
_greim_ 12y ago
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.
- james33 12y ago
  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.
  - speg 12y ago
    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'?
kneath 12y ago
(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.
- timr 12y ago
  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?
  - kneath 12y ago
    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.
    - timr 12y ago
icehawk219 12y ago
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.
dubcanada 12y ago
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.
james33 12y ago
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.
yesimahuman 12y ago
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.
mileswu 12y ago
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/ http://rowanj.github.io/gitx/ [2] http://jonas.nitro.dk/tig/ http://jonas.nitro.dk/tig/
gress 12y ago
I use this. It's actually a nice client even for non-github repos.
gcv 12y ago
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).
dfischer 12y ago
I've seen designers on a team use it.
joshschreuder 12y ago
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 :)
adnrw 12y ago
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.

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.

benologist 12y ago
This is an update not a new release.
- kkamperschroer 12y ago
  My mistake! Sorry!
agildehaus 12y ago
The Mac client has been around since 2011 ...

lbotos 12y ago

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.

karmelapple 12y ago
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!

_greim_ 12y ago

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.

james33 12y ago
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.
- speg 12y ago
  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'?

kneath 12y ago

(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.

timr 12y ago
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?
- kneath 12y ago
  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.
  - timr 12y ago

icehawk219 12y ago

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.

dubcanada 12y ago

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.

james33 12y ago

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.

yesimahuman 12y ago

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.

mileswu 12y ago

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/ http://rowanj.github.io/gitx/ [2] http://jonas.nitro.dk/tig/ http://jonas.nitro.dk/tig/

gress 12y ago

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

gcv 12y ago

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).

dfischer 12y ago

I've seen designers on a team use it.

joshschreuder 12y ago

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 :)

adnrw 12y ago

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.