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

1.

GIT – СИСТЕМА КОНТРОЛЯ ВЕРСИЙ
ОСНОВЫ ИСПОЛЬЗОВАНИЯ

ПРЕИМУЩЕСТВА GIT
Почти все операции происходят локально и доступ в интернет не требуется
Целостность данных и отслеживание изменений осуществляет с
помощью постоянного просчета хеш-суммы файлов и директорий
методом SHA-1
GIT обычно только добавляет данные
24.03.2022

4.

МЕХАНИЗМ ПСЕВДОНИМОВ
Механизм псевдонимов позволяет упаковывать длинные команды GIT со множеством опций в короткие
команды
Для создания псевдонима нужно выполнить команду git config
Например: git config
--global alias.<shortname> <long command>
--global alias.hist "log --pretty=format:'%h %ad | %s%d [%an]' --graph --date=short
Теперь команды
git hist
git log --pretty=format:'%h %ad | %s%d [%an]' --graph --date=short
идентичны
24.03.2022

5.

DIVING DEEPER
У GIT есть три основных рабочих области
1. Директория .git — место, где GIT хранит
метаданные и базу объектов вашего проекта
2. Рабочая директория является снимком версии
проекта
3. Область подготовленных файлов — это файл,
обычно располагающийся в вашей GIT-директории,
в нём содержится информация о том, какие
изменения попадут в следующий коммит
24.03.2022

6.

ЦИКЛ ЖИЗНИ ИЗМЕНЕНИЙ В GIT
Каждый файл в вашем рабочем каталоге может находиться в одном из
двух состояний: под версионным контролем (tracked) и нет (untracked).
• Отслеживаемые файлы — это те файлы, которые были в последнем
снимке состояния проекта; они могут быть неизменёнными,
изменёнными или подготовленными к коммиту.
• Не отслеживаемые файлы — это всё остальное, любые файлы в
рабочем каталоге, которые не входили в ваш последний снимок
состояния и не подготовлены к коммиту.
Любой отслеживаемый файл изначально считается не
модифицированным
После внесения любых правок в отслеживаемый файл, GIT пометит этот
файл как измененный и готовым к «индексации»
После «индексации» файлы готовы к коммиту
24.03.2022

7.

ЦИКЛ ЖИЗНИ ИЗМЕНЕНИЙ В GIT
Для добавления новый файлов к отслеживаемым используем команду
git add <file>
Для добавления модифицированных файлов к индексу так же
используем команду git add <file>
Для удаления файлов используем git rm <file>
• -f – для форсированного удаления из уже проиндексированных
файлов
• --cached – для удаления файлов из отслеживаемых
Для коммита используем команду git commit –m “Commit message”
• -a – для игнорирования этапа индексации и добавления в коммит
всех отслеживаемых файлов
Для перемещения файлов используем команду git
mv <file_from> <file_to>
24.03.2022

8.

ЦИКЛ ЖИЗНИ ИЗМЕНЕНИЙ В GIT
Для отображения информации по отслеживанию файлов в репозитории
используем команду git status
Текущая ветка
Статус ветки относительно удаленного репозитория
Проиндексированные и готовые к коммиту файлы
Модифицированные или удаленные файлы
Не отслеживаемые файлы
Для просмотра правок в измененном файле используем команду
git diff <file>
Для просмотра правок в уже проиндексированном файле используем
команду git diff --staged <file> или git diff --cached <file>
24.03.2022

9.

СОХРАНЕНИЕ ИЗМЕНЕНИЙ ДО ЛУЧШИХ ВРЕМЕН
Для сохранения изменений во временное хранилище для последующего использования существует команда
git stash
У этой команды так же существует опция --keep-index, которая позволяет отправить в хранилище только
неиндексированные изменения
Другая опция --include-untracked или -u позволяет скрыть и не отслеживаемые файлы
Так же можно задавать сообщение опцией -m как при коммите
Чтобы показать список сохраненных слотов выполняем команду git stash list
Чтобы применить одно из них, существует команда git apply [stash@{<slotindex>}], но в таком случае после применения
изменений к рабочей области, данный «патч» сохранится в списке. Если вызвать эту команду с опцией --index, то GIT,
помимо восстановления всех файлов, добавить в индекс те, которые были проиндексированы до скрытия.
Чтобы применить изменений и сразу удалить их из списка существует команда git stash pop
Так же можно вручную удалить ненужный слот командой git stash drop stash@{<slotindex>} или удалить все слоты
командой git stash clear, очистив хранилище полностью
Очень интересно работает команда git stash branch <branch>, которая, если с момента сохранения изменений в ветке
появились новые коммиты, откатывает изменения до коммита на котором был создан «патч» и создает новую ветку, на
которую постарается восстановить сохраненные изменения и, если это было сделано успешно, удалит слот из хранилища.
24.03.2022

