[doc/ug] Update github doc
Add sections to explain how to pull PR and amend other's pending PR
diff --git a/doc/ug/github_notes.md b/doc/ug/github_notes.md
index bbce4b4..3dfac05 100644
--- a/doc/ug/github_notes.md
+++ b/doc/ug/github_notes.md
@@ -356,3 +356,91 @@
be used as expected.
You may find it useful to change the default for the way git reports conflicts in a file. See [Take the pain out of git conflict resolution: use diff3](https://blog.nilbus.com/take-the-pain-out-of-git-conflict-resolution-use-diff3/)
+
+## Downloading a pull request to our local repo
+
+With the commands below, you can checkout a pull request from the upstream repo to
+your local repo.
+```console
+$ git fetch upstream pull/{ID}/head:{BRANCH_NAME}
+$ # e.g. git fetch upstream pull/5/head:docgen_review
+$ git checkout {BRANCH_NAME}
+```
+
+### Applying the pull request to the local commit
+
+In some cases, you might need to apply a pull request on top of your local commits.
+For instance, if one user prepares a verification test case and finds a bug.
+Another user fixed it and created a pull request. The first user needs
+to test if the fix works on the new verification environment.
+
+In this case, it is recommanded to create a new branch on top of the local
+commit and `rebase`, `cherry-pick`, or `merge` the pull request. Assume you have a branch
+name 'br_localfix' which has an update for the verification environment. If the
+other user created a pull request with ID #345, which has a fix for the
+design bug, then you can apply the pull request into new branch
+'br_localandremote' with the following three methods:
+* The `rebase` method:
+ ```console
+ $ git checkout -b br_localandremote br_localfix
+ $ git fetch upstream pull/345/head:pr_345
+ $ git rebase pr_345
+ ```
+* The `cherry-pick` method:
+ ```console
+ $ git checkout -b br_localandremote br_localfix
+ $ git fetch upstream pull/345/head:pr_345
+ $ # find the commit ID from pr_345 that you want to merge: b345232342ff
+ $ git cherry-pick b345232342ff
+ ```
+* The `merge` method:
+ ```console
+ $ git fetch upstream pull/345/head:pr_345
+ $ git checkout -b br_localandremote br_localfix
+ $ git merge pr_345
+ ```
+The `rebase` method is more convenient than `cherry-pick` if you have more
+than one commit ID to merge. The `merge` method can only be used for local
+testing as the upstream lowRISC repository does not allow merge commits.
+Sometimes, applying other contributor's pull request can result in conflicts
+if both commits have the same change. In that case, you should resolve the conflicts
+and continue the merge. Section [Dealing with conflicts after a rebase](#dealing-with-conflicts-after-a-rebase)
+has detailed guidance on how to solve conflicts.
+
+## Creating updates on top of a pending pull request
+
+In some cases, you might want to directly change other contributor's pull
+request. The process is quite complicated so please follow the instruction below
+step-by-step with caution:
+
+* Step 1: Checkout the other pull request branch
+ ```console
+ $ git fetch upstream pull/{ID}/head:{BRANCH_NAME}
+ $ git checkout {BRANCH_NAME}
+ ```
+* Step 2: Make necessary changes
+ ```console
+ $ git add...
+ $ git commit -m “Add CFG examples to UART specification”
+ ```
+* Step 3: Create your github branch for the pull request
+ ```console
+ $ git push -u origin {BRANCH_NAME}:<remote_branch_name>
+ ```
+ You can use any branch name for the pull request.
+ If you want to the created branch name same as local branch name, this can
+ simply be:
+ ```console
+ $ git push -u origin HEAD
+ ```
+* Step 4: Create a pull request into the other contributor's forked repository
+
+ To create a pull request in other's forked repository, you can follow the same method
+ as creating a pull request as section [Working in your local repo](#working-in-your-local-repo)
+ explained in details.
+ Once the other contributor's pull request is merged into the upstream
+ repository, you will need to create a pull request in that upstream repository
+ instead.
+
+These are all the steps needed. Once your pull request is reviewed and merged, you will
+be able to see that the commit is also visible in the original pull request.
