Question

我的要求似乎有点奇怪，但让我试着解释一下我想做什么。

所以，首先，我想在SCM中版本的东西并不是真正的源代码。它是JSON文件，包含使用提供的api配置特定服务器软件（服务器软件将其配置保存在数据库中）的语句（有一个单独的部署工具）。配置此软件的唯一方法是使用api。所以，JSON看起来像这样：

[{
  "command": "command1",
  "options": {
    "option1": "value1"
  }
}, {
  "command": "command2",
  "options": {
    "option2": "value2"
  }
}]

依旧等等。因此，现在该软件的配置是在Scrum中开发的，每个sprint的结果都需要是一组配置命令，这些命令会相应地更改软件。这意味着，发布包必须只包含最后一个版本中没有的命令。所以，我目前的想法（在git中做）如下：

当新的sprint启动时，我在存储库中创建一个新分支并清除所有配置文件（有几个）。我在上面提到的JSON语法中开发了配置更改，一切都很好。在sprint结束时，分支中的内容是发布包（仅包含先前版本和此发行版中的增量配置选项）。现在我需要手动将分支合并回主服务器以获得一整套配置选项（例如，部署新服务器或在服务器崩溃时重建服务器等）。这是一项手动任务，但是，我不知道如何以更好的方式完成。

所以，我真正想要进入的一轮是：有谁知道更好的解决方案来管理配置文件？目标是从先前版本获得配置选项的增量（可用于更新现有服务器的配置）和包含所有配置语句（主服务器）的发行包。我真的很想看到一个更好的解决方案，但是，我不知道。

提前感谢您的帮助！如果您对我的要求有疑问，请随时评论：）

编辑1：根据@Marina的答案 - MSFT，我想到了这一点。在git中，这样的东西可能会起作用：

让我们假设这样的大师：

|
C Another commit with changes to config2.json
|
B Some other commit with changes to config1.json
|
A First commit
|

所以，目前主树包含两个文件，config1.json和config2.json，两者都有如上所述的JSON内容。

现在，下一个sprint（例如，称为“Sprint 1”）启动，有人将创建一个新分支（例如git checkout -b dev）。此人还需要使用git rm *删除所有文件，并将这些chanes提交为分支的第一个提交，从而生成此图：

---A---B---C---
            \
             D

D是提交，它删除所有文件。现在，我提交更改，必须在此sprint中完成（配置文件将始终只包含这些更改）。在sprint结束时，我可能有一个像这样的图表：

---A---B---C---
            \
             D---E---F---G---H

所以，因为我只想在主人中使用E，F，G和H，所以我不会合并分支，而是挑选除D以外的所有更改。因为我总是编辑相同的文件（config1.json和config2.json），git会让我手动合并这些文件（这完全没问题，我不指望，任何工具都可以支持我合并文件的方式我需要这样做）。合并后的图表应如下所示：

---A---B---C---E'---F'---G'---H'  <--- master branch
            \
             D---E---F---G---H    <--- dev branch

现在，我可以将dev分支重命名为Sprint 1（git branch -m sprint1）或类似的东西，并在那里发布delta版本并在master中发布完整版本。这应该有用，对吧？

Answer 1

如果你想对文件进行版本控制，git是一种非常流行的方式。对于您在git中的详细要求如下（如果您的要求存在误解，请更正）：

将master分支视为主分支，每次完成冲刺后，您可以将其合并到主分支，主分支是最后一个版本，而您正在处理的分支是当前分支，所以你可以使用git merge来处理具有增量配置的冲突文件。

如下图所示，当您开始新的sprint时，创建dev1分支（git checkout -b dev1）并为配置文件创建和提交更改。然后将dev1合并到主分支（git checkout master和git merge dev1），您可以解决冲突文件以保持增量更改，使用git add .和git commit完成合并。下一个冲刺是类似的。

      ______C_____                          dev1
     /            \
A---B--new commit--D---E--new commit--G--H  master
                       \             /
                         _____F_____        dev2

注意：当您创建新的替补新主人时，配置文件无法自动清除，您需要删除文件或使用git rm *删除所有文件。

新解决方案基于您的修改：

A---B---C                     master
         \
          D---E---F---G---H   dev

如果你使用cherry-pick，你需要做4个步骤来改变E，F，G，H来掌握。因为它可以正常工作，但也有两种方法可以使它更容易：

Rebase将E，F，G，H提交给一个命令的主分支：

git rebase --onto master <commit id for D> dev

因为commitH已经包含了对E，F和G的更改，所以您只需要将commitH改为/可以选择commitH到master分支。这将使主分支仅包含每个sprint的最终版本。

用于配置语句版本控制的SCM

1 个答案: