ZebotonВ данной заметке я расскажу о моём опыт работы с системами контроля версий, а также о том почему я выбрал git, как установил его и gitosis и как их настроил.
Пропустить теорию и перейти к практике.
1. Что такое git?
Git — распределённая система контроля версий файлов. Подробнее можно прочитать в Википедии.
Если же попытаться объяснить в двух словах зачем это нужно, то я бы сделал это так. Предположим вы один реализуете какой-то программный проект. Одна из ключевых стадий — кодирование. Предположим что вы сегодня внесли какие-то изменения в некий файл своего проекта, причём не добавили что-то, а наоборот удалили. Спустя два месяца, вы поняли то что вы когда-то удалили вам бы сейчас очень пригодилось. Если проект разрабатывался без системы контроля версий, то вам пришлось бы искать в резервных копиях (Кстати, а знаете ли вы что люди делятся на тех кто не делает резервные копии и тех кто уже делает резервные копии? Вы к кому относитесь?) нужный архив и из него восстанавливать нужный код. Но если же у вас была система контроля версий, то восстановить утерянный код не составит никакого труда, так как эти системы в общем (но не только) для этого и предназначены. А теперь представьте что вы работает не один, а в команде. Как уследить за всеми изменениями, производимыми другими членами команды, и как не удалить их код своим? Правильно — нужно использовать систему управления версиями файлов.
Добавлено 4 марта 2011 04:41
Очень полезная статья для новичков Git меняет правила игры в распределенной Web-разработке.
1.1. Git не единственный?
Нет, конечно же git не единственная система контроля(управления) версиями файлов.
Об отличиях и преимуществах git над другими система данного класса написано много статей, а вся их суть, на мой взгляд, высказана на сайте Why Git is Better Then X (eng).
2. Для чего git понадобился мне
Я в силу своей профессии тоже пишу программный код. Есть проект над которым в данном направлении я работаю один, но из разных мест: офис, дом. И переносить исходный код с компьютера на компьютер в ручную мне надоело, да и делается это всё сложнее и сложнее в связи с разрастанием проекта.
Раньше в одном из проектов, над которым тоже работал один, я использовал svn. Но меня очень сильно раздражало наличие в каждом каталоге моего проекта папки .svn . Да и ветвление в svn мне не очень нравилось, хотя не исключаю что я его мог не правильно использовать.
В результате я решил использовать в текущем проекте git.
2.1. Начало знакомства
У git есть официальный сайт с гигантской документацией и не очень понятным учебным пособием, особенно если учесть что хотелось сначала не научиться пользоваться git, а понять как же я его смогу использовать в своём проекте.
На просторах Хабра я наткнулся на несколько статей, которые мне помогли разобраться с тем что такое git и как его правильно готовить за очень короткое время:
Git Workflow (копия)
Git Wizardry (копия)
Командная работа в Git (оригинал) (копия)
Без их прочтения и осмысления дальше лучше на идти.
3. Установка и настройка git и gitosis
В данном разделе я перескажу процесс установки git и gitosis, описанный на многих сайтах, с моими комментариями.
3.1. Подготовка к установке
В процессе установки нам понадобится сервер (server), две рабочие станции — компьютер (comp) и, предположим, ноутбук (note).
3.2. Установка git
3.2.1. Сам git устанавливается одной строчкой:
view sourceprint?
1.
sudo apt-get install git-core
Установку нужно произвести на всех компьютерах, которые будут работать с git.
3.3. Установка и настройка gitosis на сервере
Для более удобной работы с git есть набор скриптов под названием gitosis, которые позволяют легко управлять несколькими хранилищами и ограничивать права доступа к ним разным людям.Естественно, можно обойтись и без них, но после серии тестов я решил, что с ними работать удобнее.Итак, приступим.
ЗАМЕЧАНИЕ: команды идут после знака $
3.3.1. Установим необходимые пакеты для работы с python скриптами:
3.3.4.а. В общем-то теперь можно вернуться в домашний каталог и удалить исходные коды, они нам больше не нужны:
view sourceprint?
1.
serg@server:~/src/gitosis$ cd ~
2.
serg@server:~$ rm -rf src
Теперь важный момент, который описывался только в одном руководстве по установке gitosis из множества, что я перечитал, но и то вскользь: есть пользователи ОС, а есть пользователи git. Это разные пользователи! Для ОС пользователи git не существуют! Пользователи git определяются ключами авторизации.
Во всех инструкциях по установке git я видел, что создаётся новый пользователь с именем git и потом все действия выполняются через него. На самом деле этого можно не делать и установить git в домашнюю директорию любого пользователя ОС. Но в этом случае в файле ~/.ssh/authorized_keys этого пользователя не должно быть никаких других записей или они должны быть закомментированы!
3.3.5. Если кто-то хочет, то может создать нового пользователя и домашний каталог для git:
ЗАМЕЧАНИЕ: Если в настройках ssh (/etc/ssh/sshd_config) у вас есть список AllowUsers, то нужно туда добавить и этого пользователя (разделителем для разрешённых имён пользователя является пробел)! После этого нужно перезапустить ssh сервер: serg@server:~$ sudo /etc/init.d/ssh restart
3.3.6. Если у вас уже есть ключ авторизации для вашего пользователя, то можно перейти к следующему шагу, а если вы создали нового пользователя или хотите создать новый ключ авторизации, то выполняем:
view sourceprint?
1.
serg@server:~$ ssh-keygen -t dsa
В ssh-keygen можно создавать ключи с алгоритмом dsa и rsa. dsa используются в качестве подписи, а rsa в основном для шифрования данных. Так как мы собираемся всего лишь отличать одного пользователя от другого, а не шифровать данные, то можно использовать dsa.
После того как ключи были созданы. можно устанавливать gitosis.
3.3.7.а. Если вы создали нового пользователя с именем git, то выполните:
Ключ авторизации можно было создать и на клиентской машине, с которой будете управлять gitosis, а потом передать его публичную часть (.pub) на сервер. Но если вы создали ключи на сервере, то не забудьте забрать секретную часть ключа (без расширения) на клиентскую машину.
3.3.8. Теперь нужно установить правильные права доступа на определённый каталог (этот шаг необходим из-за особенностей python в разных дистрибутивах):
На этом установка и настройка сервера, по мнению многих руководств, завершена. Я бы посоветовал сделать ещё одно действие.
3.3.9. Установить уровень вывода информации gitosis в положение DEBUG:
view sourceprint?
1.
serg@server:~$ sudo nano .gitosis.conf
Текст в этом файле должен выглядеть так:[gitosis]loglevel = DEBUG[group gitosis-admin]writable = gitosis-admin
members = serg@server
ЗАМЕЧАНИЕ: Если вы создавали пользователя, то путь к файлу будет другим! Но такой файл всё равно должен быть в корневой директории того пользователя в чью домашнюю папку устанавливался gitosis.
Вот теперь переходим на рабочую станцию, с которой будем управлять хранилищами.
3.4. Настройка gitosis на клиенте (рабочей станции)
Секретная часть ключа авторизации, который был создан на сервере (п.3.3.6.), должна быть в папке ~/.ssh/пользователя рабочей станции от чьего имени будут управляться gitosis.
ЗАМЕЧАНИЕ: Если порт сервера отличается от стандартного или вы связываетесь с сервером в локальной сети по IP, а хотите по имени, то можно добавить в папку ~/.ssh/ конфигурационный файл config:
view sourceprint?
1.
Host server
2.
User serg
3.
Port 9876
4.
IdentityFile ~/.ssh/serg_dsa
В случае замены IP адреса на имя нужно ещё внести изменения в файл /etc/hosts на рабочей станции. В файле уже имеется пример как это правильно делается.
3.4.1. Теперь можно начать настраивать gitosis. Получаем копию репозитория с сервера и переходим в его папку:
3.5. Добавление правил доступа для нового хранилища
Для того чтобы добавить новое хранилище test нужно добавить в конец файла gitosis.conf содержимое, подобное этому:
[group testers]
members = serg@server tester
writable = test
В строке members указывается какие пользователи будут иметь доступ к хранилищу (test) на чтение и запись (writable). Название группы (testers) нигде не используется, так что может быть абсолютно любым.
Добавлено 14 марта 2010: Название группы в файле gitosis.conf должно быть уникальным!
Предположим, что открытая часть ключа пользователя tester, который работает за другой рабочей станцией (note) уже помещена в папку keydir.
3.5.1. Теперь нужно отправить изменения на сервер:
view sourceprint?
1.
serg@comp:~/gitosis-admin$ git add .
2.
serg@comp:~/gitosis-admin$ git commit -a -m "Созданы правила для нового хранилища test"
3.
serg@comp:~/gitosis-admin$ git push
Всё, данные ушли. Осталось создать само хранилище.
3.6. Создание нового хранилища
Так как пользователь gitosis tester также имеет право записи в хранилище test, как и пользователь serg@server, то создадим хранилище из под него. Хранилище может располагаться где угодно в области доступной пользователю.
ЗАМЕЧАНИЕ1: Обратите внимание на последнюю строку — это не простой push!
ЗАМЕЧАНИЕ2: В строке где указывается ссылка на внешнее хранилище (git remote add origin...) имя пользователя, то есть то что стоит до @ всегда должно быть такое же как имя пользователя ОС в чей домашней директории расположены хранилища на сервере! О том что в каталоге ~/.ssh текущего пользователя должна лежать секретная часть ключа авторизации в gitosis напоминать не надо? (Вторая часть ключа из допущения в п.3.5.)
3.7. Создание публичного доступа к хранилищу
Если нужно организовать публичный доступ к какому-либо хранилищу, то это делается следующим образом:
Надеюсь данный материал помог вам сэкономить несколько дней, которые понадобились мне чтобы во всём этом разобраться.
Похожие записи:
Делаем из нетбука карманный web-сервер.
16 комментариев для "Установка и настройка git и gitosis в Ubuntu”
Сергей
8 декабря 2009 ~ 13:45
Спасибо, сегодня, думаю, попробую все это повторить!
Ответить
Zeboton
26 декабря 2009 ~ 15:58
Если на сервере есть несколько веток, то при клонировании получается только master. Пример результата клонирования:
$ git branch -a
* master
remotes/origin/HEAD -> origin/master
remotes/origin/master
remotes/origin/branch1
remotes/origin/branch2
Для того чтобы получить и связать остальные ветки нужно проделать следующие операции:
$ git checkout -b branch1
$ git pull origin branch1
$ git checkout master
$ git checkout -b branch2
$ git pull origin branch2
В первой строке создаётся локальная ветка branch1. Переход к ней осуществляется автоматически.
Вторая строка получает содержимое branch1 с сервера в локальную branch1 и связывает локальную ветку с веткой на сервере.
В третьей строке происходит возврат к ветке мастер. Это нужно сделать для того чтобы в локальной branch2 не оказалось содержимое branch1. Скорее всего это костыль, но только из ветки master у меня получилось правильное создание веток.
Четвёртая строка создаёт локальную ветку branch2. Переход к ней осуществляется автоматически.
Пятая строка получает её содержимое с сервера и связывает локальную ветку с веткой на сервере.
ВАЖНОЕ ЗАМЕЧАНИЕ!!!
Связывание веток произошло только для получения данных с сервера. Для отправки данных на сервер нужно указывать все параметры push!
git push origin branch1:branch1
branch1 (до двоеточия) — локальная ветка.
branch1 (после двоеточия) — ветка на сервере.
Добавлено 10 февраля 2011
Как сделать, чтобы ветки автоматически корректно отправлялись на сервер читайте в комментарии от 10 февраля 2011
Установка и настройка git и gitosis в Ubuntu
7 декабря 2009
Рубрика: Ubuntu, ЗаметкиТеги: git, gitosis
ZebotonВ данной заметке я расскажу о моём опыт работы с системами контроля версий, а также о том почему я выбрал git, как установил его и gitosis и как их настроил.
Пропустить теорию и перейти к практике.
1. Что такое git?
Git — распределённая система контроля версий файлов. Подробнее можно прочитать в Википедии.
Если же попытаться объяснить в двух словах зачем это нужно, то я бы сделал это так. Предположим вы один реализуете какой-то программный проект. Одна из ключевых стадий — кодирование. Предположим что вы сегодня внесли какие-то изменения в некий файл своего проекта, причём не добавили что-то, а наоборот удалили. Спустя два месяца, вы поняли то что вы когда-то удалили вам бы сейчас очень пригодилось. Если проект разрабатывался без системы контроля версий, то вам пришлось бы искать в резервных копиях (Кстати, а знаете ли вы что люди делятся на тех кто не делает резервные копии и тех кто уже делает резервные копии? Вы к кому относитесь?) нужный архив и из него восстанавливать нужный код. Но если же у вас была система контроля версий, то восстановить утерянный код не составит никакого труда, так как эти системы в общем (но не только) для этого и предназначены. А теперь представьте что вы работает не один, а в команде. Как уследить за всеми изменениями, производимыми другими членами команды, и как не удалить их код своим? Правильно — нужно использовать систему управления версиями файлов.
Добавлено 4 марта 2011 04:41
Очень полезная статья для новичков Git меняет правила игры в распределенной Web-разработке.
1.1. Git не единственный?
Нет, конечно же git не единственная система контроля(управления) версиями файлов.
Об отличиях и преимуществах git над другими система данного класса написано много статей, а вся их суть, на мой взгляд, высказана на сайте Why Git is Better Then X (eng).
2. Для чего git понадобился мне
Я в силу своей профессии тоже пишу программный код. Есть проект над которым в данном направлении я работаю один, но из разных мест: офис, дом. И переносить исходный код с компьютера на компьютер в ручную мне надоело, да и делается это всё сложнее и сложнее в связи с разрастанием проекта.
Раньше в одном из проектов, над которым тоже работал один, я использовал svn. Но меня очень сильно раздражало наличие в каждом каталоге моего проекта папки .svn . Да и ветвление в svn мне не очень нравилось, хотя не исключаю что я его мог не правильно использовать.
В результате я решил использовать в текущем проекте git.
2.1. Начало знакомства
У git есть официальный сайт с гигантской документацией и не очень понятным учебным пособием, особенно если учесть что хотелось сначала не научиться пользоваться git, а понять как же я его смогу использовать в своём проекте.
На просторах Хабра я наткнулся на несколько статей, которые мне помогли разобраться с тем что такое git и как его правильно готовить за очень короткое время:
Git Workflow (копия)
Git Wizardry (копия)
Командная работа в Git (оригинал) (копия)
Без их прочтения и осмысления дальше лучше на идти.
3. Установка и настройка git и gitosis
В данном разделе я перескажу процесс установки git и gitosis, описанный на многих сайтах, с моими комментариями.
3.1. Подготовка к установке
В процессе установки нам понадобится сервер (server), две рабочие станции — компьютер (comp) и, предположим, ноутбук (note).
3.2. Установка git
3.2.1. Сам git устанавливается одной строчкой:
view sourceprint?
1.
sudo apt-get install git-core
Установку нужно произвести на всех компьютерах, которые будут работать с git.
3.3. Установка и настройка gitosis на сервере
Для более удобной работы с git есть набор скриптов под названием gitosis, которые позволяют легко управлять несколькими хранилищами и ограничивать права доступа к ним разным людям.Естественно, можно обойтись и без них, но после серии тестов я решил, что с ними работать удобнее.Итак, приступим.
ЗАМЕЧАНИЕ: команды идут после знака $
3.3.1. Установим необходимые пакеты для работы с python скриптами:
view sourceprint?
1.
serg@server:~$ sudo apt-get install python-setuptools
3.3.2. Создадим и перейдём в папку для хранения исходных кодов gitosis:
view sourceprint?
1.
serg@server:~$ mkdir src
2.
serg@server:~$ cd src
3.3.3. Теперь получим исходные коды последней версии gitosis из официального хранилища проекта и перейдём в папку с ними:
view sourceprint?
1.
serg@server:~/src$ git clone
git://eagain.net/gitosis.git
2.
serg@server:~/scr$ cd gitosis
3.3.4. Устанавливаем скрипты gitosis в систему:
view sourceprint?
1.
serg@server:~/src/gitosis$ sudo python setup.py install
3.3.4.а. В общем-то теперь можно вернуться в домашний каталог и удалить исходные коды, они нам больше не нужны:
view sourceprint?
1.
serg@server:~/src/gitosis$ cd ~
2.
serg@server:~$ rm -rf src
Теперь важный момент, который описывался только в одном руководстве по установке gitosis из множества, что я перечитал, но и то вскользь: есть пользователи ОС, а есть пользователи git. Это разные пользователи! Для ОС пользователи git не существуют! Пользователи git определяются ключами авторизации.
Во всех инструкциях по установке git я видел, что создаётся новый пользователь с именем git и потом все действия выполняются через него. На самом деле этого можно не делать и установить git в домашнюю директорию любого пользователя ОС. Но в этом случае в файле ~/.ssh/authorized_keys этого пользователя не должно быть никаких других записей или они должны быть закомментированы!
3.3.5. Если кто-то хочет, то может создать нового пользователя и домашний каталог для git:
view sourceprint?
1.
serg@server:~$ sudo adduser --system --shell /bin/sh --gecos 'git version control' --group --disabled-password --home /home/git git
ЗАМЕЧАНИЕ: Если в настройках ssh (/etc/ssh/sshd_config) у вас есть список AllowUsers, то нужно туда добавить и этого пользователя (разделителем для разрешённых имён пользователя является пробел)! После этого нужно перезапустить ssh сервер: serg@server:~$ sudo /etc/init.d/ssh restart
3.3.6. Если у вас уже есть ключ авторизации для вашего пользователя, то можно перейти к следующему шагу, а если вы создали нового пользователя или хотите создать новый ключ авторизации, то выполняем:
view sourceprint?
1.
serg@server:~$ ssh-keygen -t dsa
В ssh-keygen можно создавать ключи с алгоритмом dsa и rsa. dsa используются в качестве подписи, а rsa в основном для шифрования данных. Так как мы собираемся всего лишь отличать одного пользователя от другого, а не шифровать данные, то можно использовать dsa.
После того как ключи были созданы. можно устанавливать gitosis.
3.3.7.а. Если вы создали нового пользователя с именем git, то выполните:
serg@server:~$ sudo -H -u git gitosis-init < путь_к_папке_с_ключами/название_ключа.pub
3.3.7.б. Если же вы устанавливаете gitosis из под текущего пользователя, то вам подходит:
serg@server:~$ gitosis-init < путь_к_папке_с_ключами/название_ключа.pub
Ключ авторизации можно было создать и на клиентской машине, с которой будете управлять gitosis, а потом передать его публичную часть (.pub) на сервер. Но если вы создали ключи на сервере, то не забудьте забрать секретную часть ключа (без расширения) на клиентскую машину.
3.3.8. Теперь нужно установить правильные права доступа на определённый каталог (этот шаг необходим из-за особенностей python в разных дистрибутивах):
view sourceprint?
1.
serg@server:~$ sudo chmod 755 /home/имя_пользователя/repositories/gitosis-admin.git/hooks/post-update
На этом установка и настройка сервера, по мнению многих руководств, завершена. Я бы посоветовал сделать ещё одно действие.
3.3.9. Установить уровень вывода информации gitosis в положение DEBUG:
view sourceprint?
1.
serg@server:~$ sudo nano .gitosis.conf
Текст в этом файле должен выглядеть так:[gitosis]loglevel = DEBUG[group gitosis-admin]writable = gitosis-admin
members = serg@server
ЗАМЕЧАНИЕ: Если вы создавали пользователя, то путь к файлу будет другим! Но такой файл всё равно должен быть в корневой директории того пользователя в чью домашнюю папку устанавливался gitosis.
Вот теперь переходим на рабочую станцию, с которой будем управлять хранилищами.
3.4. Настройка gitosis на клиенте (рабочей станции)
Секретная часть ключа авторизации, который был создан на сервере (п.3.3.6.), должна быть в папке ~/.ssh/пользователя рабочей станции от чьего имени будут управляться gitosis.
ЗАМЕЧАНИЕ: Если порт сервера отличается от стандартного или вы связываетесь с сервером в локальной сети по IP, а хотите по имени, то можно добавить в папку ~/.ssh/ конфигурационный файл config:
view sourceprint?
1.
Host server
2.
User serg
3.
Port 9876
4.
IdentityFile ~/.ssh/serg_dsa
В случае замены IP адреса на имя нужно ещё внести изменения в файл /etc/hosts на рабочей станции. В файле уже имеется пример как это правильно делается.
3.4.1. Теперь можно начать настраивать gitosis. Получаем копию репозитория с сервера и переходим в его папку:
view sourceprint?
1.
serg@comp:~$ git clone git@YOUR_SERVER_HOSTNAME:gitosis-admin.git
2.
serg@comp:~$ cd gitosis-admin
Состав папки должен быть такой:
view sourceprint?
1.
serg@comp:~/gitosis-admin$ ls -l
2.
итого 8
3.
-rw-r--r-- 1 serg serg 176 2009-12-05 22:51 gitosis.conf
4.
drwxr-xr-x 2 serg serg 4096 2009-12-05 21:46 keydir
Файл gitosis.conf содержит настройки для gitosis. А в директории keydir находятся открытые части ключей пользователей, имеющих доступ к репозиториям:
view sourceprint?
1.
serg@comp:~/gitosis-admin$ ls -l keydir
2.
итого 4
3.
-rw-r--r-- 1 serg serg 609 2009-12-05 21:35 serg@server.pub
3.5. Добавление правил доступа для нового хранилища
Для того чтобы добавить новое хранилище test нужно добавить в конец файла gitosis.conf содержимое, подобное этому:
[group testers]
members = serg@server tester
writable = test
В строке members указывается какие пользователи будут иметь доступ к хранилищу (test) на чтение и запись (writable). Название группы (testers) нигде не используется, так что может быть абсолютно любым.
Добавлено 14 марта 2010: Название группы в файле gitosis.conf должно быть уникальным!
Предположим, что открытая часть ключа пользователя tester, который работает за другой рабочей станцией (note) уже помещена в папку keydir.
3.5.1. Теперь нужно отправить изменения на сервер:
view sourceprint?
1.
serg@comp:~/gitosis-admin$ git add .
2.
serg@comp:~/gitosis-admin$ git commit -a -m "Созданы правила для нового хранилища test"
3.
serg@comp:~/gitosis-admin$ git push
Всё, данные ушли. Осталось создать само хранилище.
3.6. Создание нового хранилища
Так как пользователь gitosis tester также имеет право записи в хранилище test, как и пользователь serg@server, то создадим хранилище из под него. Хранилище может располагаться где угодно в области доступной пользователю.
view sourceprint?
1.
serg@note:~$ mkdir test
2.
serg@note:~$ cd test
3.
serg@note:~/test$ git init
4.
serg@note:~/test$ git remote add origin git@имя_сервера:test.git
5.
serg@note:~/test$ git add *
6.
serg@note:~/test$ git commit -a -m "Создано пустое хранилище"
7.
serg@note:~/test$ git push origin master:refs/heads/master
ЗАМЕЧАНИЕ1: Обратите внимание на последнюю строку — это не простой push!
ЗАМЕЧАНИЕ2: В строке где указывается ссылка на внешнее хранилище (git remote add origin...) имя пользователя, то есть то что стоит до @ всегда должно быть такое же как имя пользователя ОС в чей домашней директории расположены хранилища на сервере! О том что в каталоге ~/.ssh текущего пользователя должна лежать секретная часть ключа авторизации в gitosis напоминать не надо? (Вторая часть ключа из допущения в п.3.5.)
3.7. Создание публичного доступа к хранилищу
Если нужно организовать публичный доступ к какому-либо хранилищу, то это делается следующим образом:
view sourceprint?
1.
serg@server:~$ sudo -u имя_пользователя git-daemon --base-path=/home/имя_пользователя/repositories/ --export-all
Теперь доступ к хранилищу можно получить из любой части Сети (если компьютер к ней подключён и имеет имя/ip) следующим образом:
view sourceprint?
1.
friend@home:~$ git clone git://имя_сервера/test.git
Надеюсь данный материал помог вам сэкономить несколько дней, которые понадобились мне чтобы во всём этом разобраться.
Похожие записи:
Делаем из нетбука карманный web-сервер.
16 комментариев для "Установка и настройка git и gitosis в Ubuntu”
Сергей
8 декабря 2009 ~ 13:45
Спасибо, сегодня, думаю, попробую все это повторить!
Ответить
Zeboton
26 декабря 2009 ~ 15:58
Если на сервере есть несколько веток, то при клонировании получается только master. Пример результата клонирования:
$ git branch -a
* master
remotes/origin/HEAD -> origin/master
remotes/origin/master
remotes/origin/branch1
remotes/origin/branch2
Для того чтобы получить и связать остальные ветки нужно проделать следующие операции:
$ git checkout -b branch1
$ git pull origin branch1
$ git checkout master
$ git checkout -b branch2
$ git pull origin branch2
В первой строке создаётся локальная ветка branch1. Переход к ней осуществляется автоматически.
Вторая строка получает содержимое branch1 с сервера в локальную branch1 и связывает локальную ветку с веткой на сервере.
В третьей строке происходит возврат к ветке мастер. Это нужно сделать для того чтобы в локальной branch2 не оказалось содержимое branch1. Скорее всего это костыль, но только из ветки master у меня получилось правильное создание веток.
Четвёртая строка создаёт локальную ветку branch2. Переход к ней осуществляется автоматически.
Пятая строка получает её содержимое с сервера и связывает локальную ветку с веткой на сервере.
ВАЖНОЕ ЗАМЕЧАНИЕ!!!
Связывание веток произошло только для получения данных с сервера. Для отправки данных на сервер нужно указывать все параметры push!
git push origin branch1:branch1
branch1 (до двоеточия) — локальная ветка.
branch1 (после двоеточия) — ветка на сервере.
Добавлено 10 февраля 2011
Как сделать, чтобы ветки автоматически корректно отправлялись на сервер читайте в комментарии от 10 февраля 2011
Ответить
Андрей
17 февраля 2010 ~ 19:28
Очень нужна помощь!
Когда делаю:
fba@fbandrey:~/work/fl/qwe.ru$ git push origin master:refs/heads/master
Получаю ответ:
ERROR:gitosis.serve.main:Repository read access denied
fatal: The remote end hung up unexpectedly
В чем может быть проблема???
В gitosis.conf добавил:
[group fl]
members = fba@webdep1
writable = qwe.com
Ключи тоже вроде на месте.
Ответить
Zeboton
10 февраля 2011 ~ 12:53
Для того чтобы локальные ветки корректно синхронизировались с хранилищем на сервере файл .git/config должен выглядеть примерно так:
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = git@server:project.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
[branch "develop"]
remote = origin
merge = refs/heads/develop