6 ms·

GitHub Cheat Sheet

193 points by jlemoine 13y ago

canadev 13y ago
Interesting, I like the "git status -sb" (short, show branch tracking info) command. The query one seems a lot like "git grep" to me, I am not sure I understand the difference. The specified "git ac" alias (git add . && git commit) is bad news, in my book. I've seen people accidentally commit extra files using "git add ." . I much prefer "git add -p" for tracked files; the git tab completion for the shell seems to be pretty good about picking up untracked files using "git add <TAB>" as well. (https://github.com/git/git/tree/master/contrib/completion https://github.com/git/git/tree/master/contrib/completion)
- masklinn 13y ago
  > The query one seems a lot like "git grep" to me, I am not sure I understand the difference. 1. shows only the most recent matching commit 2. git grep is essentially `grep` customised to the working copy (by default), you probably mean git log --grep 3. `:/foo` is actually a general revisions specifier, see third from bottom in section SPECIFYING REVISIONS of gitrevisions(7), so you should be able to use it anywhere you need to specify a revision (not that I can see much use for it outside of log and show at the moment)
CyberShadow 13y ago
> Adding `#L52` to the end of a code file URL will highlight that line number. You can click the line number (in the column to the left of the code) to add the fragment to the URL, and Shift+click to select a range. Easier than editing the URL directly.
- roryokane 13y ago
  The cheat sheet has been updated to include that: https://github.com/tiimgreen/github-cheat-sheet/commit/a6d33515c2fd467d42b0d0d21006adf35e77e441 https://github.com/tiimgreen/github-cheat-sheet/commit/a6d33...
holman 13y ago
As mentioned, these are cribbed from my Git & GitHub Secrets talk: http://zachholman.com/talk/git-github-secrets/ http://zachholman.com/talk/git-github-secrets/ If you're interested in the arcane side of Git and GitHub, you might also be interested in the follow-up talk I've given a few times the last half-year or so, which details a bunch of other new things: http://zachholman.com/talk/more-git-and-github-secrets/ http://zachholman.com/talk/more-git-and-github-secrets/ I'm more of a fan of the second talk, myself. My favorite thing I discovered while making the second talk was the "second-order-diff Git trick", which Tom Moertel came up with here: http://blog.moertel.com/posts/2013-02-18-git-second-order-diff.html http://blog.moertel.com/posts/2013-02-18-git-second-order-di...
lubomir 13y ago
Could someone give me a usecase for when an empty commit might be useful?
- daGrevis 13y ago
  To tell CI (for example, Jenkins) to rebuild.
  - reledi 13y ago
    You can often trigger a rebuild for such services via their web UI.
- epidemian 13y ago
  To make a commit to a Gist look the same as changes done through the web interface. Edit: sorry, i was thinking about --allow-empty-message, not --allow empty.
- davej 13y ago
  Annotating the start of a new bulk of work or a new feature. Documenting when you make changes to the project that aren't code related, e.g. "Now using GitHub for issue tracking, closes #1". Communicating with people using your repo, e.g. "Merry Christmas y'all, I'm away for three weeks, if you have any questions please contact Jim". I'm not saying doing any of these things is good practice but they are use-cases for when an empty commit might make sense.
- nahname 13y ago
  Opening a PR to discuss a new feature before it is built.
  - bnferguson 13y ago
    I use this constantly. Building a PR up with lot of people watching and involved is pretty amazing. Certainly don't need to all the time, but when working on something sensitive or still ambiguous it's invaluable. So many of my PRs have 50-70 comments by the time they go in. Amazing review at every step of the way.
daGrevis 13y ago
One shouldn't alias 'git add . && git commit' to 'git ac'. You should always check what you are about to commit with 'git status' and 'git diff'.
- conradev 13y ago
  Another great tool to understand what you are committing is to add each chunk individually using `git add -p`.
  - glitchdout 13y ago
    Yep. The long form of that command is `git add --patch` and so I have it aliased as `git pa`.
  - reledi 13y ago
    Also very useful is to see what you are committing with `git commit --verbose` or `git commit -v`.
- epidemian 13y ago
  If you have already checked that all unstaged changes should get included in the commit with `git st`, then i think doing `git ac` makes sense. I would, however, use `add -u` instead of `add .`, but that's mostly because i'm messy and its not unusual for me to have some local files which i don't want to commit -- e.g., one-off scripts, temporary SQL dumps, etc. YMMV.
davej 13y ago
I alias `gti` -> `git`. I'm always mistyping it, not sure why.
- krebby 13y ago
  Or use zsh, which will do something like this globally.
