Does it make sense for each developer to manage their repository in Stash?

[Kent cross]

We have installed Stash to manage a central Git project repository. The workflow that I'm used to is where developers develop on repositories on their own PC, then when they're done they push their updates to the central repositories.

A manager is suggesting that each developer has Stash manage their individual repositories on the central server instead of their own PC. Then when they're done they generate a pull request by clicking a button in JIRA. Their Lead gets an email, pulls in their change, then pushes it to the main repo.

we have a lot of developers. I am sure that Stash can manage this many repositories, but is it a best practice to have Stash manage each developer's repository centrally?

[Daniel Wester · Accepted solution]

It's one way of doing it. Stash does support personal repositories. Depending on the work involved it might work well - it might not.  The workflow is really suitable for situations where you don't quite trust the developers yet and don't want them to have write access at all to the main repository (or where you want to have the work in progress really separated out).

Take a look at the forking workflow at https://www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow

[Mike Friedrich]

Developers can manage a private repository "additionally" to ther local repo - but not "instead".

All the repositories on the server - also those which developers can create - are bare repositories. They have no working directory and developers have no way of directly accessing these. They still need to use fetch and push between their local repo and the private and/or shared repo on the server.

I found it in most cases an unnecessary overhead. Developers may want to do this sometimes to track files which have no shared repo otherwise.

[Adam]

This is my experience too. A forking workflow (where you create whole repos for each stream of work) is very heavy in comparison to a branching workflow (where you only create another branch in the same repo). Since Stash lets you restrict write access to important branches and create pull requests between branches in a repo, you generally shouldn't need to use forks with the overhead the incur. Forks are still useful for cases like external contractors where you want to really keep them isolated from the main codebase (maybe you don't want their work to clutter up your own repo, maybe you don't plan on merging their work back in, etc).

[Steven Whitman]

I think forks are useful in several situations. 1. When developers need to share work but you don't want that work to clutter the main codebase. 2. When you want to back up your work, pushing to the server provides an automatic way to back up the work (assuming the server is backed up). 3. You can manage the forked repo however you want, forced pushes, branch names, etc. 4. It keeps the main repo from becoming cluttered with dozens of developer branches that are all work in progress. I've been using forks for a while now and I don't see that they are very heavy at all. Actually they feel about the same as a branching workflow if it's a requirement that pull requests are used to get code to the main codebase. The only real issue with forks that I've come across so far is with respect to submodules that exist between projects. You can fork the submodules but the developer needs to explicitly override the remote URL. Using submodules in the same project works fine if the submodules where originally created using relative paths.

[Kent cross]

I see that it can be a valid workflow for when you don't trust your developers. It gives you the ability to isolate potential "rogue" developers from the main baseline. In our case where all of the developers are in-house, it really is an unnecessary overhead. Thank you both for your responses.