Когда только вникаешь в программирование, коммиты, ветки и пулреквесты -- это страшный лес. Интерфейс GitHub с дофигой кнопок не помогает. В этой статье -- вся база, которая нужна для уверенной работы с Git и GitHub, от азов до продвинутых фишек.
Зачем вообще нужен Git
Без системы контроля версий ты очень быстро столкнёшься с классической проблемой: программа работает, но надо сделать серьёзный рефакторинг, который может всё сломать. И чтобы сохранить рабочую версию, начинаешь копировать папку с проектом и называть её "project_final", "project_final2", "project_final2_fix".
Это неудобно, в версиях легко запутаться, и в команде так работать невозможно -- нет никакой синхронизации между разработчиками.
Git решает всё это. Он умеет отслеживать все изменения в проекте, сохранять его в разные версии и гибко с ними работать. Это де-факто базовый инструмент любого разработчика сегодня.
Коммиты: как работает сохранение в Git
Коммит -- это сохранение всего проекта. Как в играх делаешь сейв после сложного босса, так и программисты делают коммит после изменений, чтобы зафиксировать текущую версию. В любой момент к этому сейву можно вернуться.
Место, где хранятся все коммиты и вся история разработки -- репозиторий. Это просто директория ".git", которая создаётся, как только начинаешь работать с Git.
Каждый коммит обязательно сопровождается комментарием: что именно было добавлено. Без этого теряется весь смысл. Исправил баг -- пишешь, что было исправлено. Добавил фичу -- пишешь, что она делает. Провёл рефакторинг -- то же самое. Слеплять всё в один коммит с подписью «незначительные изменения» -- недопустимо.
Ветки: параллельная разработка
Главная цепочка коммитов, в которой ведётся разработка, называется "main". Туда попадает только проверенный код.
Если надо разработать новую фичу -- создают отдельную ветку. В ней разработка идёт независимо от остального проекта. Когда всё готово и проверено, ветку сливают с "main".
Слияние не всегда проходит гладко. Конфликт -- это когда разные изменения затронули одну строку кода, и Git не может решить, какую версию оставить. Он останавливается и просит вручную отредактировать файл. Конфликты -- неизбежная часть работы. Задача -- делать маленькие тематические коммиты, чтобы конфликты было легко решать.
GitHub: хостинг для репозиториев
Изначально у каждого разработчика свой локальный репозиторий. Но для командной работы нужен общий удалённый репозиторий, куда все время от времени загружают свои изменения и скачивают обновления от других. GitHub -- это такой хостинг, плюс к нему куча полезного: Issues, Pull Requests, CI/CD, канбан-доски, хостинг для сайтов, красивое оформление профиля.
Как начать: SSH-ключи и первый репозиторий
После регистрации первым делом стоит добавить SSH-ключи, чтобы GitHub понимал, что ты -- это действительно ты, и пушить код было удобно. Генерируешь ключ командой в терминале, копируешь публичный ключ и добавляешь его в настройки GitHub.
Создавая репозиторий, указываешь имя и выбираешь тип: публичный (виден всем) или приватный (доступен только тем, кому выдал доступ).
Три полезных файла при создании репо:
- "README.md" -- описание проекта: что это, для чего нужно, как установить
- ".gitignore" -- файлы, которые Git будет игнорировать: "node_modules", кэш, секреты
- Лицензия -- MIT (делай что хочешь) или GPL (производные тоже должны быть открытыми)
Что ещё умеет GitHub
- Issues -- раздел для задач, багов и предложений. Тикеты для обсуждения конкретных проблем.
- Pull Requests -- объединение изменений в коде. Здесь смотрят диффы и оставляют ревью.
- Actions -- CI/CD: скрипты, которые запускаются автоматически. Например, тесты после каждого коммита или деплой при пуше в "main".
- Insights -- графики по коммитам, активности контрибьюторов, статистика. Помогает понять, живёт проект или уже заброшен.
- Tags -- закладки в истории проекта. Обычно тегами отмечают релизы: версия 1.0.0, версия 2.3.4. Можно скачать именно эту версию кода, даже если проект развивался дальше.
Философский момент
Открытый код -- это не просто техническая возможность, это культура. Тысячи людей по всему миру комитят в чужие проекты, и именно так развивается большая часть инструментов, которыми мы пользуемся каждый день. У Chromium больше 3500 контрибьюторов -- 3500 человек когда-либо делали туда коммит.
Когда ты начинаешь работать с Git и GitHub, ты присоединяешься к этой инфраструктуре. Это стоит понять не просто как «инструмент для работы», а как способ быть частью чего-то большего.
Итог
Git и GitHub — это то, без чего сегодня не обойтись ни в одном проекте. Хорошая новость: для рядовой разработки достаточно освоить пару процентов от всего Git. Коммиты, ветки, пуш/пулл, базовый флоу с пулреквестами -- и ты уже можешь работать в команде.
Остальное придёт с практикой. Главное — начать делать коммиты осмысленно: маленькие, тематически связанные, с нормальными комментариями.