Если Вы достаточно длительное время используете UNIX/Linux, то у вас уже вероятно имеются хорошо «заточенные» файлы онфигурации Bash, Vim, Emacs и других приложений. Копирование вручную этих файлов между всеми системами, с которыми вы работаете, может быть весьма утомительным процессом. Git может существенно облегчить ваши мучения из-за копирования ваших конфигурационных файлов на новые компьютеры.
Кто-то использует  Dropbox,rsync, Duplicity или Unison, однако они не позволяют сохранять версионность файлов, и хранят лишь одну-единственную копию файла с самыми последними изменениями. Попробуем использовать для этих нужд Git.

Вкратце опишем перечень шагов, которые нам предстоит сделать в процессе изучения данного материала:

• создать ключи SSH, чтобы не приходилось авторизоваться паролем;
  
• установить Git на всех системах где будем его использовать;
  
• создать «голый» (bare) репозиторий на удалённой системе;
  
• создать репозиторий в локальной системе, файлы с которой будем синхронизировать;
  
• добавить файлы в локальный репозиторий;
  
• сделать слепок (commit) добавленных файлов;
  
• отправить (push) изменения в удалённый репозиторий;
  
• сделать изменения в локальных файлах и сделать слепок изменений;
  
• клонировать репозиторий на другую систему.

Начало

Первое, что нам понадобится — это система, которая будет хранить наш Git-репозиторий. У нас должна быть возможность подключаться к ней по SSH. Это может быть как компьютер в локальной сети, так и система, расположенная в Интернет. Даже можно использовать онлайн-сервис GitHub, если нет подходящего компьютера.
Первым делом нам необходимо создать пару SSH-ключей и настроить аутентификацию на удалённой системе. Чтобы каждый раз не вводить пароль, можно сгенерировать закрытый ключ без пароля, однако нужно не забывайть о том, что если кто-то сможет заполучить этот ключ, то он сможет авторизоваться по SSH на удалённой системе.
Процесс генерации ключей выглядел так:

$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/xxxxxх/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/xxxxxх/.ssh/id_dsa.
Your public key has been saved in /home/xxxxxх/.ssh/id_dsa.pub.
The key fingerprint is:
f0:59:19:5d:69:c7:4c:62:d0:c1:38:fe:f1:2b:2d:2c xxxхxx@home
The key's randomart image is:
+--[ DSA 1024]----+
|          ...*=*.|
|           o+.=.+|
|      .   o. o . |
|       o o  . .  |
|        S    . o |
|              . .|
|            . . .|
|           E + o |
|            . o  |
+-----------------+

После того, как пара ключей создана, закрытый ключ будет размещён в в ~/.ssh/id_dsa, а открытый — в~/.ssh/id_dsa.pub. Теперь, чтобы удалённая система аутентифицировала  нас на основе ключа, а не пароля, необходимо скопировать содержимое локального файла ~/.ssh/id_dsa.pub в файл~/.ssh/authorized_keys на удалённой системе. В  Debian/ Ubuntu для этих целей есть специальный shell-скрипт ssh-copy-id, им и воспользуемся:

$ ssh-copy-id xxхxxx@server
xxхxx@server's password:
Now try logging into the machine, with "ssh 'xxхxxx@server'", and check in:

  .ssh/authorized_keys
to make sure we haven't added extra keys that you weren't expecting.

Пользователи же других систем, в которых ssh-copy-id отсутствует, могут воспользоваться старой-доброй scp:

$ scp /home/xxхxxx/.ssh/id_dsa.pub xxххxx@server:/home/xхxxxx/.ssh/authorized_keys

Тут нужно быть внимательным т. к. если в ~/.ssh/authorized_keys на удалённой системе у нас уже имеются какие-то ключи, то нужно добавить вручную открытый ключ к существующим, поскольку приведённая выше команда затрёт существующий файл.
Ну и, само-собой разумеется, в наших системах, которые будут участвовать в работе, должен быть установлен Git. На сегодняшний день Git присутствует в репозиториях всех современных дистрибутивов, а также в коллекции портов FreeBSD, так что у нас не должно возникнуть сложностей с его установкой. Для установки git в Ubuntu можно воспользоваться:

$ sudo apt-get install git-core

Создание репозиториев

Пришло время создавать репозитории. Начнём с создания репозитория на удалённой системе, затем создадим локальный, в который и добавим файлы. Подключимся к удалённой системе по SSH:

$ ssh xxxxхx@server

создадим каталог для хранения репозитория:

$ mkdir project

и создадим в этом каталоге «голый» Git-репозиторий:

$ cd project && git init --bare
Initialized empty Git repository in /home/хххххх/project/

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

$ cd ~/ && git init
Initialized empty Git repository in /home/xxxхxx/.git/

Репозиторий успешно создан и прежде, чем продолжить работу, минимально настроим Git, а точнее определим имя и email, которые будут упоминаться к истории коммитов (слепков):

$ git config --global user.name "хххххх хххххх"
$ git config --global user.email "хххххх@list.ru"

Теперь добавим что-нибудь в репозиторий, указывая Git отслеживать изменения:

$ git add .vim
$ git add .vimrc

