Git樱桃选择vs rebase [英] Git cherry pick vs rebase
问题描述
我最近开始使用Git。
在线阅读git book（ 随着rebase的变化命令，您可以在一个分支上执行所有 （引用来自： http://git-scm.com/book/en/Git-Branching -Rebasing ） 我认为这是git cherry-pick 的确切定义（重新应用一个提交或一组提交 这两者之间有什么区别？ 由于时间 真正的区别在于创建这两种工具的初衷： （它还允许开发人员移植一系列提交到任何任意的提交，但这是不明显的使用。） 自从它首次出现以来， 因此，这两个命令之间最显着的区别可能是它们如何处理分支他们的工作是： 更新以进一步解释使用 考虑到这种情况， <这本书说： 然而，还有另外一种方法：你可以把C3中引入的修改补丁和重新应用在C4之上。在Git中，这被称为rebasing。使用rebase命令，您可以将所有在一个分支上提交的更改应用到另一个分支上。 在本例中，您将运行以下命令： 这里的catch是在这个例子中，实验分支（分配的主题）最初是从master分支中分出来的，因此它共享提交C0到C2 &MDASH;有效地，实验是主，并且包括C2加上在其上面提交C3。 （这是最简单的情况;当然，实验可能包含数十个提交在其原始基础之上。） 现在 现在回到您的问题。正如你所看到的，这里技术上 同样，从技术上讲，您可以知道 I have recently started working with Git. Going over the git book online (Git book) I found the following under the "Git Rebase" section: With the rebase command, you can take all the changes that were
committed on one branch and replay them on another one. (Quoted from: http://git-scm.com/book/en/Git-Branching-Rebasing) I thought this is the exact definition of git cherry-pick (reapply a commit or a set of commit objects on the currently checked out branch. What is the difference between the two ? Since the time The true distinction lies in original intent to create both tools: (It also allows the developer to transplant a series of commits onto any arbitrary commit, but this is of less obvious use.) Since its first appearance, Hence, possibly the most striking difference between these two commands is how they treat the branch they work on: Update to further explain an example of using Given this situation, However, there is another way: you can take the patch of the change that was introduced in C3 and reapply it on top of C4. In Git, this is called rebasing. With the rebase command, you can take all the changes that were committed on one branch and apply them onto another one. In this example, you’d run the following:
"The catch" here is that in this example, the "experiment" branch (the subject for rebasing) was originally forked off the "master" branch, and hence it shares commits C0 through C2 with it — effectively, "experiment" is "master" up to, and including, C2 plus commit C3 on top of it. (This is the simplest possible case; of course, "experiment" could contain several dozens of commits on top of its original base.) Now Now back to your question. As you can see, here technically Again, technically you can tell that 这篇关于Git樱桃选择vs rebase的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
提交的更改并在另一个分支上进行重播。
git cherry-pick 学会了能够应用多个提交，所以区分确实变得有点没有实际意义，但这是被称为趋同进化; - ）
git rebase 的任务是转发开发人员在其私有存储库中进行的一系列更改，这些更改是针对某些版本的X创建的上游分支，到同一分支的Y版本（Y> X）。这有效地改变了该系列提交的基础，因此rebasing。
$ b
git cherry-pick 是从一个发展线向另一个发展线提出一个有趣的承诺。一个典型的例子是将在一个不稳定的开发分支上进行的安全修复反向移植到一个稳定的（维护）分支，在该分支中 merge 是没有意义的，因为它会带来很多不必要的更改。
git cherry-pick 能够一次选择多个提交，
git cherry-pick 通常会从其他地方带来一个提交 并将其应用于当前分支之上，记录一个 new 提交，而 git rebase 会将当前分支和重写 自己的 提示提交以这种或那种方式。是的，这是对 git rebase 可以做的一个严重愚蠢的描述，但它是有意的，试图让大众的想法沉入其中。
git rebase 进行讨论的示例。
$ git checkout experiment
$ git rebase master
首先，倒回头重播顶部的工作...
应用：添加阶段命令
git rebase 被告知将实验重定位到master的 current 提示上，并且 git rebase 这：
git merge-base 来查看共享的最后一次提交换句话说，实验和主人（分流的意义何在）。这是C2。
git apply ）。在我们的玩具例子中，它只是一个提交，C3。假设它的应用程序将产生一个提交C3'。
git rebase 实际上是将一系列的实验提交移植到master的提示中，所以你可以正确地告诉那里确实有另一个分支在这个过程中。但要点是，实验中的提示最终成为实验中的新提示提交，它只是改变了它的基础：
git rebase 这里包含了来自主的某些提交，这是绝对正确的。
git cherry-pick learned to be able to apply multiple commits, the distinction indeed became somewhat moot, but this is something to be called convergent evolution ;-)
git rebase's task is to forward-port a series of changes a developer has in his private repository, created against version X of some upstream branch, to version Y of that same branch (Y > X). This effectively changes the base of that series of commits, hence "rebasing".git cherry-pick is for bringing an interesting commit from one line of development to another. A classic example is backporting a security fix made on an unstable development branch to a stable (maintenance) branch, where a merge makes no sense, as it would bring a whole lot of unwanted changes.git cherry-pick has been able to pick several commits at once, one-by-one.git cherry-pick usually brings a commit from somewhere else and applies it on top of your current branch, recording a new commit, while git rebase takes your current branch and rewrites a series of its own tip commits in one way or another. Yes, this is a heavily dumbed down description of what git rebase can do, but it's intentional, to try to make the general idea sink in.git rebase being discussed.
The Book states:
$ git checkout experiment
$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: added staged command
git rebase is told to rebase "experiment" onto the current tip of "master", and git rebase goes like this:
git merge-base to see what's the last commit shared by both "experiment" and "master" (what's the point of diversion, in other words). This is C2.git apply) in order. In our toy example it's just one commit, C3. Let's say its application will produce a commit C3'.git rebase indeed transplants a series of commits from "experiment" to the tip of "master", so you can rightfully tell there indeed is "another branch" in the process. But the gist is that the tip commit from "experiment" ended up being the new tip commit in "experiment", it just changed its base:
git rebase here incorporated certain commits from "master", and this is absolutely correct.
