GITСистема контроля версий

Вспомним

1. Git - распределенная СКВ

2. Запись в репозиторий - commit

3. Синхронизация удаленного и локального репозиториев - push, pull, fetch

Git репозиторий - всего лишь директория .git

Удалить репозиторий - удалить директорию .git

Бэкап - копирование .git

Анонс

1. Staging

2. Работа с коммитами

3. Ветки

4. Слияние веток

5. Stashing

6. Изменение истории

7. Решение конфликов

STAGINGЖизнь до коммита

Staging

1. Что добавлено в staging (git add), то будет закоммичено (git commit)

2. git reset HEAD <file> - убрать файл из staging area

3. git checkout -- <file> - вернуть файл к начальному состоянию (то, что сейчас в HEAD)

Staging Advanced1. git diff --staged - изменения, которые пойдут в коммит

2. git reset --hard - переходим на коммит, изменения пропадут

3. git reset --soft - переходим на коммит, изменения добавятся в staging

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

Забыли закоммитить?

git commit --amend добавить к предыдущему коммиту

Важно знать1. Все, что было закоммичено, не потеряется

2. Атомарность коммита - это образ жизни

3. Комментарии к коммиту обязательны

ВЕТКИBranches

Правила ветвления

1. Одна ветка - одна фича/багфикс (если не влазит в один коммит)

2. master всегда есть и в master всегда stable код

3. В dev ветке идет разработка (периодически в нее сливаются фичер-ветки)

4. dev периодически вливается в мастер, после код-ревью

Управление бранчами

1. git checkout -b <name> - создать новый бранч и переключиться на него

2. git branch -d <name> - удалить бранч (-D - силой)

3. git push origin :<name> - удалить remote бранч

4. git remote show origin - посмотреть бранчи на remote

СЛИЯНИЕветок

Notes

1. Merge - это не боль

2. Rebase - это еще больше не боль

3. Чаще мерджим (ребэйсим) - легче жить

4. Важно не забывать переключаться между бранчами

merge или rebase1. merge создает дополнительный merge-коммит слияния

2. rebase делает историю "плоской", как будто коммиты были всегда в одном бранче

Как работает rebase

1. Переносит все коммиты из master, которых нет в origin/master в temp

2. Выстраивает последовательно все коммиты, которые в origin/master, в локальном master

3. За этими коммитами выстраивает те, которые в temp

Например, есть бранч admin и бранч master

1. Переключается на admin

2. git rebase master - добавляем коммиты из master в admin

3. Переключаемся на master - git checkout master

4. git merge admin - не будет мердж коммитов, т.к. это простой fast-forward

Например, несколько людей работали над одним бранчем

1. git fetch - синхронизируем репозиторий

2. git rebase - начинаем rebase

3. Разруливаем конфликты, делаем git add на файлы, в которых разрулили

4. git rebase --continue - завершаем rebase

В итоге никаких merge коммитов

Интерактивный rebasegit rebase -i HEAD~3 - rebase над 3 последними коммитами

1. Интерактивный rebase открывает rebase скрипт

2. Все коммиты, указанные в команде перемещаются в temp

3. На коммиты в temp применяется rebase скрипт

Зачем?

1. Менять коммиты местами (перестановка pick строк в скрипте)

2. Изменять комментарии к коммитам (edit)

3. Разбивать коммиты на несколько (edit)

4. Объединять коммиты в один (squash)

STASH

Git stash - место, куда временно можно положить изменения, чтобы в будущем их применить.

— git stash list - посмотреть весь стек стеша

— git stash - сохранить в стеш

— git stash pop - применить изменения из стеша

— git stash --keep-index - все, кроме staging

— git stash --include-untracked

— git stash <branch> <stash> - создать из стеша новый бранч

Изменение истории1. Очень опасно

2. Иногда необходимо

3. Перед изменением истории всегда делать бекап

Фильтрация бранчей

1. git filter-branch --tree-filter 'rm -f test.txt' - перезапустит все коммиты, выполняя команду для tree-filter

2. git filter-branch --index-filter 'git rm --cached --ignore-unmatch test.txt' - работает только со staging - быстрее, но надо пользоваться в качестве команд гитовыми командами

Решение конфликтов

1. Используйте тулы вашей IDE: Xcode, IDEA - они умеют 3-way merge делать

2. Хотя бы настройте стандартный для OSX FileMerge в качестве mergetool (difftool)

3. Если же нет, то результат diff - сверху то, что было, снизу то, что приехало (с чем мерджим)

После rebase не пушится

git push --force origin master

Очень редко, но можно сделать принудительный пуш, если уверены, что не надо мерджить