WARNING WARNING WARNING: This is the Digital Rebar v2 product documentation. The v2 version is EOL as of September 2017. Please refer to the new Digital Rebar Provision v3 documentation:

8.1. Contributing Basics

These are some general guidelines for working with code in any of our repositories. Be that core, digitalrebar-deploy, or doc, the same git workflow should be followed.

While the following use core as an example, all the trees can be managed the same way.

8.1.1. Fork the Code

The following instructions assume a clone of has already been created.

  1. Create a personal fork of the
    1. Fork the code in order to be able to submit changes
    2. Rename the fork in Github to something like ‘rebar-core’ to make it easier to track. We’ll assume that these proceedures were followed in these directions
    3. Remember to update any public SSH key to github
  2. Create a personal git identity (one time only)
    1. git config --global ""
    2. git config --global "email.address"
  3. Add a personal remote: git remote add personal[]/[rebar-core]\
  4. It is possible to check remotes using git remote -v
  5. Get the latest code from the personal repository git fetch personal

8.1.2. To Create a Pull Request

  1. Make the change and commit it: git commit -a -m "I cut and pasted this"
  2. Get the latest code from origin: git fetch
  3. Sync the changed code into the trunk: git rebase
    • Changes may have to be merged using git add [file] and git rebase --continue
  4. Push the change to the personal repository from earlier in a branch: git push personal master:[my-pull-request-branch]
  5. From the Github fork UI, create a pull request from my-pull-request-branch

8.1.3. Work On a Branch

It’s good practice to work on a branch instead of trunk. That allows for several isolated changes into distinct pulls instead of co-mingling changes.

  1. Get on master using ‘git checkout master’
  2. Be certain to stay proficient with git fetch and git rebase
  3. Create a branch using git branch [namehere]
  4. Switch to that branch using git checkout [namehere]
  5. Work & commit
  6. When ready to push, use git push personal [namehere]:[namehere]

Switching between branches is possible at any time. Switching allows work to be done on master or for work to be done on multiple pull requests. This flow is especially handy if pull may take a few days to be accepted because work can still be done on the next item while the community does the review. It also isolates the branch from changes in master. If changes from master are required, use git merge master from a branch.