Как пользоваться Git и GitHub: работа с репозиторием

Git и GitHub часто путают. Главное различие: Git управляет версиями локально, GitHub помогает хранить код в облаке и работать в команде.

Git: машина времени для ваших файлов

Если коротко, то Git — это система контроля версий, которая хранит снимки (слепки) состояния всех файлов проекта в каждый момент фиксации (коммита). При этом если файл не менялся, Git не дублирует его, а ссылается на предыдущий идентичный снимок. Такой подход позволяет эффективно отслеживать всю историю и мгновенно переключаться между версиями.

Ключевая идея Git — снапшоты (снимки) состояния проекта. При каждом коммите Git сохраняет снимки всех файлов. Если файл не менялся, он не дублируется — вместо этого создается ссылка на его предыдущую версию.

По тому же принципу организована работа с кодом. Разработчики создают отдельные ветки для новых функций или исправлений, а затем сливают утвержденные изменения в основную ветку (main или master). Это позволяет экспериментировать без риска сломать стабильную версию: в любой момент можно откатиться назад или вернуться к рабочему состоянию.

GitHub: социальная сеть и облако для вашего кода

GitHub — веб-служба для хранения Git-репозиториев и совместной работы над проектами. Это не замена Git, а сервис «вокруг» него. Основные функции:

• Создание нескольких версий проекта для разработки новых функций или исправлений.

• Отслеживание изменений в проекте.

• Слияние изменений в основную ветку, командное обсуждение проекта.

• Планирование и управление задачами в рабочих досках.

• Публикация рабочих версий проекта с тегами и архивами.

• Активные обсуждение изменений в проекте и поиск ошибок.

• Создание копий чужих репозиториев для самостоятельной работы и внесения изменений. 

GitHub — не хранилище кода, как думают многие. Это полноценная и удобная платформа для командной работы. Она полезна и для личных проектов, поскольку функции решения позволяют структурировать историю изменений и поддерживать порядок в репозиториях. 

Простая аналогия: Git — движок и коробка передач, GitHub — гоночный трек и сервисная команда 

Git и GitHub решают разные задачи, но взаимосвязаны и работают вместе. Объясним это на примере. Представьте, что Git — «внутренности» автомобиля, то есть двигатель и коробка передач. Управляете ими вы и при этом ни от кого не зависите. 

Теперь представьте, что вы хотите участвовать в гонках. В этом случае вам нужен не просто автомобиль, а целая инфраструктура: трек, где проходят заезды, судьи, фиксирующие результаты, и команда механиков. Это и есть GitHub — пространство с общими правилами, где ваш код видят другие участники, а совместная работа становится возможной.

Подведем итоги. Вы можете просто ездить на своем автомобиле без гонок и судей, то есть пользоваться Git без GitHub и команды. Но гонки без автомобилей и нескольких участников не состоятся, поэтому работать в GitHub без Git невозможно. 

На практике многие пользуются и Git, и GitHub. Git отвечает за контроль версий, GitHub — за комфортную и качественную совместную работу. Если у вас есть команда, без GitHub не обойтись. 

Для начала работы с репозиториями нужно выполнить первичные настройки и определиться со способом аутентификации. 

Регистрация на GitHub и первичная настройка профиля

Чтобы зарегистрироваться на GitHub, зайдите на официальный сайт и создайте аккаунт. Укажите username — имя пользователя. Чтобы коллеги понимали, кто вносил изменения в ветке, используйте свои имя или фамилию, либо их комбинацию. Неформальных слов лучше избегать — в профессиональной среде это не всегда уместно. Учтите, что Username отображается в URL репозиториев и виден работодателям и коллегам.

После ввода username укажите email и пароль от аккаунта. Используйте сложный, с цифрами, буквами и специальными знаками. Оптимальная длина — от 12 символов. 

Указанную электронную почту нужно будет верифицировать. Зайдите в свой email, найдите ссылку и перейдите по ней. 

Установка и конфигурация Git

Чтобы установить Git на Windows, скачайте с официального сайта установщик и действуйте по инструкции мастера:

• На macOS загрузка выполняется через Xcode Command Line Tools — xcode-select --install. 

• На Linux — через пакетный менеджер дистрибутива: apt, dnf, pacman и др.  

Для проверки установки выполните команду:

После установки выполните первичную настройку — укажите имя и email. Git использует их для подписи каждого коммита. Для настройки выполните:

Расшифруем: 

• user.name — имя автора коммитов;

• user.email — подтвержденный email в GitHub;

•  --global — применение настроек для всех репозиториев на устройстве. 

Настройки можно проверить командой:

Подключение к GitHub: SSH vs HTTPS

Возможны два способа аутентификации — SSH с помощью ключа и HTTPS. Рекомендуется первый вариант, поскольку он обеспечивает более высокий уровень безопасности. К тому же, не нужно каждый раз вводить логин и пароль. 

Сначала нужно создать SSH-ключ:

Тут используется алгоритм шифрования ed25519, рекомендованный GitHub. Комментарий после -C — подтвержденный адрес электронной почты. 

Созданный ключ нужно добавить в SSH-агент:

На Linux и macOS ключи по умолчанию сохраняются в ~/.ssh/. На Windows — обычно в C:\Users\<Имя пользователя>\.ssh\. Учитывайте это при указании пути в следующих командах.

Затем публичный ключ нужно добавить в GitHub. Скопируйте содержимое файла cat ~/.ssh/id_ed25519.pub и в настройках GitHub двигайтесь по пути Settings → SSH and GPG keys → New SSH key. Вставьте и сохраните ключ. 

Проверьте подключение:

Подключение по HTTPS можно использовать при временной работе в GitHub, например, если проект краткосрочный. Для аутентификации нужен токен Personal Access Token (PAT), который создается в разделе настроек в аккаунте. Его следует вводить вместо пароля. 

Новичкам нужно освоить базовые рабочие процессы — от создания репозитория до отправки изменений в GitHub. Рассказываем ключевые моменты. 

Создание репозитория: три сценария

Можно создать репозиторий и разными способами в зависимости от особенностей проекта и написанного кода. Сценарии: 

Чтобы сразу выбрать правильный вариант, оценить свои условия работы. для командных проектов лучше облачный старт, для личных — локальный. Для open source — «форк и клон». 

Жизненный цикл файла в Git: Untracked -> Staged -> Committed

Чтобы эффективно работать в команде и правильно фиксировать изменения, нужно знать жизненный цикл файла в Git. Выделяют четыре основных состояния:

• Untracked — файл существует в рабочей директории, но Git его ещё не отслеживает.

• Unmodified — файл отслеживается и не изменялся с момента последнего коммита.

• Modified — файл отслеживается, но в него внесены изменения, которые ещё не подготовлены к коммиту.

• Staged — изменения в файле добавлены в индекс (staging area) и будут включены в следующий коммит.

После выполнения коммита файл снова переходит в состояние Unmodified (если он не был изменен во время подготовки). Цикл повторяется при новых правках.

Основные команды, соответствующие этим состояниям:

Первый коммит: best practices

Первый коммит — основа репозитория. На этом этапе вы фиксируете код и готовите проект к дальнейшему развитию. Коммит должен быть грамотным и понятным как для вас, так и для других. 

Уделите внимание сообщению коммита — оно должно полностью отражать суть изменений. Избегайте общих формулировок вроде init или update. Замените их на понятные, например, add initial project structure. Можно взять за основу стандарт Conventional Commits, где тип изменения обозначается в начале сообщения.

Не забывайте о важности файла .gitignore. Он задает исключения — изменения, которые не будет отслеживать Git. Например, в репозиторий не должны попадать логи, кеши, учетные данные. Если не знаете, как задавать исключения, используйте готовые шаблоны для нужного языка программирования. Их можно найти в официальном репозитории gitignore от GitHub.  

Второй важный файл — README.md. Это краткое описание проекта — зачем он нужен, что делает, как его запустить. Такой файл позволит другим членам команды быстрее разобраться и начать работать над кодом. 

Работа с ветками в Git — основное направление, которое нужно освоить. Рассказываем, какие бывают ветки и для чего они нужны, как сливать изменения.

Что такое ветка (branch) и зачем она нужна

Ветка в Git — это независимая линия разработки, позволяющая экспериментировать с кодом. Фактически она служит указателем на определенный коммит в истории изменений проекта. 

Ветке нужны, чтобы параллельно разрабатывать новые функции, исправлять ошибки не боясь что-то нарушить в коде. В одном репозитории может быть несколько веток, но среди них есть одна главная — main (ранее — master). Туда сливаются все утвержденные изменения, поэтому она представляет собой рабочую версию проекта. 

Для объяснения принципов использования веток разработчики часто используют аналогию «параллельных вселенных». Каждый специалист работает в своей «вселенной», не затрагивая другие. Чтобы они соприкоснулись, их нужно явно объединить. 

Работа с ветками: создание, переключение, слияние

Для работы с ветками в Git есть специальные команды. Для наглядности они оформлены в таблицу, чтобы вы могли ее использовать как шпаргалку:

Для небольших команд и новичков подходит стратегия GitHub Flow. Она подразумевает, что в репозитории есть главная ветка main или master с рабочим кодом. От нее под конкретные задачи создаются feature-ветки, где выполняются любые изменения, которые затем сливаются в основную ветку. После согласования и слияния изменений feature-ветки удаляются. 

Решение конфликтов слияния

Конфликты слияния — ситуации, когда система не может объединить изменения из разных веток, поскольку они касаются одних и тех же строк в файле. Либо один специалист внес изменения в файл, а другой — удалил этот файл. Git в таких случаях останавливает слияние и подсвечивает конфликтные моменты. Специалистам нужно вручную выбрать, какие изменения оставить. 

Пример конфликта:

Что делать в этом случае:

1. Откройте в редакторе конфликтный файл.

2. Удалите маркеры конфликта — <<<<<<<, =======, >>>>>>>.

3. Удалите все лишнее, оставив только нужную версию кода. 

4. Сохраните файл.  

Исправленный файл нужно вручную добавить в индекс с помощью:

Завершите процесс слияния:

Есть стандартные механизмы работы с кодом, которые применяются как в корпоративной разработке, так и в open source-проектах. Все изменения изолируются в отдельных ветках, обсуждаются через Pull Request и сливаются в основную ветку только после утверждения. Рассказываем, как происходят процессы. 

Модель взаимодействия в Open Source и корпоративных проектах

В open source проектах у разработчиков обычно нет прямого доступа к главному репозиторию. Они работают через Fork — вносят изменения в свои копии проекта и предлагают утвердить через Pull Request.

В корпоративных проектах удобнее использовать единый репозиторий и разграничивать права для пользователей. Разработчики создают свои feature-ветки внутри этого репозитория и работают в них. Утверждение изменений перед слиянием в главную ветку также происходит через Pull Request.  

Полный цикл внесения изменений в чужой репозиторий

Чтобы не нарушить работу в чужом репозитории нужно действовать по выверенному сценарию и безопасно предлагать изменения. Из каких этапов состоит цикл:

1. GitHub создается Fork — копия проекта. При этом в оригинальном репозитории ничего не меняется. 

2. Далее создается Clone — копия репозитория, которая сохраняется на локальном компьютере. Она позволяет работать с редакторами кода, создавать новые файлы и редактировать существующие, запускать тестирования. 

3. Для внесения изменений нужен этап Branch & Commit. От основной ветки проекта создается feature-ветка, которая позволяет изолировать изменения. После внесения всех правок разработчик делает коммиты с понятными и подробными сообщениями, поясняющими работу.

