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

Question

我的要求可能看起来有点奇怪，但让我试着解释一下我想做什么。

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

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

等等等等。所以，现在这个软件的配置是在 Scrum 中开发的，每个冲刺的结果都需要是一组相应地改变软件的配置命令。这意味着，发布包必须只包含上次发布时不存在的命令。所以，我目前的想法（在 git 中做的）如下：

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

所以，我真正想问的是：有谁知道管理配置文件的更好解决方案？目标是从以前的版本中获得配置选项的增量，可用于更新现有服务器的配置，以及包含所有配置语句的发布包（master）。我真的很想看到更好的解决方案，但是，我不知道。

在此先感谢您的帮助！如果您对我的要求有疑问，请随时发表评论:)

编辑 1：根据@Marina - MSFT 的回答，我对此进行了更多思考。在 git 中，这样的事情可能会起作用：

让我们假设这样的大师：

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

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

现在，下一个冲刺（例如，称为 "Sprint 1"）开始，有人将创建一个新分支（例如，git checkout -b dev）。此人还需要使用 git rm * 删除所有文件，并将这些更改作为第一次提交到分支，从而产生此图：

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

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

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

所以，因为我只想要 master 中的 E、F、G 和 H，所以我不合并分支，而是挑选除 D 之外的所有更改到 master。因为我总是编辑相同的文件（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分支作为主分支，每次完成一个sprint后可以合并到master分支，master分支是上一个版本，你正在做的分支是当前，所以你可以使用 git merge 来处理增量配置的冲突文件。

如下图所示，当您开始新的冲刺时，创建 dev1 分支 (git checkout -b dev1) 并对配置文件进行更改并提交。然后将dev1合并到master分支（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

注意：新建bench new master时，配置文件不会自动清理，需要删除文件或使用git rm *删除所有文件。

基于您的编辑的新解决方案：

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

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

为一个命令将提交 E、F、G、H 变基到 master 分支：

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

因为commitH已经包含了E,F,G的改动，所以你可以只需要rebase/cherry-pickcommitH到master分支。这将使主分支只包含每个冲刺的最终版本。

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

SCM for configuration statement versioning

git

version-control

configuration

json

configuration-management