Git

Это краткий справочник по командам git. Используется договорённость об обязательном использовании rebase при синхронизации с получаемой веткой.

Начальная настройка

• git config --global user.email your.name@domain - добавляет вашу почту в конфигурационный файл
• git config --global user.name "Your Name" - добавляет ваше имя(ник) в конфигурационный файл
• git config --global push.default current
• git clone <url репозитория> - клонирует репозиторий из другого репозитория(например, репозитория GitHub)

Работа с ветками

git branch <имя ветки> - создание ветки
git checkout <имя ветки> - переключение на другую ветку(или коммит)
git checkout -b <имя ветки> - две операции вместе
git branch - посмотреть ветки в репозитории(для удаленного репозитория: git branch -r)
git push -u origin <имя ветки на удаленном репозитории, обычно такое же, как и локальное> - создание удаленной ветки (соответствующей текущей ветке)

• удаление локальной ветки

1. git branch -d <имя ветки>. Но в этом случае git иногда ноет, что у вас ветка не слита с HEADом или upstream-branch.
2. git branch -D <имя ветки>. Так он удалит в любом случае, вне зависимости от merged status ветки, которую вы хотите удалить.

• cинхронизация с ветками

--взятие, без флага rebase будет выполняться merge, а с этим флагом будет выполняться rebase

1. git pull --rebase
2. git pull без --rebase использовать ЗАПРЕЩЕНО! - это создаст проблемы при последующих rebase и слиянии веток.

Также рекомендуется один раз запустить

git config branch.autosetuprebase always

Это позволит автоматически во время git pull добавлять флаг --rebase

--отправка на сервер. после первого push'a с флагом -u достаточно писать лишь git push

Пример: Cлияние ветки с master через rebase с обновлением ветки master

- обновляем master
git checkout master
git pull --rebase

- ребейзим ветки на master
git checkout <имя ветки>
git rebase master

• master при этом не меняется, то есть если вы хотите просто влить в Вашу ветку общие изменения, на этом надо остановиться.
• Только не забудьте перед следующим git pull --rebase(в своей ветке) сделать git push --force origin <имя ветки>, поскольку из-за ребейза <имя ветки> и origin/<имя ветки> разошлись. Иначе, если сделать pull --rebase то вы снова примените к своей ветке свои коммиты.
• возвращаемся обратно, делаем fast-forward merge и выливаем в репозиторий
  

git checkout master
git merge <имя бранча> (должно быть написано fast-forward)
git push

Исправления

• конфликтов

1. в любимом редакторе
2. git mergetool [--tool=<tool>]
3. сторонние gui git приложения (Валера пользуется smartgit)

• исправление коммитов
• отлично работающая штука, если вы сделали какую-то глупость (например, смерджились случайно c master):
  

git reflog

Там будет список Ваших последних действий. К любому из них можно откатиться вполне стандартным способом:

git reset --hard HEAD@{n}

• слияние коммитов
  git rebase -i <start_point> (внимание, ребейз начинается после start point'a)
• исправление предыдущего коммита
  git commit --amend

откат коммита

git reset HEAD~<n> (сами файлы в working tree останутся)

git reset --hard HEAD~<n> (working tree файлы не останутся)

откат из индекса

git reset <file name>

откат измененного файла

git checkout HEAD <file name>

git checkout -- <file name> (2-й способ начиная с версии git 1.6.1)

взятие отдельного коммита в свой бранч

git cherry-pick <commit>

взятие несколько подряд идущих коммитов

git cherry-pick <commit_from>..<commmit_to>

Удаление ветки на удаленном репозитории

git push origin --delete <имя ветки на удаленном репозитории>

См. также

http://git-scm.com/book

Возможная модель работы с ветками master и develop