Feature branching for rapidftr

It makes merging a lot easier if your changes are on their own branch. Making a pull request from 'master' means that if you do any more changes, they are added to the merge request and it makes integrating your changes a bit more difficult. An ideal situation is if your changes are commited on top of the most recent version of jorgej/rapidftr master. In fact, you should try and make all your changes on dedicated branches and only push to master when you are updating from the central repository.

The following instructions should enable you to get a fresh copy of jorgej/master, create a dedicated feature branch and put your changes on top of them.

Before you start

You need to have your own fork of the central repository: https://github.com/jorgej/RapidFTR and have it cloned locally.

Get the project running locally following the instructions for your OS:

• OSX
• Linux
• Windows

Make sure you have the central repository as a remote:

   git remote add upstream git://github.com/jorgej/RapidFTR.git

Before you start working

Reset your master branch

Get the latest from upstream:

   git fetch upstream

Make sure you have master checked out

    git checkout master

Now you need to get your master to point to the same commit as the central repository. How you do this depends on whether you have made your own changes to your master branch. If you have made no changes to your master branch:

   git merge upstream/master

If you have made no changes, this should indicate it has fastforwarded your branch forward to the latest central repository commit, something like this:

   Fast-forward
     app/helpers/application_helper.rb                  |    5 +++++
     features/basic_search.feature                      |    9 ++++++++-
     features/manage_children.feature                   |   17 ++++++++++-------
     lib/rapidftr_default_db_setup.rb                   |   20 ++++++++++----------
     etc.
     10 files changed, 59 insertions(+), 25 deletions(-)

Alternatively you can completely reset your master branch. WARNING: this will kill any non-merged commits on master of master so make sure you dont need it. If you want to keep a backup do:

   git branch old_master

Now to reset:

    git reset --hard upstream/master

Finally And push to your fork. If you had to use the resett command you will have to use the --force flag.

    git push origin master

Note: using force means that you are rewriting the commits on your repository. If anyone is watching or has checked out from your branch you might want to let them know you are doing something weird.

Create your branch

Now you have completely up to date master you can create a branch for your fix. Give it a good name (maybe with the mingle number in it).

    git checkout -b YOUR_BRANCH

The first time you push, you need to explicitly give the branch name else it won't push the changes:

    git push origin YOUR_BRANCH

Now you have to set up your local branch to track the one you just pushed

   git config branch.YOUR_BRANCH.remote origin
   git config branch.YOUR_BRANCH.merge refs/heads/YOUR_BRANCH

To do this in one action, you could check out these commands: http://git-wt-commit.rubyforge.org/ which include a git-publish-branch command.

Now you have a feature branch ready to do your changes... so go do them changes making sure you push back to github when you are done.

When you are finished

When you have finished the change you wanted to make and all the specs and features are passing, it's time to make a pull request. This tells all the committers to the central repository that your changes are waiting to be merged.

To make a pull request, go to your branch page on github (e.g. https://github.com/YOURNAME/RapidFTR/tree/YOUR_BRANCH). Then you can click "Pull Request", fill in any details and submit it. It will create a pull request from the branch rather than master. You should not make any more changes to this branch while there is a pull request out. If you have made a mistake or there is a bug you spot a little bit later, you can close the pull request and reopen a new one later.

What happens next

One of the committers to the central repository will pick up your changes and pull them into his own copy of RapidFTR. These will be reviewed to see if there are any obvious bugs or stuff missing, rake will be run and then if the committer is happy, he will push the changes into the master branch and voilà your changes have been integrated. We generally get in contact with you/put a note on the pull request if there are any questions or bugs we spot.