将所有这些库放到我的仓库并推送它们(当新版本到来时,也更新它们)是不是一个好的做法？或者我的项目仓库应该只包含项目文件(代码,资产等)？
优点：
>建筑是如此简单,因为我拥有所有我需要永远关闭的东西
>添加的库意味着我使用这些版本测试了我的项目,因为其他(旧的/更新的)可能会产生一些问题
缺点：
>项目回购膨胀
>必须手动更新依赖项
>如果我想粘贴也建立版本,我将不得不粘贴很多
>文件,它会占用大量空间,所以可能坚持使用源代码
只要？
>某些图书馆可能没有那么好的许可证并直接使用它们(除了要求用户自己获取有效的图书馆)并将它们放入我的仓库可能会造成一些麻烦
>有更多的项目来保持依赖关系意味着我必须同时为所有项目更新它们(例如,如果我根据当前项目(它的库)制作一些其他项目,那么它们都将具有相同的依赖性)
解决方法
答案很长：
在您质疑是否适合将代码包含在存储库中之前,您应该询问是否适合严格控制依赖关系或更轻松.
答案取决于您分发项目的方式,客户/用户的需求,是否需要对依赖项进行任何源代码更改以及任何其他项目要求.
例如,假设您正在销售硬件设备,而您的代码是设备的固件.在这种情况下,您可能希望严格控制依赖项(需要非常特定的版本).这使您可以完全控制整个系统,从而简化系统测试,如果您的设备受到某些安全性,安全性或可靠性要求(例如,它是医疗设备或发送给Pluto的探测器),这一点非常重要.通常,如果以二进制或文件系统映像的形式分发产品,则可能需要使用固定依赖项.
如果您希望用户能够动态链接其系统附带的任何版本的依赖项(这有很多原因,包括安全更新),那么您可能希望放宽要求.明确支持哪些版本,将自己限制在这些版本中可用的文档化API,使用工具来强制执行要求(如果依赖项太旧则出错),并针对尽可能多的依赖项版本测试代码.
一旦知道要控制依赖关系的紧密程度,就可以选择用于管理它们的机制.您可以使用像Apache Ivy这样的工具来自动获取依赖项,使用GNU Autoconf来强制执行特定版本,或者您可以将代码拉入Git存储库并自行构建.具体选择并不重要;使用满足您要求的任何内容,对您和您的用户来说都是最简单的.
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
