Branching and Forking Strategy

Branching Strategy

The will be one mainline, master. Branches will be made for each major release allowing bugfixes to be made to those releases. New features will not be accepted in a release branch and must be made in master.

The dLeyna repositories should look something like this:

               |----- 1.0         |----- 1.1
---------------|------------------|--------------- master

It is unlikely that we will need a more complicated branching strategy than this. For example, we should not need a 1.x branch from which 1.0 and 1.1 are themselves branched.

Finally, in order to keep the dLeyna repositories simple, development branches are not allowed in the main repository.

Submitting Code to dLeyna

In order to submit changes to dLeyna you need to create a fork. You should only need to fork the project once.

You should not submit any changes to your fork's master branch. All changes will be made in development branches. You can enforce this rule by disabling commits to the master branch by executing the following commands in your repository

# cat > .git/hooks/pre-commit
#!/bin/bash                                      

# remove the extra space between the opening square brackets.  Can't seem to escape these
# brackets in markdown.
if [ [ `git symbolic-ref HEAD` == "refs/heads/master" ]]
then
    echo "You cannot commit in master!"
exit 1
fi
[CTRL-D]
# chmod a+x .git/hooks/pre-commit

Please note you need to remove the extra space between the opening square brackets in the if statement. I can't work out how to escape square brackets in the wiki.

If you ever see the error, You cannot commit in master!, make sure to remove all changes you have made to the index before fetching and merging the latest changes from upstream.

All development should take place in a branch. Each time you work on a bug fix or a new feature you need to create a new branch.

Once you have finished your change and are ready to integrate you should update your master branch with any changes from upstream. First ensure that you have a remote called upstream in your fork. If you do not you can add it as follows.

git remote add upstream git://github.com/01org/[repo].git

Then fetch the latest changes and merge them into your master branch

git fetch upstream
git checkout master
git pull upstream master

Next you need to rebase your development branch with the latest changes you just received

git checkout dev-011
git rebase master

Then push your new branch to your fork's origin and submit a pull request

git push origin dev-011

It could happen that multiple pull request have been sent by different developers at the same time. If this occurs, and another pull request is merged first, your pull request might be rejected as it will no longer be possible to perform a fast forward merge from your development branch. If this happens, sync your local repository once more, create a new branch based on the latest sources and move your changes to this branch, either by using rebase onto or cherry pick.

You do not need to push your master branch back to git hub but you may wish to do this to avoid messages such as "Your branch is ahead of 'origin/master' by 1 commit." when you type git status.

Once your pull request has been accepted you will probably want to delete your development branch. This can be done as follows

git push origin --delete dev-011
git branch -d dev-011