В очередной раз утратив ценный конфиг из-за перепутанных шелловых > и >>, я, наконец, понял,
что пора делать бекапы.
Можно делать копии конфигов куда-то в укромное место на диске, можно сделать rsync на удалённый сервер
или понаписать хитрых велосипедообразных скриптов.
Но самое удобное решение находится уже прямо под руками: создать git репозиторий в корне.
Если ещё кто не знает, git не вынуждает нас поднимать какой-либо сервер. Вообще, репозиторий в git — это прежде всего локальная сущность, даже более того, репозиторий — это один единственный каталог .git. Что же до возможностей взаимодействия с внешними репозиториями, то ими никто не обязывает пользоваться.
А теперь технические детали.
Пункт номер раз: Фильтровать вхождения по путям и держать весь /etc в репозитории — это неудобный подход.
Во-первых, в /etc полно дефолтного мусора (с т.з. ценности для нас оных конфигов),
во-вторых, я, например, хочу держать /var/lib/portage/world так же близко к сердцу, как и некоторые файлы из /etc.
Пункт номер два: Если вам когда-нибудь захочется выложить свой репозиторий конфигов на гитхаб,
ваш /etc/ssh/ssh_host_rsa_key может привлечь неожиданно много внимания местных юзеров.
Исходя из этого, определяем содержимое файла .gitignore (указывает файлы, которые не будет автоматически предлагаться для добавления, а также исключения из этих же правил)
Да-да, ничего лишнего. Суть в том, что git уже добавленные (каким-либо образом вопреки .gitignore) файлы обрабатывает как обычно, а новые автоматически предлагаться к добавлению уже не будут.
Итого, достаточно один раз добавить конфиг через
и впредь его можно будет коммитить через commit -a или add -A.
У меня гит следит за следующими файлами:
что пора делать бекапы.
Можно делать копии конфигов куда-то в укромное место на диске, можно сделать rsync на удалённый сервер
или понаписать хитрых велосипедообразных скриптов.
Но самое удобное решение находится уже прямо под руками: создать git репозиторий в корне.
Если ещё кто не знает, git не вынуждает нас поднимать какой-либо сервер. Вообще, репозиторий в git — это прежде всего локальная сущность, даже более того, репозиторий — это один единственный каталог .git. Что же до возможностей взаимодействия с внешними репозиториями, то ими никто не обязывает пользоваться.
А теперь технические детали.
Здравый смысл или профилактика отстреливания конечностей
Пункт номер раз: Фильтровать вхождения по путям и держать весь /etc в репозитории — это неудобный подход.
Во-первых, в /etc полно дефолтного мусора (с т.з. ценности для нас оных конфигов),
во-вторых, я, например, хочу держать /var/lib/portage/world так же близко к сердцу, как и некоторые файлы из /etc.
Пункт номер два: Если вам когда-нибудь захочется выложить свой репозиторий конфигов на гитхаб,
ваш /etc/ssh/ssh_host_rsa_key может привлечь неожиданно много внимания местных юзеров.
Исходя из этого, определяем содержимое файла .gitignore (указывает файлы, которые не будет автоматически предлагаться для добавления, а также исключения из этих же правил)
/.gitignore (запрещаем всё) :
*Да-да, ничего лишнего. Суть в том, что git уже добавленные (каким-либо образом вопреки .gitignore) файлы обрабатывает как обычно, а новые автоматически предлагаться к добавлению уже не будут.
Итого, достаточно один раз добавить конфиг через
add -f path-to-config/configи впредь его можно будет коммитить через commit -a или add -A.
Немного о git
Ничего нового для тех, кто уже пользуется git'ом
Файлы в нашем репозитории могут находиться в трёх категориях:
not in index (untracked) — [новые] файлы, которые мы отсеяли через .gitignore
unstaged — измененённые/новые файлы, которые ещё не выбраны для коммита.
staged — соответственно, выбранные для коммита через add.
Посмотреть список изменённых файлов можно через
или для просмотра всех отслеживаемых файлов
Иллюстрация (с тем лишь замечанием, что stage — это синоним add и, соответственно, новый файл можно сразу коммитить без «edit the file»)
not in index (untracked) — [новые] файлы, которые мы отсеяли через .gitignore
unstaged — измененённые/новые файлы, которые ещё не выбраны для коммита.
staged — соответственно, выбранные для коммита через add.
Посмотреть список изменённых файлов можно через
# git statusили для просмотра всех отслеживаемых файлов
# git ls-filesИллюстрация (с тем лишь замечанием, что stage — это синоним add и, соответственно, новый файл можно сразу коммитить без «edit the file»)
Рецепты:
Ничего нового для тех, кто уже пользуется git'ом
(ключ -f будет необходим только для новых файлов)
(если без -m, то откроется редактор для описания коммита)
(показывает в т.ч. хеши (object name) коммитов, которые можно использовать в других командах. В этом плане полезна опция --abbrev-commit )
(можно использовать HEAD~N, чтобы указывать коммит, удалённый от самого нового на N или просто HEAD)
или возврат к коммиту:
Создать репозиторий:
localhost / # git initДобавить конфиг:
# git add path-to-config/config -f(ключ -f будет необходим только для новых файлов)
Посмотреть, что нового:
# git statusЧто конкретно нового:
# git diffВыбрать все изменённые файлы для коммита:
# git add -AКоммит:
# git commit [-m "message"](если без -m, то откроется редактор для описания коммита)
Комбинация из двух предыдущих команд:
# git commit -a [-m ...]История:
# git log [--stat](показывает в т.ч. хеши (object name) коммитов, которые можно использовать в других командах. В этом плане полезна опция --abbrev-commit )
Что изменилось между двумя коммитами:
# git diff COMMIT COMMIT(можно использовать HEAD~N, чтобы указывать коммит, удалённый от самого нового на N или просто HEAD)
Откат последнего коммита:
# git reset --hard HEAD~1или возврат к коммиту:
# git reset --hard COMMITОткат отката, переписывание истории
Восстановление одного файла
Изгонение душ удалённых файлов
Ветки и прочая
$ man git$ links http://git-scm.comИтого
У меня гит следит за следующими файлами:
/etc/bash/bashrc /etc/make.conf /etc/portage/env/splitdebug.conf /etc/portage/package.accept_keywords /etc/portage/package.unmask /etc/portage/package.use /etc/sudoers /var/lib/portage/world
