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

时间:2017-01-27 14:12:26

标签: json git version-control configuration configuration-management

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

所以,首先,我想在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中发布完整版本。这应该有用,对吧?

1 个答案:

答案 0 :(得分:1)

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

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

如下图所示,当您开始新的sprint时,创建dev1分支(git checkout -b dev1)并为配置文件创建和提交更改。然后将dev1合并到主分支(git checkout mastergit 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来掌握。因为它可以正常工作,但也有两种方法可以使它更容易:

  1. Rebase将E,F,G,H提交给一个命令的主分支:
  2. git rebase --onto master <commit id for D> dev

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