Skip to content

Latest commit

 

History

History
58 lines (47 loc) · 3.27 KB

release-branches.md

File metadata and controls

58 lines (47 loc) · 3.27 KB
Raw

Contributing to OSC Release Branches

OSC releases are represented across all OSC repositories by a release branch. This document describes the process for committing changes on release branches and updating master with those changes.

Release Branches

OSC release branches are protected and merges can only be made by the organization admin. Commits to these branches are reserved only for hotfixes of high priority bugs identified on that release and approved by triage.

To submit commits for a release branch create a pull request in that branch following the same steps defined in the pull requests (PRs) flow. We will diverge only on the last step: once your PR is approved the organization admin will merge it to the respective release branch.

Applying a Hotfix to Master

Once your hotfix has been committed to a shared/remote release branch you must also bring that fix to the master branch. It is the responsibility of the hotfix submitter to update the master branch with the fix, for that follow the steps below:

  1. Ensure that your local master and release branch containing the hotfix are up to date:
$ git fetch

# Updating master
$ git checkout master
$ git pull
$ git status 
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working tree clean

# Updating the release branch, i.e.: 0.6
$ git checkout 0.6
$ git pull
$ git status 
On branch 0.6
Your branch is up-to-date with 'origin/0.6'.
nothing to commit, working tree clean
  1. Create branch that will serve as the merge branch from the HEAD of master:
$ git checkout master
$ git checkout -b owner/hotfix_merge
  1. Cherry-pick your commit from the release branch to your new branch.

Note: While cherry-picking supports multiple commits you should NOT cherry-pick multiple commits from a release branch to bring to master in a single merge. That is because merges to master always must be squashed, therefore if you cherry-pick multiple commits from a release branch to master after the merge those commits will be transfered as a single one and this will make it harder to follow the commits history accross branches.

Note: When cherry-picking ensure to use the option -x. This will add the original commit number to your new commit's message in master.

The commands below demonstrate how you can cherry-pick the commit 04b42aa0ee0672f117d754b03ac92e0c459d6f47 from the 0.6 branch.
Tip: You can use the "Copy the full SHA" button displayed in the commit history on GitHub to easily copy the SHA of your targeted commit.

$ git cherry-pick -x 04b42aa0ee0672f117d754b03ac92e0c459d6f47
# This will bring that commit as a new one on your hotfix_merge branch. 
# Observe that the commit message contains the original commit number: 
# (cherry picked from commit 04b42aa0ee0672f117d754b03ac92e0c459d6f47)
  1. Push your new branch to the remote:
$ git push -f origin owner/hotfix_merge
  1. At this point, you must create a PR from your branch to master on GitHub. If your cherry-pick had any conflicts or required any additional changes follow the code review process, otherwise you can directly merge your PR.

Note: As for any other merge to master your PR must be squashed during the merge.