Git в помощь админу локалхоста

от автора

В очередной раз утратив ценный конфиг из-за перепутанных шелловых > и >>, я, наконец, понял,
что пора делать бекапы.

image

Можно делать копии конфигов куда-то в укромное место на диске, можно сделать 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.

Посмотреть список изменённых файлов можно через
# git status
или для просмотра всех отслеживаемых файлов
# git ls-files

Иллюстрация (с тем лишь замечанием, что stage — это синоним add и, соответственно, новый файл можно сразу коммитить без «edit the file»)

Рецепты:

Ничего нового для тех, кто уже пользуется git'ом

Создать репозиторий:

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

ссылка на оригинал статьи http://habrahabr.ru/post/202880/


Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *