在 A 依赖 B 和 B 在 C 的情况下并行处理 A、B 和 C 的完美工作流程是什么？答案

【问题标题】：What is the perfect workflow to work on A, B & C in parallel where A depends on B and B on C?在 A 依赖 B 和 B 在 C 的情况下并行处理 A、B 和 C 的完美工作流程是什么？
【发布时间】：2014-01-02 07:39:59
【问题描述】：

我想知道如果一个人需要并行处理项目 A、B 和 C，其中 A 依赖于 B，B 依赖于 C，那么完美的工作流程是什么。

目前，我将所有内容都放在一个存储库中，这加快了早期开发。所以我的工作目录是这样的：

/A/
/A/B
/A/B/C

所以A 是推动发展的项目，但这也意味着B 和C 是并行发展的。

但是，我想单独发布 B 和 C 项目，因为它们对其他人非常有用。

但是，我不知道如何在不破坏开发速度的情况下做到这一点。 npm 非常适合分发和依赖管理，但在开发过程中，您绝对不想为了让文件在您机器上的不同文件夹中更新而在互联网上临时移动版本:)

另一方面，您也不想手动复制它们。哎呀，所有这些我必须切换目录才能在 B 上工作，现在将其复制到 /A/B 很可怕，而且似乎容易出错。

所以，git submodule 似乎是答案，因为它本质上正是在实现这一点：您将保持目录布局不变。然后，当您对B 中的文件进行更改时，您可以直接在A 中测试它们，而无需复制某些内容。当你认为它已经准备好时，你可以从三个不同的文件夹中提交和推送。一切都自动进入三个不同的存储库。似乎是天堂，但每个人都讨厌git submodule，原因各不相同。

在处理 grunt 插件时，我遇到了几乎相同的问题。我在它自己的存储库中有 grunt 插件，然后当我处理它时，我必须将它复制到我使用它来驱动开发的项目之一中。然后在一天结束时，我将它复制回 grunt 插件工作目录，进行提交并推送它们。感谢上帝，我不是成千上万个 grunt 插件的作者，所以我可以处理这个问题，但是对于我目前正在从事的这个项目，我肯定想找到一个更好的解决方案。

所以我想知道，答案是什么？

【问题讨论】：

标签： javascript git workflow npm

【解决方案1】：

请注意，Git 子模块指向外部存储库的特定版本，即特定提交。

要将所有 Git 子模块更新到最新版本，您仍然需要run a command：

git submodule foreach git pull origin master

根据您的情况，您可以使用 npm 代替 Git 子模块。在这种情况下，您只需在 package.json 中列出您的依赖项，然后在存储库的根目录中运行 npm install 以获取它们。如果更新了依赖项并发布了新版本，您只需再次运行npm update，它将匹配package.json 文件中设置的版本要求。你也可以use npm to point to a specific commit，就像 Git 子模块的工作原理：

{
  "devDependencies": {
    "dependency-a": "git://github.com/the-user-name/the-project-name.git#b3c24169432a924d05020c85f852d4a1736e66d4"
  }
}

或者，如果您想使用依赖项的前沿版本，例如给定 Git 存储库的 master 分支，您可以使用：

{
  "devDependencies": {
    "dependency-a": "git://github.com/the-user-name/the-project-name.git#master"
  }
}

【讨论】：

有趣。这是否意味着我可以使用 npm 甚至指向本地计算机上的存储库的依赖项？所以我可以有一个package.json 用于本地开发。因为如果我在火车上，我不希望我的工作流程中断，因为它依赖于有效的互联网连接。
是的，您也可以指向本地存储库：{ "devDependencies": { "dependency-a": "*" } }，然后使用npm link /path/to/dependency-a

【解决方案2】：

我已经尝试了所有这些工作流程，并认为 git 子模块不是答案。我的主要原因是他们在 scm 级别将项目耦合在一起，并且对于这种耦合发生在修订历史中的确切位置并不直观。尤其是在头部分离的情况下。我依靠 npm 结合 npm link 和 git URL 进行依赖管理。当我想在本地测试某些东西时，npm link 很棒。 git URL 非常适合在拉取请求期间解决依赖关系。最终，我总是想要一个已发布的模块，其版本号可以与 git 标签匹配，以供将来参考和问题跟踪。我使用npm version 一步完成。允许项目在我的开发周期中以不同程度的耦合相互依赖。

【讨论】：

【解决方案3】：

使用git subtree 会是这里的答案吗？这篇文章Alternatives To Git Submodule: Git Subtree 很好地解释了使用git subtree 与git submodules 的优缺点。

【讨论】：