Issue что это в программировании

Вы отправили слишком много запросов, поэтому ваш компьютер был заблокирован.

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

В чем разница между issue и bug в тестировании?

На работе разработчики не раз мне говорят «это не bug, а issue» , я им утверждаю, что баг — это несоответствие. Если есть маленькая опечатка в тексте — это все равно баг, если программа выглядит не так, как должна выглядеть по спецификации, это баг. Мало того, любое несоответствие записывается в багтрекерной системе как баг.

Тестировщики, какое слово вы чаще используете на работе и какая разница между багом и ишью?

• Вопрос задан более трёх лет назад
• 7560 просмотров

3 комментария

Оценить 3 комментария

Называйте оба варианта фичей и будет вам счастье)))

«это не bug, а issue» например, в тз написано, что программа должны в портретной ориентации быть, а разработчик сделал и в портретной и горизонтальной,
тогда это вообще фича!

Cherry @ValentynaV Автор вопроса

Дмитрий Земсков: баг — это несоответствие актуального поведения программы с ожидающим. (это каждый тестировщик знает). В тз приписано, что ориентация должна быть такой-то, а получаем другое, вот и несоответствие. А вы тестировщик?

Решения вопроса 0
Ответы на вопрос 5

Программист

Баг — это когда вместо скидки к цене делается надбавка. А ишью — это когда у цены со скидкой слишком много цифр после запятой и она не влазит в отведенный ей контрол.

Ответ написан более трёх лет назад
Нравится 4 1 комментарий

А если цена со скидкой и слишком большим количеством цифр выравнивается по центру контейнера с overflow:hidden фиксированной длины и из-за этого пользователь не может увидеть итоговую цену?

Issue — это боль пользователя, которую он описал.
Например, пользователь забыл пароль, а система восстановления пароля не работает.
Пользователь заводит Issue, т. е. проблему, которую QA должен воспроизвести и перевести в задачу для разработчиков.

Bug — это дефект, который был обнаружен QA в процессе тестирования.

Ещё раз.
Баг — такого слова нет, есть дефект.
Любое несоответствие между работающей системой и ТЗ — это дефект.

Issue — это проблема конечного пользователя.

Ответ написан более трёх лет назад
Нравится 1 4 комментария
Cherry @ValentynaV Автор вопроса

Спасибо за ответ!! Нашла еще такое:

Bug — Any problem in existing functionality, or missing functionality. Defect in code or requirement, error which is not designed to be.

Issue (Impediment) — Any problem which might block the development process, example : a third party driver you identified as dependency is not releasing on time, so it is an issue in your development process.

Task — Any work which is planned as part of development of your project, either as result of bug, or issue or requirements, including requirement analysis or development, or testing. etc.

Cherry @ValentynaV Автор вопроса
Cherry @ValentynaV Автор вопроса

С прочитанной статьи я поняла, что ишью это когда нет проблем в коде. Например, заказчик хотел портретную ориентацию, разработчик сделал и портретную и горизонтальную, но все же работает.
Даже не знаю, какой документ взять за пример «моим» разработчикам. А то все называют ишью, в том числе неправильно написанный текст (хотя в minor bug и включают грамматические ошибки)

D’ @Denormalization

Cherry: есть проблема в понимании слова «bug» между разработчиками и QA.
Для разработчика «bug» — это что-то из разряда «всёпиздецконецсвета». Всё остальное это не баг, а фича.

xmoonlight @xmoonlight
https://sitecoder.blogspot.com

Bug — это невыполнение требований ТЗ или несоответствие реальных данных ожидаемым при тестировании продукта тест-кейсом.
Issue — это проблемы, выявленные тестером на любом этапе тестирования, не являющихся отклонениями для ожидаемых результатов во всех предыдущих тест-кейсах.
Производится принятие решение рабочей проектной группой: закрыть, нивелировать до низшего приоритета (оставить на потом), или превратить в Bug.
Всё остальное — это не баг.

Ответ написан более трёх лет назад
Cherry @ValentynaV Автор вопроса

