Запрос на вытягивание git что это

Как сделать запрос тянуть на GitHub

Как создать и / или отправить запрос на вытягивание в другой репозиторий, размещенный на GitHub?

6 ответов:

пара советов по тянуть-запросы:

предполагая, что у вас есть первый раздвоенный РЕПО, вот что вы должны сделать в этой вилке, что вы владеете:

Примечание:написать сам запрос на вытягивание, см. “Как написать идеальный запрос тяги” (Январь 2015, GitHub)

после запроса на вытягивание

относительно последнего пункта, начиная с 10 апреля 2013 года,”переработан кнопку“, ветка удалена для вас:

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

это подтверждает наилучшую практику удаления ветви после слияния запроса на вытягивание.

запрос и запрос-тянуть

pull запрос не является официальным ” git” срок.
Git использует request-pull (!) команда чтобы построить запрос на слияние:
Он ” суммирует изменения между двумя фиксациями стандартного вывода и включает данный URL-адрес в сгенерированную сводку.”
Github запускает свою собственную версию с первого дня (февраль 2008 года), а переработал эту функцию в мае 2010 года, указав, что:

электронные заметки для ” reposotory” (sic)

это (запрос на вытягивание) даже не определено должным образом GitHub!

к счастью, истинная организация Бизнес-Новостей будет знать, и есть e-примечание для замены тяги-заменить на ‘e-Примечание’:

так что если ваш РЕПОoТори нужна электронная записка. спросите Фокс бизнес. Они в курсе.

чтобы узнать, как сделать запрос на вытягивание, я просто следовал двум отдельным страницам справки на Github (см. ниже в качестве маркерных точек). Следующие команды командной строки предназначены для Часть 1. Часть 2, фактический запрос на вытягивание, полностью выполняется на веб-сайте Github.

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

Мне потребовалось некоторое время, чтобы понять это, надеюсь, что это поможет кому-нибудь.

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

рабочий процесс прост, как

для тех из нас, у кого есть github.com но только получить неприятное сообщение об ошибке, когда мы вводим “git” в командной строке, вот как это сделать все в вашем браузере:)

Источник

Pull request’ы на GitHub или Как мне внести изменения в чужой проект

По просьбе tulskiy делаю вольный перевод частей официальной документации GitHub’а Fork A Repo и Send pull requests.

Итак, что же такое «запрос на включение (сделанных вами изменений)» (именно так я перевёл pull request)? В официальной документации гитхаба говорится следующее:

Pull request’ы позволяют вам рассказать другим о тех изменениях, которые вы разместили в своём GitHub-репозитории. Как только pull request отправлен, заинтересованные стороны рассматривают ваши изменения, обсуждают возможные правки или даже добавляют дополняющие коммиты, если нужно.

Немного о моделях совместной разработки

Делаем копию репозитория

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

В рамках руководства, будем считать, что мы работаем над репозиторием Spoon-Knife пользователя octocat, а ваше имя пользователя — username.

Сделать это очень просто: на странице репозитория имеется кнопочка «Fork», которую и следует нажать.

После чего, эту свою копию уже можно «стянуть» на свой компьютер:

Склонированный репозиторий имеет одну привязку к удалённому репозиторию, названную origin, которая указывает на вашу копию на GitHub, а не на оригинальный репозиторий, чтобы отслеживать изменения и в нём, вам нужно будет добавить другую привязку, названную, например, upstream.

Делаем работу

Итак, в этой точке мы уже можем править код и делать коммиты. Если вы сделали все предыдущие шаги, чтобы потом вернуть ваши изменения в оригинальный репозиторий, то я настоятельно советую делать всю работу в отдельной тематической ветви разработки. Полезность этого станет ясна на этапе посылки pull request’а. Пускай она будет называться feature.

Вот, теперь творите добро (и пусть оно будет выражаться в коммитах).

Как только вы сделали работу (или её часть), отправьте её в свою копию репозитория на GitHub:

Возвращаем изменения: Pull request

Итак, всё сделано. Вы написали код, он у вас в ветви feature как у вас на компьютере, так и на GitHub’е. Осталось только «заслать» его в оригинальный репозиторий.

Идите на страницу вашей копии репозитория на GitHub, выбирайте ветвь feature и жмите кнопку Pull Request.

Далее вы попадёте на предпросмотровую страницу, на которой сможете ввести название и описание ваших изменений (название потом попадёт в описание мёрдж-коммита и станет достоянием общественности, учтите это).

Там же вы можете посмотреть, какие коммиты попали в пулл реквест:

А так же общий diff всех изменений в пулл реквесте:

По умолчанию, пулл реквесты считаются основанными на самой часто интегрируемой ветви родительского репозитория. В этом случае username/Spoon-Knife был скопирован с octocat/Spoon-Knife, так что pull request считается основанным на ветке master репозитория octocat/Spoon-Knife. В большинстве случаев, это будет корректно, но если не так, то вы можете нажать на кнопку «Change Commits»

