当我的雇主使用VSS时，我怎样才能最好地使用Git？

Question

我将与VSS一起工作，但我对GIT的效率和勤奋程度要高得多。

我必须适应VSS的工作流程，并在VSS中保持良好的历史。VSS的标准工作流程是

• 得到工作副本
• 做工作
• 右键单击文件夹->显示差异
• 在这个视图中：
  • 签出(不覆盖本地更改)
  • 检查(保持写访问权限)
  • 添加带有特定模板的注释

就我个人而言，我认为这已经是VSS计划的工作流程的一个侧面，并且有可能覆盖其他人所做的任何更改。

我认为我可以防止可能的覆盖，但是在这个工作流中还有什么潜在的问题我应该知道吗？

-编辑--

值得一提的是，在这种情况下，VSS只用于遗留项目，它在很大程度上受到使用它的人和维护它的人的鄙视。

80%的人使用它，与另一个版本控制系统一起使用(一些git，大部分是变化无常的)

当我问系统管理员我的工作流程应该是什么时，我被告知“不管你喜欢什么”。我让他们跟上我的想法，他们对结果很感兴趣。

我不建议使用任何极端的方法(如下面的脚本)，除非您已经与维护VSS的人讨论过它。

Answer 1

你忘了什么- VSS的标准工作流是：

• 结帐工作副本
• (可选地抱怨其他人有一些文件被锁定)
• 做文件的工作
• (可以选择处理文件被锁定的投诉)
• 检查档案。

您需要了解的是，虽然您可以获得一个只读副本，但您不能更改文件或提交更改，除非您有一个签出锁文件，以便没有其他人可以修改它们。因此，虽然通过定期将工作副本迁移到git来独立工作的概念是值得称赞的，但我怀疑它在实践中是否有效。您必须在最后一刻执行结帐(锁定文件)，将VSS中的这些最新文件合并到您的git中，然后签入生成的合并到VSS.If --其他人正在处理这些文件--当您决定要合并时，您必须等待它们完成。此外，您还必须锁定所有文件，因为您不会(很容易)知道自您上一次只读副本以来，哪些文件已经更改。

最好和你的同事一起组织你正在做的工作，或者你正在处理的文件，然后按照它的意图使用这个工具。重要的是沟通和组织团队的开发工作，而不是像使用git那样独立地工作。

Answer 2

我会回答，“别这么做。”工作流程是完全不同的，而且您不会考虑其中之一，最终会导致您自己，或者更糟的是您的团队感到非常悲伤。学习VSS，如果没有比让你更欣赏其他VCS更多的话。

Answer 3

--更新--

我一直在使用这个bash脚本，取得了很大的成功:)

另外，我现在推荐2个目录，而不是2个分支。它很干净:)

如果您有您的VSS管理员的支持，那么您可以遵循如下所示。

否则，您可以将git用于您自己的分支和一般工作流，并按预期使用VSS，但在这种情况下，我建议您进行干净的分离，而不是我所追求的互操作解决方案。我的解决方案更适合作为迁移步骤，但即使这样，我也会谨慎使用。

• 从VSS获取工作副本
• git init
• 创建"vss_branch“分支
• 从师父那里分出一个“开发”分支
• 每个特性/bug的分支开发
• 在功能完成时，重基以清除评论(如果我一直很顽皮)
• 功能/bug准备就绪时，合并到dev中
• 测试开发
• 如果所有好的合并发展成为主人
• 将我的主分支与VSS 同步
  • 切换到vss_branch
  • 从可视化源安全获取工作副本
  • 将"ss历史“作为注释提交到vss_branch中
  • 将vss_branch拉到主机上
  • 测试主机与主机同步VSS
  • "ss结帐“文件我已更改(不要覆盖工作副本)
  • 已更改的"ss签入“文件(添加git注释作为标签)

• 把主人拉进开发中

我尝试坚持我们的VSS工作流程，但对独立的VSS git分支更加健壮一些，我从来没有推动过。