Основы Git: первые шаги в работе с системой контроля версий

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

Одним из самых популярных решений для управления версиями является безлицензионный инструмент Git. Он прост в освоении и бесплатен. В этом руководстве мы объясним самые важные основы Git, необходимые для начала работы с программой управления версиями.

Git — это распределенная система управления версиями, разработанная создателем Linux Линусом Торвальдсом в 2005 году и выпущенная под свободной лицензией GNU-GPLv2. Особенностью этого инструмента является то, что, хотя для каждого проекта существует центральный репозиторий, все участвующие пользователи загружают локальную рабочую копию этого каталога на свои рабочие устройства. Каждая из этих копий представляет собой полную резервную копию репозитория, что делает ненужным постоянное подключение к сети и позволяет работать в автономном режиме. Более того, копии могут быть использованы для восстановления каждого проекта в случае сбоя или повреждения основного хранилища. Внесенными изменениями можно в любое время обменяться со всеми другими участниками проекта и — при необходимости — включить их в репозиторий.

Тот, кто хочет научиться управлять программным обеспечением с помощью Git, должен сначала ознакомиться с программой и ее пользовательским интерфейсом. Git доступен для Windows, Unix/Linux и macOS, однако различные версии немного отличаются друг от друга. После установки соответствующей версии вы можете управлять инструментом независимо от платформы с помощью командной строки или графического интерфейса пользователя.

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

Бинарные установочные файлы, руководства по установке менеджера пакетов (Unix-системы) и готовые портативные редакции для отдельных систем доступны на официальном сайте проекта Git. Просто загрузите необходимый пакет или используйте подходящий пакет в своем пакетном менеджменте, а затем следуйте инструкциям мастера установки. В случае портативного издания шаг установки, разумеется, не требуется.

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

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

Если вы хотите настроить управление версиями или установить инструменты для обучения работе с Git, вам нужно будет создать новый репозиторий. Для этого перейдите в нужный локальный репозиторий на вашем устройстве с помощью команды «cd» (change directory):

Теперь выполните следующую команду для создания репозитория .git:

Если Git-репозиторий для вашего проекта уже существует, вам понадобится только веб-адрес или сетевой адрес этого репозитория, чтобы создать рабочую копию на вашем компьютере с помощью команды «git clone»:

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

В случае вновь созданного репозитория или абсолютного совпадения центрального репозитория и рабочей копии вы получите сообщение об отсутствии новых изменений в проекте («No commits yet»). Кроме того, Git сообщит, что в настоящее время вы не представили никаких изменений для следующей фиксации («Nothing to commit»).

Чтобы добавить новый файл для управления версиями или отправить измененный файл для следующего коммита, примените команду «git add» к файлу (он должен содержаться в рабочем репозитории). В нашем руководстве по Git в качестве примера мы добавляем текстовый документ под названием «Test»:

Если вы снова проверите статус репозитория, документ-пример будет показан как потенциальный кандидат на следующее официальное обновление проекта («Changes to be committed»):

Все изменения, которые вы отправляете для управления версиями (как описано в предыдущем разделе), всегда должны быть подтверждены через Commit, чтобы быть включенными в HEAD. HEAD — это тип индекса, который относится к последней эффективной фиксации в вашей текущей рабочей среде Git (также известной как «ветка»). Команда для этого шага показана ниже:

После выполнения команды Git автоматически запускает редактор, который вы указали в качестве стандартного выбора при установке, или редактор, назначенный по умолчанию инструментом управления версиями. Теперь вы можете ввести индивидуальный комментарий для планируемого коммита; строки, включенные и разделенные точкой с запятой, в дальнейшем не отображаются. Как только вы закроете редактор, Git создаст коммит:

Как видно на скриншоте, после выполнения команды «git commit» вы получите сводку по коммиту. В предыдущих квадратных скобках вы найдёте имя ветви («master» в данном случае, так как наш рабочий репозиторий также является центральным), в которой были приняты изменения, а также контрольную сумму SHA-1 коммита («c0fdc90» здесь). Затем следует свободно выбранный комментарий («test» в нашем примере) и конкретная информация о внесённых изменениях.

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

Однако, если вы хотите отозвать самый последний коммит, вы можете использовать следующую команду Git:

