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.
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.
Bitbucket Pipelines helps me manage and automate a number of serverless deployments to AWS Lambda and this is how I do it. I'm building Node.js Lambda functions using node-lambda ...
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!
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
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot