Why fork syncing is useful?

Question

I noticed that BitBucket Server, formerly Stash, has a feature called "fork syncing", which allows to automatically sync between 2 different repositories. The way I see it is like a mirror repository.

What is the usefulness of that feature?

Why should someone use it and how?

Answer 1

To understand how fork syncing is used, it's first important to think about workflows.

If your organization uses a workflow where the developers have write access to the canonical repository, you may not need a fork at all. In such an organization, fork syncing may not offer a lot of benefit because your fork, if you have one, may only exist as a place where you keep your side projects that you're not yet ready to push to a branch in the canonical repository and share with your team.

However, if your organization restricts write access to the canonical repository to a set of trusted lieutenants and all the developers are required to do their work in a fork of the repository and open a pull request with their changes, that's the type of environment where fork syncing can pay off.

In such an environment, the normal development workflow is triangular:

• Fetch from the upstream repository
• Checkout the desired base branch for your changes and code them up
• Push your work to a branch in your fork

This workflow requires you to be actively engaged with two remote repositories for any non-trivial change. The goal of fork syncing is to eliminate this triangular workflow and allow you to develop against your fork in exactly the same way you would develop against the canonical repository itself, if you had access. So here's the workflow with fork syncing enabled:

• Fetch from your fork
• Checkout the desired base branch for your changes and code them up
• Push your work to a branch in your fork

Notice that you never needed to directly interact with the upstream, because the branches in your fork are automatically being kept in sync as new work is pushed to the canonical repository. The workflow is now identical to what it would be if you were simply working in the canonical repository directly.

Some people might want to do their own fetches to update their fork. That's fine too; fork syncing is an optional feature, so you can just turn it off. For me, though, it's an integral part of my workflow.

Full disclosure: I am the principal developer for Bitbucket Server, and the author of its fork syncing feature. I do all of my development on Bitbucket Server using branches in my fork, which is kept up-to-date by fork syncing.

Answer 2

According to Atlassian Docs: Keeping forks synchronized

Fork syncing helps you to keep your fork in Bitbucket Server up-to-date with changes in the upstream repository. Bitbucket Server can do this automatically for all branches and tags you haven't modified in the fork.

If you have modified branches or tags in the fork, Bitbucket Server will offer syncing strategies. Bitbucket Server will never update your branch or tag in your fork if this means that your changes would be lost.

Note that syncing is about pulling recent upstream changes into your fork, whereas pull requests are about pushing your changes back to the upstream repository.

On Github BootCamp you would find this definition of fork

A fork is a copy of a repository. Forking a repository allows you to freely experiment with changes without affecting the original project.

If fork is just a copy used to experiment with original repo without any causes, than: Github Help)

Syncing your fork only updates your local copy of the repository.

Answer 3

https://confluence.atlassian.com/bitbucketserver/keeping-forks-synchronized-776639961.html

It sounds like its for keeping your fork of a primary repository up to date with the upstream automatically.

Personally this is not a useful feature as I think it's important to perform these "pulls" manually.