-
Notifications
You must be signed in to change notification settings - Fork 0
Development, Branching, and Issue Tracking procedure
ICEBERG uses git-flow as development and branching model, with some simplifications. A nice interactive introduction in Git can be found at https://learngitbranching.js.org/
All development (i.e. commits to git) should be related to an issue or Pull Request Any active development is done to branches based on the Branch Naming procedure described below. When they are stable and tested, a Pull request is created towards the devel branch. At least one reviewer should check the Pull Request, before it is merged. Github allows protecting branches from direct commits. The master branch should be protected and commits should happen only through approved Pull Requests with at least one reviewer accepting.
When a significant development phase is finished, and tested, a Pull Request will be submitted from Devel to Master. When that is merged we will consider everything released and ready for executing production runs
-
devel,master: never commit directly to them -
feature/abc: development of new features -
fix/abc_123: referring to issue 123 -
hotfix/abc_123: referring to issue 123, to be released right after merge to master -
experiment/sc16: experiments toward a specific publication etc - not mergeable, will be converted to tags after experiments conclude -
tmp/abc: temporary branch, will be deleted soon -
test/abc: test some integration, like a merge of two feature branches
For the latter: assume you want to test how feature/a works in combination with feature/b, then:
git checkout feature/agit checkout -b test/a_bgit merge feature/b- do tests
All branches are ideally short living, apart from the devel branch. To support this, only a limited number of branches should be open at any point in time. Like, only N branches for fixes and M << N branches for features should be open for each developer - other features / issues have to wait.
- commits, in particular for bug fixes, should be self contained so make it easy to use
git cherry-pick, so that bug fixes can quickly be transferred to other branches (such as hotfixes). - do not use
git rebase, unless you really know what you are doing. - you may not want to use the tools available for
git-flow-- those have given us inconsistent results in the past, partially because they used rebase...
Please note that (at least initially) we don't need to follow this strictly for experiment branches, only for fix and feature branches i.e. work which has a direct route into released code.
Please adhere to the following principles, which will make all of our lives easier!
All development (i.e. commits to git) should be related to an issue or PR. If one does not exist, please create it! Issues should be closed by the person who opened them, and the closing message should document what level of testing has been done to ensure that the issue is in fact resolved. Issues should be assigned to a label.
New issues should be investigated (briefly) by a developer, and come to agreement with the reporter as to what should be done with the issue: Further investigation (assign to developer, no milestone needed at this stage) Requires immediate fix (assign to developer, add to current release milestone) Not urgent / no plan to fix (add to "Future Release" or "Backburner", no need to assign to a developer) Active issues (those assigned to current release, or updated in last week) will be reviewed at bi-weekly meetings