Using Git

1.

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

2.

В этой лекции
1.
Что такое система контроля версий
2.
Установка Git клиента и инициализация локального репозитория
3.
Работа с локальным репозиторием
4.
Ветки репозитория
5.
Работа с удаленными репозиториями

3.

Что такое система контроля версий
Не смотря на то, что система контроля версий была уже рассмотрена ранее, при установке
ее на сервер, стоит еще раз вспомнить, что это за система и в чем преимущество ее
использования.
Система контроля версий Git (далее – Git), это система, позволяющая вести непрерывное
состояние проекта, разбивая его на, своего рода, стадии разработки. Каждая из этих стадий
называется «Коммит» (Commit) и содержит определенное состояние проекта. В каждом
коммите хранится информация о том, когда он был сделан и кем он был сделан. Это дает
команде, работающей над проектом, понимание о том, когда были сделаны те или иные
изменения и кем они были сделаны. Git позволяет в любое время вернуться к
определенному коммиту и восстановить состояние проекта с него. Эта интелектуальная
система хранит, своего рода, снимки проекта в этих коммитах, поэтому, вы всегда можете
вернуть проект в то или иное состояние.
Если какой-то из разработчиков что-то сломает, то вы можете вернуть проект в состояние,
где он еще не внес эти изменения.

4.

Что такое система контроля версий
Помимо сохранения состояния проектов, Git позволяет легко и удобно орнанизовать работу
команды над одним проектом. Поможет избежать в путанице в измененных несколькими
людьми файлах и позволить наладить интеграцию проекта на разные этапы его работы,
будь то среда разработки, среда тестирования или боевая среда, с которой работают
реальные пользователи.
Плюсом также является то, что Git позволяет вести параллельную работу над другими
задачами по проекту, не мешая основному функционалу.
Для работы с Git, используются репозитории. В каждом репозитории, как правило, хранится
какой-то отельный проект. Начиная работу с Git, необходимо создать репозиторий на
сервере, это называется «Удаленный репозитоий», а на вашем рабочем компьютере,
создается «Локальный репозитоий». Что-бы начать работать с удаленным репозиторием,
его надо скачать себе на локальный репозиторий. Произведя изменения, необходимо
создать «Коммит», содержащий изменения. Далее, необходимо эти изменения выгрузить
на удаленный репозиторий, что-бы их могли увидеть остальные.

5.

Что такое система контроля версий
Итого, пользователи работают с удаленным репозиторием,
загружая данные со своего локального или выгружая данные на
свой локальный репозиторий. Для выгрузки изменений на
удаленный репозиторий, они используют «Коммиты».

6.

Что такое система контроля версий
У локального репозитория, есть три стадии. Первая – Рабочая стадия (Working Area), в
которой производятся изменения, вы меняете какие-то файлы, добавляете новые файлы и
Git фиксирует их в этой стадии. Вторая – Стадия принятия изменений (Staging Area), в
которой вы выбираете, какие файлы войдут в будующий коммит. Разумеется, туда попадут
тольк файлы из рабочей стадии. Третья стадия – Стадия фиксации изменений (Commited
Files), в этой стадии находятся те объекты, которые будут добавлены в будущий коммит.

7.

Установка Git клиента и инициализация
локального репозитория
Git доступен на всех платформах (Windows, MacOS, Linux), его можно найти уже встроенным в
популярные текстовые редакторы (например Visua Studio Code) и среды разработки. Он есть как в
графическом так и в консольном виде. Чтобы понять, как работать с клиентом Git, воспользуемся
консольной версией. Установить ее можно, выполнив команду «apt install git». Для получения
справки по основным командам, после установки клиента, можно набрать команду «git help».
После установки клиента, сперва надо инициализировать локальный репозиторий. В котором
далее мы будем работать. Выберите любую директорию, в которой будете делать проект, можно
создать директорию в вашем домашнем каталоге (/home/user). Не забудьте создать там
директорию с вашим проектом и назвать ее понятным именем.
Для инициализации в ней, локального репозитоия, воспользуемся командой «git init».
Воспользуйтесь командой «ls –la» и обратите внимание на созданную только что, скрытую
директорию «.git». Ее наличие говорит об успешно инициализированном локальном репозитории.

8.

