需要新项目的 git repo 布局建议
我正在开发一个新项目,我计划将其保存在 git 存储库中。 我知道如何在 CVS 中执行此操作,但我对 git 有点陌生,可以使用一些建议。
该项目是两个嵌入式设备的固件,它们相互通信并打包成对。 对于这两种设备,都有代码的生产变体和制造变体。 这两个设备项目都有许多子/同级项目,用于执行硬件的各个位(闪烁 LED 等),或与硬件相关的代码位(驱动程序等)。 大多数代码在所有事物中都是通用的。
我还要求能够彼此独立地修改生产和制造固件,以防止对其中一个固件的更改将另一个发送回通过验证。
下面是我现有的目录布局。 它是有机增长的,并且在我知道我将使用 git 之前就已基本完成。 如果有更好的方法的话,我并不反对重新组织整个事情。
- 项目根目录
- 包括
- 来源
- 设备A
- 生产
- 制造
- 眨眼
- 按钮
- ...
- 设备B
- 生产
- 制造
- 眨眼
- 按钮
- ...
我很想将生产和制造放在分支上,但我通常在某一天同时处理这两个分支,而 git 一次只允许一个分支处于活动状态。 然后我不知道如何处理闪烁、按钮等,因为它们并不是真正的制造或生产。 建议?
说明:
代码的制造版本用于生产线上测试硬件。 生产代码在硬件通过测试站后加载,然后运送给客户。 两者至少有 75% 相似,但它们需要独立,这样我就可以修复生产代码中的错误,而不必停止生产线。
由于DeviceA和DeviceB是一对,因此两个代码集同时标记并发布,且发布版本号相同。
由于DeviceA和DeviceB是一对,因此
I'm working on a new project that I plan to keep in a git repository. I know how I would do this in CVS, but I'm a bit new to git and could use some suggestions.
The project is firmware for two embedded devices that talk to each other and are packaged as a pair. For both devices there is a production variant and a manufacturing variant of the code. Both device projects have a number of sub/sibling projects for exercising various bits of the hardware (blink the LEDs, etc), or hardware related bits of code (drivers, etc). Most of the code is common across everything.
I also have a requirement to be able to rev the production and manufacturing firmware independently of each other to prevent a change to one from sending the other back through verification.
Below is my existing directory layout. It grew organically and was largely laid down before I knew I would be using git. I'm not averse to reorganizing the whole thing if there's a better way to do it.
- ProjectRoot
- include
- src
- DeviceA
- production
- manufacturing
- blink
- buttons
- ...
- DeviceB
- production
- manufacturing
- blink
- buttons
- ...
I'm tempted to put production and manufacturing on branches, but I typically work on both in a given day and git only allows one branch to be active at a time. And then I wouldn't know what to do with blink, buttons, etc because they're not really manufacturing or production. Suggestions?
Clarifications:
The manufacturing version of the code is used on the manufacturing line to test the hardware. The production code is loaded after the hardware passes the test station and is what's shipped to the customer. The two are at least 75% similar, but they need to be independent so I can fix a bug in the production code without having to stop the manufacturing line.
Because DeviceA and DeviceB are a pair, both code sets are tagged and released at the same time with the same release version number.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
我使用 git 来管理硬件/软件协同设计,所以我可能会提供一些有用的建议。
根据经验,如果您的设计中的某些部分可以彼此互操作,而不管您正在进行的修订如何,那么您最好为这些部分创建单独的 git 存储库。
举个例子,您希望驱动程序位于与硬件设计不同的存储库中。 这是因为软件和硬件之间的接口非常清晰,是分解的天然接缝。 此外,相同的驱动程序版本将适用于设备的一系列设计阶段。
我不确定您所说的设计的生产和制造版本是什么意思。 如果您想将开发版本和稳定版本解耦,那么您应该可以为这些版本建立单独的分支。
git 中的分支和合并非常便宜,并且分支之间的切换速度快如闪电; 因此,拥有分支机构不会受到任何惩罚。 在分支之间挑选兼容的更改也相当容易。 您在软件世界中通常看到的方法(发布分支,加上一个 HEAD)效果相当好。
您可能应该将演示/测试模块(闪光灯等)与它们应该演示/测试的模块放在一起。 这是因为演示耦合接口通常容易发生变化。 这样,您就必须使演示代码与实际设备保持同步,从长远来看,这将有助于设计的稳定性。
附带说明一下,在 FPGA 领域,您通常在大型设备上进行原型设计,并在受限设备上进行生产。 这样,您的模块最终就会有两个独立开发的品种。 您可能希望将这些变体保存在单独的存储库中,因为它们实际上是不同的实体。 在这种情况下,两者之间共享的代码(总是有一些可以重用的可移植代码)可以存在于单独的存储库中,并且是单独的库。 特别是如果代码大小合理的话。
然后,您可以使用 git 子模块将所有提到的模块绑定在一起。
I used git to manage hardware/software codesigns, so I may have some useful advice to give.
As a rule of thumb, if you have parts of the design that can interoperate with each other regardless of the revision you're working on, you're better off making separate git repositories for these.
To give an example, you want your driver to sit in a separate repository from your hardware design. This is because the interface between software and hardware is very clear-cut and is a natural seam to decompose by. Furthermore, the same driver version will apply to a range of design stages of your device.
I am not sure what you mean by production and manufacturing editions of the design. If you want to decouple the development and stable versions, you should be fine with having separate branches for these.
Branching and merging in git is as cheap as you can get, and switching between branches is lightning fast; so there's no penalty for having branches. It is also fairly easy to cherry-pick compatible changes between branches. The approach that you usually see in software world (branches for releases, plus one HEAD) works fairly well.
You should probably keep the demo/test modules (blinkers etc) together with the modules they are supposed to demo/test. This is because the demo coupling interfaces are often change-prone. This way you will have to keep the demo code in sync with the actual devices, which should help design stability in the long run.
As a side note, in the FPGA world, you are usually prototyping on a large device, and productionizing on a restricted device. This way, your modules end up having two varieties that are developed independently. You will probably want to keep these varieties in separate repositories, because they are, in effect, different entities. In this case, the code that is shared between the two (there's always some portable code you can reuse) can live in a separate repo, and be a separate library. Especially if the code size justifies it.
You can then bind all the mentioned modules together by using git submodules.
我认为你可以使用子模块。
我不是 100% 确定这是如何工作的,但是您可以为您的常用代码创建一个 git 存储库(例如 LED 和用户界面,甚至每个存储库一个),并包含此存储库的副本作为存储库的子模块A,另一个副本作为 B 的存储库的子模块。
如果您想对公共部分进行更改,请在您当前使用的单元上进行更改。 完成后,将更改推送到其他产品的子模块。
如果感觉更舒服,您也可以在其他地方拥有公共部分的存储库。
总结一下:将可重用的代码放在单独的存储库中,这样您就可以重用它。
我不是子模块之王,但我很快就需要做和你一样的事情。 所以我对你如何让它发挥作用很感兴趣。
I think you could use sub-modules.
I am not 100% sure how this works, but you can create a git repo for you common code (say LED and user interface, or even one repo for each), and include a copy of this repo as a submodule of your repo for A, and another copy as a submodule of the repo for B.
If you want to make changes to the common part, do that on the unit your currently working on. When you're done, push the changes to the submodules of the other product.
You could also have the repo for the common part somewhere else if that feels more comfortable.
To sum up: have your reusable code in separate repos, so you CAN reuse it.
I'm no king of submodules, but I will soon need to do the same thing as you're doing. So I'm interested in how you will get it working.