Usually I work on the master branch, and I make some commits, and push it.
Then I also need to push these commits to other branch.
So usually, I will do:
$ git checkout another-branch
$ git cherry-pick commit1
$ git cherry-pick commit2
...
$ git cherry-pick commitn
$ git push
Some kind of stupid, is there anyway I can merge some commits from the head of the master branch so I need not
bother to cherry-pick one by one.
It sounds like you might want to make those commits on a branch other than master, and then merge that branch to both master and your second branch:
This is much, much better than cherry-picking because it doesn’t involve duplicating commits in the history, gets rid of any issues about cherry-picking a commit twice (which you currently must manually avoid)…and is just the way git is designed to work. I don’t know what your second branch is, but what I’m describing is essentially the common workflow of periodically merging maintenance and topic branches back into master as well as any other appropriate modified-release or maintenance branches.
I strongly recommend that you adopt a workflow where this is done by merging as I described above, but to answer the question you asked, if you absolutely must work on master and cherry-pick, you might want to write yourself a little script, something like:
Obviously there are ways to make the script more robust, e.g. adding the ability to resume after cherry-picks whose patches don’t apply properly, but it’s a start.
You can mess around with the way you use git-rev-list to select the commits, of course. You could even pass all but the first argument along to git-rev-list, so that you could do
cherries-pick <branch> -n 5 masterorcherries-pick <branch> release_tag..masteror whatever you want. Have a look at its man page!You can also use
git-rebaseas was suggested elsewhere, but because you don’t actually want to move master, you’ll end up doing something like this: