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

1.

GIT
Для чайников и менеджеров

2.

ЧТО ЭТО ТАКОЕ?
Git - это система контроля версий. Система контроля версий — система, записывающая изменения и
позволяющая вернуться позже к определённой версии. Гит содержит все версии файлов(проекта), т.е.
содержит версии каждого из разработчиков. С помощью данной системы – можно наблюдать, над какими
задачами работает тот или иной разработчик, применять ту или иную версию, в качестве актуальной,
отменять/принимать изменения того или иного разработчика.
Репозиторий Git — (ваш проект в системе) каталог файловой системы, в котором находятся: файлы
конфигурации, файлы журналов операций, выполняемых над репозиторием, индекс расположения файлов
и хранилище, содержащее сами контролируемые файлы.
Локальный репозиторий(“у меня а локале изменения все”) — репозиторий, расположенный на локальном
компьютере разработчика. Именно в нём происходит разработка и фиксация изменений, которые
отправляются на удалённый репозиторий.
Удалённый репозиторий(куда все всё сливают) — репозиторий, находящийся на удалённом сервере. Это
общий репозиторий, в который приходят все изменения и из которого забираются все обновления.

3.

Словарь как понять, что там говорят эти разработчики
Ветка (Branch) — это параллельная версия репозитория. Она включена в этот репозиторий, но не влияет
на главную версию, тем самым позволяя свободно работать в параллельной. Когда вы внесли нужные
изменения, то вы можете объединить их с главной версией. Ветки могут быть локальными(копия удалённой,
но на компьютере разработчика) и удалёнными(ветка доступная всем, кому доступен репозиторий).
Пулреквест (Pull Request) — запрос на слияние Ветки разработчика с основным репозиторием. Пулреквест
может быть принят или отклонён вами, как владельцем репозитория.
Коммит (Commit) — фиксация изменений или запись изменений в ветку. Коммит происходит на локальном
копьютере.
Пул (Pull) — получение последних изменений с удалённого сервера репозитория.
Пуш (Push) — отправка всех неотправленных коммитов на удалённый сервер репозитория (с локальной ветки
на удалённую. Пока разработчик не сделает пуш – все изменения (коммиты) будут у него на компьютере и не
будут видны остальным разработчикам)
Мердж (Merge) — слияние изменений из какой-либо ветки репозитория с любой веткой этого же репозитория.
Чаще всего слияние изменений из ветки репозитория с основной веткой репозитория.(Например, приняли
пуллреквест, и его надо смержить в основную ветку, чтобы изменения применились в основной версии)
Кодревью — процесс проверки кода на соответствие определённым требованиям, задачам и внешнему виду.

4.

ПРИМЕР ПУЛЛРЕКВЕСТА(МОЖНО ПРОПУСТИТЬ, ЕСЛИ
НЕ СОБИРАЕШЬ СМОТРЕТЬ ПР-Ы)
Автор ПР-а может
и сам всё смержить,
даже если никто
не аппрувнул его ПР

5.

КОНФЛИКТЫ
Иногда процесс(пул, пуш, мерж) не проходит
гладко. Если Разработчики изменили одну и ту же
часть одного и того же файла по-разному в двух
объединяемых ветках(например, удалённую
ветку (b-v3) разработчик пытается спулить в
локальную ветке разработчика - и в удалённой
ветке, и в локальной были изменения в одних и
тех же файлах), Git не сможет их чисто
объединить – возникает Конфликт.
При решении конфликтов Разработчик может
стереть нужные данные. Решать конфликты очень
удобно прямо в IDE. Процесс решения
конфликтов заключается в сравнении и выборе
актуальных данных в Каждом конфликтном
файле. Если разработчики одновременно
работают над одними и теми же файлами у них
100% возникнут конфликты, их решение займёт
много времени и не факт, что завершится
успешно. Для этого старайтесь избегать
конфликтов.
Рис1. Можно просто принять все локальные
изменения или все, что пришли, а можно
пофайлово и построчно решить все
конфликты(рис2)

6.

ВОЗМОЖНОСТИ, О КОТОРЫХ НАДО ЗНАТЬ
1) Всегда можно вернуться ДО. Риски: есть локальные ветки – и на них отката не будет, кто-то может случайно залить
откатанные изменения, откатиться ВСЁ до определённого коммита
2) Можно убрать коммит из текущей версии. Риски: если нежелательный коммит успел появится на других ветках – он
никуда не уйдёт, его надо убирать на каждой рабочей ветке
3) Можно коммит из одной версии(ветки) скопировать в другую версию(ветку). ЭТОТ вариант лучше, чем
перенос файлов, вручную! Например, если сделали очень важный коммит в тестовой версии, а он срочно нужен
на проде – необязательно обновляться полностью – можно перенести только конкретные коммиты. Риски: если
часто обновлять версию подобным образом, есть риск нарушения целостности данных в файлах – могут возникнуть большие
проблемы. Поэтому лучше всегда выкатывать обновления полностью.
4) Игнорирование файлов. Иногда необходимо некоторые файлы не заливать в удалённый репозиторий
(локальные конфигурационные файлы, например). Для этого необходимо добавить их в .gitignore

7.

ХОРОШИЕ ПРАКТИКИ
1) README – каждый контейнер и весь проект должен иметь файл с краткой информацией, информацией о структуре,
применяемые подходы и паттерны, наиболее удобный способ влиться в проект, ссылки на полезные источники
информации.
2) 1 ветка = 1 задача. Есть основные ветки, для удобного управления(а так же в случае отката, например) и
отслеживаия прогресса разработки следует внедрить в команду это правило
3) Несколько ветвей можно тестировать по отдельности, поэтому воспользуйтесь преимуществом. (Чтобы не откатывать
функционал с багами – проще его проверить до выката в основную ветвь)
4) Jira и git могут работать вместе – под задачу создаётся одноимённая ветка. В соответствии с типом таски у веток есть
префиксы(типы) – исправление бага(bugfix), новая фича(feature), быстрый фикс(hotfix), релиз, другое
5) Пуллревесты и кодревью – нужные вещи , т.к. предотвращают появление багов в текущем релизе, но и в будудущем – т.к.
подобные практики повышают профессионализм разработчиков.
О разветвлении https://bitworks.software/2019-03-12-gitflow-workflow.html https://www.atlassian.com/agile/softwaredevelopment/branching
Полезная ссылка https://www.atlassian.com/agile/software-development/git (много полезных разделов внутри)