10.

КАК ХРАНЯТСЯ ДАННЫЕ
Предположим, в вашей рабочей директории есть три
файла и вы добавляете их все в индекс и создаёте коммит.
Во время индексации вычисляется контрольная сумма
каждого файла, затем каждый файл сохраняется в
репозиторий (GIT называет такой файл blob — большой
Если
вы сделаете
и создадите
ещё один
коммит,
бинарный
объект),изменения
а контрольная
сумма попадёт
в индекс
то он будет содержать указатель на предыдущий коммит.
Когда вы создаёте коммит командой git commit, GIT
Ветка
в GITконтрольные
— это простой
перемещаемый
указатель на
вычисляет
суммы
каждого подкаталога
(в один
из
таких
коммитов.
Поосновной
умолчанию,
имя основной
нашем
случае,
только
каталог
проекта) иветки в
GIT
— master.
только вы начнёте
создавать
сохраняет
егоКак
в репозитории
как объект
деревакоммиты,
ветка
master
будет
всегда
указывать
на последний
коммит.
каталогов.
Затем
GIT
создаёт
объект коммита
с
Каждый
раз при
создании коммита
указатель
ветки
master
метаданными
и указателем
на основное
дерево
проекта
будет
передвигаться
на следующий
коммит
автоматически.
для возможности
воссоздать
этот снимок
в случае
необходимости.
Ваш репозиторий GIT теперь хранит пять объектов: три
блоб объекта (по одному на каждый файл), объект дерева
каталогов, содержащий список файлов и
соответствующих им блобов, а так же объект коммита,
содержащий метаданные и указатель на объект дерева
каталогов.
24.03.2022

11.

ИСТОРИЯ КОММИТОВ
Для просмотра истории коммитов существует очень мощная команда git log
--pretty=oneline
У этой команды существует большое количество опций, преобразовывающих
формат вывода данных и фильтрацию
--max-count=2 – указывает лимит выводимых коммитов
--since и --until – фильтр по времени (возможен кастомный формат времени,
к примеру: 5 minutes ago)
--author – фильтр по автору коммита
--all – выводит всю историю репозитория (показывает даже коммиты,
--pretty=format:"%h %ad | %s%d [%an]"
которые не принадлежат ни одной ветке)
--graph –
--pretty – улучшает формат вывода информации по коммиту (из интересных
значений oneline и кастомный format)
опция, добавляющая визуализацию веток при помощи простых
ASCII символов
24.03.2022

12.

УПРАВЛЕНИЕ ВЕТКАМИ
Управление ветками организовывается с помощью команды git branch:
git branch –
отображает список локальных веток (символом * обозначается выбранная ветка)
git branch -v –
git branch --merged и --no-merged –
отображает список локальных веток с последними коммитами
отображает ветки, которые были слиты или не слиты с текущей веткой
соответственно
git branch -d <branch> –
удаляет ветку. Однако, если ветка еще не была слита с текущей, то появится
соответствующая ошибка. Чтобы удалить ветку игнорируя сравнения веток, можно использовать ключ -D
24.03.2022

13.

ВЕТКИ
При создании новой ветки создаётся новый указатель для
дальнейшего перемещения. Допустим вы хотите создать
новую ветку с именем testing. Вы можете это сделать
командой git branch testing.
Так же в GIT есть специальный указатель HEAD, который
указывает на текущую локальную ветку. В нашем случае мы
все
находимся
в ветке
master. Команда
git branch
Приеще
добавлении
нового
коммита
в ветку master
мы
только
создаёт вот
новую
ветку,
но не переключает на неё.
уже получаем
такую
картину.
Для переключения на существующую ветку выполните
команду git checkout. В нашем случае git checkout testing.
Добавим новый коммит в ветку testing. Указатель на ветку
testing переместился вперёд, а master указывает на тот же
коммит, где вы были до переключения веток командой git
checkout.
Теперь переключимся опять на ветку master и увидим, что
указатель HEAD опять переместился на нее.
24.03.2022

