Использование git для резервного копирования файлов конфигурации

Question

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

Однако я уверен в них:

• Можно ли добавить файл в хранилище, как если бы он был в другом пути, чем его реальный?

  Я забочусь о том, что если я буду добавлять файлы наивно, скопировав их в репозиторий и обновив репо, я бы использовал двойное пространство для каждого файла. Хотя это не будет много места, я все равно предпочел бы более чистое решение. Я просмотрел git-add, git-mv и git-filter-branch, но они, похоже, не обеспечивают чистого решения. Для выполнения этой задачи могут использоваться как механики add, так и mv, но на самом деле не обойти проблему дублирования файлов. filter-branch кажется слишком большим молотом для этой задачи.

• Возможно ли изменить путь к файлу после его добавления?

  git-filter-branch похоже на это, но я не уверен в побочных эффектах.

• Содействуют ли ссылки или жесткие ссылки, чтобы обойти необходимость копирования файлов, если git не способен к тому, что мне нужно явно? Будет ли эта работа кросс-платформенной или git обрабатывает ссылки по-разному на разных платформах?

редактировать в 2017 году - принял ответ, который я получил, потому что теперь, когда я понимаю, мерзавец лучше, я понимаю, что это не лучшее решение, чем копирование файлов или просто имея GIT репозиторий в директории прародителя. Неэлегантность этого означает, что копирование файлов является оптимальным решением, а symlinks/hardlinks не имеют отношения к этой проблеме. Комментарии и ответ могут быть полезны для кого-то, кто ищет что-то подобное, но не то же самое, поэтому я рекомендую проверить их.

Answer 1

Из обсуждения в комментариях я заключаю, что вопрос на самом деле:

В большой иерархии каталогов (мой полный домашний каталог) Я хочу, чтобы поместить выбранные файлы (файлы конфигурации) под мерзавца контроля версий в то время как большинство других файлы («нормальные» файлы) не находятся в управлении версиями.

Я никогда не делал этого, но 2 варианта приходят на ум:

1.) Сделайте всю иерархию каталог мерзавец рабочей зоны, но и с помощью .gitignore правила исключить все файлы, если они не будут явно включены. Поэтому вам нужно указать каталоги или файлы конфигурации, чтобы они контролировали их версию.

Ниже приведен демонстрационный скрипт, который создает небольшую иерархию каталогов примеров. Все исключен из системы контроля версий Git, за исключением каталогов конфигурации/файлов в явном виде включены (можно догадаться из названия, какие они есть.)

#! /bin/sh 
time=$(date +%H-%M-%S) 
mkdir example-$time 
cd example-$time 

touch a b c 
touch conf1 

mkdir d1 
touch d1/a 
touch d1/b 
touch d1/conf 

mkdir d2 
touch d2/f1 
touch d2/f2 

mkdir conf-d 
touch conf-d/conf1 
touch conf-d/conf2 

git init 

cat >.gitignore <<EOF 
# ignore all files 
* 

# but not directories (if a directory is once ignored, git will never 
# look what is inside) 
!*/ 

# of course .gitignore must never be ignored 
!.gitignore 

# list configuration files 
!conf1 
EOF 

cat >d1/.gitignore <<EOF 
# list the configuration files in this "mixed" directory 
!conf 
EOF 

cat >conf-d/.gitignore <<EOF 
# this is a configuration directory, include everthing... 
!* 
# ... but ignore editor backup files 
*~ 
EOF 

git add -A 
git status 

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

2.) Вы не указали, в какой файловой системе вы находитесь. Если вы находитесь в файловой системе Linux, вы можете использовать hardlinks. Создайте резервную копию git для резервного копирования и добавьте жесткие ссылки для всех файлов конфигурации.

Этот демонстрационный сценарий показывает идею:

#! /bin/sh 
time=$(date +%H-%M-%S) 
mkdir hl-example-$time 
cd hl-example-$time 

touch a b c 
touch conf1 

mkdir d1 
touch d1/a 
touch d1/b 
touch d1/conf 

mkdir d2 
touch d2/f1 
touch d2/f2 

mkdir conf-d 
touch conf-d/conf1 
touch conf-d/conf2 

mkdir hl-backup 
cd hl-backup 
git init 

ln ../conf1 . 

mkdir d1 
ln ../d1/conf d1 

mkdir conf-d 
ln ../conf-d/* conf-d 

git add -A 
git status 

Опять же, я не сделал это в реальной жизни, и всегда имеют жесткие ссылки свои подводные камни. Программа может отменить связь с существующим конфигурационным файлом и создать новый с тем же именем вместо обновления существующего (на самом деле это может быть хорошая реализация, потому что это помогает избежать поврежденных файлов конфигурации). Таким образом, вам понадобится сценарий, который проверяет, что все файлы конфигурации все еще жестко связаны. И поскольку вы не можете перенаправить каталоги, вам понадобится скрипт, который ищет новые файлы конфигурации в каталогах конфигурации. Я не знаю, как git точно ведет себя при оформлении заказа. Поэтому перед тем, как git изменит (например, восстановит) жесткий файл резервной копии, убедитесь, что у вас есть другой уровень резервного копирования. Не пробуйте это в производственной системе, если вы действительно не знаете, что делаете.