Question

我已经让自己和另外两个人参与了一个项目，这个项目被安置在一个git-repo中。

项目布局如下：

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

一个人正在使用Mechanical 我在FW工作我和另一个人在电气方面工作每个人都在Datasheets上工作

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

我每个人都有一个分支，每次更改我都会为它们分支... 一旦整个项目达到一个良好的停止点，我会尝试将所有内容更新并将其合并到开发中......有一天，如果有任何事情离开实验室，它将被合并到主人，但是没有＆＃39; t发生了。

我认为这是一个很好的方法，但经过6个月的努力来维持这个，我已经遇到了一些我经常遇到的问题，我想解决这个问题：

我觉得在保持每个分支相对于其他分支更新时会有很多开销...例如，如果我更改了Electrical文件夹，其中包含PCB /原理图，它几乎默认会以某种方式影响FW。这意味着当我在FW目录中工作时，我需要让absolutley确保FW目录已经使用电子目录进行了重新定位。这感觉有点愚蠢，因为FW分支中的任何更改都不会影响Electrical分支，反之亦然，但是如果不记住这一点，可能会导致使用过时的HW参考文档处理新的FW。

我已经完成了一些关于子模块的阅读，听起来它们可能适用于这种情况。这是一条值得考虑的道路吗？同样，整个项目都在一个回购中，因为事实上所有内容都是相互关联的，但上面列出的所有4个元素在开发工作流程中都是独立的，这是我在此期间真正依赖于git的内容。时间。

Answer 1

这感觉有点愚蠢，因为FW分支的变化不会影响Electrical分支，反之亦然

恕我直言这是不正确的。虽然它们在技术上可能不会相互影响，但任何一个的变化都可能给整个系统带来问题。这反映在您的其他声明中：

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

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

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

查看我的推理

分区项目的git哲学/策略

1 个答案: