Наверное не все знают, что такое git и с чем его едят.
git — это распределенная система контроля версий. Основные ее преимущества, лично для меня, распределенность и использование бинарных дифов, что упрощает работу с системой нескольких пользователей одновременно, и упрощает хранение бинарных файлов, ресурсов.
git используется во многих крупных проектах: Linux kernel, KDE и многих других.
Изначально git написал Linus Torvalds.
Создание нового репозитория
Создание нового репозитория — это наверное первая из задач, с которой сталкивается любой разработчик. К данной проблеме есть несколько подходов.
Во-первых, можно использовать только локальный репозиторий, но смысла особого я в этом не вижу.
Во-вторых, можно создать открытый репозиторий, с которым смогут работать другие люди. Рассмотрим этот вариант. Предположим, что у вас есть некий сервер example.com и ваша рабочая машинка.
Для начала вам необходимо установить git. Сделать это можно как вручную скомпилировав его из исходных кодов, так и установив с помощью менеджера пакетов. Будем считать что с этой операцией вы уже справились.
Далее вам надо создать репозиторий. Предположим что вы будете хранить все git-репозитории в /var/git:
1 2 3 4 |
cd /var/git mkdir example.git cd example.git git init --bare --share |
Теперь у вас есть пустой git-репозиторий. Это, собственно говоря, все команды, которые требуется выполнить на сервере.
Теперь идем на вашу рабочую машину и пишем:
1 2 3 4 5 6 |
git init git remote add origin ssh://username@example.com/var/git/example.git touch changelog git add changelog git commit -a -m"Initital commit" git push origin master |
Этими командами мы создали новый репозиторий, связали его с основной веткой example.git, закомитили туда файл changelog и отослали это на сервер. В результате выполнения этих команд, вы должны увидеть чтото примерно такое:
1 2 3 4 5 |
Counting objects: 3, done. Writing objects: 100% (3/3), 224 bytes, done. Total 3 (delta 0), reused 0 (delta 0) To ssh://username@example.git/var/git/example.git * [new branch] master -> master |
Получение и оправка репозитория
Разумеется, после создания репозитория разумно узнать «а как же получить эти данные на свой компьютер?».
Для данной операции используется команда clone. Она создает полную копию удаленного репозитория у вас. Под полной копией понимается именно полная копия, со всеми ветками, удаленными файлами и т.д.
1 |
git clone ssh://username@example.com/var/git/имя-репозитория |
Разумеется, /var/git может меняться, в зависимости от того, где располагаются файлы данного репозитория на удаленной машине.
Обновление данных
С таким локальным репозиторием можно работать долгое время, однако, когда-то у вас все же возникнет необходимость передать сделанные вами изменения в удаленный репозиторий, чтобы результатами вашего труда могли воспользоваться другие участники разработки, и получить из удаленного репозитория новую версию. Для этого служат команды pull и push.
1 |
git pull |
Данная команда получает обновленную версию из удаленного репозитория, при этом она проверяет на наличие различных проблем при объединении репозиториев и сообщает об этом.
1 |
git push |
Данная команда целиком передает все сделанные вами изменения, уже закомиченные в локальный репозиторий, в удаленный репозиторий. Для передачи тегов необходимо использовать аргумент —tags
1 |
git push --tags |
Базовые операции
Для базовой работы с любой системой контроля версий требуется не особенно большой набор операций: добавление файла в репозиторий, удаление файла из репозитория, комит изменений в репозиторий, отмена незакомиченных изменений и получение списка изменений.
Добавление списка файлов в комит:
1 |
git add file1 file2 ... fileN |
Добавление всех недобавленных файлов в комит:
1 |
git add -a |
Удаление файла из комита:
1 |
git rm file1 file2 ... fileN |
Удаление файла из комита и с жесткого диска:
1 |
git rm -f file1 file2 ... fileN |
Комит в локальный репозиторий (надо отметить, что в таком случае закомитятся только файлы, которые были обработаны с помощью git add/rm):
1 |
git commit |
Комит всех изменений в локальный репозиторий:
1 |
git commit -a |
Отмена всех изменений, сделанных в дереве, до состояния, которое было при последнем комите в локальный репозиторий( очень опасная команда, подумайте прежде чем пользоваться ею):
1 |
git reset --hard |
Создание дифа относительно последнего комита:
1 |
git diff |
Использование веток
Рано или поздно в любом проекте возникает ситуация, когда требуется заморозить изменения, но продолжать работать, а на замороженные изменения накладывать только баг-фиксы. Для этой цели служат ветви (branch)
В гите можно создать ветку от любого места. Для создания ветки от основного дерева надо выполнить следующую команду:
1 |
git checkout --track -b name_of_newbranch origin/master |
В результате этой команды вы увидите примерно такое сообщение:
1 2 |
Branch name_of_newbranch set up to track remote branch refs/remotes/origin/master. Switched to a new branch "name_of_newbranch" |
Это значит, что в локальном репозитории у вас создалась новая ветка.
Если в этой команде заменить origin/master на origin/remote_branch_name то вы создадите ветку от другой ветки.
Чтобы ваша ветка была видна всем, ее требуется пропихнуть в удаленный репозиторий. Делается это так:
1 |
git push origin local_branch_name:remote_branch_name |
Разумеется, надо также уметь и получать ветки в свое распоряжение:
1 2 |
git branch local_branch_name origin/remote_branch_name git checkout local_branch_name |
В результате вы получите искомую ветку после следующего сообщения:
1 |
Switched to branch "local_branch_name" |
Работа с тегами
Как правило, кроме веток разработчики используют теги — чтобы запомнить состояние кода в какой-то момент. Тег — это своеобразный слепок, точно идентифицирующий состояние кода. Гит умеет работать с подписанными GPG тегами и с неподписанными. Здесь я рассмотрю только неподписанные теги.
Для создания такого тега необходимо выполнить команду:
1 |
git tag |
Чтобы убрать тег необходимо выполнить:
1 |
git tag -d |
Для того, чтобы тег стал виден всем, необходимо отправить его в удаленный репозиторий:
1 |
git push --tags |
Чтобы получить версию с конкретного тега необходимо создать от него локальную ветку и расчекаутить эту ветку:
1 2 3 |
git fetch origin tag git branch git checkout |
Разумеется, в будущем эту ветку можно будет сделать глобальной и выслать в удаленной репозиторий.
Настройка git
Для ускорения некоторых операций и увеличения удобства работы можно провести пару настроек:
Настройка цветного вывода:
1 |
git config --global color.ui "auto" |
Настройка имени пользователя и почтового адреса (между прочим, это хороший тон):
1 2 |
git config user.name "FirstName LastName" git config user.email "user@example.com" |
Ускоряем дифы и отменяем ограничение на количество потоков упаковки при push:
1 2 |
git config --global diff.renamelimit "0" git config --global pack.threads "0" |
Вместо заключения
Git — очень мощная и удобная система контроля версий. Для нее существует несколько GUI утилит, которые могут облегчить работу, несколько веб интерфейсов для мониторинга текущего состояния. В последнее время все большее кол-во проектов переходят на использование git, и это показатель того, что git успешно развивается и соответствует последним требованиям в области систем контроля версий.
Большое кол-во документации по использованию git можно найти в сети, в том числе и на официальном сайте
спасибо! все доступно
>cd /var/git
>mkdir example.git
>git init —bare
После второй строки нужно еще сделать
cd example.git
admin Reply:
19 декабря, 2010 at 21:32
Спасибо, исправил.
Спасибо Вам)
+1) Добавил в закладки.
Для первого знакомства то, что нужно. Спасибо!
Спасибо за объяснение, а продолжение будет?
admin Reply:
12 февраля, 2013 at 20:06
Есть вот такое продолжение: http://blog.nsws.ru/bolee-pravilnaya-rabota-s-git-git-stash-i-git-rebase.html
А какие вопросы еще нужно осветить, если есть какие-то пожелания для новой статьи по git — с радостью выслушаю, и если обладаю необходимой информацией — напишу 🙂
Alex Reply:
13 февраля, 2013 at 09:41
СПАСИБО, Admin, как раз вовремя!!
— Я только начинаю осваивать Git, теперь многое стало понятно.
Артур Reply:
8 апреля, 2013 at 15:07
Спасибо. Это первая из десятков инструкция, по которой все срослось.
Создал 2 репозитария — локальный и на сервере. Сделал и пуш и пул…
Но все история затевалась для совместной работы над сайтом. Сайт лежит на том же сервере что и созданый пустой удаленный репозитарий. Как правильно наладить работу, что б все результаты работы команды программистов попадали ни просто в репозитарий, но и заменяли собой файлы скриптов на сайте?
Каков правильный и безопасный путь — по шагам?
admin Reply:
8 апреля, 2013 at 15:18
Вам нужно посмотреть в сторону post-receive hook. (http://git-scm.com/book/en/Customizing-Git-Git-Hooks)
Как вариант можно сделать на сервере post-receive hook который сделает pull в папку с вашим сайтом.
Тогда по сути будет так:
Ктото делает push в git репу на сайте. Там запускается скрипт который переходит в каталог где лежит ваш сайт и делает git pull.
Артур Reply:
9 апреля, 2013 at 13:08
ТЕОРИЯ ЯСНА
Уже создавал и удавлял кучу репозитариев. все как то не складываетсяв одну цепочку.
Вот тут что то похожее http://habrahabr.ru/blogs/Git/127213
Жаль нет единого пошагового мануала.
admin Reply:
9 апреля, 2013 at 13:13
Посмотрел статью, указанную вами, там какраз пошаговая инструкция.
Возможно если у меня будет время я наваяю нечто похожее, какраз подворачивается похожая задачка…
Артур Reply:
11 апреля, 2013 at 14:02
Сделал все по 2 инструкциям, работать невозможно. При малейшем изменении на сервере одним из программистов, мне приходится делать пул на локальную машину — все 14 гб. с сервера (весь последний слепок видимо).
Наверное все же что то ни так настроено и где тоэти 2 инструкции не согласуются. Не могли бы Вы помочь разобраться? Если нет возможности сделать мануал — просто поконсультировать в скайпе (kadomsky), а я б потом сделал черновик мануала полного процесса.
admin Reply:
11 апреля, 2013 at 14:08
Можете попробовать связаться со мной через gtalk ( http://blog.nsws.ru/about ), пока с временем беда. На выходных попробую сделать мануальчик, вроде время должно появиться.
Добавьте описание .gitignore для более полной картины
Спасибо дружище!!!
Перерыл кучу доки и сайтов, но нужна была всего лишь одна команда на сервере:
git init —bare —share
Спасибо за статью, очень доступна и полезна