2

我是源代码控制的新手。我现在正在一个团队中工作，我们正在使用 Perforce（GUI版本 P4V）。我已连接到我团队的存储库，并且在我知道我有一些工作后，我将新文件或我的更改提交到存储库。

这一切都很好而且很花哨，但我不想经常将东西提交到他们的存储库。他们使用所有这些文件运行频繁的构建，我发现最好在它们完成并正常工作时向它提交内容，而不是在此过程中逐步增加。

我的问题：我发现我经常在文件中搞砸一些东西，却不知道自己搞砸了什么。如果我可以恢复到所述文件的早期工作版本，那就太好了。但是，以我使用团队源代码控制的方式，这是不可能的。我想设置我自己的团队源代码控制的本地版本，我可以更频繁地提交事情（但他们不会真正看到）。我希望它是相同的，但我的提交仅供我个人使用（因此，如果它们不完美，也不会弄乱它们的构建）。

我基本上想要一个存储库的克隆，我可以在其中签入供我个人使用的东西，然后再将其签入他们的存储库。

我怎样才能做到这一点？我不得不承认，我发现使用源代码管理有点令人困惑。

4

3 回答 3

5

要完全回答您的问题...使用分支！

就是说这里是交通规则！

  1. 第一条规则 - 早点入住 - 经常入住..
  2. 第二条规则 - 见第一条！

我完全可以理解你，我（几年前）对此感到非常沮丧，所以让我来帮助你。假设我们有以下数据结构

//depot/shared_project/...

因此，如果我了解您，您都在使用这棵树，并且您希望自己的沙箱能够实施我制定的规则。如果我们这样做怎么办？

让我们为这种混乱添加一些秩序。我们将在其中插入几棵树以结束

//depot/shared_project/dev/...
//depot/shared_project/release/...

然后作为一个新成员，从​​ dev 分支来到他们自己的沙箱签入，然后发疯。当他们准备好时，将他们的更改合并回 dev。当开发准备好发布时，我们将其整合到发布中。这使开发人员保持理智，并允许每个人都可以利用收益。那么我们如何到达那里。

行动

  1. 发送一封电子邮件，说每个人都在周五晚上在那里签到代码。我们将重新安排一些东西，客户规格需要在周一进行一些修改。你不必这样做，但它会保持简单。

  2. 星期五晚上来。。确认每个人都检查了一切。。

p4 opened -a //depot/shared_project/...

  1. 确保您的客户规范包含完整的树 //depot/shared_project/...

  2. 让我们移动树结构..

p4 edit //depot/shared_project/...
p4 move //depot/shared_project/... //depot/shared_project/dev/...
p4 submit -d "Small move to a real dev environment" //depot/shared_project/...

现在已经完成了，让我们谈谈工作流程（你如何使用它..）

  1. 创建我们的个人分支..
p4 integ //depot/shared_project/dev/... //depot/shared_project/casey_dev/...

  1. 在非功能代码等中进行更改检查。

  2. 准备好并重新合并并解决冲突。

p4 integ //depot/shared_project/casey_dev/... //depot/shared_project/dev/...
p4 resolve
  1. 提交！！

希望有帮助

于 2011-07-15T00:19:15.210 回答
1

分支确实有效，只需在仓库中的某处创建一个分支，然后在那里检查您的更改。准备好后，从您的分支集成回主分支。

此外，如果您可以等待几个月（左右），那么真正的私人分支机构就会出现。他们称之为p4sandbox

于 2011-07-15T17:30:15.507 回答
0

这对于集中式版本控制系统（例如 Perforce、SVN 等）来说问题更大，因为没有太多个人、私有分支的概念。

最好的解决方案是将它吸干，并将您的更改检查到公共但单独的分支 - 或尝试找到其他解决方案，例如在本地使用 git 管理您的文件并定期将您的文件检查到 perforce，但这条路很痛苦，并且需要两个版本控制系统的专业知识。

至少，Perforce 相当擅长合并，因此您应该能够相当舒适地使用分支，并根据需要将其合并到主代码行中。但是，您的个人历史将是可见的。您选择的版本控制无法解决这个问题

于 2011-07-15T00:14:36.817 回答