public
Description: The Lift web framework for Scala
Home | Edit | New

Committer Process, Tips and Tricks

Process for adding code to the repo

This is a short guide to how we add new features or bugfixes to Liftweb. If you want to be able to commit code, you must have first signed an IP assignment form and been added as a committer to the project on GitHub.

When you want to fix a bug or add a new feature:

  1. Make sure you have the latest code by doing a “git pull” on the master branch
  2. Create a new local branch for your code by doing “git checkout -b your_branch_name”
  3. Make your edits
  4. Run a “mvn clean install” from the root of the liftweb project to make sure that nothing breaks
  5. Commit your changes
  6. If commits have been made against the master branch since you started work, bring your branch up-to-speed by doing a “git rebase -i master”. Be aware that “git rebase” can be a destructive operation if you fail to complete (or abort) the process correctly. If you’re at all concerned or haven’t done this before, it can be a good practice to tag your branch using “git tag your_tag_name” prior to attempting the rebase.
  7. Create a diff file by doing a “git diff master > your_branch_name.diff” (the diff file is a temporary artifact)
  8. Go to http://reviewboard.liftweb.net/ and create a new review request. You’ll upload your diff file at this point. Provide a reasonable amount of detail for the various fields in the review request, and make sure that appropriate people have been added as reviewers. Once you’re done editing, publish the review. This will send out emails to all of the reviewers on the request.
  9. Once there’s a general consensus with your reviewers that your code looks good, you can merge the code into master. Start by doing another “git rebase -i master” in case any more changes have been made. Next, switch to the master branch (git checkout master) and merge in your changes (git merge your_branch_name).
  10. Run a “mvn clean install” in the root of liftweb again to make sure that nothing has broken again
  11. If everything is fine, push your changes (git push)
  12. Go back to review board and close the request as “submitted”
  13. At this point you can clean things up by deleting the diff file and your local work branch (git branch -d your_branch_name)

If you have a good working of knowledge of Git and you prefer alternatives to these commands, please feel free to do so. In general, try to avoid cluttering the commit log with “merged branch” messages and intermediate commit entries if possible.

Last edited by nuttycom, Wed Sep 16 16:11:30 -0700 2009
Home | Edit | New
Versions: