源代码管理 [英] Source code management

查看:123
本文介绍了源代码管理的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我的目标是多个平台。通常,当我开发应用程序时,我会为某个硬件编写一个固件,用于某些微控制器系列(AVR,ARM,...)和驱动程序库/程序(在Visual C ++,Qt,C#中)。所以一个应用程序包含几个项目(带有固件的AVR项目,带驱动程序的Qt项目,可能还有一些测试项目......)。



目前,我使用单个Git存储库其结构如下:



存储库
- 库 // 共享代码,每个文件夹代表平台/编译器/应用程序的代码
- AVR
- I2C
- Uart
- Spi
- Lcd
- Rtc
- ....
- Cortex M4
- GNU
- Win32
- Qt
- ....
- MyApplication // 应用程序共享代码,用于AVR和Qt项目
- AnotherApplication // 另一个应用程序共享代码...
- 项目
- AVR
- MyApplicationProjectForAvrMcu
- AnotherApplicationProjectForAv rMcu
- VisualC
- Qt
- MyApplicationProjectForQt
- AnotherApplicationProjectForQt
- ...





我可以看到维护这个庞大的整体存储库存在很多困难。



我想我需要为每个应用程序提供单独的存储库。这样的事情:



 MyApplicationRepository 
- 库
- AVR
- I2C
- Uart
- Win32
- Uart
- Qt // 某些特定Qt代码,例如一些小部件
- MyApplication // 应用程序在AVR项目和Qt项目之间共享的源代码
- 项目
- AVR
- MyApplicationProjectForAvrMcu
- Qt
- MyApplicationProjectForQt





但是出现了新问题 - 对于每个应用程序,我将在Library文件夹中复制大多数代码 - 平台/编译器特定代码(Library / AVR,Library / Win32,Library / Qt,...)将在所有应用程序中重复存储库。



这是我想要使用的理想工作流程:我创建了一个应用程序存储库。我从共享代码库中提取该应用程序所需的平台/编译器特定代码(共享代码)(整个文件夹或单独的文件 - 例如Library / AVR / I2C,Library / AVR / Uart,Library / Qt / Something / SomeCode.cpp) 。我在应用程序库中创建所有特定于应用程序的代码和项目。后来我意识到我需要调整一些共享代码(例如Library / AVR / I2C),所以我添加了一些特殊功能并用我的应用程序测试它。然后,将该调整推回到共享存储库以便稍后在该应用程序需要时从其他应用程序存储库中获取调整将是有用的。



你能用吗?推荐一些工具来完成这个工作流程?

解决方案

永远不要复制任何代码。相反,将每个库视为单独的产品,即使不对它们使用单​​独的编译也是如此。这是头等大事。如果您需要调整一些库代码,请创建一些实验分支并单独使用它们,而不是触摸主干。如果一个应用程序需要一个版本的库而另一个应用程序需要另一个版本,该怎么办?这意味着即使把它们中的任何一个放入后备箱,这两个版本都不够好。你需要统一图书馆只有一个更通用的版本。



祝你好运。

-SA

I'm targeting multiple platforms. Typically, when I develop an application, I write a firmware for some microcontroller family (AVR, ARM, ...) and a driver library/program (in Visual C++, Qt, C#...) for that piece of hardware. So one application consists of several projects (AVR project with firmware, Qt project with driver, maybe some test projects...).

Currently, I use single Git repository and its structure is following:

Repository
 - Library // shared code, each folder represents code for a platform/compiler/application
  - AVR
   - I2C
   - Uart
   - Spi
   - Lcd
   - Rtc
   - ....
  - Cortex M4
  - GNU
  - Win32
  - Qt
  - ....
  - MyApplication // application shared code, used in AVR and Qt projects
  - AnotherApplication // another application shared code...
 - Project
  - AVR
   - MyApplicationProjectForAvrMcu
   - AnotherApplicationProjectForAvrMcu
  - VisualC
  - Qt
   - MyApplicationProjectForQt
   - AnotherApplicationProjectForQt
  - ...



I can see many difficulties maintaining this big monolithic repository.

I think I need separate repository for each application. Something like this:

MyApplicationRepository
 - Library
  - AVR
   - I2C
   - Uart
  - Win32
   - Uart
  - Qt // some Qt specific code, e.g. some widgets
  - MyApplication // application's source code shared between AVR project and Qt project
 - Project
  - AVR
   - MyApplicationProjectForAvrMcu
  - Qt
   - MyApplicationProjectForQt



However new problem arises - for each application I will have most code in Library folder duplicated - platform/compiler specific code (Library/AVR, Library/Win32, Library/Qt, ...) will be duplicated in all repositories.

This is ideal workflow I would like to use: I create an application repository. I pull platform/compiler specific code (shared code) needed by that application from my shared code repository (whole folders or separate files - e.g. Library/AVR/I2C, Library/AVR/Uart, Library/Qt/Something/SomeCode.cpp). I create all application specific code and projects in my application repository. Later I realize that I need to tweak some shared code (e.g. Library/AVR/I2C) so I add some special functionality and test it with my application. Then it would be useful to push that tweak back to the shared repository to be able to pull that tweak from another applications repositories later if needed by that applications.

Can you recommend me some instruments to accomplish this workflow?

解决方案

Never ever duplicate any code. Instead, consider each library as a separate product, even if don't use separate compilation for them. This is the top priority. If you need to tweak some library code, create some experimental branches and work with them separately, not touching the trunk. What if you need one version of the library for one application and another version for another application? It means that both versions are not good enough even for putting either of of them in the trunk. You need to unify the library to have only one, more universal version.

Good luck.
—SA


这篇关于源代码管理的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