Solü Forking Workflow

Owned by Mark Chadbourne
Last updated: Sept 05, 2019 by Raghul Krishnan (Unlicensed)Version comment
3 min read

Overview

This workflow is a commonly-used Git configuration to control repository access and allow for review of incoming commits. It provides the following features:

  • Read-only access to the central repository for developers
  • Freedom for developers to create branches/make modifications to their own copy of the repository
  • Pull requests/commit reviews built into the main workflow for delivering to the central repository
Table of Contents

Process

Initial Setup

These steps must be completed once by each developer when they begin contributing to a repository.

Forking the repository

Because our repositories are read-only, you'll need to create and maintain a separate copy - the following will walk you through the steps necessary to begin contributing to any repository utilizing this workflow.

Fork the repository in BitBucket to create your own copy: (How To Fork)
















Best Practice

Adding a fork comment explaining the purpose for the new fork helps users understand why new copies of the repository exist.

Check out The Forking Workflow and Branch or fork your Repository for more information on forking.

Cloning the repository

Clone this copy to create a version on your local environment: 



Best Practice

Downloading a GUI for Git will simplify your Git experience and shorten your ramp-up time. SourceTree, another Atlassian product, is a great option.

Check out Git Clone and Clone a repository for more information on cloning.

Feature Development

 These steps must be completed by each developer whenever they begin/complete work on a feature.

Beginning a Feature: Managing Feature Branches

Refer to the /wiki/spaces/SM/pages/32899077 for details on how to create and maintain feature branches and begin development. 

Note

Every feature (or distinct deliverable) should have a dedicated branch separate from the rest of your development.

Completing a Feature: Creating a Pull Request

When you have completed a feature and are ready to deliver, commit the change to your local repository (cloned) and Push it to your remote repository (forked). Now the change is in your forked repository, but it's not in the original. So, create a pull request in your remote repository(forked). Pull requests use the primary repository(original repository) as the destination repository. Any pull requests to your remote repository if accepted will have changes in the original repository.

Use BitBucket to create a pull request, indicating that your change is ready for review and, if all goes well, acceptance into the origin repository:



If the change has been approved, the reviewers will sign off on it and it will be merged into the origin repository. For more information about pull requests, see Making a Pull Request and Work with pull requests.