Interested in the latest Stash release? Check out What’s New »
The distributed nature of 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.
Today we’re pleased to announce Stash 2.4, which offers the choice and flexibility enterprise teams need to manage their Git development workflows. This release introduces several 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.
Collaborative Git Development with Forks
To fork simply means to create a clone of a repository, including previous history, on the server side. Forks in Stash provide developers with a workflow to contribute code back to a repository for which they do not have write access–adding a layer of control into your development process. 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. Stash lets you easily merge changes between forks through pull requests.
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 an in-depth look at why an enterprise would want to adopt forks see “Why Forks?“.
Contribute changes via pull requests
The beauty of forks is that changes being made on the forked 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.
Personal Repositories
In Stash 2.4 we’ve added 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.
With the introduction of personal repositories and personal forks, we needed an easily accessible place to summarize the information. So we revamped user profiles, too.
Repository Permissions
Stash permissions aim to keep your code secure, and give you the confidence that the right developers have the right access. Early in Stash’s development we introduced two key permission sets: Global permissions to provide control or delegate user and group access to projects, and project permissions to control read and write access per-project. In Stash 2.0 we added a deeper level of access control–branch permissions–to enforce who can commit to specific branches in a repository. Stash 2.4 adds even more fine-grained access control to Stash; you can now set permissions at the repository level.
Administrators can keep projects as open or closed as they want. 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.
Always Fork Before You Commit With Stash 2.4
New to Stash? Fork today with a free trial and get up and running in a matter of minutes.
Already using Stash? Your upgrade to 2.4 is just a click away. Check out our full release notes to get started.