Here’s a 4th step:

Be quite liberal with your cross-referencing of issues, pull requests, commits, comments in Github’s UI.

GitHub will prominently display these reference breadcrumb whenever you’re navigating around. When I found myself in an obscure Github issue tracking down a problem, it was _awesome_ to see a reference made 6 months ago by a colleague in a different team.

Now that I’ve left plenty of references in my own little corner of Github, I’ve made my own life easier too.

This has been very helpful when working on my own projects. I find issue to be a great way to add context to commits.

If a commit solves part of an ongoing problem, referencing it helps clue yourself in on why you made the change you did when you git blame yourself.

GitHub is still quite annoying to use compared to something like Phabricator.

- The diff viewer is bad at showing intraline diffs and whitespace changes. I often check out branches just to be able to view the diff in IntelliJ, which is much less noisy.

- Stacking PRs is unintuitive and requires lots of rebasing and messing with branches. With Phabricator, you can just have a stack of commits on a branch and submit them one-by-one using "arc diff HEAD^". This makes it much easier to have small self-contained diffs that depend on each other, while the PR workflow encourages large PRs that do many things.

- Phabricator's CLI can create new revisions non-interactively, so I can just do a commit in my IDE, then press a shortcut and a new revision is created without leaving the IDE. The hub CLI for GitHub requires multiple steps and wants me to fill out a PR template in an editor.

- The bug tracker misses critical features for managing large projects like task dependencies.

None of this matters for drive-by contributions or small projects, but for a company repository that I contribute to all day, the workflow is nowhere near as good as Phabricator or Gerrit.

There's a reason why even some large open source projects like AOSP or Blender use a patch-based code review tool despite the learning curve.

Some more practical tips:

Install the `hub` CLI[1]. Being able to fork, open and checkout pull-requests directly from the command-line reduced a lot of friction that I had.

Install the `h` tool[2] to automatically checkout repos in a fixed layout compatible with Go. `h org/repo` automatically clones and changes directory in one command. Instead of browsing a repo in the browser, use `h` and directly jump into the code.

Install the `vim-rhubarb` plugin[3]. This allows to select a few lines in the code and then type `:Gbrowse` to open the browser, with the same lines selected on GitHub. And then share the location to a colleague.

[1]: https://hub.github.com/

[2]: https://github.com/zimbatm/h

[3]: https://github.com/tpope/vim-rhubarb

> 2. Writing good issues

I've made a small MVP of a utility that syncs issues to/from local folder as a git repo, so that you can use your favorite editor (like Emacs) to keep extensively good issue descriptions

https://github.com/k-bx/github-agent

Nice! Another option is to use a plugin that lets you edit textfields in an external editor: https://github.com/jlebon/textern

I honestly don't see how any of this is specific to github.

Is anybody claiming that?

Well.. the title here is.

Didn't you know that github is synonymous with version control? /s

Was not aware of saved replies. Will make my life easier.

Saved replies have saved (no pun intended) me so much time. Great advice