Git хорошая штука, не просто хорошая, а очень хорошая. Теперь без Git’a у меня не обходится и дня разработки, как на работе так и для своих проектов. Для разработки использую Bitbucket, на нем, в отличии от GitHub, можно бесплатно размещать как закрытые так и открытые репозитории.
Некоторые используют в работе Subversion, у меня тоже был опыт работы с ним.
Так в чем состоит отличие Git от Subversion
Git — распределенная система контроля версий, это значит, что каждый разработчик хранит у себя на компьютере отдельный репозиторий, не копию, не отдельные бранчи, а отдельный и полноценный репозиторий.
Пока разработка идет в рамках своего репозитория, все полностью аналогично Subversion. Мы коммитим и откатываем изменения, создаем, мерджим и удаляем бранчи, разрешаем конфликты и т.д. и т.п. Также предусмотрены команды для работы с репозиториями на удаленных машинах. Например, «git push» означает слияние локальных изменений в удаленный репозиторий, а «git pull» — наоборот, слияние изменений из удаленного репозитория в локальный. Обмен информацией о изменении в репозитории происходит с использованием протокола SSH, но возможно и использование http.
Итого, главные отличия и сходства Git и Subversion:
- Git имеет все те же преимущества от использования VCS, что мы используем в Subversion.
- Git обладает нормальным шифрованием «из коробки», в Subversion надо изрядно помудохаться.
- Понятия основного сервера для Git нет, в отличии от Subversion, где без главного сервера никуда. В следствии этого мы можем не беспокоиться о сохранности наших файлов, когда мы делаем «pull» забывая залить изменения на сервер.
- Можно использовать Git только локально. Например, для того, чтобы иметь возможность откатиться к предыдущим версиям файлов или вернуть случайно удаленные.
- Git не раскидывает по каталогам служебную информацию (о этот «.svn»), вместо этого она хранится только в корне репозитория («.git»).
- Git — модная вещь, знание его в резюме разработчика будет хорошим плюсом в сравнении с другими кандидатами на должность. Конечно если руководство понимает его силу.
- Git поддерживают многие хостинги репозиториев (GitHub, BitBucket, SourceForge, Google Code, …) — есть из чего выбрать.
- Большой популярностью пользуется GitHub. Используя Git, вы увеличиваете вероятность того, что кто-то захочет безвозмездно написать патч для вашего OpenSource проекта.
Как же начать пользоваться Git’ом?
Для начала создаем пару ssh ключей:
ssh-keygen cat ~/.ssh/id_rsa.pub
Заходим на Bitbucket, создаем репозиторий под новый проект, а в свойствах аккаунта прописываем свой открытый ssh-ключ. Затем клонируем репозиторий:
cd ~/{root-of-the-project}
git clone git@bitbucket.org:{repo-name}/{project-name}.git
cd {root-of-the-project}
Делаем какие-то изменения:
echo test > test.txt
Добавляем новый файл в репозиторий и делаем коммит:
git add test.txt
git commit -m 'description'
Отправляем все сделанные изменения в репозиторий:
git push origin master
Допустим, мы хотим сделать некоторые изменения в проекте, но не уверены, выйдет ли из этого что-то хорошее. В таких случаях создается новая ветка:
git branch new_feature git checkout new_feature
Работаем с этой веткой. Если ничего хорошего не вышло, возвращаемся к основной ветке (она же «trunk» или «ствол»):
git checkout master
Если вышло что-то хорошее, мерджим ветку в master:
git commit -a # делаем коммит всех изменений в new_feature git checkout master # переключаемся на master git merge new_feature # мерджим ветку new_feature
Не забываем время от времени отправлять наш код на BitBucket:
git push
Если мы правим код с нескольких компьютеров, то перед началом работы не забываем «накатить» в локальный репозиторий последнюю версию кода:
git pull
Работа в команде мало чем отличается от описанного выше. Только каждый программист должен работать со своей веткой, чтобы не мешать другим программистам. Одна из классических ошибок при начале работы с Git заключается в push’е всех веток, а не только той, с которой вы работали. Вообще я бы советовал первое время перед выполнением каждого push делать паузу с тем, чтобы подумать, что и куда сейчас уйдет.
Для работы с Git под Windows советую начинающим использовать консоль, да, именно консоль, например вот очень очень хороший клиент для работы с Git. При работе с консолью команды запоминаются лучше, а всякие GUI развращают и ужасно тормозят.
Шпаргалка по командам
Создать новый репозиторий:
git init project-name
Клонировать репозиторий с удаленной машины:
git clone git@bitbucket.org:afiskon/hs-textgen.git
Добавить файл в репозиторий:
git add text.txt
Удалить файл:
git rm text.txt
Текущее состояние репозитория (изменения, неразрешенные конфликты и тп):
git status
Сделать коммит:
git commit -a -m "Commit description"
Сделать коммит, введя его описание с помощью $EDITOR:
git commit -a
Замерджить все ветки локального репозитория на удаленный репозиторий:
git push origin
Аналогично предыдущему, но делается пуш только ветки master:
git push origin master
Запушить текущую ветку, не вводя целиком ее название:
git push origin HEAD
Замерджить все ветки с удаленного репозитория:
git pull origin
Аналогично предыдущему, но накатывается только ветка master:
git pull origin master
Накатить текущую ветку, не вводя ее длинное имя:
git pull origin HEAD
Скачать все ветки с origin, но не мерджить их в локальный репозиторий:
git fetch origin
Аналогично предыдущему, но только для одной заданной ветки:
git fetch origin master
Начать работать с веткой some_branch (уже существующей):
git checkout -b some_branch origin/some_branch
Создать новый бранч (ответвится от текущего):
git branch some_branch
Переключиться на другую ветку (из тех, с которыми уже работаем):
git checkout some_branch
Получаем список веток, с которыми работаем:
git branch # звездочкой отмечена текущая ветвь
Просмотреть все существующие ветви:
git branch -a # | grep something
Создать локальную ветку и сопоставить ее с удаленной
git checkout --track origin/test
Замерджить some_branch в текущую ветку:
git merge some_branch
Удалить бранч (после мерджа):
git branch -d some_branch
Просто удалить бранч (тупиковая ветвь):
git branch -D some_branch
Последние изменения:
git log
История конкретного файла:
git log file.txt
Аналогично предыдущему, но с просмотром сделанных изменений:
git log -p file.txt
История с именами файлов и псевдографическим изображением бранчей:
git log --stat --graph
Изменения, сделанные в заданном коммите:
git show d8578edf8458ce06fbc5bb76a58c5ca4a58c5ca4
Посмотреть, кем в последний раз правилась каждая строка файла:
git blame file.txt
Удалить бранч из репозитория на сервере:
git push origin :branch-name
Откатиться к конкретному коммиту (хэш смотрим в «git log»):
git reset --hard d8578edf8458ce06fbc5bb76a58c5ca4a58c5ca4
Аналогично предыдущему, но файлы на диске остаются без изменений:
git reset --soft d8578edf8458ce06fbc5bb76a58c5ca4a58c5ca4
Попытаться обратить заданный commit (но чаще используется branch/reset + merge):
git revert d8578edf8458ce06fbc5bb76a58c5ca4a58c5ca4
Просмотр изменений (суммарных, а не всех по очереди, как в «git log»):
git diff # подробности см в "git diff --help"
Используем vimdiff в качестве программы для разрешения конфликтов (mergetool) по умолчанию:
git config --global merge.tool vimdiff
Отключаем диалог «какой mergetool вы хотели бы использовать»:
git config --global mergetool.prompt false
Разрешение конфликтов (когда оные возникают в результате мерджа):
git mergetool
Создание тэга:
git tag some_tag # за тэгом можно указать хэш коммита
Удаление untracked files:
git clean -f
«Упаковка» репозитория для увеличения скорости работы с ним:
git gc
Инициализация подмодулей:
git submodule init
Получение данных подмодулей:
git submodule update
Получение изменений во всех подмодулях:
git submodule foreach git pull origin master
Следует отметить, что Git позволяет использовать короткую запись хэшей. Вместо «d8578edf8458ce06fbc5bb76a58c5ca4a58c5ca4» можно писать «d8578edf» или даже «d857».
Содержание файла .gitignore для bitrix’a:
upload/* bitrix/* !bitrix/templates/ !bitrix/php_interface/ bitrix/php_interface/dbconn.php bitrix/components/bitrix/* !bitrix/components/ awstat/* /robots.txt /urlrewrite.php /robots.txt
Частые ошибки
fatal: unable to create thread: Resource temporarity unavailable
Это шибка означает то, что у вас мало памяти на сервере и необходимо поставить ограничение на использование нитей и памяти. Делается это командами:
git config --global pack.windowMemory "100m" git config --global pack.SizeLimit "100m" git config --global pack.threads "1"
Ежедневные комманды в алиасах
alias gst='git status' alias ga='git add' alias gc='git commit -m' alias gp='git pull && git push' alias gull='git pull' alias gush='git push' alias gb='git branch' alias gco='git checkout' alias gd='git diff'