RTFM по Git. Отрыл в старых записях.

git.md

Правила работы с Git

Источники

• За основу берём модель ветвления описанную в этой статье
• Про Гит - читать всем
• Из SVN в Git - сравнение с SVN, которое не стоит использовать как руководство к действию.
• Шпаргалка новичка

Имена и адреса авторов правок

Не оставляйте свои имя и адрес эл-почты пустыми, указывайте только реально существующий адрес, по которому товарищи по команде смогут с Вами связаться. Адреса типа: admin@localhost, recock@the.bolt и trash-commiters-fake-email@nail.ru - негодные.

git config user.name 'Firstname Surname'
git config user.email 'your@email.com'

Комментарии к правкам

Комментарии к правкам следует писать по-русски в кодировке UTF-8, используя для перевода строк символ перевода строки (LF 0x0A). Многострочный комментарий состоит из однострочного заголовка отделённого от тела пустой строкой. Длина строки заголовка и тела не должна превышать 80 символов (чтобы читать без горизонтальной прокрутки). Например:

refs #1234: Отправка формы входа клавишей Enter

В форму входа добавлен элемент submit, чтобы работала отправка формы
нажатием клавиши Enter

или

Отправка формы входа клавишей Enter

refs #1234, #1235
В форму входа добавлен элемент submit, чтобы работала отправка формы
нажатием клавиши Enter.

Если правка относится к задаче в трекере, в комментарии необходимо указывать ссылку на эту задачу в заголовке или в теле комментария (см. инструкцию для РедМайна).

Ветки

Основные ветки

• master - стабильная ветка, версия проекта из этой ветки используется для развёртывания на продуктиве
• development - ветка разработки, в которую сливаются свежие изменения из веток задач

Служебные ветки

• feature-* - ветка с решением задачи, добавляющим новый функционал. Имя ветки состоит из слова feature, за которым после знака "-" (минус) следует номер задачи, для решения которой добавляется функционал. При отсутствии номера, можно использовать любую строку вида [a-z0-9-]+
• release-* - ветка релиза. Имя ветки состоит из слова release и номера спринта: release-<номер спринта> (Например release-4.11).
• hotfix-* - ветка с исправлениями. Имя ветки состоит из слова hotfix, номера спринта и номера исправления: hotfix-<номер спринта>.<номер исправления> (Например hotfix-4.11.1).

Тэги версий

Тэги версий создаются на ветке master и используются для сборки проекта из хранилища кода на продуктовом сервере.

Название тэга версии состоит из буквы v, за которой следует номер версии (например: v2.1.0 или v2.1.5)

Merge и Rebase

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

Если Вы перешли в ветку, коммитнули правку, но с пушем Вас кто-то опередил - используйте rebase.

Саша: git co -b foo-bar origin/foo-bar
Лёша: git co -b foo-bar origin/foo-bar
Саша: изменил README
Лёша: изменил README
Саша: git add README
Саша: git ci
Лёша: git add README
Лёша: git ci
Саша: git push origin foo-bar

# Внимание 
Лёша: git push origin foo-bar
  Получил сообщение о конфликте
Лёша: git rebase origin/foo-bar # а не merge origin/foo-bar
Лёша: git push origin foo-bar
  Всё Ok

Ветки feature друг с другом не сливать!

Сделал задачу - сливай в development и начинай новую от него. Или делай маленькие зависимые подзадачи в одной ветке feature.

Забудьте про SVN

При использовании метафоры SVN в работе с Git (см. http://git.or.cz/course/svn.html) 2 разработчика могут сделать 2 полезных правки и 150 мусорных слияний, выполняя попеременно комбинацию: git pull, git push origin master.

Выглядит это так:

 o    Старт (git co -b foo-bar origin/foo-bar)
 |\
 o \  Правка Лёши # Лёша запушил первый   
 |  o Правка Саши
 |\ |
 |  o Саша слил, запушил
 | /|
# Начало цикла
 o  | Лёша слил, запушил
 |\ |
 |  o Саша слил, запушил
 | /|
# Конец цикла
А должно быть так:

 o  Старт (git co -b foo-bar origin/foo-bar)
 |
 o  Правка Лёши # Лёша запушил первый   
 |  
 o' Правка Саши штрих # Саша перебазировал свою правку перед пушем  (git rebase origin/foo-bar)
git pull != svn up

Полезные заметки

Поиск regexp по полной истории

git grep <regexp> $(git rev-list --all)

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

git remote prune origin 

Для убийства веток в удалённом репозитории используй этот скрипт

Короткие команды

git config --global alias.st status
git config --global alias.ci commit
git config --global alias.br branch
git config --global alias.co checkout
git config --global alias.di diff
git config --global alias.plog "log --pretty=format:'%h %Cblue%cn %Creset%cr %Cgreen%s'"

Подсветка

git config --global color.branch auto
git config --global color.diff auto
git config --global color.interactive auto
git config --global color.status auto

Кириллица в названиях файлов

git config --global core.quotepath false
git config --global core.editor vim

Игнорирование файлов IDE

# для всех проектов
echo .idea/ >> ~/.gitignore_global && git config --global core.excludesfile ~/.gitignore_global

# или для одного проекта
echo .idea/ >> .git/info/exclude

Блокировка git push без параметров

git config --global push.default  nothing

См. также https://github.com/nvie/gitflow

Блокирует команды git pull и git push без аргументов.

UPD: git push можно блокировать через конфиг

git config --global push.default nothing

# Поместить в ~/.bashrc
git() {
    if [ "$1" == "pull" ]; then
        echo "Don't pull everything! Use git fetch && git <merge|rebase> <exact branch>"
        return 1
    fi
    if [ "$1" == "push" -a "$2" == "" ]; then
        echo "example: git push <where> <what>"
        return 1
    fi
    GIT_BIN=`which git`
    return `$GIT_BIN $@`
}