Тема: технология Git: локальная и удалённая работа.
Исполнитель - Окунев Иван Александрович, группа 441-об
Научный руководитель - Русинов Владислав Леонидович,.
Актуальность: современная разработка программного обеспечения невозможна без эффективных инструментов командной работы. Git является стандартом индустрии, позволяя синхронизировать код между разработчиками (глобально) и вести гибкую историю изменений на локальной машине.
Цель:изучить архитектуру системы Git, проанализировать принципы работы с локальным репозиторием и удалёнными серверами.
Задачи:
1) Основные понятия Git: репозиторий, коммиты, ветвление. Сценарии использования в одиночной разработке.
2) Удалённые репозитории GitHub, GitLab и протоколы взаимодействия SSH/HTTPS. Работа в команде.
3) Обзор типового рабочего процесса Git Flow и решение конфликтов при слиянии веток.
Зачем всё это нужно?
История изменений - можно вернуться к любой версии проекта, понять, кто и когда внёс изменения.
Параллельная разработка - ветки позволяют разрабатывать новые функции, не мешая основной кодовой базе.
Совместная работа - несколько разработчиков могут одновременно вносить изменения, а Git помогает объединять их с минимальными конфликтами.
Безопасность - хеширование всех объектов гарантирует целостность данных: любое непреднамеренное или злонамеренное изменение будет обнаружено.
Git невероятно гибок, но в начале пути может казаться сложным.
Зачем нужен Git одиночному разработчику?
Git в одиночной разработке решает критически важные задачи :
1. Страховка от потери данных: Это как машина времени для кода. Случайно удалили нужный файл или захотели вернуться к состоянию проекта месячной давности? Git позволяет сделать это в одну команду.
2. Эксперименты без страха: Хотите попробовать новую библиотеку или кардинально переписать логику? С Git вы можете создавать отдельные ветки для экспериментов, не рискуя сломать то, что уже работает.
3. Контекст и понимание истории: Через полгода вы забудете, почему написали тот или иной кусок кода. Коммиты с понятными описаниями служат подробным дневником ваших мыслей и действий.
1. Основы Git: Репозиторий, Коммит, Ветка
Репозиторий
Что это: Это просто скрытая папка .git внутри вашего проекта. Git превращает обычную папку с файлами в репозиторий командой git init . В этой папке хранится все: вся история изменений, все ветки и слепки ваших файлов.
Можно представить как: Сейф, в котором лежат все чертежи вашего проекта, включая все когда-либо существовавшие версии.
Коммит
Что это: Коммит - это операция сохранить, но с принципиально иным подходом. В отличие от обычного сохранения файла коммит создает снимок всего проекта целиком на данный момент времени . Это не список изменений , а полная фотография всех файлов.
Внутреннее устройство: Каждый коммит - это объект, который содержит :
Уникальный идентификатор (хеш) - длинную строку из цифр и букв (например, e83c5163).
Ссылку на снимок файловой структуры проекта .
Метаданные: имя автора, email, дата и время.
Сообщение - краткое описание того, что было сделано
Ветвление
Что это: Ветка - это просто легковесный указатель (сслыка) на конкретный коммит . Когда вы делаете новый коммит в ветке, этот указатель автоматически перемещается на новый коммит.
Ключевая идея: Создание ветки в Git - это не копирование файлов в другую папку. Это создание нового ярлыка, что происходит мгновенно .
Можно представить как: Наклейку на коммите с надписью "main" или "новая-функция". Вы просто переклеиваете наклейку на новые коммиты по мере работы.
Удалённый репозиторий - это тот же самый проект, со всей историей изменений, но который лежит не у вас на компьютере, а в интернете, на серверах GitHub. У вас есть локальная версия (черновик), а есть удалённая (надёжное хранилище). Плюсы : резервная копия, синхронизация, совместная работа. Есть три основные команды, которые используются удалённым репозиторием постоянно. Это когда вы впервые приходите в проект. Вы не скачиваете просто папку - вы создаёте у себя на компьютере точную копию всего: всех файлов, всей истории коммитов, всех веток. Git ещё и запоминает, откуда вы это скопировали. Одной командой вы получаете полностью рабочий проект. Команда push для обновления своего проекта на GitHube. Команда git pull делает два дела сразу: забирает новое и склеивает с вашей текущей версией.
GitLab - это очень похожая платформа. Там тоже можно хранить удалённые репозитории, работать с коллегами.Зачем вообще эти протоколы?
Когда ты выполняешь git push или git pull, твой компьютер должен не просто отправить файлы, но и доказать серверу: «Да, я тот самый разработчик, у которого есть доступ к этому репозиторию». Для этого и нужны протоколы -- они отвечают за безопасную передачу данных и аутентификацию.
HTTPS Как работает:
Ты просто вводишь логин и пароль (или специальный токен) каждый раз, когда общаешься с удалённым репозиторием. Git хранит эти учётные данные недолго, и если ты работаешь с проектом первый раз, он спросит их.
SSHКак работает:
Ты генерируешь на своём компьютере два ключа: приватный (секретный, хранится только у тебя) и публичный (его можно показывать). Публичный ключ ты добавляешь в свой аккаунт на GitLab. Когда происходит соединение, GitLab проверяет, что у тебя есть соответствующий приватный ключ -- если да, доступ разрешён. Никаких паролей вводить не нужно. Примеры Clone with HTTPS -- даёт адрес вида https://...
Clone with SSH -- даёт адрес вида git@...
Как выглядит типовой рабочий день в Git Flow
Утром разработчик говорит: «Мне нужно сделать новую кнопку на сайте». Он заходит в рабочую папку (develop), убеждается, что у него самая свежая версия, и создаёт свою личную ветку с понятным названием - например, «кнопка-входа». В этой ветке он спокойно пишет код, ничего не мешая другим.
Когда кнопка готова, он приходит к команде: «Всё работает, можно забирать». Разработчик переключается обратно в рабочую папку, подтягивает все изменения, которые могли появиться, пока он работал, и аккуратно вкладывает свою кнопку в общую рабочую папку. Ветка с кнопкой больше не нужна - её удаляют.
Потом наступает момент, когда в рабочей папке накопилось много изменений, и пора выпускать новую версию сайта. Создаётся ветка релиза. В ней только правят мелкие баги, тестируют, а когда всё готово, эту ветку отправляют в main и ставят на ней версию, например, 2.0. И не забывают те же правки вернуть обратно в рабочую папку.
Конфликты возникают при работе двух человек над одной задачей и над одной функцией, когда мы пытаемся слить две ветки, а они изменили одни и те же строки кода по‑разному. Например, вы в своей ветке добавили новую функцию, а коллега в другой ветке переименовал ту же переменную. Git не знает, что важнее - ваша функция или его переименование. И останавливает слияние.Git Flow - это набор правил, который помогает организовать работу с ветками. У нас есть две вечные ветки: main и develop (то, что готовится к следующему релизу). Для новых функций создаются feature-ветки, для подготовки релизов -- release-ветки, для экстренных правок - hotfix-ветки.
Когда мы сливаем ветки, могут возникать конфликты - это нормально. Конфликт не означает, что кто-то сделал ошибку. Это просто ситуация, в которой нужно принять решение. Git даёт нам инструменты, чтобы увидеть разницу, а люди в команде помогают выбрать правильный вариант.
Три рассмотренные темы - это фундамент работы с Git в команде.
Понятия репозитория, коммитов и ветвления дают базовое понимание, как Git хранит и организует код.
Удалённые репозитории и протоколы SSH/HTTPS обеспечивают безопасное и удобное взаимодействие всех участников проекта через интернет.
Git Flow и умение решать конфликты превращают хаотичную разработку в предсказуемый процесс, где каждый знает, где и как создавать ветки, а конфликты перестают быть страхом, становясь просто этапом совместной работы.
