Лабораторная работа Первоначальна настройка git

Лабораторная работа Первоначальна настройка git.

1 Цель работы

  • Изучить идеологию и применение средств контроля версий.
  • Освоить умения по работе с git.

2 Теоретические сведения

2.1 Системы контроля версий. Общие понятия

  • Системы контроля версий (Version Control System, VCS) применяются при работе нескольких человек над одним проектом. Обычно основное дерево проекта хранится в локальном или удалённом репозитории, к которому настроен доступ для участников проекта. При внесении изменений в содержание проекта система контроля версий позволяет их фиксировать, совмещать изменения, произведённые разными участниками проекта, производить откат к любой более ранней версии проекта, если это требуется.
  • В классических системах контроля версий используется централизованная модель, предполагающая наличие единого репозитория для хранения файлов. Выполнение большинства функций по управлению версиями осуществляется специальным сервером. Участник проекта (пользователь) перед началом работы посредством определённых команд получает нужную ему версию файлов. После внесения изменений, пользователь размещает новую версию в хранилище. При этом предыдущие версии не удаляются из центрального хранилища и к ним можно вернуться в любой момент. Сервер может сохранять не полную версию изменённых файлов, а производить так называемую дельта-компрессию — сохранять только изменения между последовательными версиями, что позволяет уменьшить объём хранимых данных.
  • Системы контроля версий поддерживают возможность отслеживания и разрешения конфликтов, которые могут возникнуть при работе нескольких человек над одним файлом. Можно объединить (слить) изменения, сделанные разными участниками (автоматически или вручную), вручную выбрать нужную версию, отменить изменения вовсе или заблокировать файлы для изменения. В зависимости от настроек блокировка не позволяет другим пользователям получить рабочую копию или препятствует изменению рабочей копии файла средствами файловой системы ОС, обеспечивая таким образом, привилегированный доступ только одному пользователю, работающему с файлом.
  • Системы контроля версий также могут обеспечивать дополнительные, более гибкие функциональные возможности. Например, они могут поддерживать работу с несколькими версиями одного файла, сохраняя общую историю изменений до точки ветвления версий и собственные истории изменений каждой ветви. Кроме того, обычно доступна информация о том, кто из участников, когда и какие изменения вносил. Обычно такого рода информация хранится в журнале изменений, доступ к которому можно ограничить.
  • В отличие от классических, в распределённых системах контроля версий центральный репозиторий не является обязательным.
  • Среди классических VCS наиболее известны CVS, Subversion, а среди распределённых — Git, Bazaar, Mercurial. Принципы их работы схожи, отличаются они в основном синтаксисом используемых в работе команд.

2.2 Примеры использования git

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

2.2.1 Основные команды git

  • Перечислим наиболее часто используемые команды git.

  • Создание основного дерева репозитория:

    1git init

  • Получение обновлений (изменений) текущего дерева из центрального репозитория:

    1git pull

  • Отправка всех произведённых изменений локального дерева в центральный репозиторий:

    1git push

  • Просмотр списка изменённых файлов в текущей директории:

    1git status

  • Просмотр текущих изменений:

    1git diff

  • Сохранение текущих изменений:

    • Добавить все изменённые и/или созданные файлы и/или каталоги:

      1git add .

    • Добавить конкретные изменённые и/или созданные файлы и/или каталоги:

      1git add имена_файлов

    • Удалить файл и/или каталог из индекса репозитория (при этом файл и/или каталог остаётся в локальной директории):

      1git rm имена_файлов

  • Сохранение добавленных изменений:

    • Сохранить все добавленные изменения и все изменённые файлы:

      1git commit -am 'Описание коммита'

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

      1git commit

    • Создание новой ветки, базирующейся на текущей:

      1git checkout -b имя_ветки

    • Переключение на некоторую ветку:

      1git checkout имя_ветки
      • При переключении на ветку, которой ещё нет в локальном репозитории, она будет создана и связана с удалённой.

    • Отправка изменений конкретной ветки в центральный репозиторий:

      1git push origin имя_ветки

    • Слияние ветки с текущим деревом:

      1git merge --no-ff имя_ветки

  • Удаление ветки:

    • удаление локальной уже слитой с основным деревом ветки:
      1git branch -d имя_ветки
    • принудительное удаление локальной ветки:
      1git branch -D имя_ветки
    • удаление ветки с центрального репозитория:
      1git push origin :имя_ветки

2.2.2 Стандартные процедуры работы при наличии центрального репозитория

  • Работа пользователя со своей веткой начинается с проверки и получения изменений из центрального репозитория (при этом в локальное дерево до начала этой процедуры не должно было вноситься изменений):

    1git checkout master
2git pull
3git checkout -b имя_ветки

  • Затем можно вносить изменения в локальном дереве и/или ветке.

  • После завершения внесения какого-то изменения в файлы и/или каталоги проекта необходимо разместить их в центральном репозитории. Для этого необходимо проверить, какие файлы изменились к текущему моменту:

    1git status

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

  • Затем полезно просмотреть текст изменений на предмет соответствия правилам ведения чистых коммитов:

    1git diff

  • Если какие-либо файлы не должны попасть в коммит, то помечаем только те файлы, изменения которых нужно сохранить. Для этого используем команды добавления и/или удаления с нужными опциями:

    1git add …
2git rm …

  • Если нужно сохранить все изменения в текущем каталоге, то используем:

    1git add .

  • Затем сохраняем изменения, поясняя, что было сделано:

    1git commit -am "Some commit message"

  • Отправляем изменения в центральный репозиторий:

    1git push origin имя_ветки

    или

    1git push

2.2.3 Работа с локальным репозиторием

  • Создадим локальный репозиторий.

  • Сначала сделаем предварительную конфигурацию, указав имя и email владельца репозитория:

    1git config --global user.name "Имя Фамилия"
2git config --global  user.email "work@mail"

  • Настроим utf-8 в выводе сообщений git:

    1git config --global quotepath false

  • Для инициализации локального репозитория, расположенного, например, в каталоге ~/tutorial, необходимо ввести в командной строке:

    1cd
2mkdir tutorial
3cd tutorial
4git init

  • После это в каталоге tutorial появится каталог .git, в котором будет храниться история изменений.

  • Создадим тестовый текстовый файл hello.txt и добавим его в локальный репозиторий:

    1echo 'hello world' > hello.txt
2git add hello.txt
3git commit -am 'Новый файл'

  • Воспользуемся командой status для просмотра изменений в рабочем каталоге, сделанных с момента последней ревизии:

    1git status

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

    1curl -L -s https://www.gitignore.io/api/list

  • Затем скачать шаблон, например, для C и C++

    1curl -L -s https://www.gitignore.io/api/c >> .gitignore
2curl -L -s https://www.gitignore.io/api/c++ >> .gitignore

2.2.4 Работа с сервером репозиториев

  • Для последующей идентификации пользователя на сервере репозиториев необходимо сгенерировать пару ключей (приватный и открытый):

    1ssh-keygen -C "Имя Фамилия <work@mail>"

  • Ключи сохраняться в каталоге ~/.ssh/.

  • Существует несколько доступных серверов репозиториев с возможностью бесплатного размещения данных. Например, https://github.com/.

  • Для работы с ним необходимо сначала завести на сайте https://github.com/ учётную запись. Затем необходимо загрузить сгенерённый нами ранее открытый ключ.

  • Для этого зайти на сайт https://github.com/ под своей учётной записью и перейти в меню GitHub setting.

  • После этого выбрать в боковом меню GitHub setting>SSH-ключи и нажать кнопку Добавить ключ. Скопировав из локальной консоли ключ в буфер обмена:

    1cat ~/.ssh/id_rsa.pub | xclip -sel clip

  • Вставляем ключ в появившееся на сайте поле.

  • После этого можно создать на сайте репозиторий, выбрав в меню , дать ему название и сделать общедоступным (публичным).

  • Для загрузки репозитория из локального каталога на сервер выполняем следующие команды:

    1git remote add origin
2  ssh://git@github.com/<username>/<reponame>.git
3git push -u origin master

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

2.3 Базовая настройка git

2.3.1 Первичная настройка параметров git

  • Зададим имя и email владельца репозитория:
    1git config --global user.name "Name Surname"
2git config --global user.email "work@mail"
  • Настроим utf-8 в выводе сообщений git:
    1git config --global core.quotepath false
  • Настройте верификацию и подписание коммитов git (см. Верификация коммитов git с помощью GPG).
  • Зададим имя начальной ветки (будем называть её master):
    1git config --global init.defaultBranch master

2.3.2 Учёт переносов строк

  • В разных операционных системах приняты разные символы для перевода строк:
    • Windows: \r\n (CR и LF);
    • Unix: \n (LF);
    • Mac: \r (CR).
  • Посмотреть значения переносов строк в репозитории можно командой:
    1git ls-files --eol

  1. Параметр autocrlf

    • Настройка core.autocrlf предназначена для того, чтобы в главном репозитории все переводы строк текстовых файлах были одинаковы.

    • Настройка core.autocrlf с параметрами true и input делает все переводы строк текстовых файлов в главном репозитории одинаковыми.

      • core.autocrlf true: конвертация CRLF->LF при коммите и обратно LF->CRLF при выгрузке кода из репозитория на файловую систему (обычно используется в Windows).
      • core.autocrlf input: конвертация CRLF->LF только при коммитах (используются в MacOS/Linux).

    • Варианты конвертации

      Таблица 1: Варианты конвертации для разных значений параметра core.autocrlf
      core.autocrlffalseinputtrue
      git commitLF -> LFLF -> LFLF -> CRLF
      CR -> CRCR -> CRCR -> CR
      CRLF -> CRLFCRLF -> LFCRLF -> CRLF
      git checkoutLF -> LFLF -> LFLF -> CRLF
      CR -> CRCR -> CRCR -> CR
      CRLF -> CRLFCRLF -> CRLFCRLF -> CRLF

    • Установка параметра:

      • Для Windows
        1git config --global core.autocrlf true
      • Для Linux
        1git config --global core.autocrlf input

  1. Параметр safecrlf

    • Настройка core.safecrlf предназначена для проверки, является ли окончаний строк обратимым для текущей настройки core.autocrlf.
      • core.safecrlf true: запрещается необратимое преобразование lf<->crlf. Полезно, когда существуют бинарные файлы, похожие на текстовые файлы.
      • core.safecrlf warn: печать предупреждения, но коммиты с необратимым переходом принимаются.
    • Установка параметра:
      1git config --global core.safecrlf warn

2.4 Создание ключа ssh

2.4.1 Общая информация

  1. Алгоритмы шифрования ssh

    1. Аутентификация

      В SSH поддерживается четыре алгоритма аутентификации по открытым ключам:

      • DSA:
        • размер ключей DSA не может превышать 1024, его следует отключить;
      • RSA:
        • следует создавать ключ большого размера: 4096 бит;
      • ECDSA:
        • ECDSA завязан на технологиях NIST, его следует отключить;
      • Ed25519:
        • используется пока не везде.

    1. Симметричные шифры

      • Из 15 поддерживаемых в SSH алгоритмов симметричного шифрования, безопасными можно считать:
        • chacha20-poly1305;
        • aes*-ctr;
        • aes*-gcm.
      • Шифры 3des-cbc и arcfour потенциально уязвимы в силу использования DES и RC4.
      • Шифр cast128-cbc применяет слишком короткий размер блока (64 бит).

    1. Обмен ключами

      • Применяемые в SSH методы обмена ключей DH (Diffie-Hellman) и ECDH (Elliptic Curve Diffie-Hellman) можно считать безопасными.
      • Из 8 поддерживаемых в SSH протоколов обмена ключами вызывают подозрения три, основанные на рекомендациях NIST:
        • ecdh-sha2-nistp256;
        • ecdh-sha2-nistp384;
        • ecdh-sha2-nistp521.
      • Не стоит использовать протоколы, основанные на SHA1.

  1. Файлы ssh-ключей

    • По умолчанию пользовательские ssh-ключи сохраняются в каталоге ~/.ssh в домашнем каталоге пользователя.

    • Убедитесь, что у вас ещё нет ключа.

    • Файлы закрытых ключей имеют названия типа id_<алгоритм> (например, id_dsa, id_rsa).

      • По умолчанию закрытые ключи имеют имена:
        1id_dsa
2id_ecdsa
3id_ed25519
4id_rsa

    • Открытые ключи имеют дополнительные расширения .pub.

      • По умолчанию публичные ключи имеют имена:
        1id_dsa.pub
2id_ecdsa.pub
3id_ed25519.pub
4id_rsa.pub

    • При создании ключа команда попросит ввести любую ключевую фразу для более надёжной защиты вашего пароля. Можно пропустить этот этап, нажав Enter.

    • Сменить пароль на ключ можно с помощью команды:

      1ssh-keygen -p

2.4.2 Создание ключа ssh

  • Ключ ssh создаётся командой:
    1ssh-keygen -t <алгоритм>
  • Создайте ключи:
    • по алгоритму rsa с ключём размером 4096 бит:
      1ssh-keygen -t rsa -b 4096
    • по алгоритму ed25519:
      1ssh-keygen -t ed25519
  • При создании ключа команда попросит ввести любую ключевую фразу для более надёжной защиты вашего пароля. Можно пропустить этот этап, нажав Enter.
  • Сменить пароль на ключ можно с помощью команды:
    1ssh-keygen -p

2.4.3 Добавление SSH-ключа в учётную запись GitHub

  • Скопируйте созданный SSH-ключ в буфер обмена командой:
    1xclip -i < ~/.ssh/id_ed25519.pub
  • Откройте настройки своего аккаунта на GitHub и перейдем в раздел SSH and GPC keys.
  • Нажмите кнопку ew SSH key.
  • Добавьте в поле Title название этого ключа, например, ed25519@hostname.
  • Вставьте из буфера обмена в поле Key ключ.
  • Нажмите кнопку Add SSH key.

2.5 Верификация коммитов

2.5.1 Верификация коммитов с помощью PGP

  • Как настроить PGP-подпись коммитов с помощью gpg.

  1. Общая информация

    • Коммиты имеют следующие свойства:
      • author (автор) — контрибьютор, выполнивший работу (указывается для справки);
      • committer (коммитер) — пользователь, который закоммитил изменения.
    • Эти свойства можно переопределить при совершении коммита.
    • Авторство коммита можно подделать.
    • В git есть функция подписи коммитов.
    • Для подписывания коммитов используется технология PGP (см. Работа с PGP).
    • Подпись коммита позволяет удостовериться в том, кто является коммитером. Авторство не проверяется.

  1. Создание ключа

    • Генерируем ключ

      1gpg --full-generate-key

    • Из предложенных опций выбираем:

      • тип RSA and RSA;
      • размер 4096;
      • выберите срок действия; значение по умолчанию — 0 (срок действия не истекает никогда).

    • GPG запросит личную информацию, которая сохранится в ключе:

      • Имя (не менее 5 символов).
      • Адрес электронной почты.
        • При вводе email убедитесь, что он соответствует адресу, используемому на GitHub.
      • Комментарий. Можно ввести что угодно или нажать клавишу ввода, чтобы оставить это поле пустым.

  1. Экспорт ключа

    • Выводим список ключей и копируем отпечаток приватного ключа:

      1gpg --list-secret-keys --keyid-format LONG

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

    • Формат строки:

      1sec   Алгоритм/Отпечаток_ключа Дата_создания [Флаги] [Годен_до]
2      ID_ключа

    • Экспортируем ключ в формате ASCII по его отпечатку:

      1gpg --armor --export <PGP Fingerprint>

  1. Добавление PGP ключа в GitHub

    • Копируем ключ и добавляем его в настройках профиля на GitHub (или GitLab).
    • Cкопируйте ваш сгенерированный PGP ключ в буфер обмена:
      1gpg --armor --export <PGP Fingerprint> | xclip -sel clip
    • Перейдите в настройки GitHub (https://github.com/settings/keys), нажмите на кнопку New GPG key и вставьте полученный ключ в поле ввода.

  1. Подписывание коммитов git

    • Подпись коммитов при работе через терминал:
      1git commit -a -S -m 'your commit message'
    • Флаг -S означает создание подписанного коммита. При этом может потребоваться ввод кодовой фразы, заданной при генерации GPG-ключа.

  1. Настройка автоматических подписей коммитов git

    • Используя введёный email, укажите Git применять его при подписи коммитов:
      1git config --global user.signingkey <PGP Fingerprint>
2git config --global commit.gpgsign true
3git config --global gpg.program $(which gpg2)

2.5.2 Проверка коммитов в Git

  • GitHub и GitLab будут показывать значок Verified рядом с вашими новыми коммитами.

  1. Режим бдительности (vigilant mode)

    • На GitHub есть настройка vigilant mode.
    • Все неподписанные коммиты будут явно помечены как Unverified.
    • Включается это в настройках в разделе SSH and GPG keys. Установите метку на Flag unsigned commits as unverified.

3 Задание

  • Создать базовую конфигурацию для работы с git.
  • Создать ключ SSH.
  • Создать ключ PGP.
  • Зарегистрироваться на Github.
  • Настроить подписи git.
  • Создать локальный каталог для выполнения заданий по предмету.

4 Последовательность выполнения работы

4.1 Установка программного обеспечения

4.1.1 Установка git

  • Установим git:
    1dnf install git

4.1.2 Установка gh

  • Fedora:
    1dnf install gh

4.2 Базовая настройка git

  • Зададим имя и email владельца репозитория:

    1git config --global user.name "Name Surname"
2git config --global user.email "work@mail"

  • Настроим utf-8 в выводе сообщений git:

    1git config --global core.quotepath false

  • Настройте верификацию и подписание коммитов git (см. Верификация коммитов git с помощью GPG).

  • Зададим имя начальной ветки (будем называть её master):

    1git config --global init.defaultBranch master

  • Параметр autocrlf:

    1git config --global core.autocrlf input

  • Параметр safecrlf:

    1git config --global core.safecrlf warn

4.3 Настройка github

4.4 Настройка gh

  • Для начала необходимо авторизоваться
    1gh auth login
  • Утилита задаст несколько наводящих вопросов.
  • Авторизоваться можно через броузер.

4.5 Создайте ключ для подписи

  • Создадим ключ для подписи коммитов:
    1ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519-git -C "your_email@example.com"
  • Добавляем ключ в агент (см. Агенты для хранения ключей):
    1ssh-add ~/.ssh/id_ed25519-git
  • Добавьте ключ в учётную запись github (см. github: утилиты командной строки):
    1gh ssh-key add ~/.ssh/id_ed25519-git.pub --title your_email@example.com
2gh ssh-key add ~/.ssh/id_ed25519-git.pub --title your_email@example.com --type signing

4.6 Создайте ключи ssh

  • по алгоритму rsa с ключём размером 4096 бит:
    1ssh-keygen -t rsa -b 4096
  • по алгоритму ed25519:
    1ssh-keygen -t ed25519

4.7 Создайте ключи pgp

  • Генерируем ключ
    1gpg --full-generate-key
  • Из предложенных опций выбираем:
    • тип RSA and RSA;
    • размер 4096;
    • выберите срок действия; значение по умолчанию — 0 (срок действия не истекает никогда).
  • GPG запросит личную информацию, которая сохранится в ключе:
    • Имя (не менее 5 символов).
    • Адрес электронной почты.
      • При вводе email убедитесь, что он соответствует адресу, используемому на GitHub.
    • Комментарий. Можно ввести что угодно или нажать клавишу ввода, чтобы оставить это поле пустым.

4.8 Настройка подписи ключом ssh

  • Настроим подписывание в git:

    1git config --global commit.gpgsign true
2git config --global gpg.format ssh

  • Получим список ключей (используя агент хранения ключей, Агенты для хранения ключей):

    1ssh-add -L

  • Указываем ключ:

    1git config --global user.signingkey "ssh-ed25519 <key_id>"

  • Для проверки работы подписывания запустите команду в любом из ваших репозиториев:

    1git commit --allow-empty --message="Testing SSH signing"

4.9 Шаблон для рабочего пространства

4.9.1 Сознание репозитория курса на основе шаблона

  • Необходимо создать шаблон рабочего пространства (см. Рабочее пространство для лабораторной работы).
  • Например, для 2022–2023 учебного года и предмета «Операционные системы» (код предмета os-intro) создание репозитория примет следующий вид:
    1mkdir -p ~/work/study/2022-2023/"Операционные системы"
2cd ~/work/study/2022-2023/"Операционные системы"
3gh repo create study_2022-2023_os-intro --template=yamadharma/course-directory-student-template --public
4git clone --recursive git@github.com:<owner>/study_2022-2023_os-intro.git os-intro

4.9.2 Настройка каталога курса

  • Перейдите в каталог курса:
    1cd ~/work/study/2022-2023/"Операционные системы"/os-intro
  • Удалите лишние файлы:
    1rm package.json
  • Создайте необходимые каталоги:
    1echo os-intro > COURSE
2make
  • Отправьте файлы на сервер:
    1git add .
2git commit -am 'feat(main): make course structure'
3git push

5 Содержание отчёта

  1. Титульный лист с указанием номера лабораторной работы и ФИО студента.
  2. Формулировка цели работы.
  3. Описание результатов выполнения задания:
    • скриншоты (снимки экрана), фиксирующие выполнение лабораторной работы;
    • листинги (исходный код) программ (если они есть);
    • результаты выполнения программ (текст или снимок экрана в зависимости от задания).
  4. Выводы, согласованные с целью работы.
  5. Ответы на контрольные вопросы.

6 Контрольные вопросы

  1. Что такое системы контроля версий (VCS) и для решения каких задач они предназначаются?
  2. Объясните следующие понятия VCS и их отношения: хранилище, commit, история, рабочая копия.
  3. Что представляют собой и чем отличаются централизованные и децентрализованные VCS? Приведите примеры VCS каждого вида.
  4. Опишите действия с VCS при единоличной работе с хранилищем.
  5. Опишите порядок работы с общим хранилищем VCS.
  6. Каковы основные задачи, решаемые инструментальным средством git?
  7. Назовите и дайте краткую характеристику командам git.
  8. Приведите примеры использования при работе с локальным и удалённым репозиториями.
  9. Что такое и зачем могут быть нужны ветви (branches)?
  10. Как и зачем можно игнорировать некоторые файлы при commit?
Education
Предыдущий
Следующий

Обновлено 2024-08-23

Похожие