划分项目的 git 哲学/策略答案

【问题标题】：git philosophy/strategy for compartmentalized projects划分项目的 git 哲学/策略
【发布时间】：2018-07-16 17:42:40
【问题描述】：

我让自己和另外两个人在一个项目中工作，该项目位于 git-repo 中。

项目的布局如下：

./
    --DataSheets
    --Electrical
    --FW
    --Mechancial

一个人在机械上工作我在 FW 工作我和另一个人在电气工作每个人都在使用数据表

我相信每个人都曾在某个时候看到过这个：http://nvie.com/posts/a-successful-git-branching-model/，到目前为止，这就是我一直在尝试使用的......

每个分支都有一个分支，每次更改我都会从它们中创建子分支... 一旦整个项目达到一个好的停止点，我就会尝试更新所有内容并将其合并到 dev 中……有一天，如果有任何东西离开实验室，它会被合并到 master 中，但这并没有还没发生。

我认为这是一个不错的方法，但在尝试维护它 6 个月后，我遇到了一些我想解决的问题：

我觉得在保持每个分支相对于其他分支保持最新时有很多开销...例如，如果我更改包含 PCB/原理图内容的电气文件夹，它几乎默认会以某种方式影响 FW。这意味着在处理 FW 目录时，我需要确保 FW 目录已与电气目录重新建立基础。这感觉有点愚蠢，因为固件分支中的任何更改都不会影响电气分支，反之亦然，但是如果不记住这一点，可能会导致使用过时的硬件参考文档来开发新的固件。

我已经阅读了一些关于子模块的内容，这些内容听起来确实适用于这种情况。这是一条值得考虑的路吗？同样，整个项目都在一个 repo 中，因为实际上一切都是相互关联的，但是上面列出的所有 4 个元素在开发工作流程中都是独立的，这就是我在这段时间里真正依赖 git 的原因。

【问题讨论】：

标签： git workflow branch git-submodules

【解决方案1】：

这感觉有点愚蠢，因为固件分支中的任何更改都不会影响电气分支，反之亦然

恕我直言，这在某种程度上是不正确的。虽然实际上它们在技术上可能不会相互影响，但其中任何一个的更改都可能对整个系统造成问题。这反映在您的其他陈述中：

如果我更改了包含 PCB/原理图内容的电气文件夹，默认情况下它几乎会以某种方式影响固件

因此，我的建议是始终让从事特定系统更改的每个人都在同一个项目（子）分支中工作。这样您就可以确保所有组件都同步，并且您可以在将任何组件合并回主线之前在系统级别验证更改。

如果您计划在发布/运送车辆时使用master，我还建议不要将dev 分支作为master 分支的子分支。在How to get rid of develop branch for simplified Git flow查看我的推理

【讨论】：