Git复制代码

我们刚刚从Subversion切换到Git。Git复制代码

今天早上出现的问题是，我们选择了一个分支到主的提交，所以maser会有一个错误修复。然后我们将主人合并到分支。

当我们尝试编译时，所有来自樱桃选择提交的添加都在代码中两次。

挑选的提交包括添加了几行代码，最终在代码中两次结束。幸运的是，它们是完整的函数，所以它抛出了一个编译器错误。

从来没有发生冲突。

我们如何避免这种情况。这是一个主要问题。

谢谢。

来源

2013-01-09 James Baker

你应该尝试'git-flow'工作流。（说明：http://nvie.com/posts/a-successful-git-branching-model/工具：https：// github。com/nvie/gitflow）在这种情况下，“正确”的方式会为旧代码中的错误（不是在特性分支上开发的错误）创建一个新的分支，并将其合并到主机和功能中分支 - 然后git可以正确跟踪提交。 – millimoose

@millimoose nvie工作流程似乎并不适用于所有情况。开发分支似乎不太适合持续交付。 – ArtB

不幸的是，挑选樱桃有时是唯一的答案。很多时候，我们会发现一个影响所有分支的bug，我们需要将修复放在所有分支中，但我们不希望来自任何分支的其他更改。这就是为什么樱桃采摘首先存在。 –

从Git的观点来看，Cherry-pick是另一种提交方式。即当您合并时，您将合并回原始应用之上的新提交。

也就是说，您使用散列ABC创建提交。你挑选它，创建一个新的提交DEF。然后合并回DEF和ABC。

在上面，我可能会希望你简单地对master进行提交（比如说），然后把它交给你的分支。

This blog post有更多信息。

请注意，它会在主分支上创建一个新的提交。如果在 master上运行“git log”，您将看到与提交相同的消息的不同散列。为什么？

这是因为Git如何模拟提交的内容。提交是整个存储库的完整快照，并且提交的哈希提供了反映整个目录中每个文件的状态 - 它是所有哈希的散列值的。

所以很明显，因为主分支机构不具有所有提交的从的特性分支，它的一个完整快照在修正错误应用将产生不同的哈希比的功能进行完整的快照时间当时在那里应用了bugfix。因此，不同的哈希值。

但是，当你做合并功能分支到主，这不会问题;你修补程序的单个文件的散列值将是相同的，因为它们的内容将是相同的，所以将不会在该文件的主文件上更新。

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

来源

2013-01-09 14:58:26

我原以为Git会意识到提交的内容是相同的，不会重复。这可能是个不错的选择。 –

查看上面的博文和我突出显示的摘录。 –

问题不在于有两个提交具有相同的更改。我们已经习惯了来自Subversion的。问题是，当我们合并回来时，Git应用相同的更改两次，以便在源文件中有两次相同的代码行。 –

回答

相关问题