Commit dba50c3d by Chris Cantwell

Merge branch 'fix/cherrypick-guide' into 'master'

Add guide for cherry picking

See merge request !790
2 parents edbfd8e7 508fd298
Showing with 75 additions and 1 deletions
......@@ -44,7 +44,9 @@ project. It's a pretty simple process:
diff and are not quite ready to merge, use the `[WIP]` tag in the title to
prevent your code from being accidentally merged.
5. Put a comment in the MR saying that it's ready to be merged.
6. Respond to any comments in the code review.
6. If your branch is a minor fix that could appear in the next patch release,
then add the `Proposed patch` label to the merge request.
7. Respond to any comments in the code review.
## Submission checklist
- Did you add regression tests (for fixes) or unit tests and/or normal tests for
......@@ -155,6 +157,78 @@ stick to the following process:
- Once feedback received from the branch author (if necessary) and reviewers are
happy, the branch will be merged.
## Release branches
Nektar++ releases are versioned in the standard form `x.y.z` where `x` is a
major release, `y` a minor release and `z` a patch release:
- major releases are extremely infrequent (on the order of every 2-3 years) and
denote major changes in functionality and the API;
- minor releases occur around twice per year and contain new features with minor
API changes;
- patch releases are targeted on roughly a monthly basis and are intended to
fix minor issues in the code.
The repository contains a number of _release branches_ named `release/x.y` for
each minor release, which are intended to contain **fixes and very minor
changes** from `master` and which form the next patch release. This allows us to
use `master` for the next minor release, whilst still having key fixes in patch
### Cherry-picking process
Any branches that are marked with the `Proposed patch` label should follow the
following additional steps to cherry pick commits into the `release/x.y` branch.
1. If the branch is on a remote other than `nektar/nektar`, make sure that's
added to your local repository.
2. On a local terminal, run `git fetch --all` to pull the latest changes. It's
important for the commands below that you do this _before_ you merge the
branch into `master`.
3. Merge the branch into master as usual using GitLab.
4. Switch to the appropriate branch with `git checkout release/x.y` and update
with `git pull`.
5. Now check the list of commits to cherry-pick.
git log --oneline --no-merges --reverse origin/master..REMOTE/fix/BRANCHNAME
where `REMOTE` is the remote on which the branch lives and `BRANCHNAME` is
the fix branch. If the list is empty, you probably did a `git fetch` after
you merged the branch into `master`; in this case use `origin/master^`.
6. If you're happy with the list (compare to the MR list on the GitLab MR if
necessary), cherry-pick the commits with the command:
git cherry-pick -x $(git rev-list --no-merges --reverse origin/master..REMOTE/fix/BRANCHNAME)
7. It's likely you'll encounter some conflicts, particularly with the
`CHANGELOG`. To fix these:
- `git status` to see what's broken
- Fix appropriately
- `git commit -a` to commit your fix
- `git cherry-pick --continue`
8. If everything becomes horribly broken, `git cherry-pick --abort`.
9. Once you're happy, `git push` to send your changes back to GitLab.
Steps 5 and 6 can be simplified by creating a script
logopts="--oneline --no-merges --reverse"
commits=`git log $logopts master..$1 | cut -f 1 -d " " | xargs`
echo "Will cherry-pick the following commits: $commits"
echo "Press ENTER to continue..."
cherryopts="-x --allow-empty --allow-empty-message"
git cherry-pick $cherryopts $commits
which accepts the name of the source branch as the sole argument.
## Formatting guidelines
Nektar++ uses C++, a language notorious for being easy to make obtuse and
difficult to follow code. To hopefully alleviate this problem, there are a
Markdown is supported
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!