ПРАКТИЧЕСКАЯ РАБОТА. ПЛАНИРОВАНИЕ CODE-REVIEW 1. ЦЕЛЬ И ЗАДАЧИ РАБОТЫ Целью выполнения работы является получение практических навыков подготовки среды совместной разработки для проведения инспекции программного кода. 2. КРАТКИЕ ТЕОРЕТИЧЕСКИЕ СВЕДЕНИЯ Просмотр кода (англ. Code review) или инспекция кода(англ. code inspection) – систематическая проверка исходного кода программы с целью обнаружения и исправления ошибок, которые остались незамеченными в начальной фазе разработки. Целью просмотра является улучшение качества программного продукта и совершенствование навыков разработчика. В процессе инспекции кода могут быть найдены и устранены такие проблемы, как ошибки в форматировании строк, состояние гонки, утечка памяти и переполнение буфера, что улучшает безопасность программного продукта. Системы контроля версий дают возможность проведения совместной инспекции кода. Кроме того, существуют специальные инструментальные средства для совместной инспекции кода. Программное обеспечение для автоматизированной инспекции кода упрощает задачу просмотра больших кусков кода, систематически сканируя его на предмет обнаружения наиболее известных уязвимостей. В среде Github при работе с командами разработчиков программного обеспечения обычно при подготовке необходимо выполнить следующие действия: Добавить среду необходимых членов команды (организация и соавторы). Обеспечить возможность отправки версий и их слияния (Pull Requests). Обеспечить отслеживание ошибок (issues Github). Реализовать возможность комментариев к строками URLзапросов. Как правило, существует два способа настройки в Github для совместной работы необходимых членов команды: 1. Создание организаций. Владелец организации может создавать множество организаций с разными уровнями доступа для различных репозиториев. 2. Добавление сотрудников. Владелец репозитория может добавлять коллабораторов с доступом Read + Write для одного репозитория Создание организаций разработки. Если вы контролируете несколько команд и хотите установить разные уровни доступа для каждой команды с различными членами и добавить каждого участника в разные репозитории, то организация будет наилучшим вариантом. Любая учетная запись пользователя Github уже может создавать бесплатные организации для репозиториев с открытым исходным кодом. Чтобы создать организацию, необходимо перейти на страницу настроек своей организации: Рис.8.1Добавлениеорганизации Чтобы получить доступ к странице команд для вашей Организации, необходимо перейти на http://github.com/organizations/[organization-name]/teams, или для создания новых организаций – https://github.com/organizations/[organization-name]/teams/new. Для создаваемых команд возможны три уровня доступа: 1. Pull Only: выборка и слияние с другим репозиторием или локальной копией. Доступ только для чтения. 2. Push and Pull: – доступно обновлением удаленного репозитория. Читайте+ Запись. 3. Push, Pull & Administrative: (1), (2) добавляются права созданием команд, а также удаление аккаунтов организации. Чтение +запись + доступ администратора 4. Рис.8.2. Создание команд с различными уровнями доступа. Настройка отправки и слияния(PullRequests) Pull Requests –позволяет внести свой вклад в репозиторий, сделав его копию. Копия репозитария может быть отправлена (pullrequest) владельцу репозитория, чтобы объединить изменения кода. Сам pull request может включать обсуждение качества кода, функций или даже общей стратегии. В Github есть две модели для создания копии репозитория. Модель Fork & Pull – используется в общедоступном репозитории, на который у вас нет push-доступа Share Repository Model – используется в частном репозитории, на который у нас есть push-доступ. В этом случае форк не требуется. Здесь мы видим рабочий процесс между двумя пользователями (repo-owner и forked-repo-owner) для модели ForkandPull: Определите репозиторий Github, в который вы хотите внести свой вклад, и нажмите кнопку «Fork», чтобы создать клон репозитория в вашей собственной учетной записи Github. Рис.8.3Вызовкомандысозданиякопиирепозитария Это создаст точную копию репозитория в вашем собственном аккаунте. Рис.8.4 Содержание действий в создании копии репозитория 1$gitclone[ssh-url][foldername]2$cd [folder-name] Выберите URL-адрес SSH, чтобы он запрашивал вашу парольную кодовую фразу SSH вместо имени пользователя и пароля каждый раз, когда вы делаете git push или git pull. Затем мы будем клонировать этот репозиторий на наш локальный компьютер: Создадим новую ветку, чтобы внести очень простое изменение в файл readme.md : 1$gitcheckout-b[new-feature] После внесения соответствующих дополнений для создания новых функций мы просто передадим новые изменения и проверку в ветку gitmaster 1$gitadd. 2$ git commit -m «information added in readme»3$gitcheckoutmaster Перейдем на ветку с новой задачей, а также на псевдоним для удаленного репозитория. Затем мы будем пушить изменения с помощью gitpush[git-remote-alias][branch-name] : $gitbranch *master 1readme 2$gitremote-v 3origingit@github.com:[forked-repo-owner-username]/[reponame].git4(fetch) 5origingit@github.com:[forked-repo-owner-username]/[reponame].git6(push) 7$gitpushoriginreadme На исходной «развязанной» странице Github репозитория перейдем к ветке с новой функцией, а затем нажмите кнопку «PullRequest». После обсуждения возможно, что владелец «форкнутого» репозитория может захотеть добавить изменения в новую функцию. В этом случае мы выберем одну и ту же ветку на нашей локальной машине, зафиксируем ее и запушим ее обратно на Github. Когда мы заходим на страницу запроса в оригинальном репозитории, он будет автоматически обновляться. Обзор кода С каждой фиксацией изменений Github позволяет использовать чистый интерфейс для общих комментариев или даже конкретных комментариев к отдельной строчке кода. Возможность делать комментарии или задавать вопросы по каждой отдельной строке кода очень полезна при проведении обзоров строка за строкой. Чтобы просмотреть встроенные комментарии, установите флажок в верхней части каждой фиксации. Рис.8.5. Просмотр встроенных комментариев При обзоре кода могут быть использованы шаблоны URLадресов, они предоставляют возможность отслеживать различия между фиксациями. Шаблон сравнения веток–Comparebranches/tags/SHA1 https://github.com/[username]/[repo-name]/compare/[startingSHA1]...[ending-SHA1] . Рис.8.6 Шаблон сравнения веток Сравнение без пробелов: добавьте ? w=1 для сравнения URLадресов. Рис.8.7. Шаблон для сравнения адресов Diff: добавьте .diff к URL-адресам сравнения, чтобы получить информацию о git diff в текстовом формате. Это может быть полезно для сценариев. Существует другой вариант управления репозиториями. Осуществляется он при помощи IDE Visual Studio. Первое что нам потребуется сделать это создать проект в Visual Studio. В данной работе репозитории будут созданы и загружены на языке программирования С++, для своих репозиториев можете использовать любые другие языки программирования. Теперь стоит выбрать название проекта. Теперь пишем любой программный код Для создания и загрузки репозитория нужно на верхней панели выбрать и нажать Git и выбрать создание репозитория. Затем в открывшемся окне нужно авторизироваться в своём аккаунте на Github. Так же обязательно делаем ваш репозиторий общедоступным, снимая галочку с названия «Частный репозиторий» . Затем нажимаем кнопку «Создать и отправить», а так же сохраняем файлы проекта. После проделанного в левом нижнем углу может наблюдать следующее Это означает, что репозиторий создан локально и в ближайшее время будет отправлен в Github. Теперь перейдём в Github, чтобы посмотреть на содержимое проекта. Выбираем «Your repositories (твои репозитории)», чтобы посмотреть свои загруженные репозитории. Выбираем свой последний загруженный репозиторий, с которым и дальше будем работать. Открыв проект, мы можем посмотреть все файлы нашего проекта. Так же мы можем посмотреть способы скачивания репозитория из сервиса Github, нажав на зелёную кнопку «Code». Доступных способов есть несколько, но тут обсудим 4: 1. Открыть файл в приложении git, например, gitbash. 2. Открыть напрямую репозиторий в Visual Studio с помощью функции «клонирование репозитория». 3. Скачать весь проект архивом в формате ZIP. 4. Точно такой же как и 2 способ, копируем ссылку на наш репозиторий и клонируем его, им и воспользуемся. Для начала копируем ссылку на наш репозиторий, затем создаём второе окно в Visual Studio. При открытии второго окна в Visual Studio выберите пункт «клонирование репозитория» и затем вставить ссылку, которую мы скопировали ранее. При создании стоит учитывать пару моментов: 1. Если вы клонируете репозиторий, контрибьютером которого вы являетесь, то у вас не будет возникать никаких ошибок. 2. Если вы хотите как в данной работе клонировать свой собственный репозиторий, для того чтобы смоделировать ситуацию одновременной работы двух программистов, то нам следует поменять название пути. Для примера в описании «Путь» мой проект будет называться «Hello World2», для того чтобы не происходило конфликта поскольку тут будет происходить клонирование собственного локального репозитория. Теперь мы можем пользоваться своим же репозиторием со стороны 2 программиста и изменять его. Для начала стоит открыть программные файлы нашего файла в окне справа. Можете проверить работу файла, всё будет работать корректно, как и в изначальном файле. Теперь следует внести изменения со стороны 2 программиста. Создадим заголовочный файл Header.h и внесём изменения в файле main.cpp. Теперь для того чтобы 1 программист увидел изменения, которые сделал 2 программист нужно перейти во вкладку «изменения git» в правой части Visual Studio. Теперь, чтобы понимать что тут было сделано добавляем описание и нажимаем «зафиксировать всё» После того как мы зафиксировали изменения, то это было сохранено локально. А для того чтобы эти изменения были видны на Github нам потребуется найти на той же панели значок отправить и нажать на него ЛКМ. Теперь наши изменения добавлены на Github, и их можно посмотреть перейдя в Github и выбрав свой репозиторий. Там даже можно посмотреть какие изменения туда были внесены, так же это можно посмотреть в Visual Studio. Следующим шагом данной работы нужно выполнить возвращение к 1 окну Visual Studio. Так как мы моделируем ситуацию работы двух программистов, соответственно нам нужно посмотреть дошли ли наши изменения со стороны второго программиста до первого программиста. Для этого нужно во вкладке «изменения git» нажать на многоточие и выбрать «управление ветвями», тем самым мы открываем и смотрим журнал изменений нашего проекта. Открыв журнал мы не видим, что с нашим проектом произошли какие то изменения, кроме изначально загруженного проекта. Казалось бы, что это какая то ошибка, но на самом деле тут дело в том, что Visual Studio со стороны 1 программиста просто не знает какие изменения происходили за время его отсутствия. Для того чтобы их увидеть нам потребуется вытянуть все изменения нашего проекта. Чтобы это сделать, нужно в панели «изменения git» найти значок вытянуть и нажать на него, тогда все новые изменения будут добавлены в наш локальный репозиторий. Таким образом вы ознакомились с тем как добавлять и скачивать репозитории, даже если несколько программистов одновременно работают над одним и тем же проектом. Слияние проектов. У нас так же продолжается имитация работы двух программистов, но теперь будем моделировать ситуацию слияния двух проектов. Первым шагом переходим в первое окно Visual Studio, где делаем небольшие изменения, комментируем их, фиксируем и отправляем на Github. Далее переходим во второе окно Visual Studio, где добавляем строку перед вводом числа, и в заголовочном файле Header.h добавляем строку вывода нашего числа после цикла. Так же это всё комментируем, фиксируем и отправляем. И вот тут у нас появляется сбой при отправке В появившемся окошке написано, что локальная ветвь находится за удалённой ветвью. Это означает, что на удалённом репозитории появился коммит, который отсутствует у нас на компьютере и нам предлагают обновить ветвь. Если мы нажимаем «получить», то мы только получаем то самое изменение, которое у нас отсутствует и там может произойти автоматическое слияние, если изменение незначительное и внимание программиста не требуется. Если нажимаем получить, затем отправить, то мы получаем изменение, которое у нас отсутствует и пробуем отправить свои изменения на удалённую ветвь, но не факт что отправится и вот тут уже можно сделать слияние с участием программиста, какие изменения при слиянии будет учитывать сам программист. Это наш вариант. Как только нажимаем у нас происходит вытягивание ветви. При отправке репозитория возникли конфликты, потому что происходит слияние. Оно происходит автоматически в большинстве случаев, если изменение было незначительным. Но можно и вручную устранить конфликты при помощи редактора слияния. Если же изменение было значительным то перед слиянием ветвь отделяется, что можно посмотреть в журнале ветвей. Тут стоит обратить внимание на изменения. Те вещи, которые были изменены или удалены отмечены красным цветом. А те, которые были добавлены зелёным. После устранения ошибок и загрузки локальных репозиториев у нас получится ветвь, в которой будет ответвление из-за некоторых изменений. Лучше конечно делать подобную ситуацию с человеком, которого вы добавили в свои контрибьютеры. Но в данной работе пример был продемонстрирован на одном локальном компьютере, что более чем подходит для базового изучения владения ветвями. 3. ПОРЯДОК ВЫПОЛНЕНИЯ И ЗАДАНИЕ ДЛЯ РАБОТЫ 1. Создайте репозиторий на сервисе Github. 2. Создайте изменения в репозитории и отправьте его с помощью Visual Studio. 3. Посмотрите результаты ваших изменений в журнале git. 4. Смоделируйте ситуацию одновременной работы двух программистов 5. Задайте необходимые параметры для отправки и слияния копии репозитория. 4.КОНТРОЛЬНЫЕ ВОПРОСЫ 1. Какие действия необходимо выполнить чтобы подготовить среду разработки для инспекции кода? 2. Какие методы существуют для настройки Github для совместной работы нескольких разработчиков? 3. Что такое организация разработки в сервисе Github? 4. Какие уровни доступа могут быть заданы для организации в Github? 5. Какие параметры должны быть заданы при настройке отправки и слияния копии репозитория? 6. Какие модели применяются при создании копии репозито рия? 7. Что такое «обзор кода»?
