我目前正在为一家使用Rational / IBM ClearCase的公司工作，以满足其众多的源代码控制需求，并且一直在寻找（当然主要是在我的空闲时间）if / how我们可以在将来迁移到git。
对于背景：我们在ClearCase中的许多项目都来自一个共同的基础＆＃34;然后我们根据需要分支的系统。大多数应用程序从严格基础开始，但客户端需要我们在其中分支文件，产生两个版本：一个基础，一个特定于客户端。由于客户特定版本具有自己的标签，因此每个应用程序可以彼此独立地发展。由于标签贴在每个更改文件的特定版本上，因此我们不必担心基础的更改会破坏客户的内容（因为他们会在不同的版本中进行修改，直到有人进入并且移动标签周围）。我们还通过标签跟踪代码的状态（发送给QA，等待客户反馈，生产中）。
据我所知，我为“基地”创建了一个新的回购协议＆＃39;版本和使用标签来定义状态，但处理客户特定的版本真的让我很困惑。我是否需要为客户端创建一个全新的repo并在基本版本和客户端版本之间手动移动更改，还是有更好的方法？使用标签是处理特定客户哪些修订版本或我遗漏某些内容的最佳方式？我已经看到了一些子模块的提及，但据我所知，它主要用于处理代码相关的到应用程序而不是大量相同的代码？
我的问题可能会解决，但我的所有git经验都是针对个人项目的。当您处理绿地项目时，（相对）容易理解行为，而不是在您尝试在现有工作流程上强加新工具时。
我很感激您的任何见解，感谢您花时间阅读我的问题！
答案 0 :(得分：0)
根据您的描述，Git非常适合处理贵公司的用例。您将基于现有的＆＃34; base＆＃34;创建一个新的Git仓库。系统。这个＆＃34;基地＆＃34;系统将对应于Git中的master分支。对于每个客户版本，您可以创建一个新的Git分支。分支是Git真正击败几乎所有其他版本控制系统的领域，因为它可以非常快速地创建新分支，同时需要非常小的存储空间。请注意，您不必为每个客户分支初始化新的Git存储库。
如果您需要在master（＆＃34; base＆＃34;）和任何客户分支之间移动特定功能，则可以使用git merge，git rebase甚至git cherry-pick来执行此操作。 Git rebase允许您在将功能分支带回主分支时维护功能分支的整个历史记录。如果您需要仔细保留为每位客户添加的每项功能的详细信息，这对您的组织非常有价值。
这个问题实际上已在Stack Overflow already上进行了彻底讨论。