Git в помощь админу локалхоста
В очередной раз утратив ценный конфиг из-за перепутанных шелловых > и >>, я, наконец, понял,
что пора делать бекапы.
Можно делать копии конфигов куда-то в укромное место на диске, можно сделать rsync на удалённый сервер
или понаписать хитрых велосипедообразных скриптов.
Но самое удобное решение находится уже прямо под руками: создать git репозиторий в корне.
Если ещё кто не знает, git не вынуждает нас поднимать какой-либо сервер. Вообще, репозиторий в git — это прежде всего локальная сущность, даже более того, репозиторий — это один единственный каталог .git. Что же до возможностей взаимодействия с внешними репозиториями, то ими никто не обязывает пользоваться.
А теперь технические детали.
Здравый смысл или профилактика отстреливания конечностей
Пункт номер раз: Фильтровать вхождения по путям и держать весь /etc в репозитории — это неудобный подход.
Во-первых, в /etc полно дефолтного мусора (с т.з. ценности для нас оных конфигов),
во-вторых, я, например, хочу держать /var/lib/portage/world так же близко к сердцу, как и некоторые файлы из /etc.
Пункт номер два: Если вам когда-нибудь захочется выложить свой репозиторий конфигов на гитхаб,
ваш /etc/ssh/ssh_host_rsa_key может привлечь неожиданно много внимания [1] местных юзеров.
Исходя из этого, определяем содержимое файла .gitignore (указывает файлы, которые не будет автоматически предлагаться для добавления, а также исключения из этих же правил)
/.gitignore (запрещаем всё) :
*
Да-да, ничего лишнего. Суть в том, что git уже добавленные (каким-либо образом вопреки .gitignore) файлы обрабатывает как обычно, а новые автоматически предлагаться к добавлению уже не будут.
Итого, достаточно один раз добавить конфиг через
add -f path-to-config/config
и впредь его можно будет коммитить через commit -a или add -A.
Немного о git
not in index (untracked) — [новые] файлы, которые мы отсеяли через .gitignore
unstaged — измененённые/новые файлы, которые ещё не выбраны для коммита.
staged — соответственно, выбранные для коммита через add.
Посмотреть список изменённых файлов можно через
# git status
или для просмотра всех отслеживаемых файлов
# git ls-files
Иллюстрация [2] (с тем лишь замечанием, что stage — это синоним add и, соответственно, новый файл можно сразу коммитить без «edit the file»)
Рецепты:
Создать репозиторий:
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 [3]
Итого
У меня гит следит за следующими файлами:
/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
Автор: TheRipper
Источник [4]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/linux/48806
Ссылки в тексте:
[1] неожиданно много внимания: http://www.securityweek.com/github-search-makes-easy-discovery-encryption-keys-passwords-source-code
[2] Иллюстрация: http://git-scm.com/figures/18333fig0201-tn.png
[3] http://git-scm.com: http://git-scm.com
[4] Источник: http://habrahabr.ru/post/202880/
Нажмите здесь для печати.