Не соглашусь. Во-первых, далеко не всегда заказчик дает ТЗ. Во-вторых, заказчик не может знать все нюансы удобства пользования (если неправильно ввести что-то в поле или ничего не заполнить и кликнуть «ок» кнопку, выдается сообщение об ошибке). В-третьих, есть гайдлайны. А вы тестировщик? Так как меня интересует мнение опытных тестировщиков (но всеравно спасибо, что обратили внимание на мой вопрос). Я проходила курсы Портнова, человека, который создал школу тестировщиков в Америке, и как-то странно, когда мне разработчики говорят, это не баг. Есть баг удобства (в том числе, если при заполнении поля имейл не вылезает соответствующая клавиатура девайса), часто это записывается с приоритетом «minor», но все же, это баг.

xmoonlight @xmoonlight

Cherry: Валентина, еще раз давайте разберём на простом примере.
Вы заказали обычный чёрный фонарь с инструкцией (это Ваши требования или ТЗ).
Вам привезли товар и по факту вы получаете:
1. Фонарь светит красным — это баг.
2. Цвет корпуса фонаря зелёный (вместо ожидаемого чёрного) — это тоже баг.
3. Инструкция на жёлтой бумаге, вместо белой — это не баг.
Согласны?

Cherry @ValentynaV Автор вопроса

xmoonlight: для меня да, баг удобства) так как покупатель ожидает, что инструкция будет на белой бумаге, как всегда, а желтая вызывает подозрение о качестве продукции.
Так вы тестировщик?

Как работать в Jira

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

Что такое Jira?

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

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

Название, кстати, происходит от японского слова Gojira, что переводится как «Годзилла».

Что такое канбан/скрам-доска?

Канбан – это методика планирования задач, разработанная в сороковых годах. Суть канбан-доски заключается в наглядном расположении задач в соответствии с их статусом. Типичная доска делится на 3 колонки:

1. Задачи, которые необходимо выполнить (обычный to-do-лист).
2. Задачи, которые в текущий момент находятся в работе.
3. Задачи, которые уже выполнены и висят на доске исключительно для отслеживания прогресса.

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

Скрам-доска – это канбан-доска для разработчиков, исповедующих Agile. Ее обычно дополняют колонками с заданиями на проверке и с отложенными делами.

Что такое Agile-разработка?

Agile – это методика организации рабочего процесса, подразумевающая деление больших целей на мелкие, легко «перевариваемые» задачи и выполняющиеся в период спринтов (то есть недельных забегов активной работы).

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

Перед тем как начать работу с Jira, стоит ознакомиться с основными принципами канбан и Agile подробнее.

Комьюнити теперь в Телеграм
Подпишитесь и будьте в курсе последних IT-новостей

Для чего используют Jira?

Как я уже сказал ранее, разного рода канбан-инструменты можно адаптировать под любые виды планирования и менеджмента – под персональные и командные. Но с Jira все складывается немного иначе.

Эту программу создавали для программистов. «Затачивали» каждый аспект под нужды разработчиков. Поэтому работает и выглядит она иначе. Не слишком универсально. В связи с этим вырос ряд конкретных сценариев, в которых применяется JIRA:

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

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

Алгоритм работы с Jira

Процесс работы с Jira можно разложить на 6 простых шагов:

1. Для начала нужно загрузить Jira, создать профиль и запустить утилиту. Можно использовать аккаунты Apple и Google.
2. В окне приложения необходимо выбрать пункт Create Project.
3. Программа предложит список шаблонов для доски с задачами (для разработчиков, для маркетологов и т.п.). Выбираем ту, что лучше всего соответствует целям команды и стилю работы в вашей компании.
4. Затем Jira задаст пару вопросов по поводу того, пользовались ли вы ранее Agile и канбан. На основе ответов программой будет принято решение о целесообразности внедрения обучения в интерфейс.
5. Настраиваем колонки под своим нужды (если то, что было предложено в шаблоне, не на 100% удовлетворяет вашим требованиям).
6. Создаем задачу (пункт Create).
7. Приглашаем других пользователей (то есть членов команды) работать с созданной вами доской (пункт Invite).

Как устроена Jira?

Далее разберем основные компоненты Jira. Из чего состоит интерфейс, как создавать задачи, где и какую информацию искать.

Интерфейс

Интерфейс Jira делится на несколько ключевых вкладок. Во вкладке «Projects» хранятся все канбан/скрам-доски, которые вы можете просматривать или редактировать. Фактически это основное рабочее пространство. Здесь же можно перейти в режим отслеживания релизов продукта, взглянуть на все активные спринты, проанализировать отчеты о проделанной работе и т.п.

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

Задачи

Задачи в оригинале называются Issues, что можно перевести как «проблемы». Issue – это единица информации. В нее закладывается либо какая-то функция, которую нужно реализовать, либо ошибка в программе, которую необходимо исправить.

Issues – это составные части проекта и спринта. Именно список задач формирует рабочий процесс. Поэтому он и состоит из создания задач, наблюдения за ними, выполнения, анализа, дополнения, изменения и т.п.

Типы задач

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

Выбор типа задач зависит от целей команды и компании. Можно создавать свои типы для удобного распределения, фильтрации и поиска задач. Соответствующий раздел настроек находится в Project settings.

Дорожная карта (расписание)

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

К примеру, если есть ряд новых функций для приложения, которые совместно формируют какую-то общую важную особенность ПО, то их объединяют в эпик как некую общую цель, к которой стремится команда в ходе спринта (или нескольких спринтов).

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

Релизы

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

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

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

Код и деплой

Одно из преимуществ Jira – возможность тесно интегрировать ее с другими продуктами, например с платформами Bitbucket, Github и Gitlab.

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

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

Pages

Еще одна разработка Atlassian – проект Confluence. Это что-то в духе Google Docs, только работающее в рамках Jira и менее функциональное.

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

В Pages по умолчанию есть несколько шаблонов для текста:

• Пустая страница с небольшим описанием функциональности Pages.
• Страница для описания продукта. Сюда можно вписать, как продукт выглядит в глаза клиента и что он в итоге должен собой представлять.
• Тестовая форма для указания глобальных целей компании с целью донести ее до команды и сподвигнуть к обсуждению дальнейших действий.
• Форма для заполнения расписания встреч и создания заметок по ходу общения с коллегами.
• Ретроспективная заметка с описанием проделанной работы. Здесь лидер команды указывает, что в ходе работы пошло хорошо, что пошло не очень и т.п.

Дашборды

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

Дашборды позволяют собрать все необходимые данные в одно пространство без необходимости следить за процессом работы команды и фиксировать какие-то значимые аспекты, чтобы потом вручную делать аналитические сводки. В Jira можно формировать дашборды автоматически.

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

Плагины

Jira можно сделать еще функциональнее, если подключить к ней плагины сторонних компаний.

Некоторые из них продвигает сама Atlassian. В их числе интеграция с Git-системами, к примеру. Это один из наиболее распространенных и очевидных вариантов использования плагинов.

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

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

Коллекция плагинов в Atlassian Marketplace насчитывает сотни дополнений. Как платных, так и бесплатных. Есть из чего выбирать.

Как создать задачу в Jira?

Научиться создавать Issues – понять, как работать с Jira в целом. Создать новую задачу в Jira можно двумя путями:

• Кликнув по кнопке Create в верхней панели управления.
• Кликнув по кнопке Create issue в нужной колонке канбан-доски.

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

Во втором – указать название задачи и прописать дополнительные атрибуты.

Уже после этого можно кликать по кнопке Create, и новая issue автоматически появится в списке и на выбранной доске. А если поставить галочку напротив Create another, то тут же появится окно для добавления еще одной задачи.

Список issues также можно импортировать из другого приложения. Для этого нужно загрузить в Jira CSV-файл с соответствующим содержанием.

Атрибуты задач

Создавая issue, можно указать для нее ряд атрибутов:

