docs/contrib/gitcherry-pick.md
Author: @cubxxw
As OpenIM has progressively embarked on a standardized path, I've had the honor of initiating a significant project, git cherry-pick. While some may see it as merely a naming convention in the Go language, it represents more. It's a thoughtful design within the OpenIM project, my very first conscious design, and a first in laying out an extensive collaboration process and copyright management with goals of establishing a top-tier community standard.
In multi-branch repositories, transferring commits from one branch to another is common. You can either merge all changes from one branch (using git merge) or selectively apply certain commits. This selective application of commits is where git cherry-pick comes into play.
Our collaboration strategy with GitHub necessitates maintenance of multiple release-v* branches alongside the main branch. To manage this, we mainly develop on the main branch and selectively merge into release-v* branches. This ensures the main branch stays current while the release-v* branches remain stable.
Ensuring this strategy's success extends beyond just documentation; it hinges on well-engineered solutions and automation tools, like Makefile, powerful CI/CD processes, and even Prow.
main branch.release-1.18)origin fork on GitHub and making a pull request against a configured remote upstream that tracks https://github.com/openimsdk/open-im-server.git, including GITHUB_USER.gh) installed following installation instructions.Compared to the normal main branch's merge volume across time, the release branches see one or two orders of magnitude less PRs. This is because there is an order or two of magnitude higher scrutiny. Again, the emphasis is on critical bug fixes, e.g.,
A bugfix for a functional issue (not a data loss or security issue) that only affects an alpha feature does not qualify as a critical bug fix.
If you are proposing a cherry pick and it is not a clear and obvious critical bug fix, please reconsider. If upon reflection you wish to continue, bolster your case by supplementing your PR with e.g.,
If the change is in cloud provider-specific platform code (which is in the process of being moved out of core openim-server), describe the customer impact, how the issue escaped initial testing, remediation taken to prevent similar future escapes, and why the change cannot be carried in your downstream fork of the openim-server project branches.
It is critical that our full community is actively engaged on enhancements in the project. If a released feature was not enabled on a particular provider's platform, this is a community miss that needs to be resolved in the main branch for subsequent releases. Such enabling will not be backported to the patch release branches.
Run the cherry pick script
This example applies a main branch PR #98765 to the remote branch upstream/release-v3.1:
scripts/cherry-pick.sh upstream/release-v3.1 98765
Be aware the cherry pick script assumes you have a git remote called upstream that points at the openim-server github org.
Please see our recommended Git workflow.
You will need to run the cherry pick script separately for each patch release you want to cherry pick to. Cherry picks should be applied to all active release branches where the fix is applicable.
If GITHUB_TOKEN is not set you will be asked for your github password: provide the github personal access token rather than your actual github password. If you can securely set the environment variable GITHUB_TOKEN to your personal access token then you can avoid an interactive prompt. Refer mislav/hub#2655 (comment)
Your cherry pick PR will immediately get the do-not-merge/cherry-pick-not-approved label.
As with any other PR, code OWNERS review (/lgtm) and approve (/approve) on cherry pick PRs as they deem appropriate.
The same release note requirements apply as normal pull requests, except the release note stanza will auto-populate from the main branch pull request from which the cherry pick originated.
git cherry-pick applies specified commits from one branch to another.
$ git cherry-pick <commitHash>
As an example, consider a repository with main and release-v3.1 branches. To apply commit f from the release-v3.1 branch to the main branch:
# Switch to main branch
$ git checkout main
# Perform cherry-pick
$ git cherry-pick f
You can also use a branch name instead of a commit hash to cherry-pick the latest commit from that branch.
$ git cherry-pick release-v3.1
To apply multiple commits simultaneously:
$ git cherry-pick <HashA> <HashB>
To apply a range of consecutive commits:
$ git cherry-pick <HashA>..<HashB>
Here are some commonly used configurations for git cherry-pick:
-e, --edit: Open an external editor to modify the commit message.-n, --no-commit: Update the working directory and staging area without creating a new commit.-x: Append a reference in the commit message for tracking the source of the cherry-picked commit.-s, --signoff: Add a sign-off message at the end of the commit indicating who performed the cherry-pick.-m parent-number, --mainline parent-number: When the original commit is a merge of two branches, specify which parent branch's changes should be used.If conflicts arise during the cherry-pick:
--continue: After resolving conflicts, stage the changes with git add . and then continue the cherry-pick process.--abort: Abandon the cherry-pick and revert to the previous state.--quit: Exit the cherry-pick without reverting to the previous state.You can also cherry-pick commits from another repository:
Add the external repository as a remote:
$ git remote add target git://gitUrl
Fetch the commits from the remote:
$ git fetch target
Identify the commit hash you wish to cherry-pick:
$ git log target/main
Perform the cherry-pick:
$ git cherry-pick <commitHash>