5 ms·

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

by 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
    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.
    - ianstormtaylor 12y ago
      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.
      - timr 12y ago
        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....
    - madeofpalk 12y ago
      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)
- TheSoftwareGuy 12y ago
  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.
  - deleted 12y ago
    [deleted]
  - rahij 12y ago
    > 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
njs12345 12y ago
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..
- kneath 12y ago
  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.
- davvid 12y ago
  (shameless plug) git-cola can do that, and it's open source.

by kneath 12y ago

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
  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.
  - ianstormtaylor 12y ago
    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.
    - timr 12y ago
      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....
  - madeofpalk 12y ago
    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)
TheSoftwareGuy 12y ago
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.
- deleted 12y ago
  [deleted]
- rahij 12y ago
  > 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

njs12345 12y ago

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

kneath 12y ago
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.
davvid 12y ago
(shameless plug) git-cola can do that, and it's open source.