Sync a fork whenever upstream cuts a release, and within days of any security advisory that affects the code you use. Add a calendar floor, such as monthly or quarterly, so a quiet upstream does not let you drift. The right pace depends on how much you carry and how fast upstream moves.
Three triggers, not one schedule
A fixed schedule alone fails in both directions. It forces busywork when nothing changed, and it makes you wait when a fix is urgent. Use three triggers together.
- Release trigger. Upstream tags a release. Pull it in while the changes are fresh in everyone's mind.
- Advisory trigger. A security advisory names a version range that includes your base. Act on it as a security task, not a maintenance task.
- Calendar floor. If neither fires, sync anyway on a fixed date, so the gap never grows past a size you can review.
Pick the floor by how much you carry
| Your local patches | Upstream pace | Suggested floor |
|---|---|---|
| Few, small | Slow | Quarterly |
| Few, small | Fast | Monthly |
| Many, or deep changes | Any | Every release, plus monthly |
| None (fork only for a pinned copy) | Any | Reconsider the fork, use a pinned dependency |
The more you carry, the more each sync costs, and the cost grows faster than the patch count because conflicts compound. Counterintuitively, forks with many patches need to sync more often, not less, since a small gap is cheap to resolve.
What a sync should include
A sync is more than a merge. Run through the same short list each time.
- Fetch upstream and check how far apart you are. See how to measure fork divergence.
- Read the upstream changelog and the diff, not just the release title.
- Merge or rebase onto the new base. See merge or rebase for a long-lived fork.
- Run your tests and the upstream tests.
- Re-scan the result and update your SBOM.
- Record the new base tag and date.
What goes wrong when you wait
The pain of an overdue sync is the conflict pile. Git has a feature to reuse recorded resolutions of conflicted merges, which helps when you repeat the same resolution, but it does not remove the need to review. Skipping versions also means you review a larger diff at once, and large diffs get skimmed. A hidden problem in an upstream change is easier to spot in a small diff.
There is also an exposure window. Between an upstream fix and your sync, your users run the vulnerable code. Track that gap as a number: days from upstream fix to your release. If you cannot say what it is, start measuring it.
Set the rule where people will see it
Put the three triggers in the fork's README and name an owner. A rule nobody can find is a rule nobody follows. See what responsibilities come with maintaining a fork for ownership questions.
Where Safeguard fits
Safeguard's continuous monitoring and policies can alert you when a component you build is named in a new advisory, which serves as the advisory trigger above. You can start with a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a new advisory is surfaced after the original scan, which is the moment your advisory trigger would fire.
Quick check
Is a monthly sync enough on its own?
Not if a serious advisory lands mid month. Keep the advisory trigger so urgent fixes do not wait for the calendar.
Should a fork with many patches sync less often?
No. Conflicts compound with the gap, so a small gap is cheaper to resolve than a large one.
Sources
Last reviewed: 19 October 2026.
