Разработчикам необходим надёжный способ сохранять разные версии кода, поскольку программное обеспечение постоянно изменяется в процессе разработки, тестирования и отладки. Git сохраняет историю этих изменений локально и позволяет разработчикам возвращаться к предыдущим версиям, а GitHub предоставляет онлайн-платформу для хранения Git-репозиториев, публикации проектов и совместной работы с другими людьми. Понимание того, как эти два инструмента работают вместе, помогает начинающим защищать свой код и разрабатывать программное обеспечение с использованием тех же базовых рабочих процессов, которыми пользуются профессиональные команды.
Что такое Git и зачем разработчики его используют
Git — это распределённая система контроля версий, которая отслеживает изменения файлов и позволяет разработчикам сохранять полную историю программного проекта.
Без системы контроля версий разработчики могли бы создавать папки с названиями project-final, project-final-2 или project-working-copy каждый раз, когда им необходимо сохранить предыдущую версию проекта. Такой подход быстро становится запутанным и затрудняет понимание того, какие именно изменения были внесены.
Git решает эту проблему с помощью структурированной истории. Разработчики могут создавать контрольные точки, называемые коммитами, сравнивать разные версии, восстанавливать предыдущий код и экспериментировать с новой функциональностью, не изменяя окончательно стабильную версию.
Git работает локально, а значит, разработчику не нужен GitHub или постоянное подключение к интернету для создания репозиториев, выполнения коммитов, просмотра истории или создания веток.
Что такое GitHub и чем он отличается от Git
Git — это непосредственно технология контроля версий, тогда как GitHub — онлайн-сервис, созданный для работы с Git-репозиториями и совместной разработки программного обеспечения.
Git-репозиторий может полностью находиться на компьютере разработчика. GitHub предоставляет удалённое место, где этот репозиторий также можно хранить и получать к нему доступ через интернет.
Это позволяет синхронизировать код между компьютерами, публиковать open-source проекты, совместно работать с другими разработчиками, проверять предлагаемые изменения, сообщать о проблемах и автоматизировать процессы разработки.
Начинающим важно понимать это различие. Установка Git не создаёт автоматически аккаунт GitHub, а для использования Git наличие GitHub не требуется. GitHub — лишь одна из нескольких платформ, позволяющих размещать Git-репозитории в интернете.
Основные понятия Git, которые должен понимать каждый начинающий
Git становится гораздо проще для понимания, когда вы знаете, как связаны между собой репозитории, коммиты, ветки, локальные изменения и удалённые репозитории.
- Репозиторий. Репозиторий — это проект, отслеживаемый Git, включая его файлы и историю изменений, сохранённых с течением времени.
- Рабочая директория. Это текущая версия файлов проекта, которые разработчик в данный момент редактирует.
- Область подготовки. Git позволяет разработчикам выбирать, какие изменения должны быть включены в следующий коммит до его создания.
- Коммит. Коммит — это сохранённая контрольная точка, содержащая выбранные изменения вместе с такой информацией, как автор, дата и сообщение коммита.
- Ветка. Ветка создаёт отдельную линию разработки, позволяя создавать и тестировать изменения без немедленного изменения другой ветки.
Ещё одно полезное понятие — удалённый репозиторий. Локальный репозиторий находится на вашем компьютере, а удалённый репозиторий представляет собой другую копию, хранящуюся в другом месте, например на GitHub.
Как создать свой первый Git-репозиторий
Создание Git-репозитория превращает обычную папку проекта в директорию, изменения которой можно отслеживать с помощью системы контроля версий.
- Установите Git. Скачайте и установите Git для своей операционной системы, а затем убедитесь, что он доступен через терминал.
- Настройте свои данные. Укажите имя пользователя и адрес электронной почты, которые Git должен связывать с вашими коммитами.
- Откройте директорию проекта. Через терминал перейдите в папку, содержащую файлы, изменения которых вы хотите отслеживать с помощью Git.
- Инициализируйте репозиторий. Выполните команду
git initвнутри папки проекта, чтобы создать Git-репозиторий. - Создайте первый коммит. Добавьте необходимые файлы в область подготовки и создайте коммит, чтобы сохранить первую зафиксированную версию проекта.
После инициализации Git создаёт внутренние метаданные, содержащие историю и конфигурацию репозитория. Обычно эти внутренние файлы не требуется изменять вручную.
Перед добавлением всех файлов в коммит при необходимости создайте файл .gitignore. Он указывает Git, какие файлы и директории не следует отслеживать, например временные файлы, папки зависимостей, сгенерированные файлы, локальные конфигурации и конфиденциальные файлы окружения.
Как коммиты сохраняют и организуют изменения в коде
Коммит сохраняет определённый набор изменений проекта и создаёт точку в истории, которую разработчики впоследствии могут просматривать, сравнивать или восстанавливать.
Предположим, вы создаёте форму входа. После завершения и тестирования этой функции можно добавить соответствующие файлы в область подготовки и создать коммит с сообщением, например «Add login form validation».
Позже вы можете изменить навигационное меню и создать ещё один коммит. Теперь Git хранит отдельные записи для обоих изменений вместо того, чтобы воспринимать весь проект как постоянно перезаписываемый набор файлов.
Хорошие сообщения коммитов упрощают понимание истории проекта. Такие сообщения, как «fix» или «changes», дают мало информации, тогда как краткое описание того, что именно было изменено, облегчает отладку и совместную работу.
Коммиты также должны быть достаточно сфокусированными. Объединение десятков несвязанных изменений в один коммит может затруднить просмотр истории проекта и усложнить отмену конкретного изменения.
Как загрузить локальный репозиторий на GitHub
Локальный Git-репозиторий можно подключить к репозиторию GitHub, чтобы передавать коммиты между компьютером разработчика и удалённым онлайн-репозиторием.
- Создайте репозиторий на GitHub. Войдите в GitHub, создайте новый репозиторий и выберите подходящее название проекта и настройки видимости.
- Подключите удалённый репозиторий. Добавьте адрес репозитория GitHub в локальный проект с помощью команды
git remote add origin. - Подготовьте основную ветку. Убедитесь, что ветка, которую вы хотите опубликовать, имеет нужное название, обычно
main. - Отправьте репозиторий. Используйте
git push, чтобы отправить локальные коммиты на GitHub и установить связь между локальной и удалённой ветками.
После первого push репозиторий становится доступен через GitHub в соответствии с выбранными настройками видимости. В дальнейшем новые коммиты можно отправлять для обновления удалённой версии.
Разработчики также могут клонировать существующий репозиторий. Клонирование загружает проект вместе с его историей Git и автоматически настраивает исходный удалённый репозиторий.
Как ветки помогают разработчикам работать, не ломая основной код
Ветки позволяют изолировать новые функции, эксперименты и исправления от стабильной версии проекта до тех пор, пока изменения не будут готовы к интеграции.
Представьте, что ветка main содержит работающий сайт. Вы хотите переработать страницу оформления заказа, но изменения могут потребовать нескольких дней разработки и временно нарушить работу важных функций.
Вместо прямого изменения main можно создать отдельную ветку. Изменения и коммиты, сделанные в ней, останутся изолированными от основной ветки.
Когда новая функциональность будет завершена и протестирована, ветку можно объединить с основной кодовой базой. На GitHub команды обычно используют pull requests для проверки этих изменений перед объединением.
Ветки также позволяют нескольким разработчикам одновременно работать над разными функциями. Один разработчик может улучшать поиск, пока другой исправляет аутентификацию, не перезаписывая постоянно изменения друг друга.
Основные команды Git, которые начинающим стоит изучить в первую очередь
Относительно небольшого набора команд Git достаточно для выполнения большинства базовых задач контроля версий на начальном этапе изучения системы.
git status— отображает текущее состояние рабочей директории и показывает изменённые, подготовленные и неотслеживаемые файлы.git add— добавляет выбранные изменения в область подготовки, чтобы их можно было включить в следующий коммит.git commit— создаёт новую сохранённую версию на основе изменений, находящихся в области подготовки.git pull— получает изменения из удалённого репозитория и интегрирует их в текущую локальную ветку.git push— отправляет локальные коммиты в соответствующий удалённый репозиторий.
К другим полезным командам относятся git log для просмотра истории коммитов, git diff для просмотра изменений, git branch для работы с ветками и git switch для переключения между ветками.
Вместо того чтобы сразу запоминать десятки команд, начинающим важнее понять, что происходит с файлами в процессе их редактирования, добавления в область подготовки, создания коммитов, получения удалённых изменений и их отправки.
Распространённые ошибки начинающих при работе с Git и GitHub
Большинство проблем начинающих с Git возникает из-за неправильного понимания рабочего процесса или добавления в репозиторий файлов, которые никогда не должны были туда попасть.
Одна из особенно важных ошибок — случайная публикация секретных данных. Пароли, приватные ключи, данные для доступа к базам данных, API-токены и конфиденциальные файлы .env не следует добавлять в репозиторий. Простое удаление секрета в последующем коммите может не удалить его из предыдущей истории репозитория, поэтому раскрытые учётные данные обычно необходимо заменить.
Ещё одна распространённая проблема — использование git add . без предварительной проверки того, какие файлы будут добавлены в область подготовки. Выполнение git status перед созданием коммита помогает предотвратить попадание временных или несвязанных файлов в репозиторий.
Начинающие также могут забывать получать удалённые изменения перед началом работы, что способно привести к ненужным конфликтам, если несколько человек изменяют одни и те же файлы.
Сами по себе конфликты слияния необязательно являются ошибками. Они возникают, когда Git не может автоматически определить, каким образом следует объединить конкурирующие изменения. Разработчикам необходимо самостоятельно проверить конфликтующие участки и решить, какая версия должна остаться.
Наконец, Git не следует воспринимать исключительно как систему аварийного резервного копирования. Его настоящая ценность заключается в создании небольших и понятных коммитов на протяжении всего процесса разработки. Последовательный рабочий процесс, включающий редактирование, проверку, подготовку изменений, создание коммитов, работу с ветками, получение и отправку изменений, делает Git и GitHub надёжной основой для защиты кода и совместной работы над программными проектами.