Заметки с тегом «git» (страница 2)

Уборка мусора в Git

Удалить все неиспользуемые объекты можно командой

git gc

После объединения ветки, в которой велась разработка, с основной веткой проекта всегда остается указатель на эту ветку. Ваш коллега может удалить её у себя в репозитории и даже удалить её во внешнем репозитории, но ваш локальный репозиторий всё ещё будет хранить информацию об этой ветке.

Удалить все ветки, которых нет во внешнем репозитории можно командой

git remote prune origin

Если даже на какой-либо объект нет явной ссылки, то на протяжении 30 дней на все объекты сохраняется ссылка в reflog . По этому когда производится уборка мусора все коммиты за последний месяц всё равно остаются в репозитории.

Чтобы избавиться от таких недоступных комитов, выполним последовательность команд


git reflog expire --expire=1.minute refs/heads/master
git fsck –unreachable
git gc
Комментарии к заметке: 2

Блоговский движок под системой контроля версий Git

Все файлы блоговского движка я храню в Git. Я не стану всем и каждому советовать сразу переходить на систему контроля версий. Очевидно, что для её развертывания потребуется как минимум VPS, навыки администрирования и, собственно, умение пользоваться ею. Иначе все плюсы обратятся в сплошные минусы.

Однако, преодолев все эти трудности можно получить некоторые преимущества.

Редактирование темы и плагинов

Благодаря Git редактировать файлы можно как на домашнем компьютере, так и прямо на сервере. При этом точно знаю, что ничего не «случайно» не потеряется или перезатрется.

Если один и тот же файл был изменен в разных местах, то система сама попробует решить конфликт. А если её это окажется не под силу, то предоставит вам эту возможность.

Обновление версии движка

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

Чтобы сохранить свои исправления я выработал такую схему работы

Дерево коммитов Git

В одной ветке (wp31 ) я храню исходные файлы дистрибутива и все новые версии разворачиваю только туда. А свои правки делаю в основной ветке (master).

После обновления я объединяю эти ветки. Если повезет, то никаких конфликтов не появляется, и в основной ветке я получаю новую версию движка. Чаще всего конфликты в коде все же есть. Но они, как правило, не значительные и легко решаются с помощью соответствующих утилит.

Развертывание изменений на сервере

Все действия сводятся к одной простой команде.

git pull

Если вдруг обнаруживаются какие-то дефекты, то старая версия блога возвращается на прежнее место за несколько секунд.

Резервное копирование

Каждый Git-репозиторий может стать резервной копией для других. Фактически у меня 3 идентичных копии: продакшин, внешний репозиторий и локальный репозиторий на домашнем компьютере. В случае повреждения одной из них, восстановить её можно будет из двух других копий.

54307730.19286420.1324395758.c7d8ac3d6d9658c7c572ebaca98a9ceb

Комментарии к заметке: 1

Работа с тегами в Git

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

Создание тега

  1. Помечаем локальный коммит

    git tag 12345
    
  2. Отправляем его во внешний репозиторий

    
    git push origin 12345
    

Удаление тега из репозитория

  1. Удаляем тег локально

    git tag -d 12345
    
  2. Удаляем его во внешнем репозитории

    git push origin :refs/tags/12345
    
    
  3. Оповещаем каким-либо способом коллег, чтобы они сделали у себя команду

    git fetch --tags
    

    Без оповещения нельзя обойтись из-за того, что положение тега в локальном репозитории не синхронизируется автоматически в внешним репозиторием. Это можно сделать только явно выполнив соответствующую команду.

Перемещение тега на другой коммит

  1. Принудительно перезаписываем тег

    
    git tag -f 12345
    
  2. Отправляем во внешний репозиторий с принудительной перезаписью

    
    git push --force origin 12345
    
  3. Оповещаем коллег как и в случае удаления тега.

Дополнение

Если не указан хеш-код объекта, то теггируется последний коммит в активном бранче. Чтобы отметить тегом произвольный коммит нужно последним аргументом передать весь его хеш-код.

git tag 12345 6ff87c4664981e4397625791c8ea3bbb5f2279a3

Отправить во внешний репозиторий все теги текущей ветки можно одной командой.

git push --tags
Комментарии к заметке: 4

Конфигурация проектов в gitosis

После того, как gitosis установлен и настроен доступ к нему из вне, можно переходить к созданию отдельных хранилищ проектов.

Для конфигурирования gitosis используется инфраструктура git. При инициализации нового репозитория всегда создается проект gitosis-admin, где хранятся файлы конфигураций и ключи доступа. Как только в этот проект делается комит с изменениями настроек они сразу же применяются. Это обеспечивается скриптом post-update. Нужно убедиться, что он может выполняться.

sudo chmod 755 /Users/git/repositories/gitosis-admin.git/hooks/post-update