• Summary. Краткое описание текущей задачи. Буквально в одно предложение.
• Description. Полноценное описание, если таковое требуется.
• Assignee. Член команды, которому нужно делегировать создаваемую задачу.
• Labels. Что-то вроде тегов для более удобной сортировки задач по другим признакам, не входящим в список типов.
• Fix version. К какой версии относится создаваемая issue.
• Story point estimate. Потенциальные трудозатраты, требующиеся на добавление новой функции или исправление бага.
• Reporter. Пользователь, который будет отчитываться за выполнение задачи.
• Attachment. Файл, прикрепленный к задаче. Это может быть что угодно: аудио, картинка, документ docx и т.п.
• Linked issues. То, с чем связаны создаваемые задачи (другие задачи/проекты).

Настройка отчетов

В графе Reports можно взглянуть на автоматически сгенерированные отчеты о проделанной работе. Пользователям Jira доступны 4 вида отчетов.

Burnup report

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

Sprint burndown chart

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

Velocity report

Используется для отображения потенциальной производительности команды в будущем. То есть на основе уже завершенных спринтов Jira пытается предугадать, как много задач удастся выполнить разработчикам в ходе следующего «забега».

Cumulative flow diagram

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

Основные принципы повышения производительности в Jira

Есть как минимум 5 способов сделать работу с Jira эффективнее.

Делите большие задачи на мелкие

Это главная заповедь канбан и скрам, но люди все равно об этом забывают и продолжают лепить карточки с очень массивными задачами. Необходимо всегда создавать максимально компактные задачи. Такие, которые легко понять, выполнить, зафиксировать, объяснить и так далее.

Каждая issue должна быть понятной единицей информации, представляющей собой компонент более глобальной цели.

Делите даже небольшие цели на еще более маленькие составные части. Так всем будет проще. Легче будет выполнять работы, легче будет отслеживать прогресс. Не будет зависаний на выполнении какой-то одной задачи. Интерфейс Jira позволяет без проблем ориентироваться даже в большом списке задач.

Комментируйте задачи

Не стесняйтесь оставлять комментарии под каждой карточкой в каждой колонке. Освобождайте свою голову сразу по ходу создания issues и работы с ними. Нужно помнить о какой-то особенности исправляемой ошибки? Напишите об этом в комментариях. Есть какая-то идея по более прагматичной реализации запланированной функции? И это тоже зафиксируйте в комментариях.

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

Записывайте все выполненные действия

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

Логи работают по тому же принципу, что и коммиты. Коммит – это фактически выгрузка любого изменения приложения в git-систему. Поменяли цвет иконки? Сделайте коммит и отправьте его в git-систему. Добавили новую функцию в код? Сделайте еще один коммит. И так на любой чих.

Лог – это способ фиксировать коммиты в Jira. По сути, те же текстовые комментарии. Просто лидеру команды будет легче отслеживать ваш прогресс с помощью логов. Это показывает, что вы действительно работаете и постоянно выполняете какие-то задачи.

Планируйте спринты

Спринт – удобная схема оптимизации рабочего процесса, но к ней тоже нужно готовиться. Важно заранее спланировать список задач, оценить адекватность поставленных целей, приблизительно оценить сроки выполнения работы, расставить приоритет по задачам. Заранее понять, что, скорее всего, будет отложено на следующий «забег», а что можно сделать быстро и в первую очередь.

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

Делайте записи на регулярной основе

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

Стоимость Jira

В бесплатной версии Jira есть ограничение на количество участников в команде и на количество сохраняемых файлов. Чтобы их снять, нужно оплатить подписку. Она стоит около 500 рублей на пользователя. То есть команда из 20 человек заплатит за месячную подписку 10 000 рублей.

Аналоги Jira

Jira – популярный и удобный инструмент. Но многим он кажется чересчур сложным, а иногда недостаточно функциональным. Претензий к продукту Atlassian хватает. Но есть и альтернативные приложения для организации командной работы и управления проектами.

Trello

Trello появился раньше, чем Jira. Это тоже продукт Atlassian, но более универсальный. Trello не заточен исключительно под нужды разработчиков и может использоваться для решения любых задач. Его используют маркетологи, бизнесмены, HR, копирайтеры и т.п.

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

