I\'ve got two branches from my master:
Here's another approach.
git checkout {SOURCE_BRANCH} # switch to Source branch.
git checkout {COMMIT_HASH} # go back to the desired commit.
git checkout -b {temp_branch} # create a new temporary branch from {COMMIT_HASH} snapshot.
git checkout {TARGET_BRANCH} # switch to Target branch.
git merge {temp_branch} # merge code to your Target branch.
git branch -d {temp_branch} # delete the temp branch.
Suppose I have committed changes to master branch.I will get the commit id(xyz) of the commit now i have to go to branch for which i need to push my commits.
Single commit id xyx
git checkout branch-name
git cherry-pick xyz
git push origin branch-name
Multiple commit id's xyz abc qwe
git checkout branch-name
git cherry-pick xyz abc qwe
git push origin branch-name
The cherry-pick command can read the list of commits from the standard input.
The following command cherry-picks commits authored by the user John that exist in the "develop" branch but not in the "release" branch, and does so in the chronological order.
git log develop --not release --format=%H --reverse --author John | git cherry-pick --stdin
You could create a patch from the commits that you want to copy and apply the patch to the destination branch.
You should really have a workflow that lets you do this all by merging:
- x - x - x (v2) - x - x - x (v2.1)
\
x - x - x (wss)
So all you have to do is git checkout v2.1
and git merge wss
. If for some reason you really can't do this, and you can't use git rebase to move your wss branch to the right place, the command to grab a single commit from somewhere and apply it elsewhere is git cherry-pick. Just check out the branch you want to apply it on, and run git cherry-pick <SHA of commit to cherry-pick>
.
Some of the ways rebase might save you:
If your history looks like this:
- x - x - x (v2) - x - x - x (v2.1)
\
x - x - x (v2-only) - x - x - x (wss)
You could use git rebase --onto v2 v2-only wss
to move wss directly onto v2:
- x - x - x (v2) - x - x - x (v2.1)
|\
| x - x - x (v2-only)
\
x - x - x (wss)
Then you can merge! If you really, really, really can't get to the point where you can merge, you can still use rebase to effectively do several cherry-picks at once:
# wss-starting-point is the SHA1/branch immediately before the first commit to rebase
git branch wss-to-rebase wss
git rebase --onto v2.1 wss-starting-point wss-to-rebase
git checkout v2.1
git merge wss-to-rebase
Note: the reason that it takes some extra work in order to do this is that it's creating duplicate commits in your repository. This isn't really a good thing - the whole point of easy branching and merging is to be able to do everything by making commit(s) one place and merging them into wherever they're needed. Duplicate commits mean an intent never to merge those two branches (if you decide you want to later, you'll get conflicts).
git cherry-pick
: Apply the changes introduced by some existing commits
Assume we have branch A with (X, Y, Z) commits. We need to add these commits to branch B. We are going to use the cherry-pick
operations.
When we use cherry-pick
, we should add commits on branch B in the same chronological order that the commits appear in Branch A.
cherry-pick does support a range of commits, but if you have merge commits in that range, it gets really complicated
git checkout B
git cherry-pick SHA-COMMIT-X
git cherry-pick SHA-COMMIT-Y
git cherry-pick SHA-COMMIT-Z
Example of workflow :
We can use cherry-pick
with options
-e or --edit : With this option, git cherry-pick will let you edit the commit message prior to committing.
-n or --no-commit : Usually the command automatically creates a sequence of commits. This flag applies the changes necessary to cherry-pick each named commit to your working tree and the index, without making any commit. In addition, when this option is used, your index does not have to match the HEAD commit. The cherry-pick is done against the beginning state of your index.
Here an interesting article concerning cherry-pick
.