Branches

EGSnrc git branches

The EGSnrc project adopts a workflow which is very similar the widely used "git flow" model, with a master branch, a develop branch, and any number of temporary branches to implement new features or fix issues. (There is also a separate gh-pages branch which holds the files for the EGSnrc website.)

The master branch

This is the default branch of the EGSnrc project, the one considered stable. This is the default branch when cloning the repository or downloading the zipped archive. The branch does not change between releases, except for bug fixes considered serious enough to be integrated right away. About once a year, the master branch is updated with the latest code developments and is tagged as a "release". This branch is protected, so you cannot push to this branch directly and you should not open a pull request against master.

The develop branch

This is the development branch of the EGSnrc, where latest features and bug fixes are integrated on a continuous basis. This branch is a testing ground for the next release, so we encourage you to work off this branch.While we strive to keep this branch as stable as possible, there could be occasional forced rewrites to the this branch's commit history should problems be detected. About once a year, the develop branch is merged into master and this is tagged as a "release". You may open pull requests against develop. To use the latest features of EGSnrc, clone the repositry and checkout the develop branch before configuring EGSnrc:

git clone https://github.com/nrc-cnrc/EGSnrc.git
git checkout develop

The feature branches

At any time there may be a number temporary branches in the EGSnrc project. These are used to implement new features or bug fixes. These branches are completely unstable, meaning that commits on such branch may be squashed, overwritten, removed, etc. This means you should not rely on these branches or any of their commits being permanent. When a feature branch is deemed ready, its commit history is cleaned up, it is merged into develop. The reference to the temporary branch is then removed. You may open pull requests against a feature branch if you are actively involved in its development.

It is good practice to implement your changes on a feature branch, based on an up-to-date develop:

git clone https://github.com/nrc-cnrc/EGSnrc.git
git checkout -b feature-x develop
# (commit your changes...)
git push origin feature-x

When the branch feature branch is ready for integration, you should clean up the commit messages and perhaps squash small commits together, starting at the point where feature-x branched off from develop:

git checkout feature-x
git log develop..feature-x --oneline  # note last commit hash, e.g., abc1234
git rebase -i abc1234~1
# (edit commits ...)

Useful branch commands

See your branche references in detail:

git branch -avv