Похоже, их нужно добавить в ваш .gitignore
, чтобы Git их не коснется, вы можете легко загрузить их один раз вручную или создать символическую ссылку при каждом развертывании.
Как правило, это можно сделать, загрузив их в общий доступ:
shared $ tree
.
└── config
└── database.yml
└── system
└── uploads
А потом люди пишут задачи, чтобы симлинковать их в релиз:
after 'deploy:symlink' do
%w{database system}.each do |path|
run "ln -s #{shared_path + path} #{latest_release + path}"
end
end
Таким образом, можно также добавить следующие строки в gitignore:
/config/database.yml
/system/uploads
Это означало бы, что они больше не будут управляться Git, у каждого разработчика в вашей команде будет своя собственная копия этих файлов, и их нужно будет один раз создать на сервере вручную, а затем Git или Capistrano победят. не связывайтесь с ними снова.
Что касается «мне может понадобиться проверить их в будущем» - я бы посоветовал вам зафиксировать thefile.yaml.example
в репозитории и задокументировать процедуру для новых установок, чтобы облегчить жизнь вашего разработчика.
Когда вы добавляете файлы в .gitignore
, их также нужно будет удалить из репозитория, это не удалит историю файла, но удалит его из текущей главы. Если это важно, вы всегда можете получить историю файла, выполнив git log ./path/to/any/file/even/if/it/does/not/exist.anymore
. Разумнее было бы использовать git mv
для перемещения файла из его существующей позиции в {oldname}.sample
, чтобы история была перенесена в файл .sample.
person
Lee Hambley
schedule
28.03.2013