Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 12 Current »

All development needs to happen in personal development branches.  You should be creating personal branches for your work.  Please review:

Github Fork-n-Beans Workflow

  • Once you are done, create a pull request in Github to merge into Dev.  
  • Ensure that you are keeping your personal branches up to date with the main dev branch so that your reviewer will only have to see your changes.
  • For each release, there must be a branch "release/x.y.z", all release branches must be merged back to "dev" branch.
  • Your PR will be the basis for kicking off a code review.  
  • In your PR, include the Jira ticket # in the comments. (When creating the PR use smart commits, and include the Jira issue number - Medha to create a how to article about this)
  • Validate that the builds passed on your PR.   You can view the builds on Travis here:  https://travis-ci.org/rchain/rchain
  • cc 'rchain-makers@pyrofex.net' 
  • Select a reviewer.
  • Wait for your reviewer's feedback.
  • Address any feedback.
  • Once approved, you will perform the merge to Dev.


If you're picking up someone else's pull request, then whatever you do must preserve the commit history. If you can accomplish that by rebasing off someone else's PR, then great. If you need to merge the PR and then create a new PR, then that's also fine. Merging a broken PR and then fixing it "later" is the least preferable, but there are situations where this also works. E.g., if the "fix" is already implemented and will be merged almost immediately.


Please do NOT:

  • Please do not close PRs when there are new changes which result in conflicts. You can add changes and resolve conflicts by merging or rebasing.


  • No labels