docs: add rationale for using merge over rebase

---
type: pre_commit_static_analysis_report
description: Results of running static analysis checks when committing changes.
report:
  - task: lint_filenames
    status: passed
  - task: lint_editorconfig
    status: passed
  - task: lint_markdown
    status: passed
  - task: lint_package_json
    status: na
  - task: lint_repl_help
    status: na
  - task: lint_javascript_src
    status: na
  - task: lint_javascript_cli
    status: na
  - task: lint_javascript_examples
    status: na
  - task: lint_javascript_tests
    status: na
  - task: lint_javascript_benchmarks
    status: na
  - task: lint_python
    status: na
  - task: lint_r
    status: na
  - task: lint_c_src
    status: na
  - task: lint_c_examples
    status: na
  - task: lint_c_benchmarks
    status: na
  - task: lint_c_tests_fixtures
    status: na
  - task: lint_shell
    status: na
  - task: lint_typescript_declarations
    status: na
  - task: lint_typescript_tests
    status: na
  - task: lint_license_headers
    status: passed
---

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.