如何维护由多个人开发的项目的多个或单个存储库？

Question

不久前，我问项目的两个版本控制设计之间有哪些缺点和优点:多个存储库和单个存储库

1. 当一个项目有一个git存储库并由多个人同时开发时，
   • 有哪些方法可以管理不同开发人员的贡献，使他们的贡献保持一致，并成功地构建项目？

2. 当一个项目被分割成多个git存储库(每个存储库用于一个不同的库或应用程序)，并且项目中的库和应用程序由多个人同时开发时，
   • 有什么方法(在Linux、Windows或跨平台下)来维护项目中的库和应用程序，以使它们保持一致并成功构建？
   • 版本化或语义版本化 (例如GitVersion)是解决方案吗？

谢谢。

Answer 1

你正在混合应用程序和librairies，而它们不应该。

库有自己的路线图，这可能会受到请求的影响，当然，每次发布新特性时，版本都会发生变化。但是，它与使用它的应用程序无关。当您升级库的版本以具有新特性时，您必须测试应用程序。

如果你需要一个工具来管理你的依赖关系，它们是成堆的: Maven，Gradle，.如果出于任何原因你不能使用它，看看它们是如何工作的。

我认为你真正关心的可能更多的是这样的东西：

我必须管理多个共享库的应用程序，所有这些都在不断发展，如何确保我能够安全地继续发展所有的东西而不失去控制？

我可能没有足够的经验，这篇文章也没有足够的个性，需要一个长时间的解释，所以我将保持这个简短：

• 版本:一个正确的版本是绝对必要的，至少主要/次要水平。最终主要/次要/错误修复。
• 作用域:每个库/应用程序必须具有每个人都能理解的明确定义的范围。因此，人们知道他们可以从一个图书馆得到什么，什么是不存在的，什么是不会的，因为它不在他们的范围之内。
• 向后兼容性:每个共享的库/框架都必须确保其最佳的向后兼容性。不要删除代码，使用脱毛。因此，人们会看到编译器发出警告，说他们使用的是去实践的方法，这可能会破坏下一个主要版本。
• 破坏变更:如果在库/框架中引入了一个突破性的更改，因为这是要走的路，那么它必须被记录下来，并且通常是主要版本发行版的一部分。因此，您可以继续提供bug修复，通过小版本支持很少的功能，而不必引入中断的更改。
• 文档:大型项目的所有部分都必须有文档记录(不需要以冗长冗长的文本形式进行)：破坏更改、功能(什么？从哪个版本?)，错误修复。
• 自动非回归测试:要确保向后兼容性，每个特性都必须有自己的回归测试，每个修复的bug都必须有自己的测试(最终不止一个)。
• 图表:维护几个显示组件之间关系的图表，这样就省去了在页面长度中进行同样操作的麻烦。您不需要为每个应用程序记录每个函数调用的库，这太过分了。只是他们有一个依赖性，并最终有一些上下文，它是在哪里使用的。