Как сделать коммит в visual studio

Обновлено: 05.07.2024

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

Также, в зависимости от ветки, в которую были внесены изменения, могут быть выполнены:

отправка сборки (вместе с changelog-ом) в один или несколько телеграм-каналов (иногда удобнее брать сборки оттуда).
публикация файлов в систему автообновления ПО.

Под катом о том, как мы научили Gitlab CI делать за нас бОльшую часть этой муторной работы.

Чтобы настроить Gitlab Runner, выполните следующие шаги:

Посмотрите токен для регистрации Runner-а. В зависимости от того, где будет доступен ваш Runner:

только в одном проекте — смотрите токен в меню проекта Settings >CI/CD в разделе Runners,
в группе проектов — смотрите токен в меню группы Settings >CI/CD в разделе Runners,
для всех проектов Gitlab-а — смотрите токен в секции администрирования, меню Overview >Runners.

Выполните регистрацию Runner-а, с помощью команды

Далее надо ввести ответы на вопросы мастера регистрации Runner-а:

В процессе соей работы Gitlab CI берёт инструкции о том, что делать в процессе сборки того или иного репозитория из файла .gitlab-ci.yml , который следует создать в корне репозитория.

И последнее: если нам требуется передавать в скрипт значение параметра, который мы не хотим хранить в самом скрипте (например, пароль для подключения куда-либо), мы можем использовать для этого объявление параметров в gitlab. Для этого зайдите в проекте (или в группе проекта) в Settings > CI/CD и найдите раздел Variables. Прописав в нём параметр с именем (key) SAMPLE_PARAMETER, вы сможете получить его значение в в скрипте .gitlab-ci.yml через обращение $env:SAMPLE_PARAMETER.
Также в этом разделе можно настроить передачу введенных параметров только при сборке защищённых веток (галочка Protected) и/или скрытие значения параметра из логов (галочка Masked).
Подробнее о параметрах окружения сборки смотрите в документации к Gitlab CI.

Скрипт, приведённый выше, уже можно использовать для сборки и вызова тестов. Правда, присутствует НО: крайне неудобно прописывать абсолютные пути к разным установкам Visual Studio. К примеру, если на одной билд-машине стоит Visual Studio 2017 BuildTools, а на другой Visual Studio Professional 2019, то такой скрипт будет работать только для одной из двух машин.

Дописываем переменную к секции Variables:

Затем создаём новую секцию before_msbuild якорем enter_vsdevshell и следующим текстом:

И всюду, где нам надо использовать утилиты Visual Studio, добавляем этот якорь. После этого задача сборки начинает выглядеть намного более опрятно:

Результат: мы имеем путь к vswhere.

Результат: в переменную $visualStudioPath записан путь к Visual Studio или пустая строка, если инсталляций Visual Studio не найдено (обработку этой ситуации мы ещё не добавили).

Команда Import-Module загружает библиотеку Microsoft.VisualStudio.DevShell.dll, в которой прописаны командлеты трансформации консоли Powershell в Developer-консоль. А командлет Join-Path формирует путь к этой библиотеке относительно пути установки Visual Studio.
На этом шаге нам прилетит ошибка, если библиотека Microsoft.VisualStudio.DevShell.dll отсутствует или путь к установке Visual Studio нужной редакции не был найден — Import-Module сообщит, что не может загрузить библиотеку.

Результат: загружен модуль Powershell с командлетом трансформации.

Результат: мы получили полноценную консоль Developer Powershell с прописанными путями к msbuild и многим другим утилитам, которые можноиспользовать при сборке.

Раньше мы использовали t4 шаблоны для проставления версий: номер версии собиралась из содержимого файла в формате . . , далее к ней добавлялся номер сборки из Gitlab CI и он передавался в tt-шаблон, добавляющий в решение везде, где требуется, номер версии. Однако некоторое время назад был найден более оптимальный способ — использование команд git tag и git describe .

Команда git tag устанавливает коммиту метку (тэг). Отметить таким образом можно любой коммит в любой момент времени. В отличие от веток, метка не меняется. То есть если после помеченного коммита вы добавите ещё один, метка останется на помеченном коммите. Если попробуете переписать отмеченный коммит командами git rebase или git commit --amend, метка также продолжит указывать на исходный коммит, а не на изменённый. Подробнее о метках смотрите в git book.

Команда git describe , к сожалению, в русскоязычном gitbook не описана. Но работает она примерно так: ищет ближайшего помеченного родителя текущего коммита. Если такого коммита нет — команда возвращает ошибку fatal: No tags can describe ' ' . А вот если помеченный коммит нашёлся — тогда команда возвращает строку, в которой участвует найденная метка, а также количество коммитов между помеченным и текущим.

Кстати, по этой же причине если вы используете gitflow, требуется после вливания feature-ветки в develop требуется удалить влитую локальную ветку, после чего пересоздать её от свежего develop:

(обратите внимание на историю git в левой части картинки: из-за отсутствия пути из текущего коммита до коммита с меткой 1.0.5, команда git describe выдаст неверный ответ)

Но вернёмся к автопроставлению версии. В нашем репозитории царит gitflow (точнее его rebase-версия), метки расставляются в ветке master и мы не занываем пересоздавать feature-ветки от develop, а также merge-ить master в develop после каждого релиза или хотфикса.

Тогда получить версию для любого коммита и сразу передать её в msbuild можно добавив всего пару строк к задаче сборки:

Как это работает:

Мы проставляем метки в формате . . .
Тогда git describe --long возвращает нам строку, описывающую версию в формате . . - -g .
Парсим полученную строку через регулярные выражения, выделяя нужные нам части — и записывем части в $versionGroup .
Преобразовываем четыре найденные подстроки в 4 числа и пишем их в переменные $major , $minor , $patch , $commit , после чего собираем из них строку уже в нужном нам формате.
Передаём указанную строку в msbuild чтобы он сам проставил версию файлов при сборке.

Обратите внимание: если вы, согласно gitflow, будете отмечать (тэгировать) ветку master после вливания в неё release или hofix, будьте внимательны: до простановки метки автосборка будет вестись относительно последней существующей ветки. Например, сейчас опубликована версия 3.4, а вы создаёте release-ветку для выпуска версии 3.5. Так вот: всё время существования этой ветки, а также после её вливания в master, но до простановки тэга, автосборка будет проставлять версию 3.4.

SonarQube — это мощный инструмент контроля качества кода.

SonarQube имеет бесплатную Community-версию, которая способна проводить полный анализ. Правда, только одной ветки. Чтобы настроить её на контроль качества ветки разработки (develop), требуется выполнить следующие шаги (разумеется, помимо установки и развёртывания сервера SonarQube):

Создайте в SonarQube новый проект, после чего запомнить его ключ.

Распакуйте содержимое архива в папку. Например, в C:\Tools\SonarScanner .

На заметку: эту утилиту также можно скачать на сборочную машину через NuGet, но тогда надо будет чуть по-иному указывать её путь.

Зайдите в параметры CI/CD в свойствах проекта в Gitlab следующие параметры:
- SONARQUBE_PROJECT_KEY — ключ проекта,
- SONARQUBE_AUTH_TOKEN — токен авторизации.

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

Допишите переменные к секции Variables:

Допишите в задачу тестирования ветки разработки (test_job) команды для запуска анализа кода и уберите зависимость от задачи build_job:

Теперь при каждой сборке ветки develop в SonarQube будет отправляться подробный анализ нашего кода.

На заметку: вообще команда msbuild /t:rebuild полностью пересобирает решение. Вероятно, в большинстве проектов анализ можно было бы встроить прямо в стадию сборки. Но сейчас у нас анализ в отдельной задаче.

Пара слов об использованных параметрах:

Со сборкой более-менее разобрались — теперь приступаем к тестам. Доработаем код прогона тестов, чтобы он:

сам находил библиотеки с тестами,
прогонял их пачкой через xUnit,
вычислял тестовое покрытие через OpenConver,
отправлял результаты покрытия тестами в SonarQube.

На заметку: обычно в паре с OpenCover используют ReportGenerator, но при наличии SonarQube мы с тем же успехом можем смотреть результаты через его интерфейс.

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

Скачайте OpenCover в виде zip-файла с сайта github.

Распакуйте содержимое архива в папку. Например, в C:\Tools\OpenCover .

Допишите переменные к секции Variables:

Модифицируйте задачу тестирования ветки разработки (test_job), чтобы она включала и команды вызова OpenCover:

Обратите внимание: в begin-команде запуска sonar scanner-а появился дополнительный параметр — /d:sonar.cs.opencover.reportsPaths .

(необязательный пункт) Ненадолго возврващаемся в Gitlab, заходим в меню проекта Settings >CI/CD и находим на странице настроек параметр Test coverage parsing . Указываем в нём регулярное выражение, которое позволит Gitlab-у также получать информацию о покрытии тестами приложения:
- если хочется видеть значение покрытия тестов по строкам кода (его ешё называют Sequence Coverage или Statement Coverage), указываем выражение ]+)>!> ,
- если хочется видеть значение покрытия тестов по веткам условных операторов (его называют Decision Coverage или Branch Coverage), указываем выражение \[!\[([^>]+)\]!\] .

А теперь комментарии по изменениям в скрипте.

Следующая строка — запуск утилиты OpenConver с передачей ей списка библиотек нашего приложения, фильтра, по которому OpenCover исключает из покрытия библиотеки с unit-тестами, а также часть классов, не требующих расчёта покрытия (например, AssemblyInfo). Конвейер и Write-Host были добавлены в порыве вдохновения, так как без него у нас не работал вывод OpenConver-а.

Если у вас появятся вопросы или предложения — пишите в комментариях.

И спасибо за прочтение!

Я пытаюсь перевести существующий проект под контроль исходников Git, но мне неясны несколько моментов.

Я создал 'Team Foundation Service' Git аккаунт онлайн.

Как мне перенести существующие файлы в онлайн-репозиторий?

Я поискал похожий вопрос - мне удалось инициализировать Git-репозиторий для существующего файла проекта следующим образом (отказ от ответственности: это делается в Visual Studio 2013 Express, без установки Team Foundation Server):

Откройте проект в Visual Studio.
Перейдите в меню File → Add to Source Control.

Это сделало это для меня - если Git настроен для вас, вы можете перейти в меню View → Team Explorer, затем дважды щелкнуть на хранилище для файла вашего проекта и сделать начальный коммит (не забудьте добавить любые файлы, которые вы хотите).

Прежде всего, необходимо установить программное обеспечение Git на локальной машине разработки, например, Git Extensions.
Затем выполните команду git init в папке решения. Это правильный способ создания папки репозитория.
Установите разумный файл .gitignore , чтобы не фиксировать ненужные вещи.
git add .
git commit
Добавьте нужный пульт, как описано в вашей учетной записи Team Foundation Server git remote add origin

В качестве альтернативы есть подробные руководства здесь по использованию интеграции с Visual Studio.

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

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

Во-первых, добавить его в систему управления версиями. Есть некоторые объяснения, что выше, и все это далеко.

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

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

Затем просто нажмите кнопку Синхронизация на следующем экране и поместите в пустой репозиторий GitHub URL-адрес. Убедитесь, что он'ы пуст или вы'll имеет основной ветви конфликтов и он выиграл'т давайте вы. Так что либо использовать новое хранилище или удалить старое, что вы уже облажались. Имейте в виду, что это видео&усилителя;усилитель; nbsp;студия&ампер;усилитель; nbsp;2013, так что ваш пробег может варьироваться.

Я могу переместить все изменения, используя функцию Visual Studio Переместить изменения из одной ветви в другую .

Есть способ перенести конкретный коммит?

Есть же отличный инструмент под венду для работы с гит - TortoiseGit. То как это реализовано в студии это мягко говоря не удобно. А так да, в вашем распоряжении три варианта merge, rebase, cherry-pick. Всё по ситуации

1 ответ 1

Допустим вы в ветке dev в правом нижнем углу кликаем по ветке и выбираем историю

В истории выбираем нужный коммит и прав.клик по нему -> View Commit Details

Далее переключаемся в ветку master или куда вы хотите перенести коммит

Теперь можно выбрать пункт cherry-pick

Спасибо, работает. Нюанс для тех кто работает в студии 2017 - вначале переключаемся на ветку master, затем открываем историю dev и в контекстном меню коммита выбираем "отбор"/"cherry-pick".

БлогNot. Как собрать проект C++ с github из исходников и подключить его к Visual Studio

Как собрать проект C++ с github из исходников и подключить его к Visual Studio

Благодаря менеджеру пакетов winget, уже входящему в актуальные сборки масдайки, теперь в Windows 10 можно инсталлировать приложения одной простой консольной командой (см. также доку от Микрософта).

Но мы рассмотрим сейчас ситуацию, когда у нас есть только ссылка на исходники проекта, скажем, на Гитхабе (возьмём для примера библиотеку для простых чисел primesieve) и нужно каким-то образом скомпилировать внешний проект в своей Studio, чтобы воспользоваться его возможностями в своём приложении.

В противном случае, конечно же, нестандартный include вроде этого, который вы нашли в коде-образце

работать не будет ни за что.

Первым делом скачаем все исходники внешнего проекта "как есть" в архиве .zip, для этого у нас на гитхабе есть кнопка "Download ZIP":

Как загрузить проект с github в архиве .zip

Развернём проект, не создавая новой папки, если у вашего архиватора нет такого же пункта меню, просто сотрите предлагаемое архиватором имя новой папки, потому что папка уже есть в архиве:

Извлечь внешний проект из архива, не создавая новой папки

Если покопаться в файле readme.md проекта, как правило, можно найти инструкцию по установке (Build instructions) и даже "Detailed build instructions", где говорится, в числе прочего, и о компиляции проекта под Microsoft Visual C++:

Команды cmake для компиляции проекта со страницы документации

Откроем свой "некомпилируемый" без нужной библиотеки проект в Studio (я использую актуальную сборку версии 2019) и обратимся к команде меню Вид - Терминал. Выберем инструмент "Командная строка разработчика" (по умолчанию в новых сборках теперь выбран PowerShell, впрочем, если в документации приведены команды PowerShell, то применяйте их).

У Микрософта инструмент описан вот здесь.

Командная строка разработчика в Studio

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

- теперь я в нужной папке, так как развернул свой архив в папку d:\temp

Далее как написано:

Можно просто копировать команды со страницы документации, в окне консоли вверху есть стандартная кнопочка "Вставить". А вот точка в записи команд имеет значение, это ссылка на текущую папку!

Ну и, конечно, для другой версии Studio будет другое указание компилятора, узнать своё можно командой

Нужный генератор будет помечен в списке "звёздочкой".

Теперь проект можно открывать в Studio и работать с ним, все нужные файлы есть в папке d:\temp\primesieve-master

Но мы хотим подключить всё, что нужно, к своему имеющемуся проекту, а не пытаться модифицировать чужую библиотеку.

Меню Проект - Свойства, слева выбираем Свойства конфигурации, C/C++, Общие, раскрываем поле "Дополнительные каталоги включаемых файлов", говорим "Изменить" и показываем на папку D:\Temp\primesieve-master\include . В вашем проекте, как правило, тоже будет вложенная папка include .
В том же окне выбираем Компоновщик - Общие - Дополнительные каталоги библиотек, "Изменить" и добавляем путь D:\Temp\primesieve-master\Release . Этого может оказаться мало, у вашего проекта и внешнего должны быть выбраны одинаковые конфигурации решения. Так как я выбрал Release для внешнего проекта, то и в своём проекте в списке "Конфигурации решения" (на стандартной панели инструментов) указал Release и платформу x64. Можно было работать и с Debug, но тогда и внешний проект компилируем как Debug и потом выбираем путь D:\Temp\primesieve-master\Debug .
В списке C/C++ - Создание кода - Библиотека времени выполнения выбрал Многопоточный DLL (/MD), иначе будет "LNK2038: обнаружено несоответствие для 'RuntimeLibrary': значение 'MT_StaticRelease' не соответствует значению 'MD_DynamicRelease' в file.obj".
Сам файл библиотеки, как правило имеющий тип .lib , тоже нужно прописать. Всё в том же окне свойства проекта выбираем список Компоновщик - Ввод, раскрываем список "Дополнительные зависимости", жмём "Изменить" и указываем в поле ввода имя файла библиотеки primesieve.lib
На всякий случай, проверяем, что у нас в списке Компоновщик - Система - Подсистема, у меня там просто Консоль (/SUBSYSTEM:CONSOLE) , для других типов проектов может понадобиться изменение и этой настройки.

После этого у меня всё заработало.

Ну а конкретная задача, на которой я проверял библиотеку - печать самых длинных цепочек последовательных простых чисел, в которых разница между соседними значениями строго возрастает или строго убывает, предел счёта равен 1000000, вот сама программа:

Ответы вышли такие:

За счёт хорошо оптимизированного кода библиотеки считается всё мгновенно.

Читайте также: