У меня есть следующая структура каталогов:
/.git
/.git/info/attributes
/MyProject
/MyProject/pom.xml
/MyProject/MyCode.java
У меня есть главный мастер и исправление. На обоих ветвях были изменены pom.xml и MyCode.java. я хотел бы объединить изменения с bugfix в master только для MyCode.java и сохранить основную версию файла pom.xml.
Итак, я добавил "/.git/info/attributes", потому что я не хочу комментировать .gitattributes с проектом
$cat .git/info/attributes
pom.xml merge=ours
$git status
# On branch master
nothing to commit (working directory clean)
$git check-attr -a pom.xml
pom.xml: merge: ours
Наконец, проблема:
Когда я это сделаю:
$git merge bugfix
Auto-merging MyProject/pom.xml
CONFLICT (content): Merge conflict in MyProject/pom.xml
Automatic merge failed; fix conflicts and then commit the result.
Git игнорирует настройки атрибутов. Что мне здесь не хватает?
Я предпочитаю не определять "keepMine.sh" за этот пост
этот пост - это то, что мне нужно, однако я предпочитаю не запускать файл по файлу, если у меня есть простой шаблон
спасибо!
$ git config merge.ours.driver true
или даже
$ git config --global merge.ours.driver true
'ours' не является одним из встроенных драйверов слияния, хотя он совершенно ясно для вас и для меня, что он должен делать, и кажется, что git не выдает ошибку, когда пользовательский драйвер слияния undefined.
(true выше - это просто команда unix true, ее успех говорит о том, что локальная версия выглядела правильно, в этом случае ничего не делая).
Из моего тестирования с помощью git версии 1.7.1 я обнаружил, что, если нет требования о слиянии, никакой драйвер слияния не будет выполняться (независимо от того, что вы вложили в конфигурацию, и независимо от каких-либо атрибутов git).
Если вы отделитесь от "master" к вашему собственному локальному ветки "bugfix" , а затем отредактируйте кучу вещей в своем собственном филиале, зафиксируйте это. После этого вы снова проверяете ветвь "мастер", затем делаете что-то вроде:
git merge bugfix
Вы можете ожидать, что атрибут "merge = ours" защитит вас в этой ситуации. Это не будет! Фиксация "bugfix" будет топать по "master" ветки, если не было никаких изменений к этому конкретному файлу в главной ветке с момента, когда "bugfix" отделился от мастера. Никакие изменения не требуют объединения, что подразумевает, что не запускается драйвер слияния. Кажется, такая распространенная проблема, что git должен иметь определенный атрибут, предварительно определенный для предоставления абсолютной локальной защиты файла от чужих слияний, во всех ситуациях.
FWIW, я прочитал мнение других людей о том, что файлы конфигурации должны быть локальными и частными, а не проверяться на git вообще. Я думаю, что это боллок: конечно, я хочу отслеживать изменения в моем файле конфигурации. Конечно, идея совместного инструмента заключается в том, что я хочу иметь возможность сравнить мою конфигурацию с тем, что работают другие люди в моей команде, или сравнить конфигурацию разработки с конфигурацией производства. Вся идея инструмента заключается в том, что он помогает вам выполнить вашу работу.
В качестве решения kludgy лучшее, что я придумал, это каталог конфигурации с каждым конфигурационным файлом, имеющим другое имя (например, config/production config/test config/devel_joe config/devel_bill и т.д.), и все эти перейдите в git. Затем при развертывании фактический рабочий файл конфигурации копируется из этого каталога конфигурации. Я считаю это уродливым, потому что это шаг назад от идеи названных ветвей, но, по крайней мере, это безопасно.