SCM для версии конфигурации версии

Question

Мой запрос, вероятно, кажется немного странным, но позвольте мне попытаться объяснить, что я хочу делать.

Итак, во-первых, то, что я хочу для версии в SCM, на самом деле не является исходным кодом чего-то. Это JSON-файлы, содержащие инструкции для настройки определенного серверного программного обеспечения (серверное программное обеспечение сохраняет свою конфигурацию в базе данных) с помощью предоставленного api (имеется отдельный инструмент развертывания). Единственный способ настроить это программное обеспечение - использовать api. Таким образом, JSON выглядит примерно так:

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

и так далее и так далее. Итак, теперь конфигурация этого программного обеспечения разработана в Scrum, и результатом каждого спринта должен быть набор команд конфигурации, который соответствующим образом изменяет программное обеспечение. Это означает, что пакет выпуска должен содержать только команды, которые также не были последней версией. Итак, о чем я сейчас думаю (делаю в git):

Когда начинается новый спринт, я создаю новую ветку в репозитории и очищаю все файлы конфигурации (их несколько). Я разрабатываю изменения конфигурации в вышеупомянутом синтаксисе JSON, и все в порядке. В конце спринта вещи в ветке - это пакет выпуска (который содержит только опции конфигурации дельты из предыдущей версии и этой версии). Теперь мне нужно будет вручную объединить ветвь обратно в мастер, чтобы получить общий набор параметров конфигурации (например, для развертывания нового сервера или восстановления сервера при его сбое или чего-то еще). Это ручная задача, однако я не знаю, как это можно было бы сделать лучше.

Итак, что я действительно хочу задать в раунде: Кто-нибудь знает лучшее решение для управления конфигурационными файлами? Цель состоит в том, чтобы иметь дельту параметров конфигурации из предыдущей версии, которая может быть использована для обновления конфигурации существующего сервера и пакета выпуска, который содержит все инструкции конфигурации (мастер). Мне бы очень хотелось увидеть лучшее решение, но я не знаю.

Заранее благодарим за любую помощь! Если у вас есть вопросы относительно того, о чем я прошу, не стесняйтесь комментировать :)

EDIT 1: Основываясь на ответе @Marina - MSFT, я подумал об этом чуть больше. В мерзавец, что-то, как это будет, вероятно, работать:

Давайте предположим, что мастер, как это:

| 
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 1), и кто-то создаст новую ветку (например, git checkout -b dev). Этот человек также будет необходимо удалить все файлы с помощью git rm * и совершает эти chanes как первый обязательство отрасли, в результате чего на этом графике:

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

D является коммит, который удаляет все файлы. Теперь я фиксирую изменения, которые должны выполняться в этом спринте (файлы конфигурации всегда будут содержать только эти изменения). В конце спринта, я, вероятно, граф, как этот:

---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) или что-то подобное и будет иметь освобождение дельты там и полный выпуск в мастера. Это должно работать, не так ли?

Answer 1

Если вы хотите управлять версиями файлов, git является очень популярным способом. Для вашего требования к деталям в git, как указано ниже (при наличии недоразумений по вашему требованию, пожалуйста, исправьте):

Относитесь к master Ветвь как главная ветвь, каждый раз, после завершения спринта, вы можете объединить ее, чтобы овладеть ветвью, главная ветвь последняя предыдущая версия, и ветка, над которой вы работаете, является текущей, поэтому вы можете использовать git merge для обработки файлов конфликтов с конфигурацией дельта.

Показать как приведенный ниже график, когда вы начинаете новый спринт, создайте ветвь 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 

Если вы используете вишни выбрать, что вам нужно сделать 4 шага, чтобы сделать изменения для E, F, G, H освоить. Из причины он может работать правильно, но есть также два способа сделать это проще:

1. Rebase фиксации E, F, G, H освоить отделение для одной команды:

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

2. Потому что commitH уже содержит изменения для E, F и G, поэтому вам может понадобиться только переустановка/вишня-pick commitH для управления ветвью. Это приведет к тому, что главная ветвь будет содержать окончательную версию для каждого спринта.