Блог о программировании на PHP, Yii2, 1C-Bitrix, а так же о фотографии как хобби и путешествиях.

Шпаргалка по частоиспользуемым коммандам git

Git хорошая штука, не просто хорошая, а очень хорошая. Теперь без Git’a у меня не обходится и дня разработки, как на работе так и для своих проектов. Для разработки использую Bitbucket, на нем, в отличии от GitHub, можно бесплатно размещать как закрытые так и открытые репозитории.

Некоторые используют в работе Subversion, у меня тоже был опыт работы с ним.

Так в чем состоит отличие Git от Subversion

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

Пока разработка идет в рамках своего репозитория, все полностью аналогично Subversion. Мы коммитим и откатываем изменения, создаем, мерджим и удаляем бранчи, разрешаем конфликты и т.д. и т.п. Также предусмотрены команды для работы с репозиториями на удаленных машинах. Например, «git push» означает слияние локальных изменений в удаленный репозиторий, а «git pull» — наоборот, слияние изменений из удаленного репозитория в локальный. Обмен информацией о изменении в репозитории происходит с использованием протокола SSH, но возможно и использование http.

Итого, главные отличия и сходства Git и Subversion:

  1. Git имеет все те же преимущества от использования VCS, что мы используем в Subversion.
  2. Git обладает нормальным шифрованием «из коробки», в Subversion надо изрядно помудохаться.
  3. Понятия основного сервера для Git нет, в отличии от Subversion, где без главного сервера никуда. В следствии этого мы можем не беспокоиться о сохранности наших файлов, когда мы делаем «pull» забывая залить изменения на сервер.
  4. Можно использовать Git только локально. Например, для того, чтобы иметь возможность откатиться к предыдущим версиям файлов или вернуть случайно удаленные.
  5. Git не раскидывает по каталогам служебную информацию (о этот «.svn»), вместо этого она хранится только в корне репозитория («.git»).
  6. Git — модная вещь, знание его в резюме разработчика будет хорошим плюсом в сравнении с другими кандидатами на должность. Конечно если руководство понимает его силу.
  7. Git поддерживают многие хостинги репозиториев (GitHub, BitBucket, SourceForge, Google Code, …) — есть из чего выбрать.
  8. Большой популярностью пользуется GitHub. Используя Git, вы увеличиваете вероятность того, что кто-то захочет безвозмездно написать патч для вашего OpenSource проекта.

Как же начать пользоваться Git’ом?

Для начала создаем пару ssh ключей:

ssh-keygen
cat ~/.ssh/id_rsa.pub

Заходим на Bitbucket, создаем репозиторий под новый проект, а в свойствах аккаунта прописываем свой открытый ssh-ключ. Затем клонируем репозиторий:

cd ~/{root-of-the-project}
git clone [email protected]:{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 [email protected]: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'