
GitHub Cheat Sheet - jlemoine
https://github.com/tiimgreen/github-cheat-sheet
======
holman
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-di...](http://blog.moertel.com/posts/2013-02-18-git-second-order-
diff.html)

------
CyberShadow
> 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
The cheat sheet has been updated to include that:
[https://github.com/tiimgreen/github-cheat-
sheet/commit/a6d33...](https://github.com/tiimgreen/github-cheat-
sheet/commit/a6d33515c2fd467d42b0d0d21006adf35e77e441)

------
daGrevis
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
Another great tool to understand what you are committing is to add each chunk
individually using `git add -p`.

~~~
glitchdout
Yep. The long form of that command is `git add --patch` and so I have it
aliased as `git pa`.

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

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

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

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

~~~
nahname
Opening a PR to discuss a new feature before it is built.

~~~
roryokane
You can also do that by just creating an Issue, and then converting it to a
Pull Request later with `hub pull-request -i <existing-issue-num>`, when you
actually have some code to commit. That uses the software Hub, mentioned in
the cheat sheet. Or instead of installing Hub, you can convert the Issue using
one of the other methods listed in
[http://stackoverflow.com/q/4528869/578288](http://stackoverflow.com/q/4528869/578288).

~~~
reledi
I don't recommend converting issues to Pull Requests. See the discussion here
which goes into details:
[https://github.com/github/hub/commit/4f70dd126f46dec14fc341c...](https://github.com/github/hub/commit/4f70dd126f46dec14fc341c97c18efae417743c7)

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

------
sampo
> _" 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
I guess it would be more accurate to call it "shift+/"

------
lelandbatey
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
Thanks a lot. Added ([https://github.com/tiimgreen/github-cheat-
sheet#embedding-im...](https://github.com/tiimgreen/github-cheat-
sheet#embedding-images-in-github-wiki)).

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

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

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

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

------
mrfusion
I'd like to get more comfortable handling pull requests. Any tips on that?

Any time my project gets one I panic :-(

~~~
roryokane
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
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
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
I'm digging hub! Thanks for the link to the cheat sheet.

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

