Git正在复制代码答案

【问题标题】：Git is duplicating codeGit正在复制代码
【发布时间】：2012-12-23 15:52:33
【问题描述】：

我们刚刚从 Subversion 切换到 Git。

今天早上出现的问题是，我们从一个分支中挑选了一个提交到 master 中，这样 maser 就会修复错误。然后我们将master合并回分支。

当我们尝试编译时，所有来自精心挑选的提交的添加都在代码中出现了两次。

精心挑选的提交包括添加几行代码，最终在代码中出现两次。幸运的是，它们是完整的函数，因此会引发编译器错误。

从未引发过冲突。

我们如何避免这种情况。这是个大问题。

谢谢。

【问题讨论】：

您应该尝试类似git-flow 的工作流程。（解释：nvie.com/posts/a-successful-git-branching-model 工具：github.com/nvie/gitflow）在这种情况下，“正确”的方法是为旧代码中的错误创建一个新分支（而不是在功能分支上开发的那个）并合并它进入 master 和 feature 分支 - 然后 git 可以正确跟踪提交。
@millimoose 那个 nvie 工作流程似乎并不适用于所有情况。开发分支似乎对持续交付不太友好。
不幸的是，樱桃采摘有时是唯一的答案。很多时候我们会发现一个影响所有分支的错误，我们需要将修复放在所有分支中，但我们不希望任何分支的其他更改。这就是樱桃采摘存在的原因。
@ArtB 我承认我对模型的练习很有限，它在 OP 的情况下似乎很合适。 “对持续交付不友好”是什么意思？大概您仍然希望新功能通过某种集成过程，如果我理解正确的解释develop 主要是这样做的地方，而功能分支对组来说是“私有的”。或者换一种说法，你不会对“私人”代码进行 QA。（尽管对于没有专门 QA 的小型应用程序来说，整个模型显然是多余的。）
@JamesBaker 如果 bug 影响所有分支，那么您可以将 bugfix 分支基于它们的共享祖先，然后将该分支合并到所有分支中。

标签： git merge commit duplication cherry-pick

【解决方案1】：

从 Git 的角度来看，cherry-pick 是一种不同的提交。即，当您合并回来时，您正在合并一个 在最初应用的提交之上的新提交。

也就是说，你创建了一个带有哈希ABC 的提交。你挑选它，创建一个新的提交DEF。然后合并应用DEF 和ABC。

在上面，我可能希望您简单地在 master（比如说）上执行提交，然后将其挑选到您的分支。

This blog post 有更多信息。

请注意，它会在 master 分支上创建一个新的提交。如果，在大师，你运行“git log”，你会看到不同的哈希值提交消息。为什么？

这是因为 Git 如何对提交进行建模。提交是一个整个存储库的完整快照，以及给定的哈希 commit 反映了整个目录中每个文件的状态——它是他们所有哈希的哈希。

很明显，因为 master 分支没有所有的提交功能分支，修复错误时的完整快照应用将生成与完整快照不同的哈希在那里应用错误修复时的功能分支。因此，不同的哈希值。

但是当你将特性分支合并到主分支时，那不会事情;您进行错误修复的单个文件的哈希值会是一样的，因为它们的内容是一样的，所以有该文件的 master 将不会更新任何内容。

This blog post 详细介绍了类似情况以及如何使用git rebase 来避免此类问题。

【讨论】：

我原以为 Git 会意识到提交的内容是相同的，而不是重复的。这可能是一场精彩的表演。
查看上面的博客文章和我强调的摘录。
问题不在于有两个提交具有相同的更改。我们已经习惯了刚刚来自 Subversion 的情况。问题是当我们合并回来时，Git 两次应用相同的更改，因此我们在源文件中有两次相同的代码行。
博客文章的最后一段与我们所看到的不正确它说内容将是相同的，但事实并非如此。代码更改在文件中出现了两次。