Есть ли способ "заморозить" файл в Git?

Я в ситуации, когда хочу открыть исходный код моего проекта, однако есть один исходный файл, который я хочу опубликовать "чистую" версию, но использую отдельную версию локально. Есть ли у git функция, в которой я могу просто зафиксировать файл один раз и теперь перестает искать изменения в этом файле?

Я попытался добавить файл в .gitignore, но после первого раза, когда я делаю git add -f и git commit в файле, и я продолжаю редактировать его снова, git status показывает файл как изменилось. Идеальное поведение было бы для git, чтобы не отображать этот файл как измененный с этого момента, хотя я его отредактировал.

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

Ответ 1

Вы можете сделать это с помощью Git разреженной проверки. Выполните следующие команды в репо, где вы хотите получить специальный, не проверенный local.txt файл:

git config core.sparsecheckout true
echo '*' >.git/info/sparse-checkout
echo '!local.txt' >>.git/info/sparse-checkout
git read-tree --reset -u HEAD

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

Затем вы можете добавить опубликованный файл local.txt и управлять им из другого репозитория. Git будет рад отслеживать этот файл и хранить его в репозитории, но на машине с описанной выше редкой конфигурацией проверки, Git будет игнорировать локальный файл local.txt в этом рабочем каталоге, даже если он отличается от что в репозитории.

Ответ 2

Грег подходит очень адекватно и точно отвечает на ваш вопрос.

Позвольте мне сделать дополнение, которое учитывает то, что я считаю вашими высокоуровневыми задачами:

Не отпускать локальные данные в wild
Отпустите чистую версию в wild

Самый простой (и в моем опыте, наилучший заверенный) способ сделать это - использовать следующую структуру:

версированное

./application.code
./config.code
./config.local.code.sample
./.gitignore

application.code

include('./config.code')
if is_file('./config.local.code')
  include('./config.local.code')
end

config.code

username = 'root'
password = 'password'

config.local.code.sample

username = 'replace with your local username and rename file to config.local.code'
password = 'replace with your local password and rename file to config.local.code'

.gitignore

config.local.code

Неверсифицированный (необязательно)

./config.local.code # will not be picked up by git due to .gitignore

config.local.code

username = 'Suan'
password = 'myownpass'

Результат

Как вы можете видеть, вы избегаете выпуска config.local.code, который фактически содержит вашу конфиденциальную информацию, в дикую природу. Конфигурация по умолчанию (клонированная прямо с пульта дистанционного управления) будет работать в разумном, если не реже, случае, когда имя пользователя root и пароль password действительны. И метко названный config.local.code.sample содержит локальные инструкции по настройке.

Ответ 3

используйте update-index, вот документы.

Вот базовый пример замораживания файла foo.rb:

git update-index --assume-unchanged foo.rb

Затем, чтобы вернуть его:

git update-index --no-assume-unchanged foo.rb

Или для простоты добавьте его в .gitconfig

freeze = update-index --assume-unchanged
thaw = update-index --no-assume-unchanged
...
git freeze foo.rb
git thaw foo.rb

Примечание. Этот ответ был первоначально предоставлен @TheAmpersand в комментариях выше. Я думал, что это достаточно важно для формализации.

Ответ 4

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

Ответ 5

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

Скажите, что файл, который вы хотите обновить локально (а не для совместного использования), называется "local.file", а файл, который вы хотите опубликовать (в дикой природе), это "release.файл"... Вам нужно создать символический файл ссылки, позвольте этому символическому файлу ссылки "actual.file". Символический файл ссылки будет либо указывать на файл local.file или release.file в любой момент времени (или будет отсутствовать, если вы просто клонировали репо).

gitignore local.file и actual.file, чтобы они не отслеживались, так как вы не хотите, чтобы их отслеживали или отпускали. Файл actual.file всегда указывает на файл, с которым вы хотите работать.
Сделать символическую ссылку на local.file, когда вы работаете над вашим незамерзающим файлом версии.
Сделать символическую ссылку (actual.file) на "замороженную" версию release.файла, когда вы хотите сделать ручные обновления или просто скопировать изменения из файла local.file в release.файла.