Последние пару недель я изучал GIT, пытаясь получить контроль над кодом моей команды.К сожалению, код, с которым мы работаем, является проприетарным языком с некоторыми особенностями, которые мешают мне найти достаточно практичный рабочий процесс для реализации.Тем не менее, я, вероятно, не знаю всех возможностей GIT, поэтому я прошу у вас, ребята, предложения.Я разделю этот пост на три части: 1) как мои файлы;2) рабочий процесс, который мы уже выяснили;3) варианты, которые я считаю на будущее.
Мои файлы тогда;
Как я уже сказал, это проприетарный язык сценариев, в котором внутри самого кода вы найдететеги относительно конфигураций (серверы, БД и другие вещи).Я знаю, это может звучать странно, но технически этот код является большим сложным файлом конфигурации.Ну, это не может быть изменено, пока давайте просто оставим это.
У меня также есть два различных окружения: dev и prod, и я предполагаю, что его использование очевидно.Из-за странного подхода к коду, если вы сравните скрипт в dev с тем же, что и в prod, вы увидите:
prod:
CodeCode += Code(0)
Code{1} ...
CodeConfig = "ConnectionToProducionDB"
SomeMoreGenericCode.doSomething()
(...)
А в dev это будет выглядеть так:
CodeCode += Code(0)
Code{1} ...
CodeConfig = "GoToSomeDevDB"
SomeMoreGenericCode.doSomething()
(...)
Это было бы в отношении файлов.
Теперь, что было показано;
На первый взгляд, мне показалось, что классическая позволяет разветвлять ситуацию , и я справился.
[create a folder and init it]
[copy my code from production and add/commit it]
$ git checkout -b dev
[change these lines with 'CodeConfig' to the dev settings]
[go happy coding and commiting]
Через некоторое время кодированиеи испытания сделаны, и пришло время объединиться с производством.Вот когда начинается проблема.
Простой git merge dev (из моей основной ветки) слит коды в основном нормально, но конфиги также будут перенесены в главную ветку, так как из PIT GIT это один изобновления в самом коде.Хотя в этом коротком коде это не было бы проблемой, в реальной ситуации я мог бы переконфигурировать десять или двадцать источников, и откат по одному не всегда был приятной (и не надежной) задачей.
Конечно, когда я использую ветки, я хочу объединить свой код, чтобы сохранить историю коммитов и комментарии.Мне просто нужно, чтобы это было сделано более индивидуально ...
Я пробовал пару разных вещей, чтобы решить это, но безуспешно.Кажется, что слияние GIT слишком умно для меня: (
Например, *.xml merge=Unset в мой файл .gitattributes. Или пользовательский драйвер слияния в ~ / .gitconfig, пытающийся вызвать сбой автоматического слияния(хотя я не уверен, правильно ли я это понял).
Возможные решения, которые я подумал;
Как я уже сказал, я, вероятно, не знаю всех функций GIT, поэтому мойварианты связаны с теми, кого я знаю. Я ценю ваши инновации;)
Я думаю, что самый простой способ был бы, если бы я мог отключить любое автоматическое слияние и сделать все вручную (коды не такие большие, и явсе равно придется в это разобраться).После этого я бы создал простой драйвер слияния, который передавал бы все изменения кода (не только конфликты) чему-то вроде WinMerge или Kdiff3, где я выполнял свою работу.К сожалению, мне так и не удалось добиться этого.
Моя последняя попытка привела к длительному и непрактичному рабочему процессу, но я напишу его здесь, чтобы вы могли понять мою цель.
- init repo
proj1 - копирование
prod файлов - первое добавление / принятие
$ git checkout -b dev- настройка
dev настройки - код / цикл разработки
- копирование файлов разработки в
tmpDevDir $ git checkout master- использование WinMerge для сравнения
tmpDevDir с proj1[master branch] и применять только желаемые изменения - фиксировать
proj1[master branch] $ git merge dev- конфликты слияния, где это необходимо
$ git diff HEAD HEAD^ для проверки результата слияния ивернуть объединенные конфиги $ git commit -am 'final commit for the production code'
И хорошо ... не приятно.
У кого-нибудь есть идеи для более практичного рабочего процесса или других команд, которые быпомочь?
спасибо большое,
f.