You want to replicate a specific merge request or commit from one branch to another. Typically to
- Backport from
master(trunk) to a stable branch (ex.:26.x) or - A fix that was first made in a stable branch (ex.:
26.x), and that should also be inmaster(trunk)
The best tool to achieve this procedure is the git cherry-pick. Please keep in mind that one merge request (MR) may contain one or many commits (sometimes, they are squashed into one, but not always).
Example
Folder structure
The next example assumes an existing folder named tiki26 with versioned by Git and another folder tikimaster, also versioned by Git. The tiki26 is tracking branch 26.x while tikimaster folder is tracking branch master (trunk).
| . | .. | tikimaster | tiki26
1.1.1. Getting commit(s) and message
Type git log, search for commit(s) to be backported, copy its hash and assign it to a variable name TARGET_COMMIT.
TARGET_COMMIT=1f0d6c95b936aeface9a4d7bf4d2a5b18782d1e7 TARGET_MESSAGE=$(git log $TARGET_COMMIT -n1 --format='%B')
1.1.2. Update repository
cd tiki26 git pull
1.1.3. Cherry-pick commit(s)
git cherry-pick $TARGET_COMMIT
1.1.4. Test
Test that the cherry-picked commit(s) has(ve) intended effects without unwanted side-effects
1.1.5. Push it to 26.x
git push
Procedure with the GitLab GUI
Why is the CLI better?
- Easily test before making the PR
- A PR can have more than one commit (and the GitLab GUI doesn't offer this)
If despite this, you choose to proceed with the GitLab GUI:
- In the GitLab.com web interface, find the specific commit
- On that commit, pick "Options" -> "cherry-pick" and pick the branch
- You have a choice of committing directly or transforming into a merge request
To see which merged MRs are still missing a cherry pick, use this GitLab query: https://gitlab.com/tikiwiki/tiki/-/merge_requests?scope=all&state=merged&label_name[]=needsCherryPicksTo%3A%3A*
Related