我们正在内部开发服务器上使用git（Gitlab）进行工作。
我们有一个项目经常作为许多其他项目的基础。
作为一个基本示例，我们将采用基本代码（登录，会话，跟踪事件等）并添加特定于事件的代码，以更好地满足特定事件的需求。每个事件都是自己的部署，并在服务器上有自己的空间。
处理这样的代码库的首选策略是什么？
我看到两个选项：
选项1 分支 - 对于每个部署，克隆基础仓库，切换到特定于事件的分支，然后在必要时将基本代码范围的更改（基本代码的重构等）合并到分支。
这看起来很好，但有点乱（当有200个事件时怎么办？）。想要处理基本代码的人最终会立即为大量事件提取代码。这些事件通常伴随着图像，电影，声音文件，这些资源非常昂贵。
选项2 单独的回购： 对于每个部署，克隆repo，将特定于事件的代码推送到它自己的repo，并根据需要提取origin（基本代码）以合并更改。
我更喜欢第二种想法 - 浏览回购将更清洁，更容易。我的活动屏幕不会是每个事件的混乱和提交它。
值得一提的是，每个活动最有可能至少有一个开发和生产部门。
这种情况是否已经建立了实践？
还有其他/更好的选择吗？
如果我可以提供更多信息，或者更好地解释这种情况的细节，请询问。
感谢。
答案 0 :(得分：1)
您的选项2听起来不错。这正是你在github上称为fork的原因。
您真的需要更改每个事件的基本代码吗？也许更清晰的选择是将你的基础变成一个库，并使每个事件只使用该库而不是包括整个代码。 - 但根据你的语言和目前的设置，这可能有点工作......
答案 1 :(得分：1)
你的选择2是有道理的。
它类似于分叉：你的基础项目是“上游”，依赖项目是它的衍生物，独立地向不同方向，“下游”。像Ubuntu一样是基础（上游），Kubuntu，Xubuntu和Edubuntu来自（下游）。很多开发都进入了基础，并在下游合并，而一些特定的开发只涉及衍生产品，彼此独立。
当有这样一个干净的设置时，下游回购可以从上游通过VCS操作获得变化，这是很棒的，现实生活中并非总是如此。它在Ubuntu示例中的工作方式与此类似，但Ubuntu本身是从Debian派生的，我不认为VCS级别存在连接。