Supporting Inner Source with Forks

We’re very excited to announce that we’ve added the ability to fork Git repositories hosted in Visual Studio Team Services. If you work on open source projects, then you’re probably already familiar with repository forks. A fork takes a Git repository and creates a duplicate copy of it – on Visual Studio Team Services – and lets you work in that fork, isolated from the original copy. You can experiment safely and push up whatever changes you make to your fork, where they stay until you’re ready to contribute them back. Then you can open a pull request with your changes back to the original repository.

This fork-based pull request workflow is popular with open source projects, since it allows anybody to contribute to a project. You don’t need to be an existing contributor or have write access to a project to offer up your changes. But this workflow isn’t just for open source: forks also help support Inner Source workflows within your company.

Before forks, you’ve always been able to contribute to a project using Pull Requests in VSTS. The workflow is simple: push a new branch up to your repository and then open a pull request to get a code review from your team and have VSTS evaluate your branch policies. When your code is approved, you can click one button to merge your pull request into master and deploy.

This workflow is great for working on your projects with your team. But what if you notice a simple bug in a different project within your company and you want to fix it yourself? What if you want to add a feature to a project that you use but another team develops? That’s where forks come in; forks are at the heart of Inner Source practices.

Inner Source – sometimes called “internal open source” – brings all the benefits of open source software development inside your firewall. It opens up your software development processes so that your developers can easily collaborate on projects across your company, using the same processes that are popular throughout the open source software communities. But it keeps your code safe and secure within your organization.

We use Inner Source within Microsoft. As part of our efforts to standardize on one engineering system throughout the company – backed by Visual Studio Team Services – we’ve also opened up the source code to all our projects to everyone within the company.

Before our move to Inner Source, we were “siloed”: only engineers working on Windows could read the Windows source code. Only developers working on Office could look at the Office source code. So if you were an engineer working on Visual Studio and you thought that you had found a bug in Windows or Office – or you wanted to add a new feature – you were out of luck. But by moving to offer Inner Source throughout the company, supported by VSTS, it’s easy to fork a repository to contribute back. I don’t need write access to the original repository, just the ability to read it and create a fork.

To get started, I click the Fork button in the top right of the Code hub in VSTS.

Screenshot: Fork Prompt in VSTS

Then I just need to give my fork of this repository a name. I can also choose what Project to create my new fork in, and whether to bring include all the remote branches, or just the default branch, master.

Screenshot: New VSTS Fork Creation Dialog

And now, I’ve got my own copy of this repository. This repository is effectively a sandbox for me – I can clone it to my local machine and push up changes however I want. It’s a place for me to experiment, but it is a true repository of its own and I can use all of the tools in VSTS with it. For example, I can set up continuous integration and continuous delivery to my own servers. This lets me actually test and validate my experiments.

When I’m ready to contribute my changes back, I can open a Pull Request.

Screenshot: VSTS Suggesting a Pull Request

Since my repository is a fork of another repository, when I open a new pull request, I’m given the option to actually open the PR in that original repository.

Screenshot: VSTS Pull Request Header

When I do this, I’ll open a pull request in the original project and the team developing that project will be notified. All the branch policies for the target branch will be run and the team can code review my pull request, suggest changes to my code, and ultimately choose to merge my code into their project.

Screenshot: Open VSTS Pull Request Across Forks

So you can see that forks allow your company to adopt modern software engineering methodologies and Inner Source techniques within your organization, encouraging code sharing, code reuse and shared development.