Работа с локальным репозиторием
Давайте создадим простой веб сайт на статическом HTML.
Создайте файл «index.html» и впишите туда контент следующего вида:
<html>
<head>
<title>Welcome to my web site!</title>
</head>
<body>
<p>Feel free to explore its content!</p>
</body>
</html>
Выполните команду «git status», вы увидете, что ваш файл был отмечен как «не отслеженный», то есть Git
видит, что вы только что создали новый файл и ждет, что вы будете дальше с ним делать. Git сообщает вам,
что пока в коммит ничего не добавлено, но есть некоторые новые, не отслеженные файлы.

9.

Работа с локальным репозиторием
Для создания коммитов, сперва нужно задать имя пользователя и почту пользователя.
Это можно сделать с помощью команд: «git config user.name "user"», где user, это имя
пользователя. И «git config user.email "[email protected]"», где [email protected], это
почта.
Эти данные вы можете найти в вашей Git системе.

10.

Работа с локальным репозиторием
Сейчас, только что созданный файл index.html, находится в рабочей стадии (Working Area).
Git пока не знает, что с ним делать. Для того, чтобы добавить его к комиту, необходимо ввести
команду «git add index.html». Эта команда позволяет зафиксировать изменения и добавить
этот файл для будующего коммита в удаленный репозиторий.
Наконец, вы можете сделать коммит, введя команду «git commit –m “Created index page”».
Эта команда создаст коммит с сообщением о создании страницы index (Created index page).
Следует создавать комиты так, чтобы они решали какую-то одну проблему. Например, если
вы добавляете новую функцию на сайт и чините какой-то баг, а затем коммитите изменения в
один коммит, то может возникнуть ситуация, что новый функционал, вызвал сбой в работе
сайта и вам надо откатить изменения. Но вместе с новым функционалом, вы откатите и
исправление бага, которые откатывать не нужно. Поэтому, старайтесь делать коммиты
атомарными, так чтобы они решали каждый свою задачу. То есть один коммит чинит баг, а
второй добавляет новый функционал.

11.

Работа с локальным репозиторием
Можен возникнуть вопрос, для чего нужна Стадия принятия изменений (Staging Area), ответ
прост. Вы можете работать над проектом какое-то время и решать много задач, как
например, добавление нового функционала и исправление бага. В ходе этого, вы создаете
множество новых файлов и редактируете множество старых. Добавляя файлы в коммит, вы
можете выбрать только те, которые только исправляют баг и передав их из рабочей стадии в
стадию принятия изменений, передать их на коммит, а файлы, отвечающие за новый
функционал, отправлены не будут, так как они останутся в рабочей стадии.
Добавление промежуточной стадии принятия изменений (Staging Area), позволяет вам
выбрать те файлы, которые пойдут в коммит и отправить их отдельно от тех, которые должны
пойти в коммит следующей очередью.
В ходе работы над проектом, может возникнуть ситуация, что некоторые файлы и папки не
нужно передавать в коммит. Это могут быть какие ни будь логи или ваши личные заметки или
файлы кеша. Для того, чтобы исключить их из добавления в коммит, их имена надо записать в
файл «.gitignore». Туда можно как вписать сам файл, наприммер «mynotes.txt» так и
использовать регулярные выражения, типа «*.txt». В таком случае, в коммиты не попадут
файлы с расширением txt.

12.

Работа с локальным репозиторием
Для того, чтобы отследить историю коммитов, можно использовать команду «git log» или «git
log --oneline».
Она поможет посмотреть, кто и когда сделал коммит. Ключ «--name-only», отобразит список
внесенных в коммит файлов.

13.

Ветки репозитория
Ветки репозитория нужны для того, чтобы разделить работу над проектом на логические
разделы. Вы можете создать ветку (то есть раздел) для каждого разработчика. И он будет
работать в ней, не мешая и не боясь сломать проект в основной ветке. Или если необходимо
внедрить и протестировать новый функционал, вы можете создать для него отдельную ветку.
По умолчанию, в репозитории есть только ветка master. Именно в ней, как правило, хранится
исходная версия проекта. Новая ветка может быть создана от ветки master. Далее от только
что созданной ветки можно создать еще одну и так далее.
Для того, чтобы создать новую ветку, воспользуйтесь командой «git branch new_feature», где
«new_feature», это имя новой ветки. Для перехода в нее, есть команда «git checkout
new_feature». Эти две команды заменяются одной «git checkout -b new_feature», ключ «-b»,
позволяет создать ветку и сразу перейти в нее. Для удаления ветки есть команда «git branch –
d new_feature», а для вывода списка всех веток, есть команда «git branch» без аргументов и
ключей.

14.

