I often find myself merging stuff from alpha branch to main branch. The way I do this, is typically by creating a list of all commits on a specific branch (which is not yet merged to main branch).

 git log origin/release/some_alpha_branch..feature/anotherbranch --pretty=format:%h --no-merges --reverse > commits.txt

this gives me a list of commits, in reversed order, which I can manipulate in notepad in order to replace \n with spaces. After that, I have a list of commits divided by spaces which I can copy paste in my cherry pick command

git cherry-pick --no-commit <pasted-list-of-space-separated-commits>

Depending of the changes, I need to merge, commit, git cherry-pick --continue, and repeat.

Once done, I reset all the commits to create one commit with a decent commit message

git reset --soft head~<number-of-commits-I-created>

It's workable to say the least, but I was wondering if I am doing things "the wrong way".

Are there better approaches to achieve something similar with less actions?

CodePudding user response：

As Code-Apprentice is saying, you should use rebase -i to spare you the trouble:

So, if you want to cherry-picks revision from X~10 up to X (both revisions included in the things you want to cherry-pick) you could do:

git rebase -i --onto whatever-branch X~11 X # you want to include X~10 so you use X~11 in the rebase

Then have fun with the editor (move revisions around, indicate different actions for each), save, exit and behold as rebase runs its magic. The only thing you need to be careful with is the revisions to start/end.... because if the end is a branch, it would be moved after the rebase... so you should consider always using revision IDs. Also, the base branch does not move so you might need to move that pointer too when you are done.