2022-32: Github useful tips

Leave a Comment / 15/08/2022 /

Original link: https://xuanwo.io/reports/2022-32/

Today, I will talk with you about the practical tips of Github that I often use:

  • Citing Github Issues/PR/Discussion
  • Use Fix / Close to associate an Issue
  • collapsible block
  • Draft / Ready for review
  • Request Review
  • Quote Reply

Citing Github Issues/PR/Discussion

Any edit box on Github can be referenced using the # + Issues/PR/Discussion numeric ID:

But I prefer to paste the corresponding link directly (no need to use any Markdown syntax, just paste it directly):

This feature also works for cross-repo references:

Use Fix / Close to associate an Issue

In a PR, you can use the syntax of Fix #xxx to associate an issue. When the PR is merged, the corresponding Issue can be closed together.

  • The keywords that can be used are very broad: any combination of [close|fix|resolve][s|ed] will do
  • Note that if you associate multiple issues, you need to write fix #xxx repeatedly: fix #xxx,#yyy #yyy will not work, only the first one will take effect
  • Maintainers with Repo permissions can also manually associate in the sidebar: but it doesn’t feel very easy to use, and some issues cannot be searched for

For documentation see: Linking a pull request to an issue

collapsible block

In Issues and PRs, sometimes you want to display folded content, such as long complete logs, detailed results, etc. At this time, you can use the folding syntax added in HTML5:

 < details > < summary >Summary Goes Here</ summary > ...this is hidden, collapsable content... </ detials >

The display effect is as follows:

However, when using it, you need to pay attention to leaving a blank line between the content and the <details> tag, otherwise some Markdown syntax cannot be rendered normally.

See also: Using in GitHub

Draft / Ready for review

If you want to mark a PR that is currently still in work and not review or merge, you can use Github’s native Draft / Ready for review workflow.

When creating a PR, select Create draft pull request :

When the PR is ready for review, click Ready for review at the bottom of the PR:

The advantage of this is that there is no need to introduce external bots and actions, and it does not require the author to manually update the PR title. Github will ensure that this PR cannot be merged.

Request Review

It is recommended to use the Github Request Review mechanism to request a review from maintainers:

Clicking on that little circle will initiate a re-request, informing the Reviewer that the current PR is ready.

Review requests initiated in this way will be specially marked in the maintainer’s notification:

This saves you from being overwhelmed by commented and mention : maintainers of popular projects may have hundreds of notifications per day, and they will often use filters to filter out review requested notifications.

Quote Reply

When replying to comments on Github, please avoid full-text citations as much as possible, and only select the specific words you want to respond to: select the words you want to reply, then click the comment menu, select Quote Reply

Then it will automatically jump to the reply box:

The benefits of doing this are:

  • Avoid Issues / PRs being swiped by useless information
  • The answer is more accurate, and it allows readers to know what is currently being replied to

This article is reproduced from: https://xuanwo.io/reports/2022-32/
This site is for inclusion only, and the copyright belongs to the original author.

Leave a Comment