Ветки репозитория
Попробуйте создать новую ветку, перейдите в нее и создайте новую строку в ранее
созданном файле «index.html». Далее, сделайте коммит.
После этого, проверьте, что в файле «index.html», появился новый контент. Затем, перейдите
обратно на ветку мастер и снова посмотрите содержимое файла.
Вы увидите, что на ветке master, файл «index.html», не содержит этих изменений.
Вы можете объединять содержимое двух веток между собой. Например, вы тестировали
новый функционал и тесты прошли успешно. Вы хотите изменения из временно созданной
ветки перенести в основную ветку master. Для этого, перейдите в ветку master и, при помощи
команды «git merge new_feature», перенесите содержимое ветки «new_feature» в ветку
«master». Git переносит содержимое в режиме fast-forward, когда в ветке, куда переносится
содержимое другой ветки, нет новых коммитов, относительно того, где была создана та
самая ветка. Если новые коммиты есть, то перенос происходит в режиме no-fast-forward.

15.

Работа с удаленными репозиториями
До этого момента, мы работали только с локальным репозиторием. Пришло время,
подключить удаленный репозиторий.
Удаленный репозиторий может храниться в Интернете или на сервере организации. Вы
можете использовать различные Git платформы для этого, такие как GitHub, GitLab, Bitbucket,
GOGS, Gitea и так далее. Некоторые из них, можно развернуть на локальном сервере и
хостить самостоятельно.
Репозиторий выглядит, как имя пользователя или организации (1)
и имя самого репозитория (2). Для подключения к нему, нужно
скопировать строку для подключения. Используйте команду
«git remote add origin http://10.4.3.3:3000/sorbypher/sisa-test.git»,
где http://10.4.3.3:3000/sorbypher/sisa-test.git - это строка для
подключения

16.

Работа с удаленными репозиториями
Пришло время, отправить изменения в удаленный репозиторий. Для этого, вы можете
применить команду «git push origin master», для отправки master ветки. Этой командой
можно отправлять любые ветки.
Поскольку мы вели коммиты сперва в локальном репозитории, Git может отказаться
передавать их в удаленный репозиторий, так-как он отстал от нашего локального, но в нем
есть коммиты, которых нет у нас, так как мы с него ничего не забирали. Попробуйте
применить команду «git config pull.rebase true» и затем забрать изменения с удаленного
репозитория «git pull origin master», затем снова выполните push.
А вообще, правильным действием будет, сперва подключить удаленный репозиторий и
забрать с него изменения, а уже после, выкачивать в него свои коммиты.

17.

Работа с удаленными репозиториями
С помощью команды «git clone http://172.20.7.3:3000/sorbypher/sisa-test.git», где
«http://172.20.7.3:3000/sorbypher/sisa-test.git», это адрес удаленного репозитория, вы можете
клонировать репозиторий себе и далее, локально, самостоятельно проводить изменения над
проектом в нем. Такой метод также удобен, если необходимо установить какую ни будь
программу, которая располагается в репозитории. Или если у вас есть веб сайт в
репозитории, вы можете развернуть его на веб сервере.
Иногда, бывают ситуации, когда разработчики редактируют один и тот же файл в своих
ветках. В таком случае, при попытке объединения своих веток с веткой master, один из них
сделает это успешно, а у второго возникнет проблема, называемая merge-conflict. Это
ситуация, когда один и тот же файл имеет несколько разных версий. Как правило, такие
ситуации решаются вручную, и разработчики сами решают, какой файл в итоге оставить.
Можно добавить что-то из второго файла, а что-то удалить. В таком случае, сформируется
результирующий файл, который будет отправлен в репозиторий.

18.

Работа с удаленными репозиториями
Работая в большой кампании разработчиков, нельзя им просто так позволять объединять
свои ветки с веткой master. В противном случае, они могут сломать проект. Как правило, в
таких случаях, назначается человек (им может быть ведущий программист), который
устраивает код-ревью и изучает изменения, которые будут внесены в master ветку. В таком
случае, необходимо отправить pull-request через Git систему и он сможет его подтвердить
или опровергнуть.
Такой метод работает не только с репозиториями в рамках одной кампании. У многих
ведущих кампаний, которые владеют популярными, крупными программными продуктами,
есть свои репозитории. В них так просто нельзя отправлять коммиты. Можно попроситься
стать участником-разработчиком и тогда можно будет отправлять pull-request. Или, можно
создать копию их репозитория (Fork) и вести разработку самостоятельно. Fork репозитория,
это копирование чужого репозитория в свой. Соответственно, над ним можно будет
полноправно вести разработку так, как хочется и добавлять туда любые изменения.