Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Useful GitHub patterns

blog.quickpeople.co.uk

Post reply on HN
Print view View original

1–10 of 21 posts

Re: Useful GitHub patterns

#3

Post by GhotiFish » 

  4. the sneaky commit
    when do I use it?

    after the code has been reviewed and merged into master
    I need to make a small change (eg a copy change or 
    bugfix) that’s not even worth notifying others about

  what I do

    just push the new commit to master.
ಠ_ಠ That's not something you're supposed to admit in public.

I will note that github has being particularly prolific in getting git advice out there, they're working to educate developers in git, full stop. Though one or two pieces (such as this one) seem to suggest it's github specific advice.

Re: Useful GitHub patterns

#4

Post by Timothee »

GitHub’s functionality around PRs (such as inline commenting, replies, notifications and diffing) is excellent for facilitating code and design discussion

I agree but one thing I've realized recently is how all the history and discussion happening in a PR tend to be lost once the PR is merged. Not completely lost because it's still there in the "closed" PRs, but undiscoverable.

For example, you come across one line that doesn't make sense to you but you sense that there's a reason behind it. 'git blame' will tell you the specific commit but the commit message might not be explicit and you won't be able to find the corresponding pull-request easily.

I mentioned it on Twitter and exchanged with a GitHub employee that seemed to understand my issue. Hopefully they'll improve on that…

Re: Useful GitHub patterns

#5

Post by thelastnode »

Timothee wrote: post #4

GitHub’s functionality around PRs (such as inline commenting, replies, notifications and diffing) is excellent for facilitating code and design discussion I agree but one thing I've realized recently is how all the history and discussion happening in a PR tend to be lost once the PR is merged. Not completely lost because it's still there in the "closed" PRs, but undiscoverable. For example, you come across one line t…

I like to put a summarizing comment in the code for lines that require justification like the ones you mention. That way the discussion happens on GitHub and the conclusion is in the code, where future developers will see it.

Re: Useful GitHub patterns

#6

Post by diggan »

thelastnode wrote: post #5
Timothee wrote: post #4

GitHub’s functionality around PRs (such as inline commenting, replies, notifications and diffing) is excellent for facilitating code and design discussion I agree but one thing I've realized recently is how all the history and discussion happening in a PR tend to be lost once the PR is merged. Not completely lost because it's still there in the "closed" PRs, but undiscoverable. For example, you come across one line t…

I like to put a summarizing comment in the code for lines that require justification like the ones you mention. That way the discussion happens on GitHub and the conclusion is in the code, where future developers will see it.

A good thing to think when you start adding documentation to the code is "Am I really writing readable and understandable code right now?". If you answer isn't yes without any hesitation, you usually need to refactor so other people can read your code instead of you needing to comment what you do.

Re: Useful GitHub patterns

#7

Post by thelastnode »

diggan wrote: post #6
thelastnode wrote: post #5

Earlier quoted context omitted.

I like to put a summarizing comment in the code for lines that require justification like the ones you mention. That way the discussion happens on GitHub and the conclusion is in the code, where future developers will see it.

A good thing to think when you start adding documentation to the code is "Am I really writing readable and understandable code right now?". If you answer isn't yes without any hesitation, you usually need to refactor so other people can read your code instead of you needing to comment what you do.

True, but sometimes there isn't a choice, e.g., working with a clowntown library, poorly designed legacy code, etc.

Re: Useful GitHub patterns

#8

Post by cmwelsh »

My employer is similar but a little stricter about how we use GitHub pull requests. All new code goes in via pull request. All pull requests are reviewed by another developer. Almost all pull requests are sent to QA to test acceptance criteria.

The sneaky commit will get you many frowny faces on chat.

It works rather well. Does anyone else work like this?

Re: Useful GitHub patterns

#9

Post by Cyranix »

cmwelsh wrote: post #8

My employer is similar but a little stricter about how we use GitHub pull requests. All new code goes in via pull request. All pull requests are reviewed by another developer. Almost all pull requests are sent to QA to test acceptance criteria. The sneaky commit will get you many frowny faces on chat. It works rather well. Does anyone else work like this?

We're not on GitHub (to my dismay) but my company does use Atlassian Stash, and they've been mimicking GitHub more and more with each update.

Our development process does include pull requests, and code review is mandatory (with the number of reviewers configurable at some level), as is a successful build from Jenkins. Stash's UI will not permit a merge operation without satisfying those criteria. There's also a restriction on the master branch so the sneaky commit isn't even possible.

Re: Useful GitHub patterns

#10

Post by bigsassy »

cmwelsh wrote: post #8

My employer is similar but a little stricter about how we use GitHub pull requests. All new code goes in via pull request. All pull requests are reviewed by another developer. Almost all pull requests are sent to QA to test acceptance criteria. The sneaky commit will get you many frowny faces on chat. It works rather well. Does anyone else work like this?

We do the same thing, almost word for word. And yes, it has worked very well for us too.
Post reply on HN