Как я могу сказать git (или другим dvcs) отслеживать файл в частном порядке?

Question

Мой вариант использования начинается с чего-то похожего на this ; команда использует центральный репозиторий (в моем случае это subversion, но я думаю, что если бы это был git, проблема была бы та же), и некоторые из этих файлов были приватными для членов (файлы локальных настроек Django, предпочтения частного проекта IDE и т. д.) , Хотя закрытый файл должен оставаться закрытым, то есть я не хочу, чтобы изменения, которые я вносил в него, были отправлены или переданы - я хочу, чтобы файл отслеживался и контролировался версией.

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

По сравнению с предлагаемыми решениями: this и this не годятся, потому что они вообще предотвращают фиксацию файла; это не то, что я хочу. Я хочу, чтобы это совершалось на месте; Я просто не хочу, чтобы это было опубликовано.

Кстати - хотя я люблю DVCS и git был своего рода дефолтом, я не чувствую особой приверженности этому (каламбур непреднамеренный); если только hg или bzr могут сделать это, это может быть достаточной причиной для меня.

Answer 1

Как насчет игнорируемой подпапки с пользовательскими настройками?Подобно тому, как предлагает schoetbi, но только одна папка, а не одна для каждого пользователя.

/Project
    /Foo
    /Bar
    /Preferences

в /Project/.gitignore, строка /Preferences игнорировать / Project / Preferences.И инициализировать «секретный» репо в / Project / Preferences.(Я называю это секретом, потому что внешнее хранилище не знает об этом.) Если другое программное обеспечение ожидает свои файлы предпочтений в определенной части основного хранилища, вы можете создать символическую ссылку на что-то в / Project / Preferencesпапка.Симлинк может быть отслежен или нет;он должен быть в основном стабильным с течением времени, так что вы не будете заботиться о его истории, и его история в любом случае будет независима от основного проекта, поэтому я, вероятно, проигнорирую его.

Вам не нужно / Предпочтенияниже / Project, но он должен находиться в одном месте относительно / Project, чтобы идея символической ссылки работала, поэтому я бы оставил ее под.Вполне нормально инициализировать репозиторий под другим репозиторием, если внешний репозиторий игнорирует внутренний.Я делаю это с моей ~ папкой и проектами под моей ~ папкой.

Даже если вы логически хотите, чтобы ваши пользовательские настройки были связаны с определенными коммитами, которые вы сделали в основном репо, это принципиально невозможно сgit, так что вам определенно придется выполнять ручную синхронизацию между коммитами в вашем основном репо и настройками, которые соответствуют этим коммитам в вашем секретном репо.Git в основном заботится о состоянии всего репо (что означает все, что он отслеживает) и никогда не может отправить частичный коммит.(Поскольку хэш-идентификатор SHA-1 для фиксации будет совершенно другим, если вы удалите хотя бы один файл).

Answer 2

То, как мне это удалось, и я не знаю, будет ли это приемлемо в вашей ситуации, - это создать файл шаблона, например, settings.txt.template, который находится в совершенном репо. а затем настройте свой личный файл локально (settings.txt добавлен в файл .gitignore).

В противном случае вы можете посмотреть подмодули git http://book.git -scm.com / 5_submodules.html

Answer 3

Может быть, вы могли бы хранить ваши файлы в отдельной папке git и использовать символическую ссылку с именем .gitignored?

Answer 4

Грязный хакерский способ сделать это - сохранить приватный файл под другой системой контроля версий, нежели основной контент проекта.Например, игнорируйте файл настроек в .gitignore, но создайте репозиторий Mercurial в каталоге, который игнорирует все, кроме файла настроек.Это по крайней мере позволит вам отслеживать изменения в каждом наборе файлов, но не позволит связать одно с другим.

Answer 5

Я бы рекомендовал иметь папку с настройками и под ней папку для каждого пользователя.Если у вас приличная ОС, то есть переменная окружения с именем вошедшего в систему пользователя.

Тогда ваша структура каталогов будет:

Project
 / Settings
   / User1
   / User2
   / User3

Теперь все проверено, и у каждого пользователя есть свой каталог.Следующим шагом будет использование специфичной для пользователя части в вашем buildscript, projectfiles и сценариях или любой другой, использующей переменную окружения.

Answer 6

mine делает это для git, и если вы добавляете глобальное правило игнорирования svn для *_mine_*, то оно должно отлично работать для svn.

Отказ от ответственности: по умолчанию он не версия , но позволяет создавать резервные копии и восстанавливать все, что соответствует правилу игнорирования *_mine_*

Answer 7

Или, может быть, сказать git игнорировать изменения в этом файле:

git update-index --assume-unchanged <file name>