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

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

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

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

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

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