docs: add rationale for using merge over rebase

PR-URL: #6444
Reviewed-by: Athan Reines <[email protected]>

Author: anandkaranubc

docs/contributing/git_cheatsheet.md

@@ -452,28 +452,29 @@ Assuming you've already cloned the repository and set up your identity:
 
     ```bash
     $ git checkout develop
-    $ git pull --ff-only upstream develop # Update local develop first
+    $ git pull upstream develop # Update local develop first
+    $ git push origin develop
     $ git checkout feature/is-even
-    $ git rebase develop # or git merge develop
+    $ git merge develop
     ```
 
-    Resolve any conflicts with the steps mentioned earlier, then continue the rebase:
+    Resolve any conflicts with the steps mentioned earlier, then continue the merge:
 
     <!-- run-disable -->
 
     ```bash
-    $ git rebase --continue
+    $ git merge --continue
     ```
 
     Finally, push your changes:
 
     <!-- run-disable -->
 
     ```bash
-    $ git push --force # Force push after rebasing
+    $ git push origin feature/is-even
     ```
 
-    > **Note:** Force pushing is required after rebasing because it rewrites history. This is safe as long as you're the only one working on the branch. If you want to avoid force pushing, use merge instead of rebase.
+    > **Note:** When developing stdlib, we recommend using `merge` instead of `rebase` once a PR is open. Rebasing rewrites your branch history, which usually requires a force-push to update the remote branch. This can disrupt other contributors who are reviewing or collaborating on your PR. Since stdlib uses squash and merge for PRs, we don't require a clean, linear commit history. Merge commits are acceptable as long as your diff only contains relevant changes.
 
 8.  **Repeat**: After resolving conflicts and updating your branch, you can continue making changes, committing, and pushing until your PR is ready to be merged.