您的位置:首页 > 其它

git 只merge一个commit的方法

2017-03-28 21:08 375 查看
https://git-scm.com/book/tr/v2/Git-Basics-Viewing-the-Commit-History

gil log 来查看commit的记录

Other maintainers prefer to rebase or cherry-pick contributed work on top of their master branch, rather than merging it in, to keep a mostly linear history. When you have work in a topic branch and have determined that you want to integrate it, you move to that branch and run the rebase command to rebuild the changes on top of your current master (or
develop
, and so on) branch. If that works well, you can fast-forward your
master
branch, and you’ll end up with a linear project history.

The other way to move introduced work from one branch to another is to cherry-pick it. A cherry-pick in Git is like a rebase for a single commit. It takes the patch that was introduced in a commit and tries to reapply it on the branch you’re currently on. This is useful if you have a number of commits on a topic branch and you want to integrate only one of them, or if you only have one commit on a topic branch and you’d prefer to cherry-pick it rather than run rebase. For example, suppose you have a project that looks like this:



Figure 80. Example history before a cherry-pick.

If you want to pull commit
e43a6
into your master branch, you can run

$ git cherry-pick e43a6
Finished one cherry-pick.
[master]: created a0a41a9: "More friendly message when locking the index fails."
3 files changed, 17 insertions(+), 3 deletions(-)


This pulls the same change introduced in
e43a6
, but you get a new commit SHA-1 value, because the date applied is different. Now your history looks like this:



Figure 81. History after cherry-picking a commit on a topic branch.

Now you can remove your topic branch and drop the commits you didn’t want to pull in.
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: