理解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，所以您无法更改它。你必须精挑细选才能把它放在两个发布分支上。但当然，你应该首先正确地管理你的分支，而且你永远不需要精挑细选。(是的，有时还是会发生；这就是生活。)