1

在我们的项目中，我们在上游软件（U-Boot）之上实现功能。每隔一两年就开始开发新硬件，并以更新版本的上游软件为基础。一些以前实现的功能几乎原样适用于新项目，无需太多修改。

因此，我们需要一个允许跟踪和重用在特定功能范围内完成的工作的工作流，而无需从整个代码库中删除它。它不应该是完美的，因为它并不经常需要，但也不应该是痛苦的。

主要问题是，有时功能会在初始实施后的几周/几个月内修复/调整，有时会重复几次，因此普通的“功能分支工作流程”将无法正常工作。

团队和代码库都相对较小（约 5 人，上游代码上分别有约 15 个 LoC）。通常一次只有一个人在处理特定的功能。

这是我们能够提出的两个选项，我将仅描述处理上述有问题的情况，因为它是唯一的并发症来源。

方法A

初始状态：功能的第一个/上一个版本在分支 X 上，几个月前最后一次更改并合并到 master

  1. git checkout X; git merge --no-ff master
  2. 进行更改并提交
  3. git checkout master; git pull; git merge --no-ff X; git push

然后git log --first-parent --no-merges显示从一开始就在此分支上完成的提交的漂亮列表。

这种方法的主要问题是它是脆弱和限制性的：

  • 如果有人在步骤 1 中使用快进进行合并，则上述检索历史记录的方法之后将不起作用。AFAIK --no-ff 可以在回购级别强制执行，但每个人都必须这样做并且不要忘记。
  • 第 3 步中的 rebase-and-then-merge 也会打破历史记录，而且很多人都喜欢这种方法和 rebase。完全禁止变基可能更安全，但我不知道如何强制执行。

方法B

每次有人回去处理功能 X 时，他都会创建一个新的 X_fix_this、X_change_that 等。

缺点：丑陋和杂乱的分支列表，需要编写脚本来生成提交列表。

目前，我们在被子中保留了一组补丁。虽然这完美地解决了上述问题，但在其他方面却非常难看。

任何（更好的）想法？

4

0 回答 0