TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Useful GitHub patterns

141 点作者 benilov将近 12 年前

5 条评论

Timothee将近 12 年前
<i>GitHub’s functionality around PRs (such as inline commenting, replies, notifications and diffing) is excellent for facilitating code and design discussion</i><p>I agree but one thing I&#x27;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&#x27;s still there in the &quot;closed&quot; PRs, but undiscoverable.<p>For example, you come across one line that doesn&#x27;t make sense to you but you sense that there&#x27;s a reason behind it. &#x27;git blame&#x27; will tell you the specific commit but the commit message might not be explicit and you won&#x27;t be able to find the corresponding pull-request easily.<p>I mentioned it on Twitter and exchanged with a GitHub employee that seemed to understand my issue. Hopefully they&#x27;ll improve on that…
评论 #6024925 未加载
评论 #6023656 未加载
评论 #6024434 未加载
评论 #6024989 未加载
GhotiFish将近 12 年前
<p><pre><code> 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. </code></pre> ಠ_ಠ That&#x27;s not something you&#x27;re supposed to admit in public.<p>I will note that github has being particularly prolific in getting git advice out there, they&#x27;re working to educate developers in git, full stop. Though one or two pieces (such as this one) seem to suggest it&#x27;s github specific advice.
评论 #6025188 未加载
dbaupp将近 12 年前
&gt; <i>GitHub deals well with force-pushing to a PR branch, ie it doesn’t lose the comments on the previous commits, etc</i><p>This has not been my experience at all, it seems to loose non-line comments always, and line comments sometimes.<p>---<p>In any case, I&#x27;ve been doing a lot of work on the Rust language recently, and there is an integration bot (&quot;bors&quot;) which detects `r+` comments on the last comment on a pull-request, then runs 13 different configurations of the full test suite (4 platforms, 2 architectures, optimisations on&#x2F;off, with&#x2F;without valgrind; although not all combinations of these). If (and only if) all 13 test runs pass, the bot automatically pushes the commits to master.<p>(Almost) all commits go through bors, with increasingly less common pushes straight to master to get the test suite to pass again after some breakage. (The test suite used to only with 3 configurations for each pull request, so breakage occurred semi-often.)<p>(An example, <a href="https://github.com/mozilla/rust/pull/7693" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;mozilla&#x2F;rust&#x2F;pull&#x2F;7693</a>)<p>When it works, it is really nice; get someone to review, they approve it and the whole process is managed from there, no mistakes possible. (However, apparently the GH api is unreliable, so bors has moments of madness.)
cmwelsh将近 12 年前
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.<p>The sneaky commit will get you many frowny faces on chat.<p>It works rather well. Does anyone else work like this?
评论 #6024198 未加载
评论 #6025806 未加载
评论 #6024373 未加载
评论 #6027606 未加载
d4mi3n将近 12 年前
This was actually a pretty decent read. The author lists a number of common use-cases for Github pull requests and how they can be used in practice.