- perlgeek 13y ago
  I tend to type `gi tpull` instead of `git pull`, so I put this small thing into my .bashrc: function gi { first=$1; shift; first=${first/#t/}; git "$first" "$@"; } (My bash-fu is very limited, but it seems to work).
- thisisblurry 13y ago
  gti might come in handy: http://r-wos.org/hacks/gti http://r-wos.org/hacks/gti
jballanc 13y ago
One that's missing that I've found rather useful: add ".pibb" to the end of any Gist URL to get the "HTML Only" version suitable for embedding in any other site. Time was, before a lot of blogging engines had GitHub integration, this was the best way to get code on your blog.
- deleted 13y ago
  [deleted]
- rafal_chmiel 13y ago
  That's cool. Added (https://github.com/tiimgreen/github-cheat-sheet/commit/b414281c388fdb06bfbbb130a81fe8b9bc29ce94 https://github.com/tiimgreen/github-cheat-sheet/commit/b4142...).
sampo 13y ago
> "To see all of the shortcuts for given page type shift+?" Actually just ? suffices. Source: the list of shortcuts shown by typing ? on a GitHub page.
- delluminatus 13y ago
  I guess it would be more accurate to call it "shift+/"
- roryokane 13y ago
  In the U.S. keyboard layout, you have to press Shift-/ to type ‘?’. Listing Shift is a good reminder for those people, who are the majority of readers.
jdkanani 13y ago
`git instaweb` is also one of great secrets of Git that GitHub uses very effectively.
- roryokane 13y ago
  About `git instaweb` (http://git-scm.com/docs/git-instaweb http://git-scm.com/docs/git-instaweb): git-instaweb instantly configures and launches a webserver running gitweb (which is built into Git). gitweb (http://git-scm.com/docs/gitweb http://git-scm.com/docs/gitweb) is a “Git web interface (web frontend to Git repositories)”. It lets you browse commits, branches, etc.
mrfusion 13y ago
I'd like to get more comfortable handling pull requests. Any tips on that? Any time my project gets one I panic :-(
- roryokane 13y ago
  Read the code diff to see if it’s a good change you want to make to your project. If you can’t tell from just the diff, you can add their fork as a Git remote and check out their branch so you can run/test/preview your project with their proposed changes. If you like their work, just click “Merge pull request”. Your repo on GitHub will be updated. Then you can pull from your GitHub repo to your local repo to make sure you’re working on the version of the code including their changes. If you want, also post a comment in the pull request thanking the contributor. If you don’t like their work, post a comment saying why you don’t want to pull. If they just have small style problems, or the feature has a bug in it or is missing docs, describe what’s wrong or what still needs to be added or decided. You and other contributors might end up discussing what else needs to be added, using comments. The creator of the pull request can update the code in their branch at any time to accommodate feedback. At the point that their code is good enough, just click “Merge pull request”. If the pull request is something that can’t be salvaged – it’s out of scope for the project or you think it is an anti-feature – explain that in a comment, and close the pull request at the same time. Pull requests can always be closed or reopened later, and can be commented on whatever state they’re in, so the closed state is mainly for communicating whether you expect that you will eventually merge that pull request or a later update of it.
  - mrfusion 13y ago
    Thanks! I guess a problem I have is they've been sitting out there a while and my code base has changed a lot since they were posted. Any tricks there or would I just have to go through change by change?
    - roryokane 13y ago
      If your code has changed enough that GitHub can’t automatically do the merge, you have to either do the merge yourself or ask the submitter to do it. I expect that GitHub lets you do the merge yourself by adding the submitter’s fork as a remote to your clone and then doing a local merge with all your command-line tools, and finally pushing your merged version to GitHub. But I’ve never been in the situation to try it. I guess this would be what you call going through change by change. I’m afraid I don’t have any tips for doing merges in general. If you’d rather ask the submitter to do the merge, post a comment in the issue saying “Sorry it took me so long to get to this. This diff no longer merges cleanly. Please merge the latest version of my code onto your branch, and I’ll merge your pull request right after that.” You can either ask them to update the branch in the existing pull request, or close that issue and ask them to create a new pull request for their new version.
nroose 13y ago
I'm digging hub! Thanks for the link to the cheat sheet.
iancarroll 13y ago
Git.io looks really cool. Didn't know that existed!
lelandbatey 13y ago
Something also to know is there are multiple ways to embed images in wiki pages. There's the standard Markdown syntax, but there's also a syntax that allows things like specifying the height or width of the image. Example: [[ image location | height = 300px ]]
- rafal_chmiel 13y ago
  Thanks a lot. Added (https://github.com/tiimgreen/github-cheat-sheet#embedding-images-in-github-wiki https://github.com/tiimgreen/github-cheat-sheet#embedding-im...).
Myrmornis 13y ago
Gists are an easy way to work with small bits of code without creating a fully fledged repo What is the disadvantage of working with a "fully fledged repo"? Gists unecessarily fragment git workflows. For example, how do I convert my work (a git repo like all projects) into a gist? gists should have been designed as an alternative way of viewing repos, not as a slightly different species of repo.

193 points by jlemoine 13y ago

Interesting, I like the "git status -sb" (short, show branch tracking info) command. The query one seems a lot like "git grep" to me, I am not sure I understand the difference. The specified "git ac" alias (git add . && git commit) is bad news, in my book. I've seen people accidentally commit extra files using "git add ." . I much prefer "git add -p" for tracked files; the git tab completion for the shell seems to be pretty good about picking up untracked files using "git add <TAB>" as well. (https://github.com/git/git/tree/master/contrib/completion https://github.com/git/git/tree/master/contrib/completion)

masklinn 13y ago
> The query one seems a lot like "git grep" to me, I am not sure I understand the difference. 1. shows only the most recent matching commit 2. git grep is essentially `grep` customised to the working copy (by default), you probably mean git log --grep 3. `:/foo` is actually a general revisions specifier, see third from bottom in section SPECIFYING REVISIONS of gitrevisions(7), so you should be able to use it anywhere you need to specify a revision (not that I can see much use for it outside of log and show at the moment)

CyberShadow 13y ago

> Adding `#L52` to the end of a code file URL will highlight that line number. You can click the line number (in the column to the left of the code) to add the fragment to the URL, and Shift+click to select a range. Easier than editing the URL directly.

roryokane 13y ago
The cheat sheet has been updated to include that: https://github.com/tiimgreen/github-cheat-sheet/commit/a6d33515c2fd467d42b0d0d21006adf35e77e441 https://github.com/tiimgreen/github-cheat-sheet/commit/a6d33...

holman 13y ago

As mentioned, these are cribbed from my Git & GitHub Secrets talk: http://zachholman.com/talk/git-github-secrets/ http://zachholman.com/talk/git-github-secrets/ If you're interested in the arcane side of Git and GitHub, you might also be interested in the follow-up talk I've given a few times the last half-year or so, which details a bunch of other new things: http://zachholman.com/talk/more-git-and-github-secrets/ http://zachholman.com/talk/more-git-and-github-secrets/ I'm more of a fan of the second talk, myself. My favorite thing I discovered while making the second talk was the "second-order-diff Git trick", which Tom Moertel came up with here: http://blog.moertel.com/posts/2013-02-18-git-second-order-diff.html http://blog.moertel.com/posts/2013-02-18-git-second-order-di...

lubomir 13y ago

Could someone give me a usecase for when an empty commit might be useful?

daGrevis 13y ago
To tell CI (for example, Jenkins) to rebuild.
- reledi 13y ago
  You can often trigger a rebuild for such services via their web UI.
epidemian 13y ago
To make a commit to a Gist look the same as changes done through the web interface. Edit: sorry, i was thinking about --allow-empty-message, not --allow empty.
davej 13y ago
Annotating the start of a new bulk of work or a new feature. Documenting when you make changes to the project that aren't code related, e.g. "Now using GitHub for issue tracking, closes #1". Communicating with people using your repo, e.g. "Merry Christmas y'all, I'm away for three weeks, if you have any questions please contact Jim". I'm not saying doing any of these things is good practice but they are use-cases for when an empty commit might make sense.
nahname 13y ago
Opening a PR to discuss a new feature before it is built.
- bnferguson 13y ago
  I use this constantly. Building a PR up with lot of people watching and involved is pretty amazing. Certainly don't need to all the time, but when working on something sensitive or still ambiguous it's invaluable. So many of my PRs have 50-70 comments by the time they go in. Amazing review at every step of the way.

daGrevis 13y ago

One shouldn't alias 'git add . && git commit' to 'git ac'. You should always check what you are about to commit with 'git status' and 'git diff'.

conradev 13y ago
Another great tool to understand what you are committing is to add each chunk individually using `git add -p`.
- glitchdout 13y ago
  Yep. The long form of that command is `git add --patch` and so I have it aliased as `git pa`.
- reledi 13y ago
  Also very useful is to see what you are committing with `git commit --verbose` or `git commit -v`.
epidemian 13y ago
If you have already checked that all unstaged changes should get included in the commit with `git st`, then i think doing `git ac` makes sense. I would, however, use `add -u` instead of `add .`, but that's mostly because i'm messy and its not unusual for me to have some local files which i don't want to commit -- e.g., one-off scripts, temporary SQL dumps, etc. YMMV.

davej 13y ago

I alias `gti` -> `git`. I'm always mistyping it, not sure why.

krebby 13y ago
Or use zsh, which will do something like this globally.
perlgeek 13y ago
I tend to type `gi tpull` instead of `git pull`, so I put this small thing into my .bashrc: function gi { first=$1; shift; first=${first/#t/}; git "$first" "$@"; } (My bash-fu is very limited, but it seems to work).
thisisblurry 13y ago
gti might come in handy: http://r-wos.org/hacks/gti http://r-wos.org/hacks/gti

jballanc 13y ago

One that's missing that I've found rather useful: add ".pibb" to the end of any Gist URL to get the "HTML Only" version suitable for embedding in any other site. Time was, before a lot of blogging engines had GitHub integration, this was the best way to get code on your blog.

deleted 13y ago
[deleted]
rafal_chmiel 13y ago
That's cool. Added (https://github.com/tiimgreen/github-cheat-sheet/commit/b414281c388fdb06bfbbb130a81fe8b9bc29ce94 https://github.com/tiimgreen/github-cheat-sheet/commit/b4142...).

sampo 13y ago

> "To see all of the shortcuts for given page type shift+?" Actually just ? suffices. Source: the list of shortcuts shown by typing ? on a GitHub page.

delluminatus 13y ago
I guess it would be more accurate to call it "shift+/"
roryokane 13y ago
In the U.S. keyboard layout, you have to press Shift-/ to type ‘?’. Listing Shift is a good reminder for those people, who are the majority of readers.

jdkanani 13y ago

`git instaweb` is also one of great secrets of Git that GitHub uses very effectively.

roryokane 13y ago
About `git instaweb` (http://git-scm.com/docs/git-instaweb http://git-scm.com/docs/git-instaweb): git-instaweb instantly configures and launches a webserver running gitweb (which is built into Git). gitweb (http://git-scm.com/docs/gitweb http://git-scm.com/docs/gitweb) is a “Git web interface (web frontend to Git repositories)”. It lets you browse commits, branches, etc.

mrfusion 13y ago

I'd like to get more comfortable handling pull requests. Any tips on that? Any time my project gets one I panic :-(

roryokane 13y ago
Read the code diff to see if it’s a good change you want to make to your project. If you can’t tell from just the diff, you can add their fork as a Git remote and check out their branch so you can run/test/preview your project with their proposed changes. If you like their work, just click “Merge pull request”. Your repo on GitHub will be updated. Then you can pull from your GitHub repo to your local repo to make sure you’re working on the version of the code including their changes. If you want, also post a comment in the pull request thanking the contributor. If you don’t like their work, post a comment saying why you don’t want to pull. If they just have small style problems, or the feature has a bug in it or is missing docs, describe what’s wrong or what still needs to be added or decided. You and other contributors might end up discussing what else needs to be added, using comments. The creator of the pull request can update the code in their branch at any time to accommodate feedback. At the point that their code is good enough, just click “Merge pull request”. If the pull request is something that can’t be salvaged – it’s out of scope for the project or you think it is an anti-feature – explain that in a comment, and close the pull request at the same time. Pull requests can always be closed or reopened later, and can be commented on whatever state they’re in, so the closed state is mainly for communicating whether you expect that you will eventually merge that pull request or a later update of it.
- mrfusion 13y ago
  Thanks! I guess a problem I have is they've been sitting out there a while and my code base has changed a lot since they were posted. Any tricks there or would I just have to go through change by change?
  - roryokane 13y ago
    If your code has changed enough that GitHub can’t automatically do the merge, you have to either do the merge yourself or ask the submitter to do it. I expect that GitHub lets you do the merge yourself by adding the submitter’s fork as a remote to your clone and then doing a local merge with all your command-line tools, and finally pushing your merged version to GitHub. But I’ve never been in the situation to try it. I guess this would be what you call going through change by change. I’m afraid I don’t have any tips for doing merges in general. If you’d rather ask the submitter to do the merge, post a comment in the issue saying “Sorry it took me so long to get to this. This diff no longer merges cleanly. Please merge the latest version of my code onto your branch, and I’ll merge your pull request right after that.” You can either ask them to update the branch in the existing pull request, or close that issue and ask them to create a new pull request for their new version.

nroose 13y ago

I'm digging hub! Thanks for the link to the cheat sheet.

iancarroll 13y ago

Git.io looks really cool. Didn't know that existed!

lelandbatey 13y ago

Something also to know is there are multiple ways to embed images in wiki pages. There's the standard Markdown syntax, but there's also a syntax that allows things like specifying the height or width of the image. Example: [[ image location | height = 300px ]]

rafal_chmiel 13y ago
Thanks a lot. Added (https://github.com/tiimgreen/github-cheat-sheet#embedding-images-in-github-wiki https://github.com/tiimgreen/github-cheat-sheet#embedding-im...).

Myrmornis 13y ago

Gists are an easy way to work with small bits of code without creating a fully fledged repo What is the disadvantage of working with a "fully fledged repo"? Gists unecessarily fragment git workflows. For example, how do I convert my work (a git repo like all projects) into a gist? gists should have been designed as an alternative way of viewing repos, not as a slightly different species of repo.