Forking collaboration model for our team is costly

We use the forking model for collaboration within our team of ~7 developers. We've been using this model for around 3 years and migrated over from github. The issue we have is that in collaboration, it is often useful when reviewing a pull request to have access to the user's fork. The two most common caes cases this is valuable in our organization is:

1) You want to fetch their fork so you can test and work with their code before it is upstream.

2) You want to see the raw file. We use pull request for design docs so we can comment in-line, but without access to the user's repo, you cannot view the file in markdown format.

However, in order to make this work for our team, we have to give access to our private forks to the other developers which put us at more than 5 users accessing our private repos. This means we must not only pay for an upgraded account for the group account, but for each individual. This means to get forking model to work we have to pay (7+1)*10 = $80/mo instead of just the $10/mo for a 10 user group. So to get the forking model to work for our needs, it would be N times more costly where N is the number of developers in your organization. I don't believe this is the intention of the pricing model, but I could be wrong :P.

The solution that would help us the best on this would be to allow read access on private repos to be granted without it being counted as part of the user limit. Would love to hear thoughts around how to get the forking model to work better under the current pricing limitations as well.

1 answer

1 vote

For a team setup such as this, we recommend a branching model instead. This way all developers share the same repository and everyone can view all the work from everyone else. To ensure that your master branch doesn't get directly committed to, we have also created branch permissions to help you secure your production branches. Then, only designated people with write access to the branches can merge in Pull Requests. With this, you get the added benefit of all the work being in one central place.

If you remain on the forking model, we would suggest using the single team account for all forks. This way, everyone can retain access. A naming convention would help differentiate the repos from each other. Since we have no limit on the number of private repositories, this should also work for you.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Nov 06, 2018 in Bitbucket

Upgrade Best Practices

Hello! My name is Mark Askew and I am a Premier Support Engineer for products Bitbucket Server/Data Center, Fisheye & Crucible. Today, I want to bring the discussion that Jennifer, Matt, and ...

1,964 views 7 10
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you