Git – популярная система контроля версий

Мотивация

Единое место хранения кода
Удобное объединение изменений от разных разработчиков
История изменений с описанием и авторством
Откат неудачных изменений
Ревью изменений
Зачем разработчикам система контроля версий?

А зачем система
контроля версий вам?

Систем контроля версий море…
CVS
SVN
Git
Perforce
TFS
Fossil
Bazaar
Mercurial
Veracity

Распределенная
Каждому по репозиторию
Консольная
Состоит из утилит командной строки
Кроссплатформенная
Много разных GUI
Поддерживается
хостингами репозиториев: GitHub, GitLab, BitBucket
популярными IDE: Visual Studio, WebStorm, VS Code
Git – популярная система контроля версий

А кто уже пользовался Git?
А другой системой контроля версий?

Как будем изучать?

GUIов много, на любой вкус и цвет,
каждый со своими особенностями,
а придется что-то выбрать
Как будем изучать?

Примеры GUI на Git Extensions
Тонкая надстройка над консолью с минимумом магии
Удобные команды, управление с клавиатуры
Распространен в Контуре
Примеры GUI на Git Graph
Удобное расширение VS Code
Можно просматривать историю не выходя из редактора
Примеры CLI на Git Bash
Может все!
Как будем изучать?

Задания на Git Bash + Git Graph
для Linux, Maс или Windows
Как будем изучать?
Задания на Git Extensions
для Windows

VS Code для разрешения конфликтов
Показывает конфликт он как есть
Подсветка конфликта, кнопки быстрых действий
Подсвечивает код
Как будем изучать?

VS Code для редактирования
Подсвечивает Markdown
Умеет открывать папку
Как будем изучать?

Особенностей и нюансов много, а времени мало
Если освоить правила,
в нюансах легко разобраться
Сформулируем 10 правил Git
и связанные с ними команды
Как будем изучать?

Формат
Правило и теория к нему
Практические задания
Синхронизация
А потом много практики в реальной жизни,
чтобы довести до автоматизма ☺
Как будем изучать?

S1. Все локально
A1. Трехсторонний merge
в три шага
R2. Удаленное изменение
— это push
A2. rebase, cherry-pick и amend, чтобы пересоздать историю
A3. stash, reset, revert
для управления изменениями
S2. Хранятся
состояния директории,
постепенная сборка коммита
S3. Манипуляции
через ссылки,
нет ссылки — в мусор
R3. Явное сопоставление
локальных веток
с upstream
R1. Доступен fetch коммитов
любого репозитория
в любой момент
H1. Гибкое конфигурирование и качественная документация
Structure
Actions
Remote

H1. Гибкое конфигурирование
и качественная документация
Гибкая настройка под любой процесс
Документация ко всем командам
Алиасы для краткости команд
Надо игнорировать все, кроме исходников

Конфигурируется под команду и продукт
У команд Git множество опций
Поведение команд по умолчанию можно настраивать
Настройки репозитория: git config --local -e
Настройки пользователя: git config --global -e
Настройки системы: git config --system -e

Git должен знать, кто вносит изменения:
git config --global user.name "John Doe"
git config --global user.email "[e-mail]"
Стоит задать текстовый редактор:
Windows: git config --global core.editor notepad
Linux, Mac: git config --global core.editor nano
Хотя бы для того, чтобы отредактировать остальные настройки!
По умолчанию — vim ?
Минимальная Жизнеспособная Конфигурация

git help commit
git commit --help
git commit -h
Чтобы не запоминать все опции команд!
Git спешит на помощь!

Подсказки при неверных командах
Полезно читать вывод
хотя бы при освоении Git!

Полная запись:
git branch --delete awesome-feature
Короткая запись:
git branch -d awesome-feature
Полная усиленная запись:
git branch --delete --force awesome-feature
Короткая усиленная запись:
git branch -D awesome-feature
Стандарты опций

Через .gitconfig
[alias]
it = !git init && git commit -m 'Initial commit' --allow-empty
st = status -sb
commend = commit --amend --no-edit
graph = log --oneline --decorate --graph --all
Использование: git graph
Алиасы для краткости команд

Через .gitconfig
[core]
autocrlf = true
safecrlf = true
Через команды
git config --global core.autocrlf true
git config --global core.safecrlf true
autocrlf – преобразование \r\n в \n
safecrlf – проверка обратимости преобразования \r\n в \n
Настройка для Windows

Через .gitconfig
[core]
autocrlf = input
Через команды
git config --global core.autocrlf input
Даже если получено \r\n, то преобразуется в \n
Настройка для Linux и Mac

Сохранять в репозиторий нужно только исходные файлы!
Остальное — в игнор!

