Being more efficient on GitHub • Hacker News Board

Re: Being more efficient on GitHub

#11

Post by thethirdone » Sat, Dec 07, 2019, 10:34 AM UTC

thundergolfer wrote: post #4

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…

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.

Re: Being more efficient on GitHub

#12

Post by lima » Sat, Dec 07, 2019, 10:36 AM UTC

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.

Re: Being more efficient on GitHub

#13

Post by zimbatm » Sat, Dec 07, 2019, 1:29 PM UTC

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