Изучение управления версиями с помощью Git

  • 5 мин

Существуют различные типы систем управления версиями (VCS), но обычно их можно классифицировать как централизованные и распределенные. В последние годы (частично из-за растущей популярности DevOps), последняя категория получила значительную популярность, при этом Git становится де-факто стандартом в современной разработке программного обеспечения. Этот конкретный VCS будет наиболее подходящим выбором для организации в нашем примере сценария, особенно учитывая его намерение использовать GitHub в качестве целевой платформы для перехода DevOps. В этом уроке изучите использование Git в качестве элемента управления версиями.

Снимок экрана: таблица, сравнивающая преимущества централизованных и распределенных систем управления версиями.

Централизованное и распределенное управление версиями

Как централизованные системы управления версиями (CVCS), так и распределенные системы управления версиями (DVCS) предлагают возможность управлять изменениями в проектах разработки программного обеспечения и отслеживать их. Основные различия между ними связаны с тем, как они реализуют репозитории и совместную работу. В частности:

  • Расположение репозитория: в централизованных системах есть один централизованный экземпляр репозитория, содержащий полную историю проекта. В распределенных системах каждый член группы обычно имеет одну, полностью функциональную локальную копию всего репозитория, потенциально включая полный журнал версий.
  • Сетевое подключение. В централизованных системах доступ к централизованному экземпляру репозитория требуется для выполнения многих действий, включая обновление и извлечение журнала. В распределенных системах все действия можно выполнять в локальной копии репозитория.
  • Модель совместной работы. В централизованных системах разработчики извлекает файлы из централизованного экземпляра репозитория, подключенного к нему через сеть, прежде чем вносить изменения и фиксировать изменения. Это предотвращает изменения в файлах, которые были извлечены другими пользователями. В распределенных системах разработчики вносят и фиксируют изменения в локальной копии репозитория, которая в какой-то момент позже синхронизируется с другими копиями.
  • Модель ветвления и объединения: в централизованных системах, ветвление и слияние обычно требует координации с другими. В распределенных системах ветви можно создавать независимо в локальных копиях и объединять их после этого.

Стоит отметить, что, хотя распределенная модель не зависит от центрального репозитория (в традиционном смысле), обычно реализует одну копию репозитория, размещенную службами, такими как GitHub, GitLab или Bitbucket. Этот экземпляр служит центром совместной работы и синхронизации.

снимок экрана: репозитории централизованных и распределенных систем управления версиями и совместной работы.

Терминология Git

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

  • Рабочее дерево: структура каталога, содержащая все файлы проекта.
  • Репозиторий (обычно называемый репозиторием): каталог, расположенный на верхнем уровне рабочего дерева, где размещаются все файлы проекта вместе с журналом версий этих файлов.
  • Клонировать: действие создания копии удаленного репозитория на локальном компьютере для работы с проектом, к которому у вас есть доступ.
  • Форк: действие создания размещенной на GitHub копии удаленного репозитория для работы над проектом, к которому у вас нет доступа. Вилка обычно используется, если вы планируете внести свой вклад в чужой проект или создать собственную версию проекта. Хотя у вас нет доступа на запись к оригинальному репозиторию, вы можете полностью управлять своим форком.
  • Коммит: снимок изменений, внесенных в файлы в репозитории в определенный момент времени. Коммиты используются для записи и сохранения изменений.
  • Промежуточная область промежуточного расположения (которая не является частью репозитория), где изменения файлов в рабочем дереве подготавливаются до их фиксации. Это позволяет разработчикам выбирать изменения, которые они намерены зафиксировать.
  • Branch: именованный ряд связанных коммитов. В простых терминах ветвь представляет отдельную версию проекта. Это позволяет одновременно работать над различными частями проекта, не затрагивая ее основную версию. Последняя фиксация в ветви называется указателем. Ветвь по умолчанию создается автоматически при инициализации репозитория называется main или master.
  • Слияние: процесс объединения изменений из одной ветви (или фиксации) в другую. Это интегрирует изменения из одной ветви в другую.
  • Объект: один из четырех типов сущностей, доступных в репозитории. К этим сущностям относятся блобы , представляющие отдельные файлы, дерево , представляющее рабочее дерево, фиксация , обозначающая определенную версию рабочего дерева, а также тег, который является меткой, назначенной отдельной фиксации.
  • Хэш: автоматически созданный, уникальный идентификатор фиксированной длины, представляющий содержимое объекта. Всякий раз, когда этот объект изменяется, его хэш-код также изменяется. Это позволяет Git определить, какое содержимое в репозитории было обновлено.
  • удаленный: ссылка на другой, отличный от локального, репозиторий, обычно ссылающийся на экземпляр репозитория, размещенный на службе. Это является стандартным значением для операций отправки и извлечения по умолчанию.
  • вытягивание: действие, которое извлекает изменения из удаленного репозитория и объединяет их в текущую ветвь.
  • push-: действие, которое отправляет локальные коммиты в удаленный репозиторий, обновляя его с изменениями, внесенными локально.
  • фетчинг: действие, которое извлекает изменения из удаленного репозитория без автоматического объединения. Это позволяет проверить их перед применением слияния.
  • pull request: функция на платформах размещения на основе Git (например, GitHub), которая позволяет разработчикам предлагать изменения и запрашивать их объединение в целевую ветвь.

Git также имеет обширный набор команд, которые обеспечивают возможность полностью реализовать управление версиями и управлять ими с помощью командной оболочки, например Linux Bash или командной строки Windows. Кроме того, вы можете управлять Git с помощью классических приложений, таких как GitHub Desktop. Платформы размещения на основе Git предоставляют веб-интерфейс, упрощающий взаимодействие с репозиториями на стороне службы.

Git vs. GitHub

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

  • Удаленные репозитории: содействие взаимодействию между распределенными командами.
  • инструменты для совместной работы: предоставление таких функций, как задачи, обсуждения, pull-реквесты, уведомления, метки, действия, форки, вики и проекты.
  • Веб-интерфейс: минимизация необходимости использования команд Git
  • защита ветви: выполнение условий, которые должны быть соблюдены перед слиянием (например, завершенные проверки пулл-реквестов).