В любой папке и ее подпапках
.gitignore
Через .gitconfig
[core]
excludesFile
Дополнительно в репозитории
/.git/info/exclude
Коллекция .gitignore от GitHub: https://github.com/github/gitignore
Игнорирование файлов

H1. Гибкое конфигурирование и качественная документация
Structure
Actions
Remote

S1. Все локально
Все данные хранятся в локальных репозиториях,
изменения между ними можно синхронизировать

Репозиторий – хранилище кода со всей историей изменений
git init – создать репозиторий для папки
Репозиторий
Не нужен сервер!
Репозиторий
}
Рабочая
директория

Клонирование
Чтобы работать над существующим проектом надо скопировать репозиторий локально – склонировать
git clone
– склонировать репозиторий
Локальная копия
На сервере

Fork на GitHub
GitHub

Fork на GitHub
Сделать форк

Bare-репозиторий — репозиторий без рабочей директории
git init --bare – создать bare-репозиторий
Обычно называется reponame.git, например [e-mail]:kontur-courses/git.git
Обычный репозиторий — для разработки, bare-репозиторий — для облаков
Bare-репозиторий
Репозиторий
Bare — англ. Голый, Пустой

Задание 1. Init Repo
Задание 2. Fork and Config

S1. Все локально
H1. Гибкое конфигурирование и качественная документация
Structure
Actions
Remote

S2. Хранятся состояния директории,
постепенная сборка коммита
Хранятся файлы, разница вычисляется на лету
Commit index для постепенной сборки коммита

«Снимки» директории
Working directory

Сохранение состояния
Working directory

Еще сохранения
Working directory

Загрузка состояния
Working directory

Альтернативная ветка истории
Working directory

Метаинформация
Хэш-коммита
Сообщение
Информацию об авторе
Время
Родитель
Данные
Полное состояние директории
Изменения по сравнению с родителем
Что содержит коммит?

Метаинформация коммита

Полное состояние директории

Изменения по сравнению с родителем

Каждый коммит хранит структуру каталога и все файлы состояния директории
Хранение файлов оптимизировано: файлы не хранятся повторно, потому что в структуре каталога хранятся не сами файлы, а ссылки по хэшу на них
Используется сжатие, чтобы текстовые данные занимали меньше места
Разница между коммитами вычисляется на лету и с родителем и с любым другим коммитом
Хранятся файлы, разница вычисляется на лету

Working directory & Commit index
Последний коммит
Working directory

Working directory & Commit index
Последний коммит
Commit index = Staging area
Working directory
Для постепенной
сборки коммита
Staging area — англ. место сбора войск на пути к месту назначения

Working directory & Commit index

Внесение изменений
Working directory
Commit index
Последний коммит

Внесение изменений
Working directory
Commit index
Последний коммит
Редактирование

Внесение изменений
Working directory
Commit index
Последний коммит
git add init.md

Внесение изменений
Working directory
Commit index
Последний коммит
Редактирование

Working directory changes
Commit index changes

Внесение изменений
Working directory
Commit index
Последний коммит
git add commit.md

Внесение изменений
Working directory
Commit index
Последний коммит
git commit

Working directory changes
Commit index changes
Commit message

Внесение изменений
Последний коммит
Commit index
Working directory
Редактирование
git add .
git commit

Отмена изменений
Working directory
Commit index
Последний коммит
git add commit.md

Отмена изменений
Working directory
Commit index
Последний коммит
git add commit.md
git restore --staged commit.md

Отмена изменений
Working directory
Commit index
Последний коммит
git restore --staged commit.md
git add commit.md

Отмена изменений
Working directory
Commit index
Последний коммит
Редактирование

Отмена изменений
Working directory
Commit index
Последний коммит
Редактирование
git restore --worktree commit.md

Отмена изменений
Working directory
Commit index
Последний коммит
Редактирование
git restore --worktree commit.md
restore не может удалить файл из working directory

Отмена изменений
Working directory
Commit index
Последний коммит
Редактирование
v2
v1

Отмена изменений
Working directory
Commit index
Последний коммит
Редактирование
v2
v1
git restore --worktree commit.md

Отмена изменений
Working directory
Commit index
Последний коммит
Редактирование
v1
v1
git restore --worktree commit.md
restore может отменить редактирование в working directory

Отмена изменений
Последний коммит
Commit index
Working directory
Редактирование
git add .
git commit
git restore --staged .
git restore --worktree .
git restore .

Отмена изменений по-старому
Последний коммит
Commit index
Working directory
Редактирование
git add .
git commit
git restore --staged .
git reset .
git restore --worktree .
git restore .
git checkout .
Команды checkout и reset также есть
в контексте коммитов и использование тех же названий ведет к путанице

Отмена изменений
Последний коммит
Commit index
Working directory
Редактирование
git add .
git commit
git restore --staged .
git reset .
git restore --worktree .
git restore .
git checkout .

