Система контролю версій (VCS (Version Control System)) – це система, що широко використовується в процесі розробки ПЗ розробниками, яка записує зміни до файлу або перелік файлів у процесі розробки, котра дозволяє повернутися в необхідний момент до певної версії. Насправді можна використовувати контроль версій практично для файлів будь-якого типу.
Дані системи дозволяють:
зберігати різні версії одного й того самого файлу;
у разі потреби відкотитися до більш ранніх версій;
визначати, хто і коли здійснив яку-небудь зміну;
здійснювати процес розробки кількох гілок одночасно.
Централізовані (Central Version Control System)- призначені на вирішення основної проблеми локальної системи контролю версій. Для організації такої системи контролю версій використовується єдиний сервер, який містить усі версії файлів. Клієнти, звертаючись до цього сервера, одержують файли з цього централізованого сховища.
Розподілені DVCS (Distributed Version Control System) – мають на увазі, що клієнт викачає собі весь репозиторій повністю замість викачування конкретних файлів, які цікавлять клієнта. Якщо помре будь-яка копія репозиторію, це не призведе до втрати кодової бази, оскільки вона може бути відновлена з комп'ютера будь-якого розробника. Кожна копія є повним бекапом даних.
Усі копії є рівноправними і можуть синхронізуватися між собою. Подібний підхід є реплікацією виду master-master.
Порівняння систем контролю версій
на DVCS можна все те саме, що і на CVCS;
на DVCS простіше виконувати злиття гілок;
на DVCS вся історія зберігається локально, можна працювати офлайн і робота загалом швидше;
більш гнучка модель обміну змінами;
розробники звикли до CVCS, потрібно переналаштовуватися;
у CVCS нижче "поріг входження" - для роботи з DVCS треба краще розуміти концепції контролю версій;
найчастіше у світі використовується представник CVCS – SVN, а DVCS – Git.
Git – це безкоштовна та відкрита система контролю версій (SCM). Вона створена для відстежування змін коду у ваших проектах. Це надає вам контроль на кожному етапі розвитку вашого додатку.
Файл .gitignore
Git розглядає кожен файл у вашій робочій копії як файл одного з трьох вказаних нижче типів.
Файл, що відстежується – файл, який був попередньо проіндексований або зафіксований у коміті.
Файл, що не відстежується – файл, який не був проіндексований або зафіксований у коміті.
Ігнорований файл – файл, явно позначений для Git як файл, який необхідно ігнорувати. Це, як правило, артефакти складання та файли, що генеруються машиною з вихідних файлів у вашому репозиторії, або файли, які з будь-якої іншої причини не повинні потрапляти до коммітів.
Поширені приклади таких файлів:
кеші залежностей, наприклад, вміст /node_modules або /packages;
скомпільований код, наприклад файли .o, .pyc і .class;
каталоги для вихідних даних збирання, наприклад /bin, /out або /target;
файли, згенеровані під час виконання, наприклад, .log, .lock або .tmp;
приховані системні файли, наприклад, .DS_Store або Thumbs.db;
особисті конфігураційні файли IDE, наприклад .idea/workspace.xml.
Ігноровані файли відстежуються у спеціальному файлі .gitignore, який реєструється в кореневому каталозі репозиторію. У
Git немає спеціальної команди для вказівки файлів, що ігноруються: замість цього необхідно вручну відредагувати файл
.gitignore, щоб вказати в ньому нові файли, які повинні бути проігноровані.
Файли .gitignore містять шаблони, які зіставляються з іменами файлів у репозиторії визначення необхідності ігнорувати ці
файли.
Області GIT
Області GIT, в яких можуть зберігатися файли
Статуси відстежуваних файлів у GIT
Статуси відстежуваних файлів у GIT
Q&A
Дякую всім за заняття!🙌🏻
❗️🎓Тема уроку: 1. Основи Git
Нагадую, що дедлайн здачі домашніх робіт – до наступного уроку.
Якщо виникають складнощі, пишіть, допоможу із задоволенням 😌
Запис лекції тренер опублікує трохи пізніше 🖥
Не забудьте повторити матеріал та підготуватися до наступного уроку📚
Успіху і до зустрічі!🤩