Keeping the branch up to date

As you develop your branch, changes will be occurring simultaneously within the master branch. These changes should be incorporated into your branch on a regular basis to avoid large incompatible changes from forming between the two branches. For your changes to be incorporated into relax's master branch, the `git rebase' concept and not `git merge' should be used.

Versioning git branches

If you have already pushed your changes to a remote repository, you will need to create a new version of your branch. You should never rebase a branch that is tracking a remote branch (unless you subsequently rename the rebased branch and untrack the remote). In the above example, the molmol_macros/r1 branch is using such a manual versioning system. The second version of your branch can be created by typing

$ git checkout molmol_macros/r1
$ git branch molmol_macros/r2
$ git checkout molmol_macros/r2

You can then leave the molmol_macros/r1 branch untouched and instead rebase the new molmol_macros/r2 branch.

Rebasing to the master branch

Assuming you have not already pushed your branch to a remote repository, you can rebase your branch to the master branch. Firstly make sure your local copy of the master branch is fully up to date, then type

$ git rebase -i master

Or fetch all changes from the primary SourceForge remote (or a mirror) and rebase to the remote master branch with

$ git fetch sf
$ git rebase -i sf/master

If conflicts have occurred please refer to the git reference manual for information on how to resolve the problem. To avoid accidental loss of your changes when major conflicts occur, version control of your branch can be used to preserve the current set of changes (see Section 13.4.2). For example if the current branch is named my_branch/r4, increment to the fifth version of the branch with

$ git checkout my_branch/r4
$ git branch my_branch/r5
$ git checkout my_branch/r5

Then you can perform the risky rebase on the new my_branch/r5 branch, knowing that the changes in my_branch/r4 remain safe. This process is a lot less stressful than having to deal with `git reflog' when things go wrong.