Basecamp

Мощная система для организации командной работы. Она не так сильно похожа на Jira, но тоже пользуется спросом среди команд разработчиков. Здесь есть удобное совместное хранилище файлов, простой механизм для создания задач и отслеживания прогресса, а также собственная платформа для общения между коллегами.

YouTrack

Система управления проектами от знаменитой компании JetBrains, создавшей популярные IDE для разных языков программирования. У YouTrack много преимуществ: встроенная база знаний, принадлежащая конкретной команде, умный поиск по задачам, комментариям и другим единицам информации, удобные методы организации карточек на досках.

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

ClickUp

ClickUp – это своего рода прокаченная версия Jira. Здесь есть возможность делегировать комментарии, создавать упрощенные списки задач, работать с полноценным текстовым редактором, устанавливать рабочие статусы пользователям и так далее. Много мелочей, которые будут полезны для разработчиков.

Вместо заключения

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

Saved searches

Use saved searches to filter your results more quickly

Cancel Create saved search

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Термины Гита и Гитхаба #234

meritt opened this issue Apr 23, 2016 · 18 comments

Термины Гита и Гитхаба #234

meritt opened this issue Apr 23, 2016 · 18 comments

Comments

meritt commented Apr 23, 2016

Мы для Академии подготовили небольшой список терминов Гита и я хотел бы его внести в словарь. Я не уверен, что все они подойдут, поэтому скажите, что точно надо выкинуть и я оформлю пулреквест. Я предлагаю сделать отдельный файл git.md и туда добавить следующее:

• Git или Гит — система контроля и управления версиями файлов.
• GitHub или Гитхаб — веб-сервис для размещения репозиториев и совместной разработки проектов.
• Репозиторий Git — каталог файловой системы, в котором находятся: файлы конфигурации, файлы журналов операций, выполняемых над репозиторием, индекс расположения файлов и хранилище, содержащее сами контролируемые файлы.
• Локальный репозиторий — репозиторий, расположенный на локальном компьютере разработчика в каталоге. Именно в нём происходит разработка и фиксация изменений, которые отправляются на удалённый репозиторий.
• Удалённый репозиторий — репозиторий, находящийся на удалённом сервере. Это общий репозиторий, в который приходят все изменения и из которого забираются все обновления.
• Форк (Fork) — копия репозитория. Его также можно рассматривать как внешнюю ветку для текущего репозитория. Копия вашего открытого репозитория на Гитхабе может быть сделана любым пользователем, после чего он может прислать изменения в ваш репозиторий через пулреквест.
• Клонирование (Clone) — скачивание репозитория с удалённого сервера на локальный компьютер в определённый каталог для дальнейшей работы с этим каталогом как с репозиторием.
• Ветка (Branch) — это параллельная версия репозитория. Она включена в этот репозиторий, но не влияет на главную версию, тем самым позволяя свободно работать в параллельной. Когда вы внесли нужные изменения, то вы можете объединить их с главной версией.
• Мастер (Master) — главная или основная ветка репозитория.
• Коммит (Commit) — фиксация изменений или запись изменений в репозиторий. Коммит происходит на локальной машине.
• Пул (Pull) — получение последних изменений с удалённого сервера репозитория.
• Пуш (Push) — отправка всех неотправленных коммитов на удалённый сервер репозитория.
• Пулреквест (Pull Request) — запрос на слияние форка репозитория с основным репозиторием. Пулреквест может быть принят или отклонён вами, как владельцем репозитория.
• Мёрдж (Merge) — слияние изменений из какой-либо ветки репозитория с любой веткой этого же репозитория. Чаще всего слияние изменений из ветки репозитория с основной веткой репозитория.
• Кодревью — процесс проверки кода на соответствие определённым требованиям, задачам и внешнему виду.
• Обновиться из апстрима — обновить свою локальную версию форка до последней версии основного репозитория, от которого сделан форк.
• Обновиться из ориджина — обновить свою локальную версию репозитория до последней удалённой версии этого репозитория.

The text was updated successfully, but these errors were encountered: