git-auto-sync-pipelines

原文涵盖的主题

• Git auto-sync pipelines
• When to Use
• Gate order (never reorder)
• Rules that matter more than the happy path
• Secret scan specifics
• Repo-specific validation stays in the repo
• Pitfalls
• Configuration

A repo is edited by hand (notes vault, research repo) and must be committed and pushed on a schedule. An existing auto-sync needs a safety review: branch guard, secret scan, alert noise, silent stalls. Someone asks to "sync these two repos every N hours" without a PR workflow. Scheduled "validate → commit → rebase → push the target branch" for a repo the owner edits by hand. Reference implementation shape: one shared library ( /lib/git-sync-common.sh) plus one wrapper per repo, run by a single scheduler entry that loops the wrappers and prints only what they printed. A separate watchdog is usually retired into the daily health sweep: "has not succeeded recently" is one step of that sweep, because a periodic watchdog cannot outlive the scheduler it is watching. 1. flock — one run at a time; silent skip on contention. 2. pre-staged index → refuse. Staging is the human's signal, not the automation's. 3. no-op check → exit silently (still stamp the success heartbeat). 4. branch must equal the target branch. git push origin HEAD: from a feature branch publishes that branch's commits to the target — this is the single highest-severity failure mode. 5. in-progress git operation markers (r

这里只展示节选，请以完整原文和当前要求为准。