Stash is now known as Bitbucket Server.
See the

Unknown macro: {spacejump}

of this page, or visit the Bitbucket Server documentation home page.

This page provides a high-level description of Git workflows that are supported by Stash. These come under two broad categories: 

  • Branch workflows - for where all developers have access to the master repository
  • Fork workflows - for where you need to maintain restricted access to the master repository

Branch workflows

Branches in Stash provide for various workflows for developer teams. Some typical examples are described below. See Using branch permissions for more information about using branches in Stash.

On this page:

Centralised workflow

If your developers are already comfortable with Subversion, the Centralized Workflow lets you experience the benefits of Git without having to adapt to an entirely new process. It also serves as a friendly transition into more Git-oriented workflows. Read more...

Feature branch workflow

The Feature Branch Workflow builds on the Centralized Workflow by encapsulating new features into dedicated branches. This enables the use of pull requests as a means to discuss changes before they’re integrated into the official project. Read more...

Gitflow workflow

The Gitflow Workflow streamlines the release cycle by using isolated branches for feature development, release preparation, and maintenance. Its strict branching model also lends some much needed structure to larger projects. Read more...

Fork workflows 

Forks in Stash provide a workflow for developers to contribute code back to a repository for which they do not have write access. The merging of new code back into master may be controlled by a 'gatekeeper', and the review of code changes is performed by means of pull requests. Typical scenarios that suit fork workflows include:

  • 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.
  • Enterprise teams – with hundreds of developers working on the same repository, the volume of branches and activity in the repository can become 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 are spiking a project or simply prototyping a feature, experimenting on forks gives developers the option to simply discard the changes made and not pollute the main repository with commits if the experiment goes nowhere.

See Using forks in Stash for more information.

  • No labels
 

 

 

 

 Except where otherwise noted, content in this space is licensed under a Creative Commons Attribution 2.5 Australia License.