Сделаем копию этого проекта на рабочем компьютере

git clone git@repo.local:gitosis-admin.git

В файле gitosis.conf содержится описание проектов и прав доступа к ним, а в директории keydir — публичные ключи других пользователей репозитория.

После того как необходимые изменения будут сделаны, выполните следующие команды, чтобы отправить их в репозиторий на сервере:


git commit -a -m "Комментарий к комиту"
git push

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

Исходная конфигурация в gitosis.conf

[gitosis]

[group gitosis-admin]
writable = gitosis-admin
members = user1

В строке members перечисляются имена ключей (без расширения .pub), которые лежат в папке keydir.

По аналогии добавим еще одну группу:

[group project1]
writable = project1
members = user1

Эти правила задают группу project1, в которую входит пока только 1 пользователь user1. Все пользователи из этой группы имеют доступ для записи в проект project1.

Сохраним изменения и опубликуем их в удаленный репозиторий.

Теперь создадим сам проект. На рабочем компьютере выполним команды:


mkdir project1
cd project1
git init
git remote add origin git@repo.local:project1.git

Было бы хорошо, если к этому моменту у вас уже были какие-либо файлы, которые можно отправить в репозиторий. Если таковых нет, то нужно создать пусть даже пустой файл, чтобы его опубликовать (потом этот файл можно удалить или отредактировать).

touch file.txt

Отправляем проект в удаленный репозиторий:


git add .
git commit -a -m 'init commit'
git push origin master:refs/heads/master

Проект с названием project1 будет создан на сервере в директории /Users/git/repositories/

Оставте свой комментарий

Установка и настройка git-репозитория на Mac OS X 10.6

Переустановка системы на домашнем сервере подтолкнула написать еще одну подробную инструкцию по настройке git-репозитория на Mac OS X 10.6 (Snow Leopard)

Установка и настройка gitosis

Предположим, что git-клиент уже установлен. В интернете можно с легкостью найти несколько готовых сборок. Он нам понадобится, чтобы загрузить gitosis

cd ~/Desktop
mkdir src
git clone git://eagain.net/gitosis.git
cd gitosis
sudo python setup.py install

Создадим пользователя, под которым мы будем подключаться к репозиторию. Это можно сделать из панели управления пользователями или из командной строки

Найдем не используемые uid и gui

sudo dscl . list /Users uid
sudo dscl . list groups gid

Предположим, что число 410 не используется в обоих случаях. Это будет нашим идентификатором.

Создаем группу git


sudo dscl . create groups/git
sudo dscl . create groups/git gid 410

Создаем пользователя git


sudo dscl . create users/git
sudo dscl . create users/git uid 410
sudo dscl . create users/git NFSHomeDirectory /Users/git
sudo dscl . create users/git gid 410
sudo dscl . create users/git UserShell /bin/bash
sudo dscl . create users/git Password '*'

Создаем домашнюю директорию пользователя

sudo mkdir /Users/git
sudo chown git /Users/git
sudo chgrp git /Users/git

Теперь для текущего пользователя на локальном компьютере сгенерируем ssh ключ, если его еще нет. Если ключ есть, то этот шаг пропускаем


ssh-keygen -t rsa

И копируем его на удаленный сервер

scp ~/.ssh/id_rsa.pub repo.local:/tmp/my_key.pub

Если же репозиторий создается на рабочем компьютере, то эта команда немного упрощается

cp ~/.ssh/id_rsa.pub /tmp/my_key.pub

Теперь на сервере выполним инициализацию репозитория

cd /Users/git
sudo -H -u git gitosis-init < /tmp/my_key.pub

При удачном раскладе вы должны увидеть сообщения вроде этих


Initialized empty Git repository in /Users/git/repositories/gitosis-admin.git/
Reinitialized existing Git repository in /Users/git/repositories/gitosis-admin.git/

Устанавливаем переменную PATH для пользователя git

sudo su git
echo "export PATH=$PATH" > ~/.bashrc
exit

На этом настройку gitosis можно считать законченной. Проверим подключение к репозиторию из вне.

git clone git@repo.local:gitosis-admin.git

Если вы увидите сообщение


Cloning into gitosis-admin...
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (5/5), done.
remote: Total 5 (delta 0), reused 5 (delta 0)
Receiving objects: 100% (5/5), done.

то значит все сделано правильно и можно переходить к конфигурации проектов и прав доступа к ним для разных пользователей.

Потенциальные проблемы

Когда я настраивал gitosis в первый раз, то долго бился над тем, что подключение по SSH для пользователя git ни как не устанавливалось. Причина этому, как выяснилось позже, послужило ограничение доступа по SSH только администраторам.

Общий доступ → Удаленный вход

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

Комментарии к заметке: 1