我们刚刚从 Subversion 切换到 Git。
今天早上出现的问题是,我们从一个分支中挑选了一个提交到 master 中,这样 maser 就会有一个错误修复。然后我们将master合并回分支。
当我们尝试编译时,所有来自精心挑选的提交的添加都在代码中出现了两次。
精心挑选的提交包括添加几行代码,最终在代码中出现两次。幸运的是,它们是完整的函数,因此会引发编译器错误。
从来没有发生过冲突。
我们如何避免这种情况。这是一个大问题。
谢谢。
我们刚刚从 Subversion 切换到 Git。
今天早上出现的问题是,我们从一个分支中挑选了一个提交到 master 中,这样 maser 就会有一个错误修复。然后我们将master合并回分支。
当我们尝试编译时,所有来自精心挑选的提交的添加都在代码中出现了两次。
精心挑选的提交包括添加几行代码,最终在代码中出现两次。幸运的是,它们是完整的函数,因此会引发编译器错误。
从来没有发生过冲突。
我们如何避免这种情况。这是一个大问题。
谢谢。
从 Git 的角度来看,cherry-pick 是一种不同的提交。即,当您合并回来时,您将在最初应用的基础上合并回一个新提交。
也就是说,您使用 hash 创建了一个提交ABC
。你挑选它,创建一个新的 commit DEF
。然后合并回来DEF
与 一起应用ABC
。
在上面,我可能希望您只需在 master 上执行提交(例如),然后将其挑选到您的分支。
这篇博文有更多信息。
请注意,它会在 master 分支上创建一个新的提交。如果在 master 上运行“git log”,您将看到相同提交消息的不同哈希。为什么?
这是因为 Git 如何对提交进行建模。提交是整个存储库的完整快照,给定提交的哈希反映了整个目录中每个文件的状态——它是所有哈希的哈希。
很明显,由于主分支没有来自功能分支的所有提交,因此在应用错误修复时它的完整快照将生成与错误修复时功能分支的完整快照不同的哈希值应用在那里。因此,不同的哈希。
但是,当您确实将功能分支合并到主分支时,这无关紧要;您进行错误修复的单个文件的哈希值将相同,因为它们的内容将相同,因此该文件的主文件将没有任何更新。
这篇博文详细介绍了类似的情况以及如何使用git rebase
来避免此类问题。