Git cherry pick和datamodel完整性
Git cherry-pick和datamodel完整性问题的出现原因是cherry-pick操作不会存储父级ID，因此无法知道过去已经cherry-pick的提交，从而无法避免重新引入这些提交。
解决这个问题的方法是使用rebase来避免重复提交。具体的方法可以参考链接http://davitenio.wordpress.com/2008/09/27/git-merge-after-git-cherry-pick-avoiding-duplicate-commits/中的说明。该链接提到了如何使用rebase来避免重复提交。
然而，即使在rebase之后，cherry-pick的提交仍然会出现。至于为什么会出现这种情况，作者表示自己还不太理解rebase的工作原理。
在这篇文章中，《避免重复提交》提到了一个关于Git cherry pick和数据模型完整性的问题。文章中描述了一个场景：假设我们有一个主分支master和一个分支b，现在我们急需将分支b中的提交b1和b3合并到主分支master中，但不需要合并b中的其他提交。为了实现这个目标，我们可以切换到主分支master，然后使用git cherry-pick命令来挑选提交b1和b3。这样的结果是，主分支master上会出现新的提交b1'和b3'，而分支b的提交历史保持不变。
然而，如果在主分支master上再进行一次提交，然后将分支b合并到主分支master中，就会出现问题。合并后的提交历史中，b1和b3的更改会出现两次。为了避免这种情况，可以使用git rebase命令而不是git merge命令。通过执行git rebase master b，可以将分支b上的提交应用到主分支master上，而不会出现重复的提交。最后，再执行git merge命令将分支b合并到主分支master上，得到最终的提交历史。
对于问题中提到的“即使在rebase之后，cherry pick的提交还是会出现吗？”这个问题，答案是不会。根据git rebase的文档，如果主分支上已经包含了你所做的更改，那么这个提交将会被跳过。所以在执行git rebase命令后，cherry pick的提交将不会再次出现。
通过git cherry master命令可以检测一个提交是否已经存在于主分支上。这是在topic分支上执行的，如果你想知道一个提交是否已经存在于主分支上，可以使用该命令。
总结起来，解决Git cherry pick和数据模型完整性问题的方法是使用git rebase命令而不是git merge命令来合并分支，避免重复的提交。