4. Далее следует этап Push — отправка feature-ветки из локального репозитория в форк на GitHub. На этом этапе код уже доступен через web-интерфейс и готов к слиянию в основной проект. 

Ключевой шаг в совместной работе — Pull Request. Это запрос на интеграцию локальных изменений из форка в главный репозиторий. Его нужно корректно оформить: присвоить информативное название, описать все изменения и их цели и дать ссылку на задачу. 

После создания Pull Request проводится Code Review. Участники проекта просматривают изменения и обсуждают их реализацию, ищут ошибки и пути улучшения кода. Автор запроса вносит правки. Если других участников команды все устраивает, Pull Request получает одобрение — approval. 

Финальный этап совместной — Merge или Squash and Merge. При Merge коммиты Попадают в главную ветку в том виде, в каком они есть. При Squash and Merge — сливаются в один коммит для чистоты истории. После слияния изменения будут частью основного проекта. 

Команда git pull по умолчанию — это сочетание git fetch и git merge. Сначала git fetch загружает новые данные из удаленного репозитория (коммиты, ветки), не изменяя вашу локальную ветку. Затем git merge сливает эти изменения в текущую ветку. В результате вы получаете актуальное состояние проекта, объединённое с вашей работой.

Однако такое слияние может создавать лишние коммиты слияния (merge-commits). Чтобы история оставалась линейной, используют git pull --rebase, где вместо слияния применяется перебазирование ваших локальных коммитов поверх свежих изменений. Подробнее об этом — ниже.

Обычный git pull подходит не всегда. Например, вы сделали локальные коммиты, а коллеги уже поменяли эту ветку на сервере. Команда git pull создаст merge-коммит, который попадет в историю, из-за чего она станет запутанной. Как это может выглядеть: 

Чтобы поддерживать чистую линейную историю, используйте команду git pull --rebase. Сначала выполнится git fetch, затем локальные коммиты временно закрываются и применяются свежие из удаленной ветки. Ваши коммиты будут накладываться поверх новой истории без merge-коммитов. Пример:

Чтобы git pull всегда выполнял rebase, выполните следующую настройку:

Освоив базовые инструменты и команды, двигайтесь дальше в сторону продвинутых методик. Рассказываем, что стоит изучить для эффективного использования репозиториев. 

GUI-клиенты (GitHub Desktop, GitKraken) vs. терминал

С репозиториями можно работать через визуальные программы — GUI-клиенты. Например, GitHub Desktop, GitKraken, Sourcetree. Они обеспечивают визуализацию всех веток и истории коммитов, упрощают работу с merge и rebase. Однако не дают понимания, что происходит «за кулисами», то есть у других участников команды. 

Второй вариант — работа через командную строку. Терминал дает возможности использовать все команды Git, полностью контролировать процесс создания кода, исправлять конфликты слияния, автоматизировать некоторые скрипты. Однако наглядного представления веток не будет.

Полезные команды для расследования: git log, git diff, git stash

Чтобы более детально погрузиться в происходящее с ветками и проектом, можно использовать специальные команды для расследования. 

Команда git log позволяет вывести полную историю коммитов. Пример применения: 

Расшифровываем:

• --oneline — каждый коммит выводится в одной строке;

• --graph — визуализируются все ветки и слияния; 

• --all — демонстрация всех веток; 

• git diff — вывод изменений между состояниями репозитория.

Команда git diff показывает изменения между изменением состояния репозитория. Пример применения:

Команда git stash позволяет временно сохранять незакоммиченные изменения, чтобы без проблем переключаться между ветками. Пример использования:

Рекомендации для углубления знаний

Какие методы и инструменты освоить, чтобы выстроить эффективную командную работу над проектами:

Заключение

Git и GitHub — это не просто инструменты, а фундамент современной разработки. Освоить их можно только на практике: начните с небольшого личного проекта, делайте осмысленные коммиты, пробуйте работать с ветками и открывать Pull Request. Не заучивайте команды — разберитесь с логикой workflow. Это база, с которой начинается путь любого разработчика.