Один файл с разными версиями

Working directory changes
Commit index changes
Commit message

Удобный алиас
git config --global alias.st "status -sb"

Задание 3. Commits

S1. Все локально
S2. Хранятся
состояния директории,
постепенная сборка коммита
H1. Гибкое конфигурирование и качественная документация
Structure
Actions
Remote

S3. Манипуляции через ссылки,
нет ссылки — в мусор
HEAD — текущая ссылка,
tag — фиксированная ссылка,
branch — движущаяся за HEAD ссылка
checkout — перемещение на ветку или коммит,
reset — перемещение с веткой на коммит
Видно то, на что есть ссылки, остальное — мусор

Указывает на коммит, относительно которого выполняются операции
с ним связан Commit index и Working directory
в него будет сделан следующий коммит, смещается при коммите
перемещается при checkout, switch или reset
относительно него работают merge, rebase и т.д.
HEAD – точка приложения усилий
HEAD

Именованная ссылка, привязанная к конкретному коммиту
Псевдоним коммита
Применяется для обозначения версий
Полезен при манипуляциях над историей
Типы тегов:
lightweight — просто ссылка
annotated — с доп. информацией,
в том числе об авторе
Tag
v0.2
v0.1

Движущаяся ссылка, которая сдвигается вместе с HEAD, если тот на нее указывает
Branch
f1
HEAD
master
f2

Движущаяся ссылка, которая сдвигается вместе с HEAD, если тот на нее указывает
Branch
f1
HEAD
master
f2

Движущаяся ссылка, которая сдвигается вместе с HEAD, если тот на нее указывает
Получающаяся за этой ссылкой последовательность коммитов похожа на ветку
Ветки используются для разработки нового функционала
Главная ветка по соглашению называется master
Branch
f1
master
HEAD
f2

Каждой фиче – отдельная ветка

Detached HEAD
f1
HEAD
master
f2
HEAD может указывать не только на ветку, но и непосредственно на коммит
В этом случае говорят, что это detached HEAD

Что произойдет после коммита?
f1
HEAD
master
f2

Коммит без движения ветки
f1
master
f2
Коммит всегда происходит в HEAD, но если HEAD не указывает ни на одну ветку, то ветки не двигаются
HEAD

Ветки и теги в Git Extensions

Ветки и теги в Git Graph

Ветки и теги в Git Bash

Удобный алиас
git config --global alias.graph "log --oneline --decorate --graph --all"

Команда checkout может перенести HEAD на какую-нибудь ветку
Checkout на ветку
f1
master
HEAD
f2

Команда checkout может перенести HEAD на какую-нибудь ветку
Checkout на ветку
f1
master
HEAD
f2

Команда checkout может перенести HEAD на любой коммит, причем получится detached HEAD
Checkout на коммит
f1
master
HEAD
f2

Команда checkout может перенести HEAD на любой коммит, причем получится detached HEAD
Checkout на коммит
f1
master
HEAD
f2

Checkout старается перенести локальные изменения,
либо не выполняется

Switch — новая команда,
задуманная как замена для checkout

Команда reset может перенести HEAD на любой коммит, причем захватывает с собой ветку, на которую указывает HEAD
Перенос ветки с reset --hard
f1
master
HEAD
f2

Команда reset может перенести HEAD на любой коммит, причем захватывает с собой ветку, на которую указывает HEAD
Перенос ветки с reset --hard
f1
master
HEAD
f2

Reset в режиме hard затирает локальные изменения
Пока этого достаточно!

Если на коммит есть ссылка: HEAD, tag, branch – то он показывается, а иначе скрывается
Если нет ссылок, то коммит будет удален через 30 суток
git gc вызывает ручную очистку ненужного
Видно то, на что есть ссылки

Помните выполнение reset --hard?
f1
master
HEAD
f2

Вот это уже мусор
f1
master
HEAD
f2

Выглядеть будет так
f1
master
HEAD
f2

Если потерялся коммит в ходе манипуляций,
то он не удален и его можно найти
Если закоммичено – не потеряете
Но все же...

Все перемещения ссылок логируются и хэши всех видимых когда-либо ревизий оседают в этих логах

Reflog в Git Extensions

Reflog в консоли

Отмечать дорогие сердцу коммиты тегами перед сложными манипуляциями
Помнить про особенность git log. По умолчанию показывает предков HEAD, а не все коммиты
В крайнем случае использовать reflog
Как ничего не терять?

A
/ \
/ \
B C
/|
/ |
D E
Относительная адресация коммитов
A = A^0
B = A^1 = A^ = A~1
C = A^2
D = A^1^1 = A^^ = A~2
E = B^2 = A^^2
~N — 1-ый родитель из N-ого поколения
^N — N-ый родитель предыдущего поколения

А это точно надо запомнить?

