3

我正在努力解决跟踪我所有的更改之间的感知冲突，以便我可以弄清楚我昨天在哪里破坏了代码，并有一个受控的（高开销）代码审查过程来保持事情的理智。

我在一家非常传统的 ClearCase 商店工作。所有签入都需要代码审查，我没有创建私有分支的权限。为了满足对版本控制我所有日常工作的原始冲动，我在 clearcase 视图中使用 mercurial

我寻求集体智慧，了解什么是跟踪我的日常变化的最佳方式，同时尽可能与明确的案例人员一起玩。

4

5 回答 5

3

所有签入都需要代码审查，我没有创建私有分支的权限。

我们也在使用 ClearCase 并且有开发分支（不是每个开发人员一个分支！，而是一个涉及一个到几个开发人员的“开发工作”分支）以便及早检查。
但规则是：它必须编译并通过基本单元测试。如果 CI（持续集成工具）“变红”，则该开发工作团队中的每个人都会停止。并帮助解决错误。
这样，我们提早提交并提早修复。

然后，合并分支有助于报告已通过更严格控制（代码审查或一些高级测试）的代码。

这一切都是为了拥有一个合并工作流程。

对于非常中间的提交，我在我的 ClearCase 视图中使用 Git（在 ClearCase 视图中使用一个简单的“ git init”，并且您已经准备好自己的 Git 工作区！）。
任何数量的私有分支都可以存在于这个工作空间中，帮助进行私有实验。
A " git bundle" 帮助我将该 Git 工作区的当前状态备份到我的工作站外保存的文件中。

你如何处理从一个清晰的案例视图转移到另一个？

这是合并工作流程的缺点：使用 ClearCase，您必须设置与 Streams（使用 UCM）或分支（非 UCM）一样多的视图。我们使用动态视图进行合并及其解决方案，然后使用快照视图进行开发。
由于我们对不同的流有不同的视图，我们可以通过简单的WinMerge轻松比较两种不同的开发工作。

于 2009-06-12T03:52:41.330 回答
1

你和你的同事讨论过你的问题吗？他们应该面临同样的问题，也许有一些好主意。
我会尝试请求您的老板允许创建分支机构 - 或者至少获得一个私人分支机构。但是使用这个分支并不会改变你当前的问题。当您转储 4780 行代码进行代码审查时，没有人关心它们来自哪里。
您真的应该尝试尽早并经常检查。如果您需要在私有分支中进行实验 - 很好。但是一旦你得到结果，你应该提交它并获得代码审查。
使用 mercurial 听起来不像是“官方方式”——你的老板知道吗？是否定期备份？这就是为什么我会去私人分支。在遇到麻烦之前让您的工作流程正式化。

于 2009-06-12T00:09:05.627 回答
1

尽早并经常提交。您的同事将欣赏较小的代码审查，并且更改将更易于管理和合并。专注于咬掉一小部分工作，然后付诸实施。

您在跟踪日常变化方面遇到什么问题？做一个 clearcase diff 会告诉你你已经改变了什么。

于 2009-06-12T00:12:55.307 回答
1

我和 tanascius 和 Stephen 在一起。仅仅因为您使用 mercurial 来跟踪个人更改并不意味着您不能更早地提交给 ClearCase 进行审查。问题不在于反复无常或 ClearCase，它提交了 4780 行代码供某人查看。

我还在一家拥有严格审查政策和 Perforce 的商店工作。我使用 git 来跟踪本地的小更改，但我仍然会在更改变得很大以供我的同事理解之前发送审查。

尽早提交并提交少量。

于 2009-06-12T02:29:16.040 回答
1

我不熟悉 ClearCase，因此我的回答范围只会是mercurial。

我考虑您的以下问题：即使步骤不完整/损坏，我也会在本地跟踪更改以便能够保存我的步骤，然后我提交整个图片以供审查，但结果往往是提交太大且不易审查. 我对么？

为了解决这个特殊问题，我使用Mercurial Queues。这些队列允许您基本上编辑本地未推送的提交，重新排序并将多个补丁折叠成一个/或将一个提交拆分为小的可读块。在阅读更多关于它的信息之前，这里是我关于如何使用它们的建议：

  • 你做你平时的工作。根据您自己的个人标准，按照您的意愿进行简单的小提交，因为您的同事不会看到这些提交。必要时打破构建，做任何你想做的事。
  • 一旦你了解了整个大图，4780 行长的补丁，暂停。
  • 在您的 mercurial 队列中导入您的本地提交。
  • 在本地查看您的连续提交，并问自己“我怎样才能使它可读？”。例如，您将识别同一功能上的提交组。或者多次尝试解决相同的问题。
  • 一旦你确定了有意义的提交组，重新排序你的补丁（重新排序你的提交：这是 Mercurial Queues 允许你做的）。在此之后，fold类似的补丁在一起。例如，如果您有连续尝试 n、n+1 和 n+2，其中 n+1 部分撤消 n，并且 n+1 是拼写错误 oneliner... 只需将三个提交合并为一个有意义的提交“这个提交完全修复了问题 #1212313 做这个和那个”。
  • 在重组你的提交堆/队列之后，你最终会得到一系列有意义的小补丁。因为它们很小，所以很容易阅读。只需将一系列有意义的补丁提交给你的同事：如果每个补丁都是干净的、小的，并且解决了一个问题，那么审查时间将非常短。
于 2009-06-13T14:37:48.090 回答