理解git cherry-pick

Question

来自svn背景:由于(缺乏)切换速度以及将分支合并回主干所需的小时或更长时间,我几乎没有分支.有时,如果我需要修复网站上的问题,我会在主干中进行更改(这将与之前的更改或新功能一起生效)然后转到该文件并执行"svn up path/to/filename"它只会更新该文件,修复问题但保留其余文件.

从概念上讲,这似乎不可能在git(或必要); 是结构化的分段和分组提交,允许采摘樱桃？所以,我可能会更改网站的特定区域并将其作为一个组提交,而不是像我一样使用svn,并且大约一天的工作并触摸整个提交整个批次的文件？

Answer 1

在这种情况下,您可能想要做的是为您的修补程序创建一个新分支,从需要修复的所有分支的共同祖先分支出来.例如,假设您有一些维护版本以及当前的开发:

- X - o - o - o - o - o - o - o - o - o (master)
   \                       \
    o - o - o (release A)   o - o (release B)

如果您需要制作适用于这两个版本的修补程序,请从标记为X的提交开始创建一个分支.提交修复,然后将该分支合并到所有三个分支中.

你可以挑选,但这里有一个很好的经验法则,关于何时采摘樱桃:不要.你唯一想要挑选的情况就是当你管理好自己的分支机构时.在这种情况下,这可能意味着您在master上进行了修复,而不是从之前的点开始正确分支,并且人们已经将更新提取到master,因此您无法更改它.你必须在两个发布分支上挑选它.但是,当然,你应该首先管理你的分支机构,你永远不需要挑选.(是的,有时候它仍会发生;这就是生活.)