Git и Github. Простые рецепты

Использование программы

Для запуска необходим python версии не менее 2.7. Команда:

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

Пример использования:

— это граф, заданный матрицей смежности взвешенного графа в виде таблицы формата *.csv.

Файл выхода программы, по умолчанию , содержит полученные кластеры графа, выведенные в виде ассоциативного массива: индекс кластера -> список содержащихся в нем вершин по индексам, взятым из матрицы смежности. (см. пример из двух кластеров)

Точность создания кластеров алгоритмом регулируется задаваемыми константами, которые можно найти в файле config.py. Среди них:

  • — фактор накачивания — константа, использующаяся в операторе накачивания алгоритма как степень r (см. ). При значениях накачивание преобразует элементы матрицы, являющиеся вероятностями перехода из одного состояния в другое для конкретной вершины (соответующей столбцу матрицы), в элементы более вероятных прогулок. Чем выше параметр, тем больше находится кластеров.
  • — максимальное количество итераций, по умолчанию стоит 100, для более высокой точности можно выставить больше итераций, но оптимально иметь 100. В действительности в большинстве случаев количество итераций будет меньше, так как будет достигнуто устойчивое состояние матрицы (разница двух подряд идущих матриц при заданной точности будет равна 0).
  • — константа, задающая значения диагональных элементов матрицы, говоря понятием графа: вес петли в графе. Если верить автору алгоритма, оптимально иметь значение, равное 1. Увеличение приведет к более высокой гранулярности графа (степени разбиения).
  • — точность — константа задает порядок, которым можно пренебречь при расчете вероятности. Используется в подсчете разницы двух подряд идущих матриц. Чем выше точность, тем больше итераций алгоритма, и наоборот.

Принцип работы с репозиторием

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

Логично предположить, что когда два человека захотят залить результаты своей работы в общий git репозиторий могут возникать конфликты. Это называется merge conflict.

Чтобы минимизировать частоту появления конфликтов зачастую люди

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

Остановимся на втором пункте чуть подробнее. Ранее мы говорили, что суть git в том, чтобы сохранить прогресс в общем репозитории. Как же быть, если фичу доделать не успеваем, а сохраниться надо?

Ветки в git репозитории

Базовая концепция git – ветки. Вы можете создать ответвление от базового timeline в определенный момент времени и сохранять всю работу в своей отдельной “вселенной”.

Когда работа будет завершена останется только слить вашу ветку с общей и разрешить merge конфликты если такие будут. Влитые без ведома остальных членов команды изменения могут стать неожиданными. И вот тут появляется такая вещь как pull request и code review.

Pull request и Code review при слиянии веток

Суть подхода в том, что перед тем как смержить ваши наработки с основной master веткой проекта дать возможность вашим коллегам посмотреть то, что вы сделали. Для этого создается pull request (запрос на добавления кода в общую ветку).

Далее начинается code review.


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

Overview

Continuous Integration works by pushing small code chunks to your
application’s code base hosted in a Git repository, and, to every
push, run a pipeline of scripts to build, test, and validate the
code changes before merging them into the main branch.

Continuous Delivery and Deployment consist of a step further CI,
deploying your application to production at every
push to the default branch of the repository.

These methodologies allow you to catch bugs and errors early in
the development cycle, ensuring that all the code deployed to
production complies with the code standards you established for
your app.

For a complete overview of these methodologies and GitLab CI/CD,
read the Introduction to CI/CD with GitLab.

For a video demonstration of GitLab CI/CD, see Demo: CI/CD with GitLab.

GitLab и GitHub

Как известно, главный конкурент GitLab — это сервис GitHub. Появился он на три года раньше (в 2008), поэтому более популярен. Да что там говорить, GitHub сегодня — это сайт номер один по размещению open source-проектов. Они почти все на нём и размещаются.))) И у многих людей Git напрямую ассоциируется с сервисом GitHub.

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

