: Translate Documentation : : Appendix A - Glossary

How-To - Commit Changes to Github

The Rubinius Project does a majority of its work on the master branch. The goal is to keep master “clean” so that it always builds a working binary and provides a snapshot of the latest fixes and enhancements.

Committers With Read/Write Access to Rubinius Repository

We recommend that committers who have read/write access to the repository do their work on a branch in their local repository. As the changes stabilize, they should be committed in two steps. The first step should commit the spec that highlights the behavior under construction while the second commit adds the behavior and allows the spec to pass.

After committing to the local repository’s branch, the commit should be merged back to master and pushed to github. To avoid superfluous git merge messages, we ask that the committer first rebase the master branch prior to the merge.

  1. git branch name-of-fix-branch
  2. git checkout name-of-fix-branch
  3. git add
  4. git commit
  5. git add
  6. git commit
  7. git checkout master
  8. git pull –rebase
  9. git checkout name-of-fix-branch
  10. git rebase master
  11. git checkout master
  12. git merge name-of-fix-branch
  13. git push origin master

Steps 9 through 15 can be automated via a script to save on all of that typing.

Committers With Read-only Access to Rubinius Repository

Please read:

: Translate Documentation : : Appendix A - Glossary

Tweet at @rubinius on Twitter or email community@rubinius.com. Please report Rubinius issues to our issue tracker.