What's New In Stash 2.4
Forking in the Enterprise
Git gives development teams a plethora of options when choosing how to collaborate on projects. Teams migrating their development to Git need the flexibility to best work with code in a distributed enterprise environment. Common practices have emerged using branch- and fork- based workflows, igniting debates on how they can best be used in the enterprise.
Stash 2.4 introduces key features to manage and collaborate on your Git repositories behind the firewall–forking, a distributed development workflow popularized in open source development, along with personal repositories and per-repository permissions.
Choice, flexibility, control–that's Stash 2.4
Own Stash?
View the full release notes »
New to Stash?
Take the Stash feature tour »
Forking Workflow
To fork simply means to create a clone of a repository, including previous history, on the server side. In Stash, clicking the 'Fork' button on a repository creates a copy that is tracked by Stash and modified independently of the original repository, insulating code from the original repository to unwanted changes or errors. You can fork a repository into any other project in Stash for which you have admin access, or create personal forks and give other developers access.
Why Fork?
- Contractors – Allow external developers to contribute to a project while only core team members have write access to the repository. Contributors can simply fork a repository and contribute changes back via pull requests.
- Large teams – With hundreds of developers working on the same repository, the volume of branches and activity in the repository can turn into noise. Forks provide a way for teams to work separately while constantly syncing new additions from the core repository into their project.
- Experiments – Whether you're participating in ShipIt, spiking a project, or simply prototyping a feature, experimenting on forks gives developers the option to trash changes without polluting the main repository with commits if the experiment goes nowhere.
For reasons why an enterprise would want to adopt forks see "Why Forks?".
Personal Repositories
Stash 2.4 adds a way to create personal repositories that are not related to other projects. This gives developers the freedom to innovate and store their private snippets of work, kick-start their own project, contribute a bug fix for a project they are not a member of, or add a feature to a common component maintained by a small group in an organization. Keep your personal repositories as open (or closed) as you want, then use repository permissions to collaborate with other users and groups if and when you are ready.
Repository Permissions
Grant access to individual repositories within a project without making the entire project available to the user. There are several scenarios where this can benefit your workflow:
- External developers – Opening up broad access to your repositories can be nerve-racking when working with external developers. For a given project, your core team should have access to all repositories, while only select repositories are available to contractors.
- Open up access – Many teams restrict write access to a small group of developers for specific projects. To foster collaboration you can open up view access to the rest of an organization so other non-core team members can fork and contribute.
- Delegate administration – Save valuable time by providing administration access for a repository to trusted team members, giving them the freedom to manage specific repositories.
Stash lets you choose how you and your teams work with distributed code, and that flexibility means you can work and ship faster.
Contribute Via Pull Requests
The beauty of forks and personal repositories is that changes being made on the repository will not affect the main code line. Once a fork is ready for primetime, a request can be made to merge it into the original repository. Stash and pull requests facilitate the process of merging those changes. This gives other developers an opportunity to review and discuss the changes before they become a part of the main codebase. From there the changes can be merged based on the pull request settings and branch permissions in the original repository.
