Основы работы с git

Основные постулаты работы с кодом:

• Каждая задача решается в своей ветке.
• Коммитим сразу, как что-то получили осмысленное.
• В master мержится не разработчиком, а вторым человеком, который производит вычитку и тестирование изменения
• Все коммиты должны быть осмысленно подписаны.
• Репозиторий должен держаться сухим и шелковистым

Инструкция-шпаргалка для начинающих

Git Wizardry. Азы.

Плюс настройка gitolite


Вариант ssh, авторизация только от 1 юзера - git. Нет контроля, кто вносил изменения, но для введения и 1 человека - достаточно.
Как просто создать удаленный GIT репозитарий на домашнем сервере

Если работают больше 1 человека - нужны доп утилиты. Связано это с тем, что в гит вообще нет контроля пользователей (привет обычные системы контроля, где те же юзеры в conf/passwd). [1] Поэтому нужны доп модули вроде gitolite
Gitolite allows a server to host many git repositories and provide access to many developers, without having to give them real userids on the server. The essential magic in doing this is ssh's pubkey access and the authorized keys file, and the inspiration was an older program called gitosis.
Gitolite can restrict who can read from (clone/fetch) or write to (push) a repository. It can also restrict who can push to what branch or tag, which is very important in a corporate environment. Gitolite can be installed without requiring root permissions, and with no additional software than git itself and perl. It also has several other neat features described below and elsewhere in the doc/ directory.

Также есть вариант gitosis
Gitosis — это набор скриптов, реализующих удобное управление git-репозиториями и доступом к ним. Работает это так:

— на сервере заводится пользователь, которому будут принадлежать все репозитории
— все обращения к репозиториям происходят по SSH, под именем этого пользователя, авторизация пользователей производится по ключам
— при входе по SSH автоматически запускаются скрипты gitosis, которые, в зависимости от настройки, разрешают или запрещают дальнейшие действия с репозиториями

Что выбрать? Кто-то говорил, что гитозис перестали поддерживать, а по гитолайту мало документации. Впрочем, в гугле много доков from gitosis to gitolite
типа этой.
Или установка с нуля, требуется подключение репы epel:
# yum install gitolite
# adduser -m git
# ssh-keygen -f ~/.ssh/id_rsa -b 2048 -N ''
# cp ~/.ssh/id_rsa.pub /tmp/admin.pub
# sudo su git
$ gl-setup -q /tmp/admin.pub

Тут у меня вылезла ошибка
fatal: empty ident not allowed
про которую ничего не было в инет-мануалах.
Зададим ему данные о себе.
$ git config --global user.name "me"
Снова запустим установку
$ gl-setup -q /tmp/admin.pub
...
2 files changed, 6 insertions(+), 0 deletions(-)
create mode 100644 conf/gitolite.conf
create mode 100644 keydir/admin.pub

Теперь проверим работу
$ssh git@localhost info
Если спросит пароль: http://sitaramc.github.com/gitolite/sts.html#stsapp1_
Вкратце:

1. (от себя) проверить, что запрашиваем от нужного юзера. Что это? Мы указывали ключ конфигуратору, соответственно проверки будут работать пока только от этого же пользователя. От самого git - не будет. Надо его ключ потом закидывать в базу, чтобы он же прописался в authorized_keys.
2. Проверить, что запрашивает именно пароль (password), а не ключевую фразу ключа (passphrase). У них разный вывод.
3. Проверить права на файлы и каталоги, относящиеся к ключам
4. Убедиться, что в /etc/ssh/sshd_config нет AllowUsers или наш юзер там прописан, иначе не пустит
5. Некоторые ОС хотят, чтобы у юзера git был пароль и аккаунт был не залочен. centos-у пароль не нужен, а вот аккаунт скорее всего не должен быть залочен

Теперь можно работать.
# git clone gito@localhost:testing.git
# cd testing/
# ls -a
. .. .git

Поскольку репа только создана, она пустая. Заполним чем-нибудь.
# echo "Test" > test.txt
# git add test.txt
Тут можно словить [2]
Далее. Закоммитим наши изменения.
#git commit -m 'Initial commit of testing repository'