А это точно надо запомнить?
Нет!

Удобный алиас
git config --global alias.undo "reset --soft HEAD^"
Эта команда отменяет commit, но про режим soft будет позже...

Задание 4. Tag
Задание 5. Feature Branches

S1. Все локально
S2. Хранятся
состояния директории,
постепенная сборка коммита
S3. Манипуляции
через ссылки,
нет ссылки — в мусор
H1. Гибкое конфигурирование и качественная документация
Structure
Actions
Remote

A1. Трехсторонний merge в три шага
Два состояния можно объединить через merge, mergetool и commit
Участвуют три стороны: current, incoming и base

Разрабатывать в отдельных ветках правильно, но в конце концов надо объединить функционал в одной версии
Слияние
1
4
2
3
master
f2

Разрабатывать в отдельных ветках правильно, но в конце концов надо объединить функционал в одной версии
Значит надо получить новое состояние – коммит
Слияние
1
4
2
3
master
f2
5

Как объединить изменения?
A.txt
D.txt
A.txt
B.txt
D.txt
A.txt
C.txt
master
f2
?

Как объединить изменения?
A.txt
D.txt
A.txt
B.txt
D.txt
A.txt
C.txt
D.txt
master
f2
A.txt
B.txt
C.txt

Общий родитель
1
4
2
3
master
f2
Общий родитель
для master и f2

А если был изменен
один и тот же файл?

Как объединить изменения?
master
f2
?

Как объединить изменения?
master
f2

А если одна и та же строчка?

<<<<<<< HEAD:index.html
contact : [e-mail]
=======
please contact us at [e-mail]
>>>>>>> iss53:index.html
Конфликт

<<<<<<< HEAD:index.html
contact : [e-mail]
=======
please contact us at [e-mail]
>>>>>>> f2:index.html
Конфликт
Создается текстовый блок,
содержащий изменения из обоих коммитов

Необходимо заменить все «объединенные» текстовые блоки на правильное содержимое
Стратегии
Взять один вариант
Взять второй вариант
Взять оба варианта последовательно
Написать что-то совершенно иное
Разрешение конфликтов

Разрешение конфликта в VS Code

В конфликтах
HEAD указывает на current
Другая ветка — это incoming
При merge HEAD указывает на ветку,
в которую вливается другая ветка

Current и Incoming

Надо объединять на уровне списка файлов
и на уровне содержимого файлов
Нужно знать две объединяемые версии,
а также общего предка
Часто происходит автоматическое объединение
В остальных случаях необходимо вручную решать конфликты
Как объединять изменения?

Алгоритм слияния

Алгоритм слияния

Алгоритм слияния
Можно остановиться,
а затем продолжить
Git Extensions автоматически
переходит к следующему шагу

Как поведут себя ветки?
1
4
2
3
master
f2
5

Как поведут себя ветки?
1
4
2
3
master
f2
5
HEAD

Как поведут себя ветки?
1
4
2
3
master
f2
5
HEAD
Сдвинется ветка,
на которой был HEAD
Ветка, которую вливают
стоит на месте

Слияние в Git Extensions

Слияние в Git Graph

А что если обратно влить?
1
4
2
3
master
f2
5
HEAD

Fast-Forward Merge
1
3
2
4
master
f2
5
HEAD
Нет смысла создавать коммит – просто передвигается ветка
Это Fast-Forward Merge
или «Перемотка»

merge --no-ff
1
3
2
4
master
f2
5
HEAD
Можно заставить Git
создать новый коммит
без Fast-Forward
6

Иногда вследствие неведомых действий
состояние директории полно конфликтов,
merge не завершен и его хочется отменить
А если merge не удался?

Иногда вследствие неведомых действий
состояние директории полно конфликтов,
merge не завершен и его хочется отменить
Переходим на исходный коммит с помощью
checkout или reset, а затем повторяем merge
А если merge не удался?

Иногда вследствие неведомых действий
состояние директории полно конфликтов,
merge не завершен и его хочется отменить
Переходим на исходный коммит с помощью
checkout или reset, а затем повторяем merge
При этом затрутся все локальные изменения,
поэтому перед слиянием все изменения
рекомендуется сохранять (commit или stash)
А если merge не удался?

Иногда вследствие неведомых действий
состояние директории полно конфликтов,
merge не завершен и его хочется отменить
git merge --abort
Более корректный способ
Предыдущий вариант тоже ок. Разве нет?

Лишние файлы после merge?
При создании конфликта Git генерирует .orig-файлы с версиями до слияния
Они исчезнут после успешного merge,
если выставлено в настройках
[mergetool]
keepbackup = false

Задание 6. Merge Conflict
Задание 7. Hidden Conflict
Задание 8. Fast-Forward Merge