Вы попадёте в форму выбора базовой и исходной ветвей:

Слева выбираете в какую ветку будут вливаться изменения в родительском репозитории, справа — какие изменения будут браться с вашего репозитория. По примеру: справа octocat/Spoon-Knife/master, слева username/Spoon-Knife/feature. Здесь вы можете указывать не только ветки, но так же теги и id отдельных коммитов в соответствующем репозитории.
ВАЖНО: Договоритесь с владельцем «родительского» репозитория, в какую ветку будете вливать изменения (он может написать это в README)

Изменение базового репозитория меняет и список людей, кто получит уведомление о пулл реквесте. Каждый, кто имеет право «на запись» в базовый репозиторий, получит письмо и увидит уведомление на главной GitHub’а, в следующий раз, как на него зайдёт.
Как только список коммитов вас удовлетворит, нажмите кнопку Update Commit Range.

Когда вы ввели название и описание и перепроверили список коммитов и изменения в файлы, попавшие в пулл реквест, нажмите кнопку Send pull request. Пулл реквест будет создан незамедлительно.

Что дальше?

Следите за вашим пулл-реквестом. Что прокомментируют люди, что скажет мэйнтэйнер, примет или нет ваш пулл реквест.

Когда ваш pull request примут, не забудьте слить изменения в свой репозиторий (или удалить его, если больше не нужен):

Так же можно удалить ветку, в которой велась разработка:

Что следует делать, если работа заняла большое время и оригинальный репозиторий успел уйти вперёд?

Можно просто влить изменения из оригинального репозитория к себе:

Однако хозяину оригинального репозитория или, может быть, даже вам, не понравится наличие мёрж-коммитов и коммитов из master’а в списке коммитов на пулл. В таком случае вам стоит воспользоваться git rebase.

Прочитать про то, как работает rebase можно в официальном руководстве. Там имеются и очень понятные иллюстрации. Так же есть статья в помощи GitHub.
ВНИМАНИЕ: Пожалуйста, учтите, что git rebase меняет id коммитов! Поэтому, все действия с этой командой стоит выполнять только на локальном репозитории, до того, как эти коммиты станут общедоступны, т.е. до того, как вы их push’нули на гитхаб.

Если вы хозяин: Как принять pull request

Если пулл реквест удовлетворяет всем условиям, то кто-либо с правом «на запись» (т.е. может сделать push) в целевой репозиторий, должен принять pull request одним из многих методов. Ниже описаны три наиболее популярных метода:

Auto Merge (автослияние)

Во многих случаях можно попросить github автоматически принять пулл реквест, используя большую зелёную кнопку Merge Pull Request, которая сама вольёт изменения, создаст мёрж-коммит и закроет пулл реквест.

Подробнее можно почитать в этом хабратопике: Кнопка слияния на GitHub.

Fetch and Merge (скачать и слить)

Основной метод вливания изменений. Он требует добавления remote, ведущего к репозиторию человека, отправившего pull request, скачивания изменений с этого репозитория, объединения нужной ветви, исправления конфликтов и выгрузки обновлённой ветви обратно в исходный репозиторий:

Patch and Apply (пропатчить и принять)

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

Закрытие пулл реквеста

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

Так же возможно вручную закрыть пулл реквест в случае, если он был отклонён. Иногда это необходимо в случаях, когда изменения были приняты с помощью git-cherry-pick или другого механизма, который не позволяет обнаружить факт слияния (merge).

Источник

Рабочий процесс по внесению значительных или времязатратных изменений на сайте GitHub

Порядок внесения незначительных изменений или уточнений в документацию и примеры кода из общедоступных репозиториев см. в условиях использования на сайте docs.microsoft.com. Если новые или значительные изменения вносят не сотрудники корпорации Майкрософт, в комментариях к запросу на вытягивание на сайте GitHub появится предложение принять условия лицензионного соглашения с участником (CLA). Вам нужно заполнить онлайн-форму перед обработкой запроса на вытягивание.

Общие сведения

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

Ниже представлены примеры таких изменений.

Терминология

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

Рабочий процесс

Если вы еще не сделали это, выполните инструкции из раздела, посвященного настройке. Из этого раздела вы узнаете, как настроить учетную запись GitHub, установить Git Bash и Markdown Editor, создать вилку и настроить локальный репозиторий. Если вы не работали с Git и GitHub и не знаете, что такое репозиторий или ветвь, сначала ознакомьтесь с основными понятиями.

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

Использование процедуры GitHub

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

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

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

Теперь создадим рабочую ветвь в локальном репозитории, чтобы записать предложенные изменения. Если вы установили Git Bash (см. статью Установка средств создания содержимого), можно создать новую ветвь и извлечь ее с помощью одной команды из клонированного репозитория:

Клиенты Git отличаются, поэтому ознакомьтесь со справочными сведениями об используемом клиенте. Дополнительные сведения об этом процессе см. в соответствующем руководстве GitHub.

Внесение изменений

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

Сохранение изменений в репозиторий

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

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

Затем необходимо зафиксировать сохраненные изменения в локальном репозитории. Для этого в Git Bash выполните следующую команду:

И, наконец, так как эта ветвь создана на локальном компьютере, необходимо указать на это вилке в вашей учетной записи GitHub.com. Для этого в Git Bash выполните следующую команду:

Готово! Теперь ваш код находится в репозитории GitHub и может использоваться для создания запроса на вытягивание.

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

Нужно исправить уже отправленные изменения? Это не проблема! Просто внесите изменения в ту же ветвь, а затем зафиксируйте и отправьте их снова (настраивать вышестоящий сервер для последующих отправок той же ветви не требуется).

Внесение следующего изменения

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

Теперь вы снова находитесь в новой ветви. Постепенно вы становитесь опытным участником!

Обработка запроса на вытягивание

В предыдущем разделе был представлен процесс отправки предлагаемых изменений путем их объединения в новый запрос на вытягивание (PR), который добавляется в очередь запросов на вытягивание целевого репозитория. Запрос на вытягивание активирует модель совместной работы GitHub, запрашивая изменения из рабочей ветви, которые следует вытянуть и интегрировать в другую ветвь. В большинстве случаев такой ветвью является ветвь по умолчанию в главном репозитории.

Проверка

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

Проверка и подписание

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

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

После устранения ошибок и подписания запроса ваши изменения будут объединены в родительскую ветвь и запрос на вытягивание будет закрыт.

Публикация

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

Утвержденные и объединенные изменения будут захвачены процессом публикации docs.microsoft.com. Время публикации зависит от команды, управляющей репозиторием, в который вы вносите изменения. Статьи, публикуемые в следующих расположениях, обычно развертываются с понедельника по пятницу с 10:30 до 15:30 (по тихоокеанскому времени):

После публикации отображение статьей в Интернете может занять до 45 минут. После публикации статьи можно проверить изменения по соответствующему URL-адресу: https://docs.microsoft.com/

Дальнейшие действия

Вот и все! Вы внесли свой вклад в содержимое сайта docs.microsoft.com.

Источник

Русские Блоги

Как изящно тянуть запрос

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

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

Многие проекты с открытым исходным кодом на Github используют запросы на вытягивание для управления изменениями от участников, потому что они предоставляют способ уведомить разработчиков проекта об изменениях, внесенных другими участниками, и могут вносить изменения в код перед слиянием с основной веткой Просмотрите и обсудите это.

Есть два основных рабочих процесса для запроса на вытягивание;

Запрос на перенос на раздвоенный склад;

Вытяните заявку на отделение на складе;

Эта статья в основном объясняет первый способ.

1. Вилочный склад

Разверните склад проекта, в котором вы хотите участвовать, на свой github;

2. git clone этот форк-проект

Найдите проект fork в вашем собственном github и клонируйте git в локальный.

3. Добавить вышестоящий склад

Следуя предыдущему шагу в этом проекте, выполните следующие операции для подключения вышестоящего склада к локальному складу, который является адресом нашей вилки:

Другие вспомогательные функции:

4. Сохраняйте синхронизацию с исходным складом

Обновите ветку под “указанным” пультом:

Приведенная выше команда может обновлять только один пульт за раз. Если у нас несколько пультов, мы можем использовать:

Когда мы используем команду pull для получения последнего кода восходящей ветки, если локальная ветвь отстает от восходящей ветки, будет сгенерирована новая избыточная информация о фиксации слияния, поэтому рекомендуется использовать:

5. Сообщить о проблеме

Для сопровождающих проекта

Рекомендуется, чтобы сопровождающие проекта поддерживали шаблон задачи проекта, а участники отправляли задачи в соответствии с этим шаблоном;

Создать шаблон задачи можно двумя способами:

(1) Добавьте в проект шаблон ошибки и файл шаблона функции:

Содержимое шаблона bug_request выглядит следующим образом:

(2) После этого для внесения вкладов откройте проблему в github, чтобы увидеть соответствующие параметры шаблона:

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

Шаблон задачи должен быть создан в ветке по умолчанию.

Для авторов

Перед новым запросом на вытягивание лучше всего поднять вопрос для обсуждения;

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

Добавьте соответствующие теги к своим проблемам, чтобы вы могли легко классифицировать и фильтровать проблемы:

Проблема может иметь несколько ярлыков;

Milstone соответствует группе задач проекта, функции или временного периода: например, номер версии, конкретный крайний срок, рефакторинг новых функций и т. Д.

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

