Linkage maintenance of PR and issue

When we need to solve a bug in a project, usually a new PR will be accompanied by an issue, this article will introduce only one operation when creating a PR, associate the issue , and then when the PR is approved, the corresponding associated 'issue' will also be closed.

Again, I'll start by creating an issue in the sample project:

In this case, as the project maintainer, we can directly click Create a branch in Development to create a fix branch, which will automatically associate the issue, and similarly, when the PR created by the fix branch is merged, the issue will be automatically closed.

However, this kind of scheme is not mentioned here, and you can experience it for yourself if you are interested

Here is our more common operation, in the local editor, based on the latest main branch cut out a fix branch, as follows:

git checkout main
git pull
git checkout -b fix_testbug

Then there is the fix for the corresponding problem on the fix_testbug branch, which is not repeated.

When we feel that the fix is okay and have self-tested, we can commit this temporary branch:

git add .
git commit -m "fix: test bug"
git push --set-upstream origin fix_testbug

After pushing to the remote, we come to the GitHub page, at which point we can see that GitHub will automatically prompt a new branch to merge:

You can directly click Compare & pull request:

Pay attention to the instructions in Development on the right, we can add some by adding some to the instructionskeywords，This associates the issue and triggers a shutdown. Of course, you can also create a PR first and then associate it:

After completing the associated PR, you can see that there is a status display like this:

At this time, we click on the #21 issue, and we can also see that it is linked to the PR:

Now we merge the #23 PR , and after the merge, you can see that the associated issue has also been closed, and the temporary branch of the link has been deleted:

The above is the linkage maintenance of PR and issue in project collaboration.

---

Other than that： A small point here, when we go through a PR process, as the main maintainer of the project, we usually switch back to the main branch again, and then pull the code that was merged into the main branch remotely:

git checkout main
git pull

After executing this way, you will find that the local code has exceeded the remote branch:

Among them, 389fe is the ID of the current remote branch, we can execute the following command to align with the remote:

$ git reset --hard origin/main
HEAD is now at 389fe7b fix: test bug (#23)

In this way, the local and remote are aligned, and the next time you re-branch and then commit a PR, there will be no several merges like the above.

The illustration is as follows:

Theoretically, there is only one commit this time, instead of 3 commits, which is why.