S1. Все локально
A1. Трехсторонний merge
в три шага
S2. Хранятся
состояния директории,
постепенная сборка коммита
S3. Манипуляции
через ссылки,
нет ссылки — в мусор
H1. Гибкое конфигурирование и качественная документация
Structure
Actions
Remote

A2. rebase, cherry-pick и amend, чтобы пересоздать историю
Нельзя переписать историю — можно создать новую

Даже если кажется,
что Git редактирует коммиты,
на самом деле он создает новые

Amend — англ. Вносить правки
Amend Commit
Последний коммит
Commit index
Working directory
Хочется дополнить
последний коммит

Amend Commit
Изменения из Commit index
и старого коммита
теперь в новом коммите
Старый коммит остался,
но никому не нужен

Слияния порождает лишние коммиты,
а история становится нелинейной
Rebase
master
HEAD
f2

Слияния порождает лишние коммиты,
а история становится нелинейной
Хочется получать линейную историю!
Менять коммиты нельзя – значит надо создавать копии
Rebase
master
HEAD
f2

Rebase создает новые коммиты
1
4
2
3
master
HEAD
f2
1
4
2’
3’
master
HEAD
f2
2
3
Общий родитель для HEAD и новой базы

Те же изменения на новой «базе»
1
4
2’
3’
2
3
1.txt
2.txt
3.txt
4.txt
1.txt
2.txt
4.txt
1.txt
4.txt
1.txt
1.txt
2.txt
1.txt
2.txt
3.txt

Rebase по шагам
1
4
master
HEAD
f2
2
3

Rebase по шагам
1
4
master
HEAD
f2
2
3

Rebase по шагам
1
4
2’
master
HEAD
f2
2
3

Rebase по шагам
1
4
2’
3’
master
HEAD
f2
2
3

Изменения в коммите 4, новой базе, могут конфликтовать с изменениями в 2 и в 3
Следовательно,
перенос каждого коммита может породить конфликт
Конфликты разрешаются аналогично merge
Конфликты при rebase
1
4
2’
3’
2
3
1.txt
2.txt
3.txt
4.txt
1.txt
2.txt
4.txt
1.txt
1.txt
2.txt
1.txt
2.txt
3.txt
1.txt
2.txt
3.txt

В конфликтах
HEAD указывает на current
Другая ветка — это incoming
После начала rebase HEAD перемещается
на коммит построения новой истории,
а в конце оказывается на вершине построенной ветки

После решения конфликтов — продолжение
git rebase --continue

Иногда приходит понимание, что не надо было ввязываться в этот rebase с кучей конфликтов при переносе каждого коммита и его хочется отменить
git rebase --abort
А если rebase идет как-то не так?

Позволяет указать, как применять каждый коммит
Например, можно делать squash всех переносимых коммитов в один
Интерактивный rebase
1
4
2’, 3’
master
HEAD
f2
2
3

Сценарий интерактивного rebase
Обычный вариант
С объединением коммитов

Rebase в Git Extensions

Rebase в Git Graph

Позволяет создать копию изменений произвольного коммита в новом месте
cherry picking — идиома, означающая взять лучшее и оставить все остальное
Cherry Pick
1
4
2
3
master
HEAD
f2
5

Позволяет создать копию изменений произвольного коммита в новом месте
cherry picking — идиома, означающая взять лучшее и оставить все остальное
Cherry Pick
4
master
HEAD
3’
2
3
f2
5
1

Задание 9. Hot Rebase
Задание 10. Reflog

S1. Все локально
A1. Трехсторонний merge
в три шага
A2. rebase, cherry-pick и amend, чтобы пересоздать историю
S2. Хранятся
состояния директории,
постепенная сборка коммита
S3. Манипуляции
через ссылки,
нет ссылки — в мусор
H1. Гибкое конфигурирование и качественная документация
Structure
Actions
Remote

R1. Доступен fetch коммитов
любого репозитория в любой момент

Клонирование
https://repos/repo
git clone https://repos/repo

origin
https://repos/repo
origin = https://repos/repo
git clone https://repos/repo

remote
https://repos/repo
origin = https://repos/repo

Таблица remote
https://repos/repo
origin = https://repos/repo
arnold = https://arnold/repo
https://arnold/repo
Список «кликух» для дружественных репозиториев

Remote в Git Extensions

Remote в Git Extensions

Remote в консоли

Обмен изменениями
1
master

Появился клон
1
master
1
master
origin/master

Прошло время
1
f1
2
3
master
4
5
1
f2
6
master
7
8
origin/master

А что если в правый добавить из левого?
1
f1
2
3
master
4
5
1
f2
6
master
7
8
origin/master

А что если в правый добавить из левого?
origin/f1
2
3
origin/master
4
5
1
f2
6
master
7
8

fetch – операция получения изменений из другого репозитория
Это безопасная операция за счет неизменности истории
В коммитах может быть «каша», но это уже отдельный вопрос
Fetch ничего не меняет, просто позволяет взглянуть шире: на изменения из других репозиториев, а не только на локальные
Можно сделать fetch из любого репозитория,
даже если нет общих коммитов
Fetch

Все же, что здесь делать?
origin/f1
2
3
origin/master
4
5
1
f2
6
master
7
8

Rebase локальной ветки
origin/f1
2
3
origin/master
4
5
1
f2
7
8
6’
master

Теперь все хорошо
origin/f1
2
3
origin/master
4
5
1
f2
7
8
6’
master

Задание 11. Fetch From Remote
Задание 12. Interactive Rebase
Задание 13. Cherry Pick

S1. Все локально
A1. Трехсторонний merge
в три шага
A2. rebase, cherry-pick и amend, чтобы пересоздать историю
S2. Хранятся
состояния директории,
постепенная сборка коммита
S3. Манипуляции
через ссылки,
нет ссылки — в мусор
R1. Доступен fetch коммитов
любого репозитория
в любой момент
H1. Гибкое конфигурирование и качественная документация
Structure
Actions
Remote

R2. Удаленное изменение — это push

Надо отправить изменения
origin/f1
2
3
origin/master
4
5
1
f2
7
8
6’
master

Применим push
origin/f1
2
3
origin/master
4
5
1
f2
7
8
6’
master

Применим push
2
3
origin/master
1
6’
master
Раз master можно влить
в origin/master
через fast-forward merge,
то push будет успешным

Отправляет коммиты в удаленный репозиторий
Сдвигает ветки в удаленном репозитории
Требует права на запись в удаленный репозиторий, а следовательно некий способ аутентификации
Push

Удаление ветки – это тоже push, только другой
git push
-d
В Git Extensions разница между удалением
локальной и удаленной ветки особо не чувствуется
Удаление удаленной удаленки ветки

Добавление или удаление тегов в удаленном
репозитории — это тоже push
git push tag
git push
--tags
git push
-d
Теги в удаленном репозитории

Ситуация без rebase
origin/f1
2
3
origin/master
4
5
1
f2
6
master
7
8

Fast-Forward Merge невозможен
2
3
origin/master
1
6
master

Force Push может помочь…
2
3
origin/master
1
6
master

Force Push заставит ветку сдвинуться
2
3
origin/master
1
6
master

Force Push заставит ветку сдвинуться
2
3
origin/master
1
6
master
Коммиты будут потеряны
Если их использовали – за тобой придут…

Никогда не делай
Force Push
в master
Со своими ветками делай что хочешь

Реалистичный пример

Картина мира первого разработчика
2
3
origin/master
1
2’, 3’
master

Картина мира второго разработчика
f3
2
3
master
9
1
origin/master

Худшие ожидания второго
f3
2
3
master
9
1
10
origin/master
Легко решается:
FF merge для master
rebase f3 на master или merge f3 в master

Но первый делает подлянку
2
3
origin/master
1
2’, 3’
master

Что видит второй после fetch
f3
2
3
master
9
1
origin/master
2’, 3’
Неожиданный подарок:
для master невозможен merge
для f3 возможен только rebase
Лишняя возня из-за первого, перед тем как влить свою работу в master

А что если второй будет быстрее?
f3
2
3
master
9
1
origin/master

Вольет свою ветку в master и запушит?
f3
2
3
master
9
1
origin/master
Работа сделана!
Можно радовать менеджера
и идти домой!

Затем первый в неведении делает подлянку
2
3
origin/master
1
2’, 3’
master

Итоговая картина
origin/f3
2
3
9
1
origin/master
2’, 3’
master

Итоговая картина
origin/f3
2
3
9
1
origin/master
2’, 3’
master
Изменения второго разработчика не влиты и он похоже об этом узнает только после неудачного релиза...

Итоговая картина
origin/f3
2
3
9
1
origin/master
2’, 3’
master
Изменения второго разработчика не влиты и он похоже об этом узнает только после неудачного релиза...

Пристальный взгляд на проблему
2
3
9
1
origin/master
2’, 3’
master
origin/master

Пристальный взгляд на проблему
2
3
9
1
origin/master
2’, 3’
master
origin/master
Надо запрещать Force Push,
когда origin/master сдвинут!
Force Push With Lease так и работает
Lease — англ. Аренда

Никогда не делай Force Push
Не делай Force Push With Lease в master
Со своими ветками делай что хочешь, но используй Force Push With Lease

Удобный алиас
git config --global alias.please "push --force-with-lease"

Задание 14. Push

S1. Все локально
A1. Трехсторонний merge
в три шага
R2. Удаленное изменение
— это push
A2. rebase, cherry-pick и amend, чтобы пересоздать историю
S2. Хранятся
состояния директории,
постепенная сборка коммита
S3. Манипуляции
через ссылки,
нет ссылки — в мусор
R1. Доступен fetch коммитов
любого репозитория
в любой момент
H1. Гибкое конфигурирование и качественная документация
Structure
Actions
Remote

R3. Явное сопоставление
локальных веток с upstream

Upstream repository
GitHub

Upstream repository
GitHub

Никак – надо всегда прописывать обе ветки явно
Должно совпадать имя
Есть внутренняя таблица сопоставления
Git использует все способы,
режим сопоставления можно настраивать
Как push понимает какую ветку сдвигать?

Для основного репозитория
Используется сопоставление из таблицы
При push новой ветки достаточно указать намерение
git push –u origin HEAD
Чтобы создать локальную ветку для удаленной с записью в таблицу достаточно на нее перейти
git checkout
Для других репозиториев идет сопоставление по имени ветки можно не запоминать
По умолчанию режим simple

Как создать привязку для f1?
origin/f1
2
3
origin/master
4
5
1
f2
7
8
6’
master
Перейти на ветку

Как создать привязку для f2?
origin/f1
2
3
origin/master
4
5
1
f2
7
8
6’
master
push -u

Удобный алиас
git config --global alias.pushup "push -u origin HEAD"

Upstream mapping в Git Extensions

Upstream mapping в консоли
Local branch
Upstream branch
Remote name

git pull origin =
git fetch + git merge origin/
git pull --rebase origin =
git fetch + git rebase origin/
Pull нужно знать с какой веткой делать merge или rebase и здесь тоже нужно сопоставление веток
Pull тоже использует upstream mapping

Либо fast-forward merge, либо без merge
С помощью опций:
pull --ff-only
Установить для pull по умолчанию:
git config --global pull.ff only
Безопасный pull

Удобный алиас
git config --global alias.pure "pull --rebase --autostash"

Задание 15. Upstream

S1. Все локально
A1. Трехсторонний merge
в три шага
R2. Удаленное изменение
— это push
A2. rebase, cherry-pick и amend, чтобы пересоздать историю
S2. Хранятся
состояния директории,
постепенная сборка коммита
S3. Манипуляции
через ссылки,
нет ссылки — в мусор
R3. Явное сопоставление
локальных веток
с upstream
R1. Доступен fetch коммитов
любого репозитория
в любой момент
H1. Гибкое конфигурирование и качественная документация
Structure
Actions
Remote

A3. stash, reset, revert
для управления изменениями
Изменения можно временно припрятать
Можно получить разницу между любыми коммитами
Коммит можно отменить другим коммитом

Что произойдет при влитии f1 в f2?

Произойдет конфликт

Что произойдет при влитии f1 в f2?

Бесконфликтное слияние

Почему?

Состояния слева и справа совпадают
ABC
ABC
ABC
f1
f2
А история не имеет значения

Каждый коммит хранит структуру каталога и все файлы состояния директории
Хранение файлов оптимизировано: файлы не хранятся повторно, потому что в структуре каталога хранятся не сами файлы, а ссылки по хэшу на них
Используется сжатие, чтобы текстовые данные занимали меньше места
Разница между коммитами вычисляется на лету и с родителем и с любым другим коммитом
Хранятся файлы, разница вычисляется на лету

Diff можно получить между любыми коммитами
2
3
1
5
6
4

Diff можно получить между любыми коммитами
2
3
1
5
6
4
A.txt
B.txt
D.txt
A.txt
C.txt
D.txt
A.txt
D.txt

Что изменится при переходе от 4 к 6?
2
3
1
5
6
4
A.txt
B.txt
D.txt
A.txt
C.txt
D.txt
A.txt
D.txt
diff по сравнению с 4
-B.txt
+C.txt

Что изменится при переходе от 6 к 4?
2
3
1
5
6
4
A.txt
B.txt
D.txt
A.txt
C.txt
D.txt
A.txt
D.txt
diff по сравнению с 6
+B.txt
-C.txt

reset --hard
HEAD
f1
HEAD
f1

Переносит ветку вслед за HEAD
Выставляет индекс и директорию согласно коммиту, устраняет разницу
reset --hard

reset --hard
A.txt
B.txt
A.txt
A.txt
A.txt B.txt
B.txt
B.txt

reset --mixed
HEAD
f1
HEAD
f1

Переносит ветку вслед за HEAD
Задает индекс согласно коммиту
Оставляет разницу между исходным и новым состоянием в директории
reset --mixed

reset --mixed
A.txt
B.txt
A.txt
A.txt
A.txt B.txt
B.txt
A.txt
Δ WD: +A, -B
Δ CI: +-

Working directory changes
Commit index changes

reset --soft
HEAD
f1
HEAD
f1

