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

править

Задать имя и почту автора для commit

git config user.email your.name@domain
git config user.name "Your Name"

При отправке объектов в удалённый репозиторий отправлять по умолчанию текущий branch

git config push.default current

Скачать удалённый git и выгрузить в рабочую папку последний commit

git clone https://example.org/user1/repo1
git clone ../myrepo2/
git clone git://server.org/repo1.git

или так

git init
git remote add repo1 https://example.org/user1/repo1
git fetch

Просмотрим все коммиты

git log --oneline --graph --all

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

править
  • git branch mybranch1 — создать ветку mybranch1 на текущем коммите (просто создаёт файл с чексуммой текущего commit в refs/heads/mybranch1)
  • git branch — список веток
  • git branch -r — список веток в других добавленных репозиториях
  • git checkout mybranch1 — переключиться на ветку mybranch1 (или на коммит по чексумме)


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