Repo sync

content/admin/enforcing-policies/enforcing-policy-with-pre-receive-hooks/about-pre-receive-hooks.md

@@ -43,3 +43,9 @@ Due to risk of failure and performance impact for all users of your instance, we
 
 > [!NOTE]
 > To avoid rejection of a push due to a timeout, all combined pre-receive hooks should run in under five seconds.
+
+{% ifversion ghes > 3.16 %}
+
+{% data reusables.repositories.push-rule-and-prereceive-hooks %}
+
+{% endif %}

content/code-security/dependabot/working-with-dependabot/dependabot-options-reference.md

@@ -498,7 +498,8 @@ Each package manager **must** define a schedule interval.
 * Use `semiannually` to run every six months, on the first day of January and July.
 * Use `yearly` to run on the first day of January.
 * Use `cron` for cron expression based scheduling option. See [`cronjob`](#cronjob).
-By default, {% data variables.product.prodname_dependabot %} randomly assigns a time to apply all the updates in the configuration file. You can use the `time` and `timezone` parameters to set a specific runtime for all intervals.
+
+By default, {% data variables.product.prodname_dependabot %} randomly assigns a time to apply all the updates in the configuration file. You can use the `time` and `timezone` parameters to set a specific runtime for all intervals.  If you use a `cron` interval, you can define the update time with a `cronjob` expression..
 
 ### `day`
 

content/get-started/writing-on-github/working-with-advanced-formatting/autolinked-references-and-urls.md

@@ -75,7 +75,7 @@ When referencing a commit from a private repository inside of a commit message,
 
 ## Avoiding backlinks to linked references
 
-By default, references generate a backlink. For example, manually linking to an issue in a pull request will automatically generate another link from the issue *back* to the pull request.
+By default, references generate a backlink. For example, manually linking to an issue in a pull request will automatically generate another link from the issue _back_ to the pull request.
 To avoid this behavior, you can use `redirect.github.com` instead of `github.com` when constructing the URL in your reference. If you do use a `redirect.github.com` URL in your reference link, no pop-up window will appear when hovering over it.
 
 ## Further reading

data/release-notes/enterprise-server/3-16/0.yml

@@ -223,8 +223,8 @@ sections:
 
       [Updated: 2025-03-19]
     - |
-      The security risk page returns a 500 error when Secret scanning is disabled. [Updated: 2025-04-25]
-   
+      The security risk page returns a 500 error when secret scanning is disabled. [Updated: 2025-04-25]
+
   closing_down:
     # https://github.com/github/releases/issues/4683
     - |

data/release-notes/enterprise-server/3-16/1.yml

@@ -73,7 +73,7 @@ sections:
     - |
       After a geo-replica is promoted to be a primary by running `ghe-repl-promote`, the actions workflow of a repository does not have any suggested workflows.
     - |
-      The security risk page returns a 500 error when Secret scanning is disabled. [Updated: 2025-04-25]
+      The security risk page returns a 500 error when secret scanning is disabled. [Updated: 2025-04-25]
   errata:
     - |
       Known issues incorrectly indicated that administrators could immediately run the `/usr/local/share/enterprise/ghe-es-search-repair` script after a restore to resolve indexing and collaborator access issues. In reality, this script must be run only after the system has been up for at least one hour. [Updated: 2025-04-22]

data/release-notes/enterprise-server/3-16/2.yml

@@ -79,5 +79,4 @@ sections:
     - |
       Repository Cache Replicas return `Repository not found` when changes have been pushed to the Primary instance that have not yet synchronized to the Cache Replica. This issue can also occur in all previous patches of this release.
     - |
-      The security risk page returns a 500 error when Secret scanning is disabled. [Updated: 2025-04-25]
-
+      The security risk page returns a 500 error when secret scanning is disabled. [Updated: 2025-04-25]

data/reusables/repositories/push-rule-and-prereceive-hooks.md

@@ -0,0 +1,12 @@
+## Choosing between push rules and pre-receive hooks
+You can use push rules and pre-receive hooks to control what changes users can push to your repository. Both help you enforce policies, but they work in different ways and are designed for different use cases.
+
+Push rules are a built-in way to enforce common policies across repositories. You can use them to block pushes that don’t meet specific conditions, such as updates to specific files and paths, file size, or file type.
+You can manage push rules through the UI or API. As they are a type of repository rulesets, push rules support audit logs, and can be used with evaluate mode to preview changes or bypassed when needed.
+
+Use push rules if you want to easily:
+
+* Enforce standard policies without writing scripts.
+* Apply policies consistently across organizations and repositories.
+* Manage rules through {% data variables.product.github %}'s UI and APIs.
+* Use {% data variables.product.github %} native features like audit logging, bypass lists and rule insights.