Assignee gitlab что это
Перейти к содержимому

Assignee gitlab что это

  • автор:

Assignee, approver, reviewer, oh my!

Picture of Horst Gutmann

Horst Gutmann, software engineer from Graz , Austria .

I’m working daily with GitLab and absolutely love it. When it comes to all the different roles that a person can have around issues and merge requests, though, I sometimes get confused and so I thought I’d finally write them down so that even I can remember:

Assignee

Each merge request and issue can have one or multiple users assigned to it. That assignment can change during the life-time of that item but in both contexts these are the people to contact if there are questions about that MR or issue.

Merge request author

In the context of merge requests there is also always an author. That’s the user that initially created the merge request. As far as I can tell, this attribute of an MR cannot be changed while assignees can.

Approver/Reviewers

A reviewer is someone who you want to review your merge request. Actually, you want that they approve your merge request which makes them an “approver”. That’s confusing… let’s work with a little example:

Let’s say you’re the maintainer of ProjectX. This means that whenever a new merge request is opened, you should be automatically assigned as reviewer so that nobody can merge it without you giving it an approval first!

To do that, you create an “approval rule” within your project that set the number of approvals required to “1” and add yourself to the list of “approvers”.

OK, but that only decides who’s approval is required for an MR. If you want to explicitly request a review from someone, you can now add them to a merge request as a “reviewer”. Once you are added to an MR as a reviewer, you can also find that request in the quick menu in GitLab’s top bar:

Screenshot of the GitLab top bar with expanded merge-request menu

Once you are a review of an MR, you can easily navigate to it using the top bar menu

Code owner

Related to approvers are code owners. These are defined inside the CODEOWNERS file within the repository and indicate which people are responsible for which part of the repository. GitLab can add these people to the required approvers if code that’s under their responsibility would be changed by a MR. This feature can be configured for protected branches.

I think that’s basically it for now. Personally, I think the whole approver vs. reviewer naming is a bit unfortunate but otherwise everything is pretty clear once you’ve understood what each role is there for ��

Do you want to give me feedback about this article in private? Please send it to comments@zerokspot.com.

Alternatively, this website also supports Webmentions. If you write a post on a blog that supports this technique, I should get notified about your link ��

Comments

If you have a Mastodon account, you can also leave a comment by replying to this status.

You can also find this post linked to from the following pages:

Creative Commons License

(cc) 2003-2023 Horst Gutmann | /feeds

If not otherwise stated this work is licensed under a Creative Commons Attribution-Share Alike 3.0 Austria License.
The source code of this site is available on GitHub. The primary font used here is Liberation Mono by Red Hat.

gitlab merge request. Who is the assignee?

There is one particular point I don’t understand for GitLab’s merge requests.

I cloned a repository and made a feature branch. I worked something on it, committed it, and pushed the new branch to my GitLab repo.

With that I can make a merge request. When I do it says:

Assignee (and Assign to me)

Who should I assign it to? I mean, if I assign it to me, it is going to be me who "reviews" the change and approves it, so what is the point?

Or should I assign it to the repository administrator? Or to other member reviewers, so that they can check that and approve the merge?

What is the "Assign to me" option, and how does that makes sense?

karel's user avatar

2 Answers 2

There is documentation for that. It states:

This person owns the merge request, but isn’t responsible for reviewing it.

Additionally, the documentation explains an exemplary merge request workflow. You would typically create the MR before working on your feature branch. Then you can use the Assign to me feature to indicate that you are the one currently working on implementing the features of the MR. After your work is done you can request approval from a reviewer by assigning the MR to them (see Step 7 in the MR flow).

The people who are assigned to a merge request are the people who are responsible for it, not in a review kind of sense.
Usually it is the person who creates the pull request who counts as responsible for it i.e. has the responsibility of merging when all reviewers are happy and have approved or making changes according to the reviewers comments.

However, multiple people can have this responsibility as it is not always prudent for this to rest on a single person (what if the person goes on vacation?). Another case is if multiple developers have been working on the same feature and therefor have shared responsibility for the code in the merge request.