Просмотр изменений в истории

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

  • показывает изменения в каждом коммите;
  • показывает сокращённую статистику для коммитов, например изменённые файлы и количество добавленных/удалённых строк в каждом их них;
  • показывает n последних коммитов;
  • и позволяет отфильтровать коммиты по промежутку времени, например покажет коммиты с 1 января 2019 года;
  • позволяет указать формат логов (например, ), также можно использовать для большей кастомизации, например ;
  • и фильтруют коммиты с сообщениями/изменениями кода, которые содержат указанную строку, например,  позволяет посмотреть добавление/удаление функции;
  • пропускает коммиты со слиянием веток;
  • позволяет посмотреть, какие коммиты из ветки 2 не находятся в ветке 1 (полезно при слиянии веток). Например,  покажет, каких коммитов из ветки test нет в master (о ветках поговорим чуть позже).
  • показывает коммиты, которые есть либо в ветке 1, либо в ветке 2, но не в обеих; знак
  • принимает аргумент  или  и показывает историю изменений переданного набора строк или функции в файле.

Другой полезной командой является , которая для каждой строки файла показывает автора и контрольную сумму последнего коммита, который изменил эту строку. позволяет ограничить эту команду заданными строками. Это можно использовать, например, для выяснения того, какой коммит привёл к определённому багу (чтобы можно было его откатить).

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

Примечание Не путайте с ! Первый ищет по файлам среди коммитов, а последний смотрит на сообщения логов.

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

Для работы с GitHub нам потребуется установить клиент контроля версий (в GitHub, это GitHub Desktop) и создать репозиторий. Репозиторий можно создать, как через веб-сайт, так и через клиент.

Принципы работы с репозиторием GitHub

  1. С помощью клиента копируем весь репозиторий на свой компьютер (pull).
  2. Вносим различные правки, сохраняем, вносим правки и т.д. в различные файлы репозитория.
  3. Просим клиента внести изменённые файлы в репозиторий.
    Внесение измененных файлов в репозиторий называется фиксацией изменений или «коммитом» (commit).
  4. После коммита версия вашего локального репозитория изменилась.
  5. На данный момент изменения фиксированы только на локальном репозитории, чтобы они отобразились на сайте GitHub, требуется еще одна функция «синхронизация репозиториев» (push).
  6. Теперь ваш главный репозиторий, расположенный в GitHub, такой же, как на вашем компьютере.

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

Слияние, конфликт, разрешение конфликта

Для понимая нужен пример. Влад и Артем сделали копию репозитория (pull) с фалом версии 1 с GitHub, внесли разные изменения в этот файл, оба зафиксировали изменения (commit) → версии фала в локальных репозиториев изменились, у Влада версия 2, у Артем 2А. И затем Влад запушил (синхронизировал репозитории- push). Теперь на GitHub добавилась версия файла 2. Артем тоже решил запушить свои изменения, т. к. на GitHub есть версия которой нет у Артема (у него нет версии 2), система откажется принимать его репозиторий для сохранения версии 2.

Для того, чтобы внести свои изменения, Артему нужно опять скопировать репозиторий (pull) с GitHub с дополнительной версией этого файла. При копировании произойдет конфликт.

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

Способы решения конфликта:

  1. Автоматическое слияние. Сравнивая построчно код Влада и Артема, GitHub может решить совместить куски кода в файле, при этой получится новая версия файла. При таком подходе в репозитории будут находиться версии 1, 2, 2А, и 3, а Артем теперь может запушить все отсутствующие версии файла.
  2. Разрешение конфликта вручную. Git пометит, какой код конфликтует, и вам нужно будет решить, какой вариант оставить или вообще внести третий. Создается версия 3, и Артем может запушить отсутствующие версии файла.

Master / не master, Fork, Pull request

Ветки — это своеобразные папки со всеми файлами проекта. Ветка Master — это самая главная папка вашего проекта, она всегда существует. Дополнительные ветки создаются под всякие дополнительные нужды.

Пример модели работы с ветками:

В Master лежит последняя стабильная версия, где вы можете вносить незначительные изменения; development — ветка для непосредственной разработки; dev-adaptive — ветка разработки, связанная с планируемым расширением функционала.

Что такое Fork? К примеру, на GitHub вам понравился какой-то проект, но вы заметили в нем ошибку и знаете, как ее решить, но доступа к редактированию чужого проекта у вас нет. Для этого вам нужно создать fokr. Теперь у вас есть доступ для редактирования файлов проекта. Вы справились с багом, но ваши труду пропадут даром т. к. изменения не отобразится в master ветке проекта. Чтобы такого не произошло и создан Pull request.

Pull request — это обращение к владельцам проекта с предложением внести в главную ветку ваши изменения.

Настройте и запустите тестирование для проекта

Runner — это специальная программа, которая осуществляет процесс тестирования и сборки проекта в среде GitLab по заданной вами инструкции.

Настройте и зарегистрируйте runner

  1. Зайдите по SSH на виртуальную машину и перейдите в режим администратора в консоли:

  2. Загрузите runner:

  3. Сделайте runner исполняемым:

  4. Создайте отдельного пользователя для запуска runner:

  5. Установите и запустите runner:

  6. Зарегистрируйте runner в GitLab:

    1. Запустите интерактивную регистрацию командой .

    2. Введите адрес вашего GitLab-сервера. При запросе:

      введите

    3. Введите регистрационный токен для runner. Чтобы его найти, нужно перейти в GitLab на страницу проекта, затем в панели слева выбрать Settings и открыть вкладку CI/CD. После этого нажмите кнопку Expand в блоке Runners. В разделе Set up a specific Runner manually скопируйте токен из третьего пункта и введите его в ответ на запрос:

    4. На запрос:

      введите описание runner: .

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

    6. Укажите среду выполнения. В нашем случае, на запрос:

      введите:

На этом установка и настойка runner выполнена. Если все сделано правильно, то на странице, где вы копировали регистрационный токен, должен появиться раздел Runners activated for this project, в котором будет отображаться зарегистрированный runner.

Создайте сценарий тестирования

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

Так как тестирование будет выполняться в операционной системе ВМ, установите приложения, которые необходимы для тестирования: для клонирования проекта из репозитория и для компиляции проекта.

Чтобы создать сценарий тестирования:

  1. Подключитесь к ВМ по SSH и установите необходимые приложения:

  2. Добавьте сценарий тестирования:

    1. В веб-интерфейсе GitLab в панели слева перейдите выберите раздел Project и выберите вкладку Details.

    2. На открывшейся странице нажмите кнопку Set up CI&CD.

    3. Откроется страница с предложением добавить новый файл , в котором в формате YAML нужно описать сценарий. Добавьте текст сценария:

      В сценарии указано, что работа разделена на три этапа, которые выполняются последовательно:

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

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

    4. Нажмите Commit changes

После коммита система автоматически начнет тестировать последний коммит. Процесс тестирования и результаты можно посмотреть, в разделе CI/CD на панели слева. В результате должна появиться строчка с первым тестом и статусом . Нажав на значок с облаком вы можете загрузить артефакты сборки.

Создайте ошибку в проекте

Теперь сделайте так, чтобы в проекте произошла ошибка, которую runner должен помочь найти в процессе выполнения тестирования. Для этого:

  1. Зайдите в репозиторий проекта и откройте файл .
  2. Нажмите Edit.
  3. Укажите в проверке (assert), что результат выполнения умножения 2 на 2 должен быть равен 5. В этом случае при выполнении программы произойдет ошибка и она завершится некорректно.

  4. Назовите коммит .
  5. Нажмите Commit Changes.

Откройте раздел CI/CD. В столбце Stages видно, что в результате выполнения теста был успешно пройден первый этап , а на втором этапе произошла ошибка. Третий этап был пропущен и итоговые артефакты не были сформированы.

Если нажать на статус выполнения и перейти на вкладку Failed Jobs, можно увидеть текст ошибки, где указано, что не выполнился :

Осовной действия

Клонирование репозитория

Слева вверху есть значок папки. Кликаем по нему

  1. Выбираем пункт «Клонировать»
  2. Если вы авторизировались через аккаунт GitHub, то сможете видеть все свои репозитории и тогда смело выбирайте пункт GitHub. Иначе сверху есть вариант «Клонировать через Url» — так вы сможете скопировать любой гит репозиторий из интернета (не обязательно свой).
  3. Найдите в открывшемся меню справа свой репозиторий, который хотите клонировать
  4. Если не хотите устраивать свалку на диске C, то можете выбрать любое расположение репозитория у себя на диске.
  5. Все! Нажимайте кнопку «Клонировать» и ура-ура, репозиторий скачается с сервера и создастся у вас в файловой системе

После клонирования ГитКракен предложит сразу же и открыть репозиторий. Открывайте. Чего уж тянуть кота за это дело.

Интерфейс работы с репозиторием

Итак. Теперь самое интересное.

  1. Это так называемое «дерево изменений» вашего репозитория. Здесь наглядно можно увидеть, кто пакостил в вашем репозитории: кто сливал вместе изменения, кто ответвлялся и т.д. В сложных проектах такое дерево может быть достаточно симпатичным (см. картинку ниже)
  2. Справа, если в дереве выбрать какой-то коммит, будет отображена информация об этом коммите: когда и кем сделан, какие файлы были изменены. При двойном клике на файл, откроет просмотр изменений в этом файле.
  3. Панелька слева отображает, какие ветки (направления работы вашего репозитория) есть на сервере — Remote и на вашей локальной машине — Local. В крупных проектах тут могут быть десятки веток.

Пример неплохого дерева:

Pull = Получение изменений с сервера

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

Commit + Push = Фиксация изменений + отправка этих изменений на сервер

Итак. Вот вы что-то поменяли в своих файлах. Пришла пора сохранить эти изменения и зафиксировать их с помощью гит.

После того, как файлы были изменены, когда вы откроете ГитКракен, то увидите в дереве репозитория, что появился новый необозначенный, выделенный пунктиром коммит (AHTUNG!). Выберите его в дереве.

  1. В окошке справа вы можете видеть список измененных файлов. Не обзательно, что вы захотите их «фиксировать» в гите!
  2. Если вы изменили файл случайно, вы можете отказаться от этих изменений и «отверстать все обратно» с помощью кнопки «Discard all changes». Можно отменить изменения только для одного файла. Для этого достаточно навести курсор на этот файл и справа, рядом с именем файла, появится маленькая красная кнопка «Discard»
  3. Если же вы изменили файлы намеренно, то их нужно «зафиксировать» — нажать на кнопку «Stage all changes». Зафиксировать можно только некоторые файлы точно также наведя на них курсор и кликнув на маленькую кнопку «Stage»

Отлично! Осталось совсем немного.

  1. В окошке вы теперь видите Staged files — файлы, готовые к тому, чтобы их «зафиксировать».
  2. Если вы случайно нажали на Stage all changes и вовсе не хотите коммитить файлы, то можно все отменить, нажав на кнопку «Unstage all stages». Естественно, эту же операцию можно сделать для файлов и по отдельности.
  3. Гит не может делать коммиты без текста описания коммита. Обычно пишут что-то, чтобы быстро понять, что было изменено в этом коммите. Например, «добавил функцию чтения из файла» или «исправил ошибку чтения с экрана». Если все-таки ничего не хотите писать, то можно вписать просто «.» — точку. Но пустым оставить описание нельзя. Кнопка «Коммит» просто не активируется.
  4. Итак, если все было сделано правильно, то активируется кнопка «Коммит». Жмите ее!

Ура-ура-ура! Мы сделали это, коммит создан. Но помните, что гит делает коммиты в локальный репозиторий на вашей машине. Если, не дай бог, с вашей машиной что-то случится, то вы потеряете все изменения, которые накоммитили. Поэтому не забывайте периодически «пушить» ваши локальные изменения на сервер. Но не слишком часто. А то станете «пушистиками». 😉

P.s. Про «пушистиков» это была шутка. Пушьте так часто, как хотите. Я вот «пушистик» и горжусь этим. 🙂

Система контроля версий Git

Для начала определим, что такое система контроля версий.

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

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

Одна из самых популярных систем называется Git. Её отличие от других программ — отсутствие графической версии. Поэтому работа с Git ведётся через командную строку. В разных операционных системах свои программы для взаимодействия с Git.

В Windows их две: PowerShell и cmd.exe. В Ubuntu это Terminal. Самая популярная программа на macOS тоже называется Terminal. Если вам не подходит встроенная в систему программа для работы с командной строкой, вы можете поставить свою. Например, написанную на JavaScript программу Hyper, которая работает на любой операционной системе. На Windows популярны программы Cmder и Git Bash, а на macOS — iTerm.

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

Устанавливаем Git

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

Установка в Linux

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

  • Если у вас 21 или более ранняя версия Fedora, используйте .
  • Для 22 и последующих версий Fedora вводите .
  • Для дистрибутивов, основанных на Debian, например, Ubuntu, используйте .

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

Установка на macOS

  1. Скачиваем Git со страницы проекта.
  2. Запускаем загруженный файл.
  3. Система может показать окно с ошибкой, где будет написано, что файл скачан с неавторизованного сайта и инсталлятор не может быть запущен. В таком случае нужно зайти в «Системные настройки» — «Безопасность» (Security and Privacy), в появившемся окне будет сообщение об ошибке и кнопка Open anyway (Всё равно открыть). Нажимаем.
  4. Система покажет окно, уточняющее хотите ли вы запустить установку. Подтверждаем действие.
  5. Установщик проведёт через все необходимые шаги.

Установка в Windows

Скачайте exe-файл инсталлятора с сайта Git и запустите его. Это Git для Windows, он называется msysGit. Установщик спросит добавлять ли в меню проводника возможность запуска файлов с помощью Git Bash (консольная версия) и GUI (графическая версия). Подтвердите действие, чтобы далее вести работу через консоль в Git Bash. Остальные пункты можно оставить по умолчанию.

Проверим, что Git установлен

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

Настройка Git

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

Откройте терминал и используйте следующую команду, чтобы добавить своё имя:

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

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

Продвинутое использование: интерактивная подготовка

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

  • — показывает для каждого файла краткое описание того, что (не)подготовлено;
  • — подготавливает отслеживаемые файлы;
  • — убрать один или несколько файлов из подготовленной области;
  • — подготавливает неотслеживаемый файл;
  • — подготавливает только часть файла (полезно, когда вы, например, изменили несколько функций, но хотите разбить изменения на несколько коммитов). После выбора файла вам будут показаны его фрагменты и представлены возможные команды: . Можно ввести , чтобы узнать, что делает каждая команда;
  • — показывает список подготовленных файлов и позволяет посмотреть изменения для каждого из них;
  • — выходит из интерактивной консоли;
  • — показывает краткое описание каждой команды.

Символ рядом с файлом означает, что команда изменит его статус (подготовлен/неподготовлен в зависимости от того, происходит ли обновление или откат). Если нажать Enter, не введя ничего ни в одном из под-меню команды, то все файлы перейдут в (не)подготовленное состояние.

Обратите внимание, что создание патчей (подготовка только части файла) доступно не только в интерактивной консоли, но и через команду

GitLab CI YML

GitLab CI использует YAML файл .gitlab-ci.yml для определения конфигураций проекта, включающих в себя определение всех этапов, которые будут выполняться после того, как конвейер CI/CD запускается в ответ на git push/merge. В этом примере нам нужно провести unit-тест над простым Node.js проектом, чтобы убедиться, что в коде нет ошибок. Чтобы вым стало понятнее, попробуйте сами запустить данный репозиторий.

В вышеприведенном конфигурационном файле YAML мы все разбили на 3 этапа. Каждый из этапов это просто gulp.task, заданный в gulpfile.js . Так как у нас установлен Node.js, пользователь может по отдельности запускать любой из этапов. Но в GitLab CI требуется указать, какой из образов Docker вам нужен. В нашем случае, это узел:6.11.2. Кроме того, данный Docker-атрибут можно задать внутри определенного этапа, поэтому вы сможете использовать различные инструменты для любого из этапов.

Ссылка на основную публикацию