我有一个包含2个存储库的项目。存储库1使用git url依赖于存储库2。
我们正在使用gitflow，但我们不了解如何进行有效的发布。
我们在repository1和repository2之间的依赖关系指向开发分支，一旦我们发布，所有代码都转移到master分支，但依赖关系仍在查看develop分支！
另一方面，我们也不能一直看着主分支的依赖。
似乎我们需要在发布时对代码进行更改，这将更改依赖关系网址，但这会违反git flow master should not have commits that are not merges
我们做错了什么，我们如何才能正确释放？
2个团队为nodejs项目开发不同的git存储库。
一个团队依赖于另一个团队，因此为了每天获得所有最新的更改，他们会编写以下npm依赖项
"otherTeam": "git://github.com/sameProject/otherTeam.git#develop",
在依赖url的末尾看到开发？
在开发结束时，这应该是master - 标签名称。
如果在发布期间不直接提交主数据，我怎样才能实现？
感谢@Graham的评论。
如果我理解正确 - 你建议发布component1，然后在component2上连续更新依赖版本以指向1的新版本。然后component1应该在某个时候停止当前版本的开发 - 这意味着component2不需要再次更新依赖关系，然后component2最终将到达版本的末尾，然后我们可以发布整个产品。
如果我误解了你，请纠正我。这个解决方案是在公司提出的，但是人们对这个程序不够自动化提出了担忧。该公司希望所有组件一起构建，具有相同的版本等...
答案 0 :(得分：0)
您必须原谅我的Java背景并将某些要点与node.js生态系统联系起来。
鉴于对库的依赖，例如模板渲染库，我会将其与主Web应用程序完全分开处理。
为了在网络应用程序中启用，通常我会使用依赖管理器来删除库的一个版本，例如：常春藤/ Maven的。
通常我最终发布时更喜欢显式版本。这使您可以了解正在使用的内容，并帮助缩小与特定版本的依赖项相关的问题。了解您已经发送给客户的内容的开销，因此您知道如何解决自动流程的方式。在自动过程中，这些信息会丢失。
此外，模板库的版本仅与此库相关，并且与主Web应用程序不同。这允许您在其他地方重用库。
要在开发主Web应用程序版本时启用更自动的过程，您可以下载最新版本，直到发布分支准备就绪。此时，发布模板库并使Web应用程序使用显式版本。
如果你愿意的话，你总是可以下载最新版本的依赖项，（至少我知道如何用常春藤这样做），但我认为它有点风险。