我是源控制的新手。我现在在一个团队工作，我们正在使用Perforce（ GUI 版本P4V）。我已经连接到我的团队的存储库，在我知道我有工作之后，我将新文件或我的更改提交到存储库。
这都是好事和花花公子，但我不想经常向他们的存储库提交。他们使用所有这些文件运行频繁的构建，我发现最好在它们完成并正常工作时提交它，而不是在整个过程中递增。
我的问题：我发现我经常在文件中搞砸了一些东西并且不知道我搞砸了什么。如果我能够恢复到所述文件的早期工作版本，那将是太棒了。但是，通过我使用我的团队的源代码控制的方式，这是不可能的。我想建立我自己的团队源代码控制的本地版本，我可以更频繁地提交事情（但实际上并不是所有人都能看到）。我希望它是相同的，但我的提交仅供我个人使用（因此如果它们不完美则不会弄乱它们的构建）。
我基本上想要一个克隆存储库，我可以在将其存入个人用途之前将其检入存储库。
我该怎么做？我不得不承认，我发现使用源代码控制有点令人困惑。
答案 0 :(得分：5)
要完全回答您的问题...请使用branches !!
这就是说这里的规则了！
我可以完全与你联系，我（多年前）对此感到非常沮丧，所以让我帮助你。让我们假设一分钟我们有以下数据结构
//depot/shared_project/...
所以，如果我理解你，你们都在这棵树上工作，并且你希望自己的沙箱能够实现我已经规定的规则......如果我们这样做怎么办？
让我们为这个混乱添加一些顺序。我们将在其中插入几棵树以结束
//depot/shared_project/dev/...
//depot/shared_project/release/...
然后作为一名新成员从dev开始到他们自己的沙箱签到，并坚持下去。当他们准备好时，将他们的更改合并回dev。当dev准备发布时，我们将其整合到发布中。这样可以保持开发人员的理智，并让每个人都能利用好处。那么我们如何到达那里。
操作
发送电子邮件，说每个人都在周五晚上办理登机手续。我们将重新整理东西，客户端规格将需要在星期一进行修改。你不必这样做，但它会保持简单。
周五晚上来。确认每个人都已检查过所有内容..
p4 opened -a //depot/shared_project/...
确保您的客户端规范包含完整的树// depot / shared_project /...
让我们移动树形结构..
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/...
现在已经完成了，让我们谈谈工作流程（你如何使用它......）
p4 integ //depot/shared_project/dev/... //depot/shared_project/casey_dev/...
更改非功能性代码等。
准备好并将其合并并解决冲突。
p4 integ //depot/shared_project/casey_dev/... //depot/shared_project/dev/... p4 resolve
希望能帮助
答案 1 :(得分：1)
分支可以正常工作，只需在软件仓库中的某个位置创建分支，然后检查那里的更改。准备就绪后，从分支机构集成到主分支机构。
此外，如果你可以等待几个月（左右），真正的私人分支机构将会出现。他们称之为p4sandbox
答案 2 :(得分：0)
对于集中式版本控制系统，例如Perforce，SVN等，这更成问题，因为没有太多的个人私有分支的概念。
最好的解决方案是将其搞砸，并检查您对公开但独立分支的更改 - 或尝试找到其他解决方案，例如在本地使用git管理文件并定期检查您的文件到perforce，但是路径是痛苦的，需要专业知识的版本控制系统。
Perforce至少在合并方面相当不错，因此您应该能够合理地使用分支并将其合并到主代码行中。但是，您的个人历史将是可见的。您可以选择版本控制