VSTS - Personal Git repositories for forking
This suggestion is migrated to Developer Community. Please use below link to view the current status.
Give each user a personal Git repo space. The "root" repo today is "Git Repositories". Create a special root called "My Repositories".
Then add a "fork" button next to the "clone" link that would automatically clone in a new repo in "My Repositories" Git folder. Repositories here should still have their origin remote and be available to submit Pull Requests against the origin.
Here is a manual workaround that some are following to recreate this flow:
Work on this feature has halted, and we’re re-evaluating the plan for delivering this.
Yaron Y. Goland commented
This would make working with customers vastly easier. They can just hit 'fork' and be done. Instead I have to point them at the article above.
lemuel nabong commented
We need this
"Of course, if no one can push to master directly, we need some shared place for pull requested work to live before it gets merged. There are two possible answers here. One answer is to use branches in the shared repository, and the other is to give every developer their own fork, to which they alone have access. Both approaches work, but in general the forking approach scales much better.
The reason for this is the fact that branches on the shared repository are shared with all developers. Not all developers may be interested in your refactoring of this tiny module off in an obscure part of the codebase. Why should they even have to see your branch in the first place? They're going to see the pull request; that's more than enough. Putting branches on the shared repository causes all of the developers to live in the same effective namespace, stepping on each other with each new branch created or deleted. It becomes very easy to accidentally push to the wrong place, or delete the wrong branch, or similar. These problems are manageable in a team of a dozen or so. They are categorically unmanageable in a team of hundreds. Remembering our scaling mandate, we choose forking instead." - git dmz
Thomas Pickersgill commented
The free community edition of GitLab I originally installed at my workplace has this feature, as do the other options we are considering (GitHub, BitBucket). VSTS is quite convenient for us because we are already in the Azure landscape.
I'm hoping new features such as this will be added when requested. VSTS looks quite promising, don't forget about it as it would be a shame to have to choose another option!
Gino Filicetti commented
Looks like there is renewed interest in this topic just in the last week!
Can a PM tell us if this is in the backlog? It's a key element of allowing a wide range of contributor work on our VSTS project.
Hugh Gleaves commented
The lack of fork support in VS Online is truly puzzling. Many Github users have made the fork a central pivot in their team's workflows and omitting this from VS online is holding back adoption by larger Github users.
Forks - at the very least - provide a way for developers to save their work off their local machines completely independently of the original repo.
Without forks the only way to enable such saving is to create per-developer branches, a drag to say the least.
Once can emulate forking (as described in the article mentioned above) but this is contrived and not really helpful (for example Github makes it easy for an organization admin to see and get to any fork his team members have made).
I'd consider moving from Github to VS Online tomorrow IF it provided forks, until then I'm afraid VS Online's Git support is just an also-ran.
There are multiple ways to think of the developer flow, but minimally allowing a Team Project members to have their own forks as they work on one or more repositories as part of the team. With larger teams, it is a bit hard to manage a set of topic branches from every even with "/" conventions in the names.
Keith Hill commented
Great idea!! I'd love to see this as well. However, I think there should be an option to fork to a regular TFS Git repo i.e. not be just "individual". I could see a team wanting to fork another repo to work on it in parallel. And then you would need to support PRs between the forked repo and the original - just like you can on GitHub.