3 ms·

Being more efficient on GitHub

39 points by henrikwm 7y ago

selbekk 7y ago
Saved replies have saved (no pun intended) me so much time. Great advice
k_bx 7y ago
> 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 7y ago
  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
thundergolfer 7y ago
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 7y ago
  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.
snvzz 7y ago
I honestly don't see how any of this is specific to github.
- dijit 7y ago
  Didn't you know that github is synonymous with version control? /s
- janpot 7y ago
  Is anybody claiming that?
  - pvinis 7y ago
    Well.. the title here is.
zidoo 7y ago
Just Write Fucking Code that makes sense. And don't be an attention whore.
sveingjoby 7y ago
Was not aware of saved replies. Will make my life easier.
lima 7y ago
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 7y ago
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

39 points by henrikwm 7y ago

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

k_bx 7y ago

> 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 7y ago
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

thundergolfer 7y ago

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 7y ago
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.

snvzz 7y ago

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

dijit 7y ago
Didn't you know that github is synonymous with version control? /s
janpot 7y ago
Is anybody claiming that?
- pvinis 7y ago
  Well.. the title here is.

zidoo 7y ago

Just Write Fucking Code that makes sense. And don't be an attention whore.

sveingjoby 7y ago

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

lima 7y ago

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 7y ago

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