6. Создайте новую ветку

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

В последнем нажатии используйте:

Отправьте новый филиал на удаленный склад.

Если вышестоящему складу также необходимо создать эту ветвь, это можно использовать:

7. Отправьте информацию о фиксации.

После внесения изменений в проект нам нужно сгенерировать фиксацию для записи наших изменений. Ниже приводится спецификация формата фиксации в Angular:

(1) Формат

Информация о подаче состоит из трех частей: Header ， Body с участием Footer 。

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

1> Header

В части заголовка всего одна строка, включая два поля: type (Обязательно) и subject (Необходимые).

type используется для описания категории фиксации, могут использоваться следующие категории:

feat: новые функции (функция)

fix: исправить ошибку

style: Format (не влияет на изменения в работе кода)

рефакторинг: рефакторинг (то есть это не новая функция и не изменение кода для изменения ошибки)

тест: добавить тест

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

Начните с глагола и используйте настоящее время от первого лица, например “изменить”, а не “изменить”.

Нет точки (.) В конце

2> Body

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

3> Footer

Часть нижнего колонтитула должна содержать: (1) критические изменения; (2) закрыть проблему;

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

Связать проблему с фиксацией:

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

Как показано на рисунке ниже, зафиксируйте ветку по умолчанию, чтобы закрыть проблему:

И когда другие ветки хотят закрыть:

4> Примеры

Вышеупомянутая информация должна объяснить, что вы имеете в виду.

8. Интегрируйте информацию о фиксации, чтобы сохранить чистоту информации о фиксации.

Редактировать информацию о предыдущей фиксации;

Объедините несколько данных о фиксации в одну;

Удалите информацию о фиксации.

Есть 6 вариантов перебазирования:

pick: pick означает использовать фиксацию;

reword: опция reword может изменять информацию о фиксации;

edit: вы можете изменить информацию о фиксации. В отличие от reword, этот параметр может приостановить процесс перебазирования, позволяя вам добавить больше информации о фиксации, что позволяет разбивать большие коммиты на более мелкие или удалять коммиты, сделанные в фиксации Ошибка изменения;

squash: эта команда позволяет объединить два или более коммитов в один коммит. Представление сжато в представление над ним. Git дает вам возможность написать новое сообщение фиксации, описывающее эти два изменения.

fixup: это похоже на сквош, но объединяемый коммит отбрасывает свое сообщение. Коммит просто объединяется с коммитом над ним, и предыдущее сообщение фиксации используется для описания этих двух изменений.

exec: это позволяет вам запускать произвольные команды оболочки для отправки.

Пример объяснения

Ниже приведен пример сквоша:

Как показано на рисунке, есть три записи фиксации:

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

(2) Отменить операцию перебазирования

выполненный git reflog Найдите идентификатор фиксации;

Reflog может просматривать операции, связанные с изменениями проекта, выполненными локально с даты создания локального хранилища, такие как фиксация, клонирование, перебазирование и другие операции. git log Это просмотр текущего репозитория и всех предыдущих коммитов.

(3) Вернуться в состояние фиксации

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

выполненный git log Команда для просмотра записи фиксации:

Как показано выше, вы можете увидеть хеш-значение фиксации;

Например, нам нужно вернуться к Новый режим MVC В предыдущей версии выполните:

В этом случае при нажатии выполните:

9. Отправить на удаленный склад

Перед продвижением вы должны снова вытащить вышестоящий склад, чтобы сравнить локальную фиксацию с удаленной фиксацией. Если удаленный склад имеет новое обновление и конфликтует с локальным хранилищем, то сначала необходимо разрешить конфликт, а затем git add && git commit ；

10. Новый запрос на вытягивание.

В новом запросе на перенос в вашем собственном проекте выберите, какую ветвь с какой веткой объединить:

Выберите рецензента, клиента, лейбл и другую информацию;

11. Рецензент для проверки

Если новый код запускать не нужно, проверяющий может оценить, следует ли выполнять слияние после проверки;

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

Существует три варианта поведения слияния, которые можно выбрать в зависимости от конкретной ситуации:

Другие случаи

Отменить все локальные модификации (зафиксировано);

Отменить временно сохраненный файл, то есть отменить предыдущую операцию “git add”

(Файлы, которые не отслеживаются, не будут изменены, то есть файлы, которые не были выполнены git add)

Откатим локальное состояние до удаленного:

Просмотрите конкретное содержимое записи фиксации:

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

Используйте changlog для печати информации о фиксации (при условии, что информация о фиксации написана в соответствии со спецификацией angular)

Как правило, информация журнала изменений печатается при выпуске пакета.Журнал изменений фактически является одним из этапов выпуска.

Дополнительные инструкции см. В другом документе общих команд git.

Источник