Я використовую Gentoo Linux і він має досить складну конфігурацію. Моє питання, чи розумно використовувати git для версії, що контролює мої конфігураційні файли?

У мене вдома є кілька репост, я думаю, якщо я поставив / home / ** до свого .gitignore, вони не спричинять проблем.

Оновлення уточнення:

Чи розумний метод використовувати git для керування версіями файлів конфігурації системного рівня в кореневій директорії "/"?

Коротка відповідь на ваше запитання - так .

Я б не вагаючись рекомендував Git (або будь-яке інше програмне забезпечення управління версіями) для відстеження файлів конфігурації. З цього моменту я був більш продуктивним (особливо для налаштування нових установок) і більше впевнений у своїх конфігураційних файлах. З контролем версій, у мене є запис , що були внесені зміни і фіксація повідомлення забезпечують причину , чому було зроблено зміна. Якщо зміна має небажані побічні ефекти, я можу легко переглянути журнал / історію, щоб побачити, яка зміна спричинила наслідки.

Особисто я б насторожився відстежувати всі файли в /кореневому каталозі. Список шляхів ігнорування може стати великим і непростим. Я вважаю за краще зберігати кожен логічний набір файлів у власному сховищі.

Я вручну використовую Git для відстеження моїх особистих файлів конфігурації / запуску, наприклад, конфігурація Vim, функції Bash, псевдоніми тощо - подібний до підходу, наведеного в розділі Як відстежувати $ HOME за допомогою git . Я зберігаю кожен набір файлів у власному сховищі та використовую символічні посилання на домашній каталог.

Для файлів конфігурації системи я використовую Git з Etckeeper для відстеження файлів у моєму /etcкаталозі.

Недоліки

Одним із питань, яких слід насторожити, є те, якщо відстежувані файли містять жорсткі посилання . Коли Git використовується для перевірки файлів або іншої модифікації робочого дерева, він від’єднує файли та відтворює їх . Більш детальне пояснення див. У розділі Git, Dotfiles та Hardlinks .

Etckeeper

Etckeeper можна використовувати для збереження повної історії змін, внесених в / і т.д. Він відстежує метадані файлів, які системи контролю версій зазвичай не підтримують, але це важливо для /etcтаких, як дозволи /etc/shadow.

Він підключається до менеджерів пакунків, таких як apt та yum і (у своїй конфігурації за замовчуванням), запускає до- та після встановлення, щоб /etcвідслідковувати всі зміни .

Якщо пакет встановлений чи вилучений, всі незапущені зміни в / і т. Д. Будуть здійснені перед операцією пакету, так що є два коміти:

1. "Збереження незапущених змін у / etc перед запуском"
2. "Внесення змін у / і т.д. після запуску"

Я використовував його в дистрибутивах на основі Debian і Red Hat, і я знаю, що він підтримує управління пакетами Arch. Я не можу сказати, скільки автоматизації вона додала б до системи Gentoo, але пакет доступний для неї .

Він також підтримує переміщення файлів конфігурації до віддаленого сховища (що, звичайно, має бути приватним).

Конфігурація

Після установки пакета вам може знадобитися налаштувати його ( /etc/etckeeper/etckeeper.conf), наприклад, в системах Ubuntu система управління версією за замовчуванням змінюється з Git на Bazaar. Ви також можете відключити щоденні автоматичні комісії .

Щоденні автокомісії

Зміни можуть бути автоматично введені щоденним завданням із застосуванням cron . Це може дратувати, оскільки сховище може бути захаращене кількома повідомленнями автоматизованих фіксованих повідомлень.

Я коментую відповідний рядок у /etc/etckeeper/etckeeper.conf:

sed -i '/AVOID_DAILY_AUTOCOMMITS/s|^#* *||' /etc/etckeeper/etckeeper.conf

Ігноруйте певні файли

Змінити, /etc/.gitignoreщоб вказати файли, які не слід відстежувати.

Перший пробіг

Після налаштування запустіть такі команди:

sudo etckeeper init
sudo etckeeper commit "Initial commit"

Якщо ваш поточний каталог etc, ви можете запускати звичайні gitкоманди, наприклад,

sudo git status
sudo git log

Я використовую git для відстеження конкретних областей мого домашнього каталогу. Особисто я б не пішов шляхом відстеження кореневого каталогу, але мушу сказати, що я захоплююсь вашими амбіціями. :)

Можливо, цей збірник досвіду може дати вам краще уявлення про те, що ви можете потрапляти:

ефекти ініціалізації репозиторію git у кореневому каталозі Linux 3 :)

Вибачення за "відповідь", замість того, щоб просто кинути посилання в коментар; однак, недостатньо представників, але хотів би звучати.

Редагувати

Оце Так! Дуже приємна відповідь від @AnthonyGeoghegan. Я вважаю, що це не стільки боротьба, скільки я спочатку передбачав її.

Я також використовую gitдля зберігання та обслуговування своїх dotfiles, але в git bare repository. Детальний посібник можна знайти тут . Я використовую два сховища: одне для моїх користувачів dotfiles з іменем myconfта одне для dotfiles root з ім'ям rootconf.

Крім того, ви можете використовувати обидві конфігурації на багатьох машинах, різних дистрибутивах Linux або віртуальних машинах: просто створіть нову гілку для окремої конфігурації. Тоді ви уникаєте змішування коду в одному файлі (наприклад .bash_alias): Не дратується, якщо більше перевіряти поточну машину; ні, ніякі посилання не потрібні!