Repo sync

content/authentication/managing-commit-signature-verification/about-commit-signature-verification.md

@@ -52,6 +52,8 @@ Signing commits differs from signing off on a commit. For more information about
 
 {% data reusables.pull_requests.rebase_and_merge_verification %}
 
+{% data reusables.pull_requests.rebase_and_merge_verification_2 %}
+
 For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/about-merge-methods-on-github#rebasing-and-merging-your-commits)."
 
 {% ifversion fpt or ghec %}

content/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/about-merge-methods-on-github.md

@@ -45,6 +45,8 @@ For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-me
 
 Before enabling commit rebasing, consider these disadvantages:
 - Repository contributors may have to rebase on the command line, resolve any conflicts, and force push their changes to the pull request's topic branch (or remote head branch) before they can use the **rebase and merge** option on {% data variables.location.product_location %}. Force pushing must be done carefully so contributors don't overwrite work that others have based their work on. To learn more about when the **Rebase and merge** option is disabled on {% data variables.location.product_location %} and the workflow to re-enable it, see "[AUTOTITLE](/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/about-pull-request-merges#rebase-and-merge-your-pull-request-commits)."
-- {% indented_data_reference reusables.pull_requests.rebase_and_merge_verification spaces=3 %}
+- {% indented_data_reference reusables.pull_requests.rebase_and_merge_verification spaces=2 %}
+
+  {% indented_data_reference reusables.pull_requests.rebase_and_merge_verification_2 spaces=2 %}
 
 For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/configuring-commit-rebasing-for-pull-requests)."

data/reusables/pull_requests/rebase_and_merge_verification.md

@@ -1,5 +1,3 @@
 When using the **Rebase and Merge** option on a pull request, it's important to note that the commits in the head branch are added to the base branch without commit signature verification.
 When you use this option, {% data variables.product.prodname_dotcom %} creates a modified commit, using the data and content of the original commit. This means that {% data variables.product.prodname_dotcom %} didn't truly create this commit, and can't therefore sign it as a generic system user.
 {% data variables.product.prodname_dotcom %} doesn't have access to the committer's private signing keys, so it can't sign the commit on the user's behalf.
-
-A workaround for this is to rebase and merge locally, and then push the changes to the pull request's base branch.

data/reusables/pull_requests/rebase_and_merge_verification_2.md

@@ -0,0 +1 @@
+A workaround for this is to rebase and merge locally, and then push the changes to the pull request's base branch.

package.json

@@ -213,7 +213,7 @@
     "esm": "^3.2.25"
   },
   "engines": {
-    "node": "^16 || ^18 || ^20"
+    "node": "^18 || ^20"
   },
   "cacheDirectories": [
     "node_modules",