Далее сделаем слепок состояния добавленных файлов, указав при помощи опции -m комментарии к слепку:

$ git commit -m 'Первый слепок'
[master (Браузер 0pera-commit) f4c5dcf] Первый слепок
 4 files changed, 90 insertions(+), 0 deletions(-)
 create mode 100644 .vim/.netrwhist
 create mode 100644 .vim/spell/ru.utf-8.spl
 create mode 100644 .vim/spell/ru.utf-8.sug
 create mode 100644 .vimrc

Отлично, файлы и каталог успешно добавлены, теперь можно «слить» локальный репозиторий в удалённый. Для начала необходимо в локальном репозитории определить один или несколько  удалённых, с которыми Git сможет производить синхронизацию. Добавим ранее созданный удалённый репозиторий project на удалённой системе server, доступ к которой у нас настроен от имени пользователя хххххх:

$ git remote add origin ххххх@server:project

И отправим изменения из локального репозитория:

$ git push origin master
Counting objects: 8, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (8/8), done.
Writing objects: 100% (8/8), 2.37 MiB | 462 KiB/s, done.
Total 8 (delta 0), reused 0 (delta 0)
To хххххх@server:project
 * [new branch]      master -> master

Отслеживание изменений

После того, как сделали первый слепок и отправили изменения в удалённый репозиторий, самое время разобраться с тем, как отслеживать изменения в файлах. Сделаем какое-нибудь незначительное изменение, например, в файле .vimrc и сделаем после этого слепок состояния всех отслеживаемых файлов:

$ git commit -a -m 'Изменён .vimrc'
[master 0d6096f] Изменён .vimrc
 1 files changed, 0 insertions(+), 1 deletions(-)

Теперь можено отправить изменения в удалённый репозиторий:

$ git push origin master
Counting objects: 5, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 317 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
To хххххх@server:project
   f4c5dcf..0d6096f  master -> master

Копирование файлов на другие системы

Пришло время «размножить» конфигурационные файлы на тех системах, где это нам нужно. Авторизуемся в нужной системе и создадим в домашнем каталоге новый  Git-репозиторий, как это делали ранее:

$ cd ~/ && git init
Initialized empty Git repository in /home/хххххх/.git/

И теперь скопируйте файлы удалённого репозитория на диск:

$ git pull хххххх@server:project
remote: Counting objects: 11, done.
remote: Compressing objects: 100% (11/11), done.
remote: Total 11 (delta 1), reused 0 (delta 0)
Unpacking objects: 100% (11/11), done.
From server:project
 * branch            HEAD       -> FETCH_HEAD

Если сделать изменения в каком-то из отслеживаемых файлов на любой системе, достаточно просто воспользоваться командами git commit и git push, как это было показано выше и изменения будут доставлены в удалённый репозиторий, после чего можно их загрузить во все локальные репозитории систем, в которых эти версии файлов необходимы, при помощи команды git pull.
Тут нужно обратить внимание на то, что используется git pull, а не git clone, поскольку нам нужно получать именно изменения в файлах, а не весь репозиторий целиком.

Управление версиями

По ходу работы можете добавлять в репозиторий новые файлы для отслеживания при помощи команд git add и удалять ненужные при помощи git rm. Если необходмо узнать, какие файлы находятся в состоянии «отслеживаемых», воспользуемся командой git ls-files:

$ git ls-files
.vim/.netrwhist
.vim/spell/ru.utf-8.spl
.vim/spell/ru.utf-8.sug
.vimrc

Что делать, если случайно сделали ненужные изменения в локальном файле и хотим восстановить версию, находящуюся в последнем слепке? Для этого существует команда git checkout. Например, следующая команда восстановит последнюю версию файла .vimrc:

$ git checkout .vimrc

Просмотреть историю слепков можно при помощи команды git log:

$ git log
commit 0d6096f96c647e8b1bdfb6a217cbae967b16a5cd
Author: хххххх
Date:   Fri Apr 22 02:46:15 2011 +0300

    Изменён .vimrc

commit a7c5dcf4f4c89ab8b495f6e29afb1afc21b6678a
Author: хххххх
Date:   Fri Apr 22 01:54:14 2011 +0300
    Первый слепок

Обратим внимание на 40-битное значение хэша слепка. Оно уникально идентифицирует каждый коммит, так что можно обращаться к нему. В частности иногда бывает полезно восстановить не отдельный файл а весь слепок целиком. Для этого достаточно команде git revert передать хэш-значение нужного слепка:

$ git revert 0d6096f96c647e8b1bdfb6a217cbae967b16a5cd
Finished one revert.
[master 933c16f] Revert "Изменён .vimrc"
 1 files changed, 1 insertions(+), 0 deletions(-)

Резюме

Хотя Git далёк от определения дружественной пользователям утилиты, разобраться с основами его использования не так уж и сложно. Данная заметка никоим образом не претендует на описание принципов работы Git, а лишь рассказывает об идее применения этой очень мощной утилиты для нужд рядовых пользователей и системных администраторов. Git обладает огромными возможностями и если это интересно, и хотелось бы подробней узнать о них, рекомендуется начать с замечательной книги Pro Git, в большей части уже доступной на русском языке.

(с) ashep, проверено и подтверждено: bender