As mentioned, these are cribbed from my Git & GitHub Secrets talk: <a href="http://zachholman.com/talk/git-github-secrets/" rel="nofollow">http://zachholman.com/talk/git-github-secrets/</a><p>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: <a href="http://zachholman.com/talk/more-git-and-github-secrets/" rel="nofollow">http://zachholman.com/talk/more-git-and-github-secrets/</a><p>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: <a href="http://blog.moertel.com/posts/2013-02-18-git-second-order-diff.html" rel="nofollow">http://blog.moertel.com/posts/2013-02-18-git-second-order-di...</a>
> Adding `#L52` to the end of a code file URL will highlight that line number.<p>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.
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'.
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.
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.<p>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 ." .<p>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. (<a href="https://github.com/git/git/tree/master/contrib/completion" rel="nofollow">https://github.com/git/git/tree/master/contrib/completion</a>)
<i>Gists are an easy way to work with small bits of code without creating a fully fledged repo</i><p>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.
> <i>"To see all of the shortcuts for given page type shift+?"</i><p>Actually just ? suffices.<p>Source: the list of shortcuts shown by typing ? on a GitHub page.
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:<p><pre><code> [[ image location | height = 300px ]]</code></pre>