Не существует надежного способа сохранить файл в хранилище, игнорируя локальные изменения в этом файле. Лучшее решение - организовать процесс сборки таким образом, чтобы локальные различия вводились либо (а) за пределами вашего рабочего дерева, либо (б) в файлах, которые вы не храните в управлении исходным кодом, и, следовательно, можете исключить их с помощью .gitignore.
Например, предположим, у вас есть файл app.config. Требуется один набор значений в локальных сборках и другой набор значений на производственном сервере (или, возможно, даже больше наборов значений в разных серверных средах). Предположим, что текущая копия в системе контроля версий выглядит следующим образом:
db-server = devdb.mydomain.com
db-user = svcDevDb
db-password = s3cr3t
Вы можете сделать следующее:
- Удалить
app.config из коммитов, идущих вперед: git rm --cached app.config
- Добавить
app.config в .gitignore файл
- Создайте новый файл
app.config-template, который содержит заполнители для значений, которые будут различаться в разных средах
Это может выглядеть как
db-server = ${db-hostname}.mydomain.com
db-user = ${db-user}
db-password = ${db-password}
- Создайте один или несколько «файлов свойств», содержащих общие наборы значений, которые можно подключить к шаблону
...
$ mkdir propfiles
$ cat > propfiles/dev
db-hostname = devdb
db-user = svcDevDb
db-password = s3cr3t
- Теперь вам понадобится скрипт, который, учитывая имя файла свойств, генерирует ваш
app.config, заполнив шаблон; и это становится частью вашего процесса сборки. (Может показаться, что я здесь замаскирую сложную часть, но любой приличный фреймворк должен либо сделать это за вас, либо иметь плагин, который это делает.)
Итак, вы add эти изменения и commit их. Теперь, когда вы строите для среды dev, вы указываете, что значения должны быть взяты из propfiles/dev. Для локальных сборок вы можете создать свой собственный файл local; Вы можете сохранить его вне рабочего дерева или добавить propfiles/local к .gitignore. Вы можете создать local-defaults propfile для управления исходным кодом с намерением, чтобы люди скопировали его и отредактировали копию для создания своего собственного локального propfile; но дело в том, что локальные изменения не вносятся напрямую в файлы, находящиеся в системе контроля версий.
Это также означает, что ваш рабочий файл может находиться вне контроля исходного кода и поддерживаться в безопасной среде (например, на сервере сборки, к которому не у всех есть полный доступ). В нашем примере файл конфигурации содержит пароль, поэтому возможность сохранить производственный пароль (и ваш личный пароль из локального файла) вне контроля исходного кода, возможно, стоит даже больше, чем избежать случайных коммитов локальных изменений конфигурации в это дело.
Существуют и другие решения, и детали всегда могут отличаться; но дело в том, что лучше решать проблему сборки, чем проблему управления исходным кодом.