14.

СЛИЯНИЕ ВЕТОК (MERGE)
В случае сливания веток, которые различаются только одним коммитом (на данном рисунке это ветки master
и hotfix), оно будет проходить «перемоткой». То есть GIT всего лишь переместит указатель ветки на новый
коммит.
24.03.2022

15.

СЛИЯНИЕ ВЕТОК (MERGE)
На самом деле со слиянием веток все очень просто.
Когда мы выполняем команду git merge iss53, находясь на ветке master, GIT:
считывает последние коммиты веток
считывает последний общий коммит веток
делает трёхстороннее слияние
создает коммит слияния.
24.03.2022

16.

СЛИЯНИЕ ВЕТОК (REBASE)
Команда git rebase работает следующим образом:
• берётся общий родительский снимок двух веток
• определяется дельта каждого коммита текущей ветки и
сохраняется во временный файл
Перебазирование
осуществляется
в несколько этапов в отличии от слияния:
• текущая ветка
устанавливается
на последний коммит
ветки, поверх которой вы выполняете перебазирование
Находясь надельты
вливаемой
ветке нужно
выполнить команду git rebase master
• по очереди •применяются
из временных
файлов
• Переключаемся на целевую ветку командой git checkout master
• Сливаем ветку experiment в ветку master (будет использована «перемотка»),
используя команду git merge experiment
24.03.2022

17.

УДАЛЕННЫЕ РЕПОЗИТОРИИ
Для просмотра списка удаленных репозиториев существует команда
git remote -v
Для добавления репозитория используем команду
git remote add <name> <url>
Для переименования репозитория используем команду
git remote rename <from> <to>
Для удаления ссылки на репозиторий используем команду
git remote rm <name>
Для дополнительной информации об удаленном репозитории используем команду
git remote show <name>
Ссылки для обновления и «пуша» изменений
Ветка в удаленном репозитории по умолчанию
Список веток на удаленном сервере
Ветки сконфигурированные для pull и push команд
Для синхронизации данных с удаленным репозиторием используем команду
git fetch
24.03.2022

18.

РАБОТА С УДАЛЕННЫМ РЕПОЗИТОРИЕМ
Для получения коммитов из удаленной ветки нужно выполнить две команды:
git fetch <remote> <branch>
git merge <remote>/<branch>
Однако есть способ получить изменения используя всего одну команду – git pull, но для этого нужно сначала
связать локальную и удаленную ветки в пару. Для это существует несколько способов.
git checkout --track <remote>/<branch> – команда склонирует ветку из удаленного репозитория в локальный с
таким же именем и установит между ними связь. Так же можно просто вызвать команду git checkout <branch>,
если не существует такой локальной ветки, но существует удаленная
git checkout -b <local_branch> <remote>/<branch> – если нужно задать отличное от удаленного репозитория
название ветки
git branch -u <remote>/<branch> –
для установки пары для уже существующей локальной ветки
После этого можно использовать команду git pull
У git pull есть опция --rebase, которая заставляет GIT использовать команду rebase вместо merge
24.03.2022

19.

РАБОТА С УДАЛЕННЫМ РЕПОЗИТОРИЕМ
Для отправки коммитов используем команду git push
У нее очень простой синтаксис, но есть парочка скрытых возможностей
git push <remote> <branch> –
git push <remote> <local_branch>:<remote_branch> –
отправка коммитов в удаленный репозиторий
для отправки коммитов в удаленный репозиторий, но в
переименованную ветку
git push -u <remote> <branch> – для отправки изменений и создания связи для команды git pull
git push --force <remote> <branch> –
git push <remote> --delete <branch> – удаление ветки в удаленном репозитории
форсированная отправка ветки в удаленный репозиторий (удаленная ветка
полностью замещается локальной)
24.03.2022

English Русский Правила