Эта команда отменяет коммит, включенный в HEAD последним. Содержащиеся в нём файлы возвращаются в состояние: «Планируемые изменения для следующего коммита». Чтобы удалить файлы полностью, введите команду ниже:

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

Команда «git log» выводит список созданных коммитов в обратном хронологическом порядке, при этом стандартно отображается контрольная сумма SHA-1, автор (имя и адрес электронной почты), а также дата коммита. Более того, можно увидеть и отдельное сообщение, предоставляя вам и другим пользователям ключевую информацию для быстрой классификации каждого из изменений. В нашем руководстве по Git мы ранее создали один коммит с сообщением «Test». Это отображается командой следующим образом:

Команда log также может быть изменена различными параметрами. Некоторые полезные параметры приведены в таблице ниже:

До сих пор мы показывали вам, как сохранять изменения в виде коммита в HEAD локального репозитория. Однако для того, чтобы коммит был включен в центральный репозиторий, необходимо ввести следующую команду:

После ввода этой команды Git автоматически переносит все созданные коммиты, которые ранее существовали только в рабочей копии, в центральный репозиторий. Этот репозиторий также называется «master». Если вы замените это имя в приведенном коде на имя другой ветки, файлы будут отправлены туда.

Как и многие другие системы управления версиями, Git также предлагает функцию меток, которая позволяет отмечать выбранные точки в истории репозитория как важные. Эти метки обычно используются для обозначения релизов программы (например, версии 1.0, 2.0 и т.д.), чтобы они оставались легкодоступными даже для больших проектов. Git поддерживает два типа тегов:

• «Аннотированные» теги сохраняются как независимые объекты в базе данных, включая собственную контрольную сумму, сообщение о теге, дату, имя и адрес электронной почты автора тега, а также дополнительную подпись GNU Privacy Guard (подпись GPG).
• «Облегченные» метки действуют как ветки, служа лишь ссылкой на коммит. Этот тип подходит, когда вам нужны только временные метки или вы не хотите сохранять расширенную информацию.

Вы можете создавать аннотированные метки в Git’е, используя команду «git tag -a» на соответствующем коммите. Если вы также добавите параметр «-m» в качестве суффикса, вы сможете составить нужное сообщение о метке прямо в командной строке (между прямыми кавычками). В этом Git-руководстве мы создали коммит «Test», который мы также можем связать с тегом, включающим сообщение «example tag»:

Подход для облегченных тегов аналогичен. Однако вам нужно использовать только основную команду «git tag» на соответствующем коммите — без каких-либо дополнительных параметров. Для нашего учебного примера Git эта команда будет выглядеть следующим образом:

Как только для вашего репозитория появятся теги, вы также сможете отобразить их с помощью команды «git tag» и дополнительных параметров «-l» или «—list»:

Чтобы удалить тег из локального рабочего репозитория, примените к нему цепочку команд «git tag -d». Мы можем удалить наш тег для «Test» следующим образом:

Теги должны быть вручную адаптированы в центральный репозиторий. Для этого требуется как имя тега, так и команда «git push origin». Вместо имени тега можно также добавить параметр «—tags», который переносит все сгенерированные теги в репозиторий.

Ветви, используемые в этом учебнике по Git, по сути, являются отдельными рабочими версиями центрального репозитория, который сам классифицируется как ветвь, называемая «master». Благодаря этим ветвям Git предлагает идеальную основу для разработки функций и возможностей по отдельности и их последующего объединения. Этот процесс также известен как «слияние».

Создать новую ветку довольно просто: Вам понадобится только команда «git branch», которую вы затем дополните желаемым именем ветви. Чтобы создать пример ветви под названием «test_branch», вы введете приведенную ниже команду:

После этого вы сможете в любой момент перейти в эту ветвь с помощью команды «git checkout»:

Если вы хотите объединить ветви, вы можете использовать команду «git merge». Сначала введите команду «checkout» для перехода в репозиторий, в который будет интегрирована другая ветвь, а затем выполните команду merge, указав имя объединяемой ветви. Например, наша рабочая версия «test_branch» может быть объединена в центральный репозиторий следующим образом:

После того, как вы объединили ветви и, следовательно, больше не нуждаетесь в определенной ветви, вы можете просто удалить ее. Для этого добавьте команду «git brand -d» к ветке, которая больше не нужна. Наш пример из учебника Git «test_branch» можно удалить, выполнив приведенную ниже команду:

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