1

我正在与一位设计师合作开展一个名为“已验证帐户”的项目

我正在一个名为的分支上开发，verified_accounts而设计师在一个名为chris_verified_accounts. 我们一直在定期合并彼此的更改，当项目完成后，我们将合并verified_accounts到master

然而，所有这些合并都导致了一堆垃圾/重复提交。例如：

http://dl.dropbox.com/u/2792776/screenshots/2012-03-02_1024.png

提交 (1) 是仅包含提交 (2) 的拉取请求的合并。这意味着这些提交本质上是相同的（它们具有相同的差异等）。同样，commit(3) 是只合并 commit(4) 的合并，意思是 3 和 4 也基本相同

管理这些相同提交的最佳方法是什么？即，对于我的代码中的每个功能更改，我想要一个关联的提交。这样，如果我在评论一个变更集，我可以确定我在正确的地方发表评论（而不是评论另一个 dupe-y 提交的完全相同的变更集）

这种事情的最佳做法是什么？

4

2 回答 2

3

由于您合并，您将获得合并提交，这在您合并分支时是不可避免的。你可以做的是同时拉动和变基：

git pull --rebase
于 2012-03-02T18:41:15.473 回答
2

最佳实践是将这些提交视为它们的本来面目：合并提交。不仅仅是“重复提交”。（事实上​​，它们根本不是重复提交。）它们包含分支合并到另一个分支的信息。当你试图拥有一个线性历史（让我们面对现实——是无法处理分支，特别是以理智的方式合并的系统的残余）时，你不可避免地会丢失有关源代码如何形成的信息。现在。合并提交是项目历史的重要组成部分，允许您查看哪些提交在哪个时间点属于哪个分支。它允许您在编写每个分支后几年也可以关注它们。如果提交中有任何可疑之处，您可以使用该上下文信息来重新理解您这样做的原因。

请不要通过试图让它在某些可视化工具中看起来不错来人为地阻碍您的存储库。尝试利用分支和合并的全部力量。

（是的，我喜欢 Git。还有分支。还有合并。）

于 2012-03-02T19:25:29.467 回答