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，因此您无法更改它。你必须在两个发布分支上挑选它。但是，当然，你应该首先管理你的分支机构，你永远不需要挑选。（是的，有时候它仍会发生;这就是生活。）

理解git cherry-pick

1 个答案: