Git конфликты с файлами JSON

Ответ 1

мы получаем много конфликтов, даже если люди меняют разные линии

Это не должно происходить, вы получаете только конфликты, если одна и та же строка модифицируется другими людьми, совершается, а затем сливается.

О, я действительно попробовал это и столкнулся с некоторыми нечетными проблемами.

Commit 1 (master):

{
    "a": "1",
    "b": "2",
    "c": "3",
    "d": "4",
    "e": "5",
    "f": "6",
    "g": "7"
}

Commit 2 (tmp)

{
    "a": "1",
    "b": "2",
    "c": "3",
    "d": "4",
    "e": "5",
    "f": "6",
    "g": "7"
}

Commit 3 (master):

{
    "a": "1",
    "b": "2",
    "c": "3",
    "d": "4",
    "e": "5",
    "f": "6",
    "g": "7"
}

git merge tmp: правильный результат

{
    "a": "1",
    "b": "2",
    "c": "3",
    "d": "4",
    "e": "5",
    "f": "6",
    "g": "7"
}

Однако я получаю конфликты, если также была изменена строка "d", возможно, git не удалось установить границы diff. Мое глупое предложение избежать этого глупого поведения git заключается в том, чтобы добавить "дополнение" к файлу JSON (уродливое, не так ли? Но больше не конфликты):

{
    "a": "1",

    "b": "2",

    "c": "3",

    "d": "4",

    "e": "5",

    "f": "6",

    "g": "7"
}

Ответ 2

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

Файл JSON, если необходимо, может генерироваться "на лету" каждый раз или генерироваться один раз во время развертывания для каждого сервера из таблицы базы данных.

Ответ 3

Другая причина, почему вы видите так много конфликтов, может заключаться в том, что ваши разработчики используют разные конфигурации завершения строк. См. Как изменить параметры окончания строки в Git. Чтобы узнать, вы можете открыть json файл с помощью редактора Hex и посмотреть, согласованы ли все контуры строк по всему файлу.

Ответ 4

Вы можете запустить git pull --rebase. Таким образом, когда кто-то другой отредактировал ваш файл JSON, git сначала потянет за собой свои изменения, а затем попытается применить ваши изменения поверх своих. Есть возможность делать это каждый раз: просто поместите название своей ветки вместо BRANCH и запустите это: git config branch.BRANCH.rebase true

Ответ 5

Например, в проекте работают 2 разработчика (разработчик A и B). Я создам 2 файла перевода: A.json и B.json. A.json для разработчика A, B.json для разработчика B. И я создам файл перевода с именем en_US.json. en_US.json игнорируется в файле .gitignore.

Итак, структура каталога переводов, как показано ниже:

$ tree . -a
.
├── A.json
├── B.json
├── en_US.json
└── .gitignore

Итак, теперь мне нужно создать задачу для объединения всех файлов JSON в en_US.json. Это проще, если вы используете Javascript-проект. Я предлагаю вам использовать grunt или gulp для запуска задачи. Например, вы можете обратиться к https://www.npmjs.com/package/grunt-merge-json или https://www.npmjs.com/package/grunt-concat-json