TL;DR Multiple people can have responsibility / can be accountable for the merge request.

    The Overflow Blog
Related

Most asked in [gitlab]

Hot Network Questions

Subscribe to RSS

To subscribe to this RSS feed, copy and paste this URL into your RSS reader.

Site design / logo © 2023 Stack Exchange Inc; user contributions licensed under CC BY-SA . rev 2023.3.11.43304

By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.

Name already in use

gitlabhq / doc / user / project / merge_requests / index.md

  • Go to file T
  • Go to line L
  • Copy path
  • Copy permalink
  • Open with Desktop
  • View raw
  • Copy raw contents Copy raw contents

Copy raw contents

Copy raw contents

Merge requests (FREE)

To incorporate changes from a source branch to a target branch, you use a merge request (MR).

When you open a merge request, you can visualize and collaborate on the changes before merge. Merge requests include:

  • A description of the request.
  • Code changes and inline code reviews.
  • Information about CI/CD pipelines.
  • A comment section for discussion threads.
  • The list of commits.

For a quick overview of merge requests, view this GitLab Flow video.

Create a merge request

Learn the various ways to create a merge request.

View merge requests

You can view merge requests for your project, group, or yourself.

View merge requests for a project

To view all merge requests for a project:

  1. On the top bar, select Main menu > Projects and find your project.
  2. On the left sidebar, select Merge requests.

Or, to use a keyboard shortcut, press g + m .

View merge requests for all projects in a group

To view merge requests for all projects in a group:

  1. On the top bar, select Main menu > Groups and find your group.
  2. On the left sidebar, select Merge requests.

If your group contains subgroups, this view also displays merge requests from the subgroup projects.

View all merge requests assigned to you

To view all merge requests assigned to you:

  1. On the top bar, put your cursor in the Search box.
  2. From the dropdown list, select Merge requests assigned to me.
  • To use a keyboard shortcut, press Shift + m .
  1. On the top bar, in the upper-right corner, select Merge requests ( ).
  2. From the dropdown list, select Assigned to you.

Filter the list of merge requests

  • Filtering by approved-by introduced in GitLab 13.0.
  • Filtering by reviewer introduced in GitLab 13.7.
  • Filtering by potential approvers was moved to GitLab Premium in 13.9.
  • Filtering by approved-by moved to GitLab Premium in 13.9.

To filter the list of merge requests:

  1. Above the list of merge requests, select Search or filter results. .
  2. From the dropdown list, select the attribute you wish to filter by. Some examples:
      .
    • ID: Enter filter #30 to return only merge request 30.
    • User filters: Type (or select from the dropdown list) any of these filters to display a list of users:
      • Approved-By, for merge requests already approved by a user. (PREMIUM).
      • Approver, for merge requests that this user is eligible to approve. (For more information, read about Code owners). (PREMIUM)
      • Reviewer, for merge requests reviewed by this user.
  3. Select or type the operator to use for filtering the attribute. The following operators are available:
    • = : Is
    • != : Is not
  4. Enter the text to filter the attribute by. You can filter some attributes by None or Any.
  5. Repeat this process to filter by multiple attributes. Multiple attributes are joined by a logical AND .
  6. Select a Sort direction, either for descending order, or for ascending order.

GitLab displays the results on-screen, but you can also retrieve them as an RSS feed.

Filter merge requests by environment or deployment date

To filter merge requests by deployment data, such as the environment or a date, you can type (or select from the dropdown list) the following:

  • Environment
  • Deployed-before
  • Deployed-after

NOTE: Projects using a fast-forward merge method do not return results, as this method does not create a merge commit.

When filtering by an environment, a dropdown list presents all environments that you can choose from:

Filter MRs by their environment

When filtering by Deployed-before or Deployed-after , the date refers to when the deployment to an environment (triggered by the merge commit) completed successfully. You must enter the deploy date manually. Deploy dates use the format YYYY-MM-DD , and must be quoted if you wish to specify both a date and time ( «YYYY-MM-DD HH:MM» ):

Filter MRs by a deploy date

Add changes to a merge request

If you have permission to add changes to a merge request, you can add your changes to an existing merge request in several ways, depending on the complexity of your change and whether you need access to a development environment:

    in your browser with the . keyboard shortcut. Use this browser-based method to edit multiple files, or if you are not comfortable with Git commands. You cannot run tests from the Web IDE. , if you need a fully-featured environment to both edit files, and run tests afterward. Gitpod supports running the GitLab Development Kit (GDK). To use Gitpod, you must enable Gitpod in your user account. , if you are familiar with Git and the command line.

Assign a user to a merge request

To assign the merge request to a user, use the /assign @user quick action in a text area in a merge request, or:

  1. On the top bar, select Main menu > Projects and find your project.
  2. On the left sidebar, select Merge requests and find your merge request.
  3. On the right sidebar, expand the right sidebar and locate the Assignees section.
  4. Select Edit.
  5. Search for the user you want to assign, and select the user.

The merge request is added to the user’s assigned merge request list.

Assign multiple users (PREMIUM)

Moved to GitLab Premium in 13.9.

GitLab enables multiple assignees for merge requests, if multiple people are accountable for it:

multiple assignees for merge requests sidebar

To assign multiple assignees to a merge request, use the /assign @user quick action in a text area, or:

  1. On the top bar, select Main menu > Projects and find your project.
  2. On the left sidebar, select Merge requests and find your merge request.
  3. On the right sidebar, expand the right sidebar and locate the Assignees section.
  4. Select Edit and, from the dropdown list, select all users you want to assign the merge request to.

To remove an assignee, clear the user from the same dropdown list.

Close a merge request

If you decide to permanently stop work on a merge request, GitLab recommends you close the merge request rather than delete it. The author and assignees of a merge request, and users with Developer, Maintainer, or Owner roles in a project can close merge requests in the project:

  1. Go to the merge request you want to close.
  2. Scroll to the comment box at the bottom of the page.
  3. Following the comment box, select Close merge request.

GitLab closes the merge request, but preserves records of the merge request, its comments, and any associated pipelines.

Delete a merge request

GitLab recommends you close, rather than delete, merge requests.

WARNING: You cannot undo the deletion of a merge request.

To delete a merge request:

  1. Sign in to GitLab as a user with the project Owner role. Only users with this role can delete merge requests in a project.
  2. Go to the merge request you want to delete, and select Edit.
  3. Scroll to the bottom of the page, and select Delete merge request.

Delete the source branch on merge

You can delete the source branch for a merge request:

  • When you create a merge request, by selecting Delete source branch when merge request accepted.
  • When you merge a merge request, if you have the Maintainer role, by selecting Delete source branch.

An administrator can make this option the default in the project’s settings.

Update merge requests when target branch merges (FREE SELF)

    in GitLab 13.9. in GitLab 13.9. GitLab 13.10.

Merge requests are often chained together, with one merge request depending on the code added or changed in another merge request. To support keeping individual merge requests small, GitLab can update up to four open merge requests when their target branch merges into main . For example:

  • Merge request 1: merge feature-alpha into main .
  • Merge request 2: merge feature-beta into feature-alpha .

If these merge requests are open at the same time, and merge request 1 ( feature-alpha ) merges into main , GitLab updates the destination of merge request 2 from feature-alpha to main .

Merge requests with interconnected content updates are usually handled in one of these ways:

  • Merge request 1 is merged into main first. Merge request 2 is then retargeted to main .
  • Merge request 2 is merged into feature-alpha . The updated merge request 1, which now contains the contents of feature-alpha and feature-beta , is merged into main .

This feature works only when a merge request is merged. Selecting Remove source branch after merging does not retarget open merge requests. This improvement is proposed as a follow-up.

Move sidebar actions

Introduced in GitLab 14.10 with a flag named moved_mr_sidebar . Disabled by default.

FLAG: On self-managed GitLab, by default this feature is not available. To make it available per project or for your entire instance, ask an administrator to enable the feature flag named moved_mr_sidebar . On GitLab.com, this feature is enabled in the following projects: gitlab-org/gitlab , gitlab-com/www-gitlab-com , and gitlab-org/customers-gitlab-com .

When this feature flag is enabled, in the upper-right corner, Merge request actions ( ) contains the following actions:

  • The notifications toggle
  • Mark merge request as ready or draft
  • Close merge request
  • Copy reference

When this feature flag is disabled, these actions are in the right sidebar.

Merge request workflows

For a software developer working in a team:

  1. You check out a new branch, and submit your changes through a merge request.
  2. You gather feedback from your team.
  3. You work on the implementation optimizing code with Code Quality reports.
  4. You verify your changes with Unit test reports in GitLab CI/CD.
  5. You avoid using dependencies whose license is not compatible with your project with License Compliance reports.
  6. You request the approval from your manager.
  7. Your manager:
    1. Pushes a commit with their final review. .
    2. Sets it to merge when pipeline succeeds.

    For a web developer writing a webpage for your company’s website:

    1. You check out a new branch and submit a new page through a merge request.
    2. You gather feedback from your reviewers.
    3. You preview your changes with Review Apps.
    4. You request your web designers for their implementation.
    5. You request the approval from your manager.
    6. Once approved, your merge request is squashed and merged, and deployed to staging with GitLab Pages.
    7. Your production team cherry-picks the merge commit into production.

    Rebase a merge request from the Rails console (FREE SELF)

    In addition to the /rebase quick action, users with access to the Rails console can rebase a merge request from the Rails console. Replace <username> , <namespace/project> , and <iid> with appropriate values:

    WARNING: Any command that changes data directly could be damaging if not run correctly, or under the right conditions. We highly recommend running them in a test environment with a backup of the instance ready to be restored, just in case.

    Fix incorrect merge request status (FREE SELF)

    If a merge request remains Open after its changes are merged, users with access to the Rails console can correct the merge request’s status. Replace <username> , <namespace/project> , and <iid> with appropriate values:

    WARNING: Any command that changes data directly could be damaging if not run correctly, or under the right conditions. We highly recommend running them in a test environment with a backup of the instance ready to be restored, just in case.

    Running this command against a merge request with unmerged changes causes the merge request to display an incorrect message: merged into <branch-name> .

    Close a merge request from the Rails console (FREE SELF)

    If closing a merge request doesn’t work through the UI or API, you may want to attempt to close it in a Rails console session:

    WARNING: Commands that change data can cause damage if not run correctly or under the right conditions. Always run commands in a test environment first and have a backup instance ready to restore.

    Delete a merge request from the Rails console (FREE SELF)

    If deleting a merge request doesn’t work through the UI or API, you may want to attempt to delete it in a Rails console session:

    WARNING: Any command that changes data directly could be damaging if not run correctly, or under the right conditions. We highly recommend running them in a test environment with a backup of the instance ready to be restored, just in case.

    GitLab для начинающих: зачем он нужен в мире, где есть GitHub

    GitLab для начинающих: зачем он нужен в мире, где есть GitHub главное изображение

    Статья рассчитана на читателей, которые уже хотя бы немного знакомы с Git. Изучить основы работы с системой контроля версий можно бесплатно в большом курсе Хекслета.

    Что такое GitLab и зачем он нужен

    GitLab — сервис для хранения и управления Git-репозиториями. Как и его более известный конкурент, GitHub, он значительно облегчает коллективный труд разработчиков, позволяя им писать и редактировать код, а также его тестировать и развертывать без лишних проблем.

    Работать с GitLab можно по-разному: как через командную строку, Web IDE (встроенный IDE для работы в браузере), так и через сторонние Git-клиенты. Скажем сразу, правильного способа нет: каждый работает, как ему удобно, в зависимости от задач и доступных устройств.

    GitLab vs GitHub

    Существенных различий между GitLab и GitHub на самом деле практически нет. Разве что:

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

    С 2018 года владельцем GitHub является компания Microsoft, что, учитывая репутацию этого гиганта, было воспринято сообществом неоднозначно. Тем не менее популярность GitHub выше, чем у GitLab: у платформы не было конкурентов с 2008 года. О GitLab тогда еще мало кто знал — он появился только в 2011 году, а активно развиваться начал далеко не сразу.

    Что выбрать начинающему разработчику?

    Оба сервиса хорошо справляются с большинством задач разработки, однако:

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

    А вот для веб-разработки подойдут оба проекта: для этих целей у обоих есть свои Pages. Держите ссылки на них для GitLab и для GitHub.

    Читайте также: Как правильно составлять описания коммитов и почему это важно

    Ключевые особенности GitLab

    • Совместимость. Гитлаб поддерживает интеграцию с популярными платформами и сервисами — Docker, Kubernetes, Jira, сервисы от Google, а также имеет инструментарий для совмещения практически с любыми приложениями. Это означает, что GitLab может быть легко интегрирован и в корпоративную среду.
    • Метки и документация. Удобная система меток, которая значительно упрощает процесс разработки, позволяя классифицировать ошибки или запросы. Также с ее помощью можно отслеживать изменения, выполняемые по своим или чужим проектам. Система документации на Гитлабе выстроена так, что каждый проект документируется в отдельном репозитории.
    • Гибкие настройки доступа. Доступ к репозиториям настраивается в соответствии с группой, в которой находится пользователь. Закрытые ветки создаются с использованием встроенного модуля, который позволяет настраивать права для каждого пользователя. И благодаря собственной системе защиты от киберугроз GitLab предлагает безопасную аутентификацию.
    • Удобный импорт и экспорт данных. Сервис позволяет легко импортировать большие объемы данных из разных источников. Это обеспечивается за счет интеграции с популярными решениями, например, Jira. Также пользователям доступны инструменты для синхронизации кода.
    • Kubernetes по умолчанию для развертывания. Удобное решение для тех, кто занимается разработкой и тестированием приложений, поскольку Kubernetes — самый популярный оркестратор в среде контейнеризации.
    • Выделенное пространство в облаке. GitLab предлагает всем пользователям бесплатное размещение проектов в облаке. Кроме того, в GitLab можно бесплатно создавать частные репозитории для хранения открытого кода.
    • Инструменты аналитики и планирования. Аналитические инструменты Гитлаба позволяют отслеживать время, затраченное на каждую задачу, планировать дальнейшую работу, отслеживать активность каждого разработчика. А инструмент Burndown Chart понравится тем, кто использует в разработке метод спринтов.
    • Регулярные обновления. Гитлаб обновляется каждый месяц, причем значительное внимание уделяется удобству и безопасности работы.

    GitLab Runner

    GitLab Runner — полезный веб-инструмент для выполнения инструкций файлов репозиториев. Устанавливать GitLab Runner необходимо тем, кто собирается выполнять настройку CI/CD собственного проекта. Но в первую очередь нужно установить Docker — платформу контейнеризации, с помощью которой выполняется создание образов и развертывание контейнеров.

    GitLab CI/CD

    CI/CD — технология непрерывной интеграции и доставки. CI/CD помогает автоматизировать и масштабировать проекты, что значительно сокращает время разработки. GitLab CI/CD — инструмент, который позволяет превратить Гитлаб в полноценную платформу для DevOps со всеми необходимыми функциями.

    GitLab CI/CD обеспечивает управление конфигурациями через yaml-файлы, стабильный запуск в различных средах, сборку и выполнение в разных операционных системах. Кроме того, с помощью этого инструмента можно выполнять интеграцию с кластерами Kubernetes и работать с задачами в окружениях Docker.

    Дальше мы предсказуемо сравним GitLab CI/CD со схожим по функциям инструментом Гитхаба — GitHub Actions.

    GitLab CI/CD vs GitHub Actions

    Чтобы при переходе с GitHub Actions на GitLab CI/CD у новичка не возникло трудностей, рассмотрим основные различия между этими инструментами.

    1. В CI/CD скрипты в заданиях выполняются с помощью ключа script , а в Actions для этого используется ключ run .
    2. Задания на разных платформах в CI/CD выполняются с помощью ключа tags , а в Actions — с помощью runs-on .
    3. Оба инструмента могут работать с заданиями в образах Docker, а также указывать дополнительные контейнеры, для чего в CI/CD используется ключ image , а Actions — container .
    4. При выполнении заданий с условиями CI/CD использует ключ rules , а Actions — if .
    5. Для выполнения заданий с зависимостями в CI/CD есть ключ stages , а в Actions используется needs .

    Посмотреть примеры кода для каждого сервиса, а также узнать о некоторых менее существенных расхождениях можно в официальной документации GitHub по этой теме. И, хотя инструкция называется «Миграция с GitLab CI/CD на GitHub Actions», она подойдет и при переходе с Actions на CI/CD.

    Читайте также: Как присоединиться к работе над опенсорсом, что такое PS1 и другие вопросы: отвечает разработчик Хекслета Андрей Мошков

    Немного практики: первый проект на GitLab

    Чтобы создать проект на GitLab, нужно выполнить несколько несложных шагов:

    • Создать учетную запись и рабочую группу
    • Создать репозиторий
    • Загрузить файлы
    • Добавить ключи авторизации.

    Теперь о каждом из этих шагов подробнее.

    Создание учетной записи и рабочей группы на GitLab

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

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

    Создание репозитория в GitLab

    После создания группы в верхней панели появится иконка с плюсиком: кликните на выпадающее меню рядом и выберите пункт New project или New project/repository . Далее выбираем уровень приватности. Если не хотите, чтобы ваш код был виден другим пользователям и вообще никому, кроме вас, выберите из выпадающего меню уровень Private . Теперь можно приступать к загрузке файлов в репозиторий Git, который будет сформирован вместе с проектом.

    Загрузка файлов в GitLab

    Файлы загружаются одним из трех способов:

    • Через веб-интерфейс нажатием на кнопку Upload File
    • Через командную строку при помощи программы git
    • Через сторонний Git-клиент, например, Sublime Merge или Tower.

    Можно также использовать и Web IDE, предназначенный для работы в браузере.

    Добавление ключей авторизации

    Для генерации ключа понадобится ввести в терминале команду ssh-keygen , при этом директорию, где будут храниться ключи, можно оставить по умолчанию. Далее сервис предложит ввести пароль, а затем скопировать ключ из папки (его можно узнать по расширению .pub) и вставить его на сайте GitLab: нажмите на пункт SSH-keys в меню слева. Узнать больше об установке Git вы можете, изучив наши инструкции.

    Дальнейшая работа

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

    • Для создания новой ветки перейдите в репозиторий, откройте уже знакомое по внешнему виду меню с плюсиком и выберите пункт New Branch . Те, кто пользуется git-клиентами, могут сделать то же самое командой git checkout или с помощью графического интерфейса
    • Для объединения веток проекта в одну (этот процесс называется мерджинг или слияние) нажмите на кнопку Create merge request и заполните необходимые поля. Потребуется написать поясняющий комментарий, указать автора запроса, проверяющего и поставить теги, после чего подтвердить слияние
    • Добавление новых пользователей осуществляется через левое меню. Выберите там Project information и далее Members . В открывшейся форме, помимо ника и электронной почты, укажите роль пользователя и дату, когда срок действия его прав истечет, и он будет исключен из проекта. Это время всегда можно продлить.
    • Для оповещений коллег и пользователей о каких-либо проблемах — чаще всего это баги или ошибки, — выберите в левом меню пункт Issues . Далее по клику на кнопку New Issue , откроется форма, где нужно будет указать название и добавить описание проблемы, а также назначить ответственного — Assignee .

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

    Похожие публикации:
    1. Как закрепить эксель поверх всех окон
    2. Как подключить систему 5 1 к телевизору
    3. Как подключиться к серверу в локальной сети
    4. Как сделать qr код на вордовский документ

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *