从项目到项目，我们注意到我们的代码执行相同的功能，并且看起来几乎相同。 这使我们感到疑惑-我们不是通过重写同一件事来做额外的工作吗？ 我们开始从以前的项目中复制类，但仍然了解我们做错了什么是对的-只是将类从项目复制到项目中，我们可以轻松地丢失/替换/擦除某些内容，并且如果我们的团队领导了另外几个项目项目同时进行，那么在借用类中进行错误检测将需要对所有项目进行手动更改。 厌倦了踩此耙，我们决定需要一个公共代码，该代码将在所有项目中共享，并且对其中的任何更改都可以轻松提取。 是的，我们正在创建可重用组件的库！ 您将了解组织图书馆的不同方法，以及cat方法下的所有利弊：)
有几种方法可以组织我们的通用代码库：
- Android库（AAR / JAR）
- Git子模块
- Git子树
Android库（AAR / JAR）
适用于我们应用程序的任何库仅仅是以某种方式组织的许多类。 每次我们在build.gradle中连接某些Retrofit或Dagger时， 都会从一个库发布平台中将库作为aar / jar存档加载。 最受欢迎的图书馆发布平台是JCenter和MavenCentral。 库的开发人员在新版本的存储库中工作，当该版本准备发布时，他们将其发布在一个平台上，然后说：“嘿，我们发布了顶级库的新版本！”。 对于在项目中使用此lib的开发人员，要做的所有工作就是更改build.gradle中的版本并享受新功能。 方便吗 字错！
但是，如果我们的库正在开发并且每天由我们团队中不同项目的不同开发人员使用新功能进行更新，这种方法有多方便？ 让我们看看它在实际中的外观。
我们创建库的存储库，在其中提供一些功能，对其进行调试，并准备与我们的团队共享。 然后，我们将学习诸如JCenter，MavenCentral，Bintray，Jitpack.io之类的单词……所有这些都是发布库的平台。 现在，Android项目的主要平台是JCenter。 如果创建项目，您将看到在存储库的build.gradle （项目级别）中，指定了JCenter
repositories { google() jcenter() }
也就是说，如果开发人员想要连接您的库，那么将其连接到build.gradle模块级别就足够了。
对我来说，最简单的发布库的方法似乎是Jitpack.io，只需几个步骤，您的库就可以使用了。
如何组织图书馆的团队合作
如果我们创建了一个库并将其上传到存储库，那么我们团队的其余成员将只有收到的jar / aar存档。 为了使整个团队能够从事任何工作-每个开发人员都必须缩小库资源库并对其进行更改。
版本控制
在开发和使用库时，必须处理诸如版本控制这样的概念。 也就是说，我们要发布的库中的更改集必须由版本固定。 这将在将库更新到新版本时有所帮助，以了解由于采用的版本控制方案而造成的严重/重大更改。
检查项目中的库
为了验证所做的更改是否达到了我们的预期目的-必须检查项目中编写的代码的行为。 我们提高了库的版本，...这是此方法的瓶颈之一。 我们的库和项目位于不同的存储库中，这意味着我们不能仅在项目中获取库类。 我们有2个选项可签出新的库代码：
- 在示例库项目中创建一个模块，在该模块中将编写检查库功能的代码。 该选项很简单，但是有2个缺点：1.我们编写其他代码； 2.测试模块的环境与我们将在其中使用库的实际项目不同，并且如果我们出错，则在获得新版本的项目时会弹出该模块。
- 将更改发布到本地mavenLocal存储库。 通过这种方法，您可以在项目中获得一个新代码，但是不会为整个团队发布（但是您需要对设置进行一些修改）。
Git子模块
在以前的方法中，我们遇到了在项目的开发/调试阶段获取新代码的困难，因为库和项目代码位于不同的存储库和Studio项目中。 Git子模块方法还涉及使用单独的存储库，但允许主项目使用Git将库作为模块获取。 这意味着库代码将在项目中可用，所有更改立即在项目中可用！
如何运作
子模块允许您将一个Git存储库包含为另一个Git存储库的子目录。 这样就可以在项目内部克隆另一个存储库，并分别存储该存储库的提交。
简而言之，我们有2个存储库：一个项目和一个库。 项目存储库存储库代码和指向库存储库状态的链接。 因此，Git可以了解项目所需的库状态（版本）。
在此处阅读有关Git子模块如何工作的更多信息。
如何组织团队合作
在Git子模块方法中，库的团队工作组织如下：
- 在创建新项目或将库连接到现有项目时，将使用项目名称创建master的新Git分支。
- 当需要为库补充一些功能时，将创建任务的分支（来自项目分支），并在那里进行更改。
- 正在进行审查，项目分支中涌入了大量资金。 当键入足够的更改以发布版本时，将在库的master分支中的project分支的合并中创建一个池。
- 在库通过负责库的团队通过审核并注入主分支后，将通知剩余的项目团队有关已出现的库更新的信息，并将决定更新。
版本控制
当将池倒入master池中时，团队会收到库更新的通知，他们不知道新版本中的更改有多全局。 毕竟，使用Git子模块的方法不需要任何版本控制方案。 但是，通过引入版本控制方案可以轻松解决此问题。 所需要做的只是将更改的版本和描述写到master分支的请求池中，并在描述中添加。 然后，开发人员将了解他们现在可以真正升级到该库的新版本了多少。 听起来不错，但问题是：
是的，工作室不知道如何单独提交由子模块连接的库。 我使用SourceTree解决此问题。 该应用程序适用于Windows和Mac，而Linux适用于GitKraken。
Git子树
Git子树是Git子模块的增强版本。 在Git Subtree中，他们试图解决开发人员在使用Git Submodule时遇到的问题，该中心上有一篇不错的文章描述了工具之间的差异。 尽管它们的工作方式不同，但它们解决了一个问题。
结论
Git子模块/子树工具非常适合解决为参与多个项目的团队创建通用代码库的问题。 重要的优点之一是在更改库后立即在项目上验证新代码。 在这种情况下，将库发布到JCenter或MavenCentral的标准方法较差。 如果您决定将Git子模块/子树带到您的团队，请事先考虑版本控制方案，并创建规则/插件来控制版本控制。
大家都可以重用！