
Being more efficient on GitHub - henrikwm
https://opensource.christmas/2019/7
======
thundergolfer
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.

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

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

------
zimbatm
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/](https://hub.github.com/)

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

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

------
k_bx
> 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](https://github.com/k-bx/github-agent)

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

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

~~~
janpot
Is anybody claiming that?

~~~
pvinis
Well.. the title here is.

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

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

