Сведения о GIT

Узнайте о системе управления версиями, Git и о том, как она работает с GitHub.

В этой статье

Сведения об управлении версиями и GIT

Система управления версиями отслеживает историю изменений в процессе совместной работы над проектами. По мере того как разработчики вносят изменения в проект, в любое время можно восстановить любую более раннюю его версию.

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

  • какие изменения были внесены;
  • кто внес изменения;
  • какие изменения были внесены;
  • зачем потребовались изменения.

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

В распределенной системе управления версиями каждый разработчик имеет полную копию проекта и его журнала. В отличие от популярных централизованных систем управления версиями распределенные системы не требуют постоянного подключения к центральному репозиторию. GIT — это самая популярная распределенная система управления версиями. Git широко используется как для open source, так и для коммерческой разработки программного обеспечения, что приносит значительную пользу для отдельных лиц, команд и бизнеса.

  • GIT позволяет разработчикам просматривать всю временную шкалу изменений, решений и хода выполнения любого проекта в одном месте. С момента доступа к истории проекта разработчик получает всю необходимую информацию, чтобы разобраться в проекте и начать вносить свой вклад.

  • Разработчики работают в разных часовых поясах. Благодаря распределенной системе управления версиями, такой как GIT, совместную работу можно вести в любое время, сохраняя целостность исходного кода. С помощью ветвей разработчики могут безопасно предлагать изменения для рабочего кода.

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

Сведения о репозиториях

Репозиторий или проект GIT включает в себя полный набор файлов и папок, связанных с проектом, а также журнал изменений каждого файла. Журнал файла представлен в виде моментальных снимков на определенные моменты времени. Эти снимки называются фиксациями. Фиксации можно упорядочивать по нескольким линиям разработки, называемым ветвями. Так как GIT — распределенная система управления версиями, репозитории являются автономными единицами и любой пользователь, имеющий копию репозитория, может получать доступ ко всей базе кода и ее истории. С помощью командной строки или других удобных интерфейсов возможны также следующие действия с репозиторием GIT: взаимодействие с журналом, клонирование репозитория, создание ветвей, фиксация, слияние, сравнение изменений в разных версиях кода и многое другое.

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

Как работает GitHub

GitHub размещает репозитории Git и предоставляет разработчикам средства для отправки более эффективного кода через функции командной строки, проблемы (потоковые обсуждения), запросы на вытягивание, проверку кода или использование коллекции бесплатных и для покупки приложений в GitHub Marketplace. Благодаря уровням совместной работы, таким как поток GitHub, сообществом 100 миллионов разработчиков и экосистемой с сотнями интеграции, GitHub изменяет способ создания программного обеспечения.

GitHub создает совместную работу непосредственно в процессе разработки. Работа организована по репозиториям, в которых разработчики могут устанавливать требования или давать указания участникам команды. Затем с помощью потока GitHub разработчики просто создают ветвь для работы с обновлениями, фиксируют изменения для их сохранения, открывают запрос на вытягивание для предложения и обсуждения изменений, а также объединяют запросы на вытягивание после того, как каждый пользователь находится на одной странице. Дополнительные сведения см. в разделе GitHub flow.

Сведения о планах и затратах на GitHub см. в разделе GitHub Pricing. Для получения информации о том, как GitHub Enterprise сравнивается с другими вариантами, см. Сравнение GitHub с другими решениями DevOps.

GitHub и командной строки

Основные команды Git

Работая с GIT, разработчики используют определенные команды для копирования, создания, изменения и объединения кода. Эти команды можно выполнять непосредственно из командной строки или с помощью приложения, например GitHub Desktop. Ниже приведены некоторые распространенные команды для работы с GIT.

  •         `git init` — инициализирует новый репозиторий GIT и начинает отслеживание существующего каталога. В существующий каталог добавляется скрытая вложенная папка, в которой размещается внутренняя структура данных, необходимая для управления версиями.

  •         `git clone` — создает локальную копию проекта, который уже существует удаленно. Клон включает в себя все файлы проекта, журнал и ветви.

  •         `git add` — подготавливает изменение. GIT отслеживает изменения в базе кода разработчика, но для включения изменений в журнал проекта необходимо подготавливать их и создавать моментальные снимки. Эта команда выполняет первую часть этого двухэтапного процесса, то есть подготовку. Все подготовленные изменения станут частью следующего моментального снимка и журнала проекта. Раздельные подготовка и фиксация дают разработчикам полный контроль над историей проекта без необходимости изменять подход к написанию кода и работе в целом.

  •         `git commit` — сохраняет моментальный снимок в журнале проекта и завершает процесс отслеживания изменений. Иначе говоря, фиксация похожа на создание фотографии. Все, что было подготовлено с помощью команды `git add`, станет частью моментального снимка при использовании `git commit`.

  •         `git status` — выводит состояние изменений: не отслеживаются, изменены или подготовлены.

  •         `git branch` — показывает ветви, с которыми ведется локальная работа.

  •         `git merge` — выполняет слияние линий разработки. Эта команда обычно применяется для объединения изменений, внесенных в двух разных ветвях. Например, разработчик выполняет слияние, когда необходимо объединить изменения из ветви функции с главной ветвью для развертывания.

  •         `git pull` — применяет к локальной линии разработки обновления из удаленного аналога. Разработчики используют эту команду, если коллега выполнил фиксации в ветви удаленного репозитория и эти изменения нужно отразить в локальной среде.

  •         `git push` — обновляет удаленный репозиторий с учетом фиксаций, выполненных в ветви локально.

Дополнительные сведения см. в полном справочном руководстве по командам GIT.

Пример. Участие в существующем репозитории

# download a repository on GitHub to our machine
# Replace `owner/repo` with the owner and name of the repository to clone
git clone https://github.com/owner/repo.git

# change into the `repo` directory
cd repo

# create a new branch to store any new changes
git branch my-branch

# switch to that branch (line of development)
git checkout my-branch

# make changes, for example, edit `file1.md` and `file2.md` using the text editor

# stage the changed files
git add file1.md file2.md

# take a snapshot of the staging area (anything that's been added)
git commit -m "my snapshot"

# push changes to github
git push --set-upstream origin my-branch

Пример: Запустите новый репозиторий и опубликуйте его в GitHub

Сначала необходимо создать новый репозиторий на GitHub. Дополнительные сведения см. в разделе Hello World. Не инициализируйте репозиторий с помощью файла сведений, GITIGNORE или файла лицензии. Этот пустой репозиторий ожидает добавления кода.

# create a new directory, and initialize it with git-specific functions
git init my-repo

# change into the `my-repo` directory
cd my-repo

# create the first file in the project
touch README.md

# git isn't aware of the file, stage it
git add README.md

# take a snapshot of the staging area
git commit -m "add README to initial commit"

# provide the path for the repository you created on github
git remote add origin https://github.com/YOUR-USERNAME/YOUR-REPOSITORY-NAME.git

# push changes to github
git push --set-upstream origin main

Пример: участие в существующей ветви на GitHub

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

# change into the `repo` directory
cd repo

# update all remote tracking branches, and the currently checked out branch
git pull

# change into the existing branch called `feature-a`
git checkout feature-a

# make changes, for example, edit `file1.md` using the text editor

# stage the changed file
git add file1.md

# take a snapshot of the staging area
git commit -m "edit file1"

# push changes to github
git push

Модели совместной разработки

Существует два основных способа совместной работы с переменными данных.product.github %}:

  1. общий репозиторий;
  2. создание вилок и вытягивание.

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

Для проектов с open source или для проектов, в которых любой может участвовать, управление индивидуальными правами может быть сложным, но модель fork and pull позволяет всем, кто может просматривать проект, вносить вклад. Вилка — это копия проекта в личной учетной записи разработчика. Каждый разработчик имеет полный контроль над вилкой и может свободно реализовывать исправление или новую функцию. Результаты работы в вилках либо хранятся отдельно, либо переносятся обратно в исходный проект с помощью запроса на вытягивание. Лица, ответственные за проект, могут проверять предлагаемые изменения перед их слиянием. Дополнительные сведения см. в разделе Участие в проекте.