Переносит ветку вслед за HEAD
Не задает ни индекс, ни директорию согласно коммиту
Оставляет разницу между исходным и новым состоянием в индексе и директории
reset --soft

reset --soft
A.txt
B.txt
A.txt
A.txt
A.txt B.txt
A.txt
A.txt
Δ WD: +-
Δ CI: +A, -B

Working directory changes
Commit index changes

Удобный алиас
git config --global alias.undo "reset --soft HEAD^"

Тайник для временного сохранения изменений
После сохраненные изменения можно восстановить
в том же или в другом месте
Работает по принципу стека: push, pop
Можно применять сохраненные изменения неоднократно
Stash

Неудачные изменения одного коммита можно отменить противоположными изменениями в следующем коммите
Revert
+
master
HEAD

Неудачные изменения одного коммита можно отменить противоположными изменениями в следующем коммите
Revert
+
-
master
HEAD

Неудачные изменения одного коммита можно отменить противоположными изменениями в следующем коммите
Revert
+
-
master
HEAD
master
HEAD
Одинаковые

Revert полезен,
когда надо отменить изменение,
а перестраивать историю нельзя

Задание 16. Stash
Задание 17. Hard Reset
Задание 18. Soft Reset

S1. Все локально
A1. Трехсторонний merge
в три шага
R2. Удаленное изменение
— это push
A2. rebase, cherry-pick и amend, чтобы пересоздать историю
A3. stash, reset, revert
для управления изменениями
S2. Хранятся
состояния директории,
постепенная сборка коммита
S3. Манипуляции
через ссылки,
нет ссылки — в мусор
R3. Явное сопоставление
локальных веток
с upstream
R1. Доступен fetch коммитов
любого репозитория
в любой момент
H1. Гибкое конфигурирование и качественная документация
Structure
Actions
Remote

Разное

Что такое Pull Request
GitHub

Изменения в локальном репозитории
GitHub
f1

Отправка изменений в свой удаленный
GitHub
f1
f1

PR – запрос на fetch + merge
GitHub
f1
f1

Если PR принят, то fetch
GitHub
f1
f1
f1

Если PR принят, то merge
GitHub
f1
f1
master

Что такое Merge Request
GitLab

Изменения в локальном репозитории
GitLab
f1

Отправка изменений в удаленный
GitLab
f1
f1

MR – запрос на merge
GitLab
f1
f1

Если MR принят, то merge
GitLab
f1
master

Картина для централизованного репозитория
https://repos/repo
https://arnold/repo
https://brayan/repo
Здесь создаются коммиты
Этот репозиторий
обрабатывает пуши
и отдает наработки
при фетчах

Получить последние изменения
Создать локальную ветку
Разработать в ней фичу
Получить последние изменения
Влить мастер в свою ветку (опционально)
Влить свою ветку в мастер
Запушить (если кто-то успел запушить раньше, то повторить 4-7)
Алгоритм для разработчика

Блиц

Надо подключить Git к папке,
в который ты делаешь тестовое задание

Надо загрузить локальный репозиторий
с тестовым заданием на GitHub для проверки

Надо подключиться к разработке сервиса
в отдельном репозитории

Надо начать разработку новой фичи

Сделаны некоторые изменения,
надо их сохранить в репозитории

Ты забыл добавить кое-что
в последний коммит, а надо

Надо сделать так, чтобы новая фича была доступна для тестирования

Тестировщик попросил,
чтобы последние исправления из master
тоже были в ветке с фичей

При влитии исправлений
из master возникли конфликты

Пора сделать релиз фичи,
у вас фичи релизятся из master

Надо помочь другому разработчику
сделать фичу

За день ты сделал некоторые изменения
и решил ими поделиться

Оказалось, что твой напарник
тоже сделал изменения
Надо их получить, а затем
опубликовать свои изменения

На следующий день ты продолжил
работать над фичей,
но тебя срочно попросили починить
опечатку прямо в master
ЧТО ТВОРЯТ =/

Ты поправил опечатку, закоммитил в master
и получил изменения в origin/master
Ты решил переключиться на origin/master,
Git Extension предложил сделать reset master
на origin/master, а ты машинально согласился…

Ты вернулся к фиче,
которую делал с другим разработчиком

У твоего напарника сегодня выходной
Ты доделал изменения,
о которых вы договаривались
Их надо сохранить перед тем,
как переходить к следующей задаче

Ты начал делать новую задачу
и сделал первый коммит
Но понял, что забыл завести ветку,
а коммит ушел в master

Разработка не клеилась…
Ты сделал десяток коммитов, перед тем
как понял, как решать задачу
Чтобы избежать позора, ты решил заменить
эти коммиты на один

Чтобы список веток был коротким,
ты решил удалить влитые локальные ветки

Бурная неделя закончилась
Пора отдыхать!