git-sync ensures your local repository is identical—at least in terms of branches and tags—to some trusted remote, bar some configurable set of local refs.
Before syncing, mark each branch or tag you wish to protect by setting the appropriate configuration parameter branch.<name>.protectFromSync or tag.<name>.protectFromSync to true.
The following example marks the branch my_local_branch and the tag my_local_tag for protection.
$ git config --bool branch.my_local_branch.protectFromSync true
$ git config --bool tag.my_local_tag.protectFromSync true
git-sync takes exactly one argument: a named remote (from which to fetch branches and tags).
Prior to fetching, git-sync will assert: (i) the specified named remote is valid and not configured with bespoke fetch refspecs; (ii) your working tree is clean and there are no untracked files; and (iii) the refs/sync/ namespace is empty.
Prior to integration, you will be presented with a summary of changes and prompted for whether you wish to proceed.
The following example syncs a fork by fetching from a remote named upstream (and pushing to a remote named origin).
$ git sync upstream && git push --prune origin '+refs/heads/*:refs/heads/*' '+refs/tags/*:refs/tags/*'
The repositories I work with tend to necessitate checking out multiple branches locally, for reference purposes.
Thus, when I fetch from my “canonical” remote, I find myself having to checkout each reference branch to perform a fast-forward (or forced) update.
This gets annoying if you have a lot of reference branches, and your working trees are quite beefy.
Since I have no intention of performing a full-blown merge on these reference branches, I’d rather Git simply update their refs, whilst leaving my topic branches alone.
Having perused the manual and turning up empty on a built-in command to do this, git-sync was born.
They’re not too shabby for stringing together a few existing commands. (Admittedly, writing a test harness in shell is… less defensible.)