Работает. Но теперь надо настроить основной шаблон.
# cd ~
# mkdir gitolite-admin
# git clone git@localhost:gitolite-admin.git gitolite-admin
# cd gitolite-admin/
В conf находится конфиг, где настраиваются права
в keydir надо класть ключи наших пользователей.

Если мы хотим формировать ключи на сервере и выдавать их пользователям:
$ mkdir keys
$ cd keys/
$ ssh-keygen -f user1 -N ''
$ copy user1.pub ../gitolite-admin/keydir
Это скопирует ключ для всех проектов и при clone добавит его на новые проекты. Если надо дать этому ключу права в 1 репу - копируем в repo.git/keydir/
Есть готовый ключ. Если надо под винды - открываем его и импортируем в puttygen, сохраняем пару открытый+закрытый...






Для добавления нового пользователя достаточно скопировать публичный ключ в папку gitolite-admin/keydir
После изменений с gitolite-admin необходимо сделать Commit и Push, сервер автоматически создаст необходимые новые репозитории и следующим шагом может уже являться клонирование.

https://gist.github.com/1318214

Варианты доступа к репам: ssh, http, git read-only (крайне убогий вариант, поэтому RO). Есть вариант через webdav, но применение крайне специфичное.

Git-протокол

Следующий протокол ― Git-протокол. Вместе с Git поставляется специальный демон, который слушает порт 9418 и предоставляет сервис схожий с протоколом ssh, но абсолютно без аутентификации. Чтобы использовать Git-протокол для репозитория, вы должны создать файл git-export-daemon-ok, иначе демон не будет работать с этим репозиторием, но следует помнить, что в протоколе отсутствуют средства безопасности. Соответственно любой репозиторий в Git может быть либо доступен для клонирования всем, либо не доступен никому. Как следствие обычно вы не можете отправлять изменения по этому протоколу. Вы можете открыть доступ на запись, но из-за отсутствия авторизации в этом случае кто угодно зная URL вашего проекта сможет его изменить. В общем, это редко используемая возможность.
http://progit.org/book/ru/ch4-1.html

Небольшое замечание. Если создается bare репа, правильное название должно быть вида project.git - тут .git говорит о том, что это bare. Принято так.

Комментарии
[1] Поскольку система децентрализованная, пароли хранить в открытом виде вообще запрещено. Да и список юзеров тоже нежелательно - можно клонировать чужую репу, получить список пользователей и попытаться подобрать под них пароль. Даже права на файлы/директории/коммиты/... - уже может многое рассказать. С другой стороны, поскольку нет единого сервера, мастер хранилищем может стать любое доступное (другой вопрос, что и все проекты и разработчики должны на него перейти, в чём основная сложность). Возможно, из-за этого и возникла эта проблема.

[2]fatal: LF would be replaced by CRLF in ...
Для лучшей переносимости часто устанавливают
#git config --global core.autocrlf true
#git config --global core.safecrlf true
С одной стороны это позволяет правильно преобразовывать текстовые документы к юникс-виду, с другой - бинарные файлы могут оказаться битыми. Плюс вот так может ругаться.
Надо отключить автоконверт
# git config --global core.autocrlf false
или сконвертировать все файлы к нужному формату.
"core.safecrlf true - эта опция нуна, чтобы предотваратить автозамену lf<->crlf. Такое бывает полезно, если у вас какие-то специфические бинарники, очень похожие на текстовые файлы.

core.safecrlf warn - позволяет проводить автозамену, но с руганью в консоле в виде варнингов.

У меня используется core.autocrlf true, core.eol native(по умолчанию) , core.safecrlf false(по умолчанию)"
отсюда

[3] подключение из мира
Подключение идёт через ssh, то есть 22 порт. Но зачастую он слушает на другом порту или просто замаплен на гейте на другой. В этом случае надо указывать, через какой порт мы подключаемся.


Links
Как начать работать с GitHub: быстрый старт (есть примеры вин и лин клиентов)
Удачная модель ветвления для git
Командная работа в git
19. Gitolite + git настройка
Pro git

VCS=versioning control system, это все системы контроля версий которые бывают.