Как сделать пул реквест на все файлы
Обновлено: 04.07.2024
Пул-реквесты облегчают совместную работу разработчиков в Bitbucket. Они обеспечивают удобный веб-интерфейс для обсуждения предлагаемых изменений до их включения в официальный репозиторий проекта.
В упрощенном виде запросы pull — это механизм, с помощью которого разработчик уведомляет участников команды о том, что он подготовил некий функционал. Закончив работу над функциональной веткой, разработчик создает запрос pull с помощью аккаунта Bitbucket. Так все участники процесса узнают, что требуется проверить код и выполнить слияние с главной веткой ( main ).
Однако запрос pull — это не просто уведомление, а специальный форум для обсуждения предлагаемой функции. Если с изменениями возникли какие-либо проблемы, участники команды могут публиковать в запросе pull отзывы и даже изменять функцию с помощью дополнительных коммитов. Все эти действия отслеживается непосредственно внутри запроса pull.
По сравнению с другими моделями совместной работы это формальное решение для обмена коммитами обеспечивает гораздо более упорядоченный рабочий процесс. SVN и Git могут автоматически отправлять уведомления по электронной почте с помощью простого скрипта; однако когда дело доходит до обсуждения изменений, разработчикам обычно приходится вести диалог по электронной почте. Такой подход может внести путаницу, особенно если начинается обмен дополняющими коммитами. Запросы pull помещают все эти функции в удобный веб-интерфейс рядом с репозиториями Bitbucket.
Структура запроса pull
Создавая пул-реквест, вы всего лишь просите другого разработчика (например, человека, занимающегося поддержкой проекта) забрать ветку из вашего репозитория в его репозиторий. Поэтому для создания пул-реквеста необходимо указать 4 параметра: исходный репозиторий, исходную ветку, репозиторий назначения и ветку назначения.
Для многих параметров сервис Bitbucket определяет нужные значения по умолчанию. Однако в зависимости от того, как налажен процесс совместной работы команды, может потребоваться указать другие значения. На приведенной выше схеме показан запрос pull о слиянии функциональной ветки с официальной главной веткой, однако существует множество других способов использования запросов pull.
Порядок действий
Пул-реквесты можно применять в сочетании с процессами Feature Branch Workflow, Gitflow Workflow или Forking Workflow. При этом для использования пул-реквестов требуются две отдельные ветки или два отдельных репозитория. Поэтому пул-реквесты не будут работать при использовании процесса Centralized Workflow. Использование пул-реквестов в каждом из перечисленных процессов имеет свои нюансы, но общий подход описан ниже.
Разработчик создает функцию в отдельной ветке в своем локальном репозитории.
Разработчик отправляет эту ветку в публичный репозиторий Bitbucket командой push.
Разработчик создает запрос pull через Bitbucket.
Остальные участники команды проверяют код, обсуждают его и вносят изменения.
Человек, занимающийся поддержкой проекта, сливает функцию в официальный репозиторий и закрывает запрос pull.
Далее в этом разделе описывается, как запрос pull может использоваться в различных процессах совместной работы.
Использование запросов pull в рабочем процессе с функциональными ветками
В жизненном цикле функциональной ветки для организации совместной работы используется общий репозиторий Bitbucket, в котором разработчики создают новый функционал в изолированных ветках. Но вместо немедленного слияния кода с веткой main разработчики должны создать запрос pull, чтобы начать обсуждение функциональной ветки до ее включения в основную базу кода.
В процессе Feature Branch существует только один публичный репозиторий, поэтому исходный и целевой репозитории в запросе pull всегда будут совпадать. Обычно разработчик указывает свою функциональную ветку в качестве исходной, а ветку main — в качестве целевой ветки.
Получив запрос pull, человек, занимающийся поддержкой проекта, должен принять решение. Если функциональная ветка готова к использованию, можно выполнить слияние кода с веткой main и закрыть запрос pull. Но если в предлагаемых изменениях есть проблемы, можно оставить комментарии в запросе pull. Последующие коммиты будут отображаться рядом с соответствующими комментариями.
Кроме того, можно создать запрос pull для незавершенной функции. Например, если у разработчика возникают проблемы с реализацией определенного требования, он может создать запрос pull, содержащий его наработки. Другие разработчики могут оставить внутри этого запроса pull свои предложения или даже решить проблему, добавив дополнительные коммиты.
Использование запросов pull в рабочем процессе Gitflow
Рабочий процесс Gitflow похож на рабочий процесс с функциональными ветками, но устанавливает строгую модель ветвления, разработанную для релиза проекта. При добавлении запросов pull в рабочий процесс Gitflow разработчики получают удобное место для обсуждения ветки релиза или ветки сопровождения в ходе работы над ней.
Механизм запросов pull в рабочем процессе Gitflow аналогичен описанному выше: разработчик просто создает запрос pull, когда необходимо проверить функцию, релиз или ветку исправлений, а остальные участники команды получают уведомления через Bitbucket.
Слияние функциональных веток обычно выполняют с веткой разработки develop , а слияние веток релизов и исправлений выполняют и с веткой develop , и с веткой main . Запросы pull можно использовать в качестве инструмента формального управления всеми этими слияниями.
Использование запросов pull в рабочем процессе с форками
В процессе с использованием форков разработчик помещает завершенную функциональную ветку в собственный публичный репозиторий, а не в общий репозиторий. После этого разработчик создает пул-реквест, оповещая человека, занимающегося поддержкой проекта, о готовности кода к проверке.
Для этого рабочего процесса наличие уведомления в запросе pull особенно важно, иначе человек, занимающийся поддержкой проекта, не сможет узнать о том, что другой разработчик добавил коммиты в свой репозиторий Bitbucket.
Поскольку у каждого разработчика есть свой публичный репозиторий, исходный и целевой репозитории в запросе pull будут отличаться. Исходным будет публичный репозиторий разработчика, а исходной веткой — та, что содержит предлагаемые изменения. Если разработчик предлагает слить функциональную ветку с основной базой кода, целевым репозиторием будет официальный репозиторий проекта, а целевой веткой — главная ветка main .
Кроме того, пул-реквесты можно использовать для совместной работы с другими разработчиками за пределами официального репозитория проекта. Например, если разработчик работал над функциональной веткой вместе с коллегой, они могут создать пул-реквест, указав в качестве назначения репозиторий Bitbucket коллеги, а не официальный репозиторий проекта. Тогда они смогут указать в качестве исходной ветки и ветки назначения одну и ту же функциональную ветку.
Два разработчика могут обсуждать и разрабатывать функцию внутри запроса pull. По окончании разработки один из них создает новый запрос pull на слияние этой функции с официальной главной веткой. Такая гибкость делает запросы pull невероятно мощным инструментом совместной работы в рамках рабочего процесса с форками.
Пример
В приведенном ниже примере демонстрируется использование запросов pull в рабочем процессе с форками. Он одинаково применим как для разработчиков, работающих в маленьких командах, так и для независимых разработчиков, участвующих в проекте с открытым исходным кодом.
В данном примере Мэри — разработчик, а Джон — человек, занимающийся поддержкой проекта. У обоих есть собственные публичные репозитории Bitbucket, и в репозитории Джона находится официальный проект.
Мэри создает форк официального проекта
Чтобы начать работу над проектом, Мэри сначала должна создать форк репозитория Джона в Bitbucket. Для этого ей нужно войти в Bitbucket, перейти к репозиторию Джона и нажать кнопку Fork.
Указав имя и описание для репозитория, создаваемого с помощью форка, она получит копию серверной части проекта.
Мэри клонирует свой репозиторий Bitbucket
Затем Мэри должна клонировать репозиторий Bitbucket, который она только что создала с помощью форка. Так она получит собственную рабочую копию проекта на своей локальной машине. Она может сделать это с помощью следующей команды:
Помните, что команда git clone автоматически создает удаленный репозиторий origin , который указывает на репозиторий Мэри, созданный с помощью форка.
Мэри разрабатывает новый функционал
Прежде чем писать какой бы то ни было код, Мэри должна создать новую ветку для функции. Эту ветку она будет использовать в качестве исходной в запросе pull.
Мэри может выполнять сколько угодно коммитов во время работы над функциональной веткой. Если история создания функциональной ветки выглядит слишком запутанной, она может использовать интерактивную операцию rebase для удаления или склеивания ненужных коммитов. Такая очистка истории функциональной ветки в больших проектах помогает человеку, занимающемуся поддержкой проекта, быстрее понять, что включено в пул-реквест.
Мэри помещает функциональную ветку в свой репозиторий Bitbucket
Закончив свою задачу, Мэри помещает функциональную ветку в собственный репозиторий Bitbucket (не в официальный репозиторий проекта) с помощью простой команды git push :
Так изменения Мэри будут доступны человеку, занимающемуся поддержкой проекта (или любым другим участникам, которым может понадобиться доступ к этим изменениям).
Мэри создает запрос pull
После добавления своей функциональной ветки в Bitbucket Мэри из своего аккаунта Bitbucket может создать пул-реквест, перейдя в свой репозиторий, созданный с помощью форка, и нажав на кнопку Pull request в верхнем правом углу. Отобразится форма, в которой репозиторий Мэри автоматически будет указан в качестве исходного. Мэри останется указать исходную ветку, а также репозиторий и ветку назначения.
Мэри хочет выполнить слияние функциональной ветки с основной базой кода. При этом исходной веткой будет ее функциональная ветка, целевым репозиторием — публичный репозиторий Джона, а целевой веткой — ветка main . Мэри потребуется ввести заголовок и описание запроса pull. Если кто-либо еще кроме Джона должен одобрить код Мэри, она может указать нужных людей в поле Reviewers (Проверяющие).
После создания запроса pull Джону будет отправлено уведомление через Bitbucket и (опционально) по электронной почте.
Джон просматривает запрос pull
Джон может увидеть все созданные другими разработчиками пул-реквесты, перейдя на вкладку Pull request в своем репозитории Bitbucket. Нажав на пул-реквест Мэри, он увидит описание пул-реквеста, историю коммитов функциональной ветки и все изменения в пул-реквесте.
Если Джон считает функционал готовым к слиянию с проектом, ему достаточно нажать кнопку Merge (Слияние), чтобы одобрить запрос pull и выполнить слияние функционала Мэри со своей веткой main .
Но для примера представим, что Джон нашел небольшой баг в коде Мэри и хочет, чтобы он был исправлен перед слиянием. Джон может либо опубликовать комментарий к запросу pull в целом, либо выбрать определенный коммит в истории функциональной ветки и прокомментировать его.
Мэри добавляет дополняющий коммит
Если у Мэри есть какие-либо вопросы по поводу отзыва Джона, она может ответить внутри запроса pull, используя его как форум для обсуждения функции.
Для исправления ошибки Мэри добавляет другой коммит в свою функциональную ветку и помещает этот коммит в свой репозиторий Bitbucket, как и в первый раз. Коммит автоматически добавится в исходный запрос pull, и Джон сможет снова просмотреть изменения прямо рядом с его исходным комментарием.
Джон принимает запрос pull
В конечном счете Джон принимает изменения, выполняет слияние функциональной ветки с главной и закрывает запрос pull. Функциональная ветка включена в проект. И теперь каждый разработчик проекта может скопировать изменения в свой локальный репозиторий, выполнив стандартную команду git pull .
Куда можно перейти отсюда
Теперь у вас есть все необходимые инструменты, чтобы начать использование пул-реквестов в текущем рабочем процессе. Помните, что пул-реквесты не заменяют процессы совместной работы в Git, а лишь дополняют их, облегчая взаимодействие всех членов команды.
Это руководство научит вас делать изменения в проекте на GitHub. Описываемый процесс предлагает лучшие практики , и является достаточно распространённым — вы сможете применять его за пределами нашего сообщества. В проектах сообщества придерживаться такого процесса очень рекомендуется.
Сначала мы приведём высокоуровневое описание процесса , а затем подробно опишем каждый этап.
Предполагается знание основ системы контроля версий Git. Если вы ещё не работали с Git, мы дадим ссылки на официальную русскоязычную документацию по необходимым командам.
Вот процесс с высоты птичьего полёта.
- Форкните проект.
- Склонируйте репозиторий.
- Создайте ветку для своей работы.
- Сделайте необходимые изменения в файлах — коде , документации , тестах. Закоммитьте их в только что созданную ветку.
- Убедитесь , что проект работает после ваших изменений.
- Сделайте Pull Request.
- Обсудите его с рецензентом в процессе Code Review. При необходимости , внесите изменения в свой Pull Request.
- Когда все довольны , Pull Request принимают — с этого момента ваши изменения попали в исходный репозиторий ( upstream) и являются частью проекта.
Работа над задачей закончена!
Теперь рассмотрим каждый этап подробнее.
Форкаем проект
Вы не можете отправлять коммиты ( git push ) напрямую в исходный репозиторий. По желанию хозяин проекта может это разрешить , но обычно доступ на запись есть только у людей , поддерживающих проект , а все остальные работают через Pull Request’ы ( «запросы на вливание изменений»; о них — ниже).
Поэтому мы форкаем проект — это создаст копию репозитория в вашем аккаунте. При этом у вас появится доступ на запись в вашу копию.
Через мгновение вы будете перенаправлены на страницу вашего форка.
Клонируем репозиторий
Затем выполняем команду в терминале ( или командной строке Windows):
git clone <вставляем_URL>
Репозиторий склонируется в под-директорию текущей директории. Например , если репозиторий называется foobar , у вас появится каталог foobar .
Создаём ветку
Ветка по умолчанию — master . Чтобы изменениями было проще управлять и они не смешивались друг с другом , создадим отдельную ветку , где и будем работать. При этом ветку стоит назвать так , чтобы имя говорило о её назначении.
Теперь заходим в наш склонированный репозиторий и создаём ветку:
Вторая команда создаст ветку и перейдёт на неё ( сделает checkout).
Если после этого выполнить git status , он покажет
Эту команду стоит запомнить — когда не понимаете , в каком состоянии репозиторий, просто выполните её. Чаще всего в её выводе git покажет другие команды, которые делают то , что вы ( скорее всего) и хотите сделать.
Делаем изменения
Теперь приступаем к работе. Редактируем код , обновляем документацию , чиним тесты , дополняем README.
Эти изменения мы коммитим в нашу ветку. Как это сделать — ниже.
При этом старайтесь делать коммиты часто , а сами коммиты — небольшими по объёму. Каждый коммит должен делать ровно одну вещь , и при этом поддерживать работоспособность проекта. Стремиться нужно к тому , чтобы в будущем можно было перейти на любой коммит и получить рабочий проект.
Если у вас сразу не получается придерживаться такой дисциплины , или изменения затрагивают весь проект « насквозь», допустимо ломать проект и постепенно чинить его в следующих коммитах.
Если вы уже достаточно разбираетесь в Git, такие не-атомарные изменения потом нужно объединить в один коммит с помощью interactive rebase и squash.
Итак , после редактирования файлов мы имеем следующую ситуацию ( это вывод git status ):
В выводе есть все необходимые вам команды:
- git add <file>. добавляет файл в содержимое коммита , который вы собираетесь записать
- git checkout -- <file>. откатывает ваши изменения файла
Она должна иметь вид <Глагол в настоящем времени, первом лице, множественном числе> <объект изменения> . Говорим о том , что мы делаем в этом коммите: [мы] исправляем ошибку , [мы] добавляем возможность , [мы] обновляем документацию.
git log --oneline выводит историю в формате « 1 коммит — 1 строка на экране». При этом он использует в качестве описания коммита первую строку — краткое описание. Поэтому оно обязательно должно быть отделено пустой строкой от остального описания — иначе однострочный вывод разъедется.
Проверяем изменения
Когда вы сделали правки , стоит их проверить — если только это не что-то абсолютно тривиальное.
Для этого нужно собрать проект и запустить тесты , если они есть. В любом случае стоит проверить работу кода , который вы написали или изменили , запустив программу или вызвав библиотеку.
Если проект — это статически генерируемый сайт , то сгенерируйте его локально и убедитесь , что ничего не отвалилось и вёрстка не разъехалась. Если книга — то же самое. Смотрите по крайней мере на те места , которые вы правили.
Создаём Pull Request
Когда работа и проверка закончены , пора создавать Pull Request. Pull Request — это запрос на вливание изменений из вашей ветки в основную ветку исходного репозитория. Таким образом они попадут к хозяевам проекта.
Чтобы создать Pull Request, зайдём на страницу вашего форка. Справа от выпадающего меню с выбором ветки есть кнопка « New pull request».
Вы попадаете в окно сравнения веток.
Вот элементы этого окна , по порядку:
Дальше просмотрите изменения — то ли это , что вы делали? Если да , то нажимайте кнопку « Create pull request». В моём примере её нет , т. к. ветки в форке и в оригинале находятся в одинаковом состоянии. В вашем же случае внизу будет список коммитов , которые попадут в исходный репозиторий , и , на других вкладках — сами изменения и комментарии к изменениям.
Затем нажимаем « Create pull request». Он создаётся , о нём приходит уведомление людям , поддерживающим проект , и он становится виден в исходном репозитории на вкладке « Pull requests». С этого момента начинается рецензирование изменений ( code review).
Подсказка: если сразу после того , как вы отправили ветку в свой репозиторий ( git push origin ) зайти на страницу репозитория , там будет предложение создать Pull Request на вливание недавно отправленной ветки в master. Сделать это можно как в вашем форке , так и в исходном репозитории. Это будет отдельная кнопка вверху , и при её нажатии в качестве ветки для слияния будет указана та , куда вы делали git push .
Участвуем в Code Review
Со стороны автора Pull Request ( а раз вы читаете это руководство , вы наверняка автор) требуется с пониманием относиться к комментариям рецензента — они направлены на повышение качества проекта. Если ошибка в сборке выявляется в процессе рецензирования , это гораздо лучше , чем если она попадёт в репозиторий, а следующий человек , который попытается поучаствовать в проекте , не сможет этого сделать из-за той самой ошибки. Да и это касается не только сборки , разумеется.
Также отмечу , что общаться в комментариях к PR следует вежливо и с уважением. Даже если вы общаетесь не с рецензентом. Не надо делать разнообразные далекоидущие выводы относительно пола , возраста , расы , интеллектуальных способностей и других черт человека. Если вы будете грубить рецензенту , в следующий раз он просто не захочет смотреть PR от вас. Не забывайте , что рецензирование — это тоже работа. Так что будьте добры и уважайте труд людей — они делают это бесплатно.
Если кто-то ведёт себя неадекватно — не медлите. Сначала сообщите об этом собеседнику и призовите его к благоразумию. Если не сработало — смело обращайтесь к рецензенту или к автору данного текста ( Панкову Михаилу — @mkpankov). Это можно сделать в нашем чате.
Пожелание относительно процесса рецензирования — постарайтесь не сильно затягивать с ответами на комментарии или изменением указанных вещей.
Почему это важно? Автор PR хорошо разбирается в том , что он сделал , а если процесс затягивается на недели и месяцы , высока вероятность , что или автор , или рецензент отвлекутся на другие вещи , а обратный вход в контекст изменений тоже стоит усилий и времени. « Другие вещи» здесь — это вся остальная жизнь человека. Может на работе аврал , может личные проблемы , может заболел. В итоге может получиться так , что ваш PR навеки повиснет в неготовом состоянии и так и не будет влит. Конечно , нам бы этого не хотелось.
В отдельных случаях стоит обсудить спорный момент в чате , нежели перебрасываться комментариями на GitHub. Это гораздо быстрее , и объяснить свою позицию в интерактивном общении проще.
Также стоит отметить , что процесс рецензирования итеративен по природе. То , что рецензент написал комментарий к какой-то строке на пятой итерации , хотя она не менялась с первой , не значит , что он захотел придраться. Возможно , в результате окружающих изменений она потеряла смысл , или нужно изменить стиль фразы в документации , чтобы он согласовался с окружающим текстом. Также , часто просто сложно увидеть все места , требующие правки , с первого раза — внимательность и память любого человека ограничены. По мере того , как самые заметные вещи исправляют , внимание уделяется менее заметным — это нормально.
В нашем сообществе не принято наезжать на новичков , и мы всегда стараемся помочь. Не пугайтесь рецензирования — выше написано много слов , но на деле достаточно просто адекватно себя вести и не забивать на исправления.
Когда этот этап завершается , рецензент нажимает кнопку « Merge Pull Request». Ваши изменения влиты в основной репозиторий проекта.
Поздравляем! Теперь вы полноправный участник проекта.
Завершение работы
После вливания PR нужно прибраться в репозитории. Если ваши изменения самодостаточны и после PR не требуется продолжать работу дальше , стоит удалить ветку. Как вы помните , мы создали её раньше , чтобы удобнее управлять изменениями.
Но сначала лучше обновить вашу локальную master-ветку — тогда git убедится, что ваша ветка уже влита в master , и не будет предупреждать , что вы можете потерять свои изменения.
Итак , обновляем нашу локальную рабочую копию. Для этого добавим ещё один remote — так называется удалённый репозиторий. Сейчас он у вас только один — origin , и он указывает на ваш форк. Добавим remote с именем upstream , который будет указывать на исходный репозиторий:
Перевод статьи «How to make your first pull request on GitHub».
Что такое форк?
Когда нам нравится чей-то репозиторий и мы хотели бы иметь его в собственном аккаунте на GitHub, мы делаем форк («вилку») этого репозитория, чтобы иметь возможность работать с ним отдельно.
Когда мы делаем форк репозитория, мы получаем экземпляр всего репозитория, со всей его историей. После форка мы можем делать с ним все, что угодно: оригинальная версия при этом не будет задета.
Что такое пул-реквест?
Пул-реквесты нужны. Когда мы хотим принять участие в групповой разработке проектов с открытым исходным кодом.
Например, пользователь Павел делает форк репозитория ThanoshanMV (автора статьи, — прим. перев.) и вносит изменения в свой экземпляр. После этого Павел отсылает пул-реквест ThanoshanMV, который может либо принять его, либо отклонить. По сути это что-то вроде письма «Не будете ли вы так любезны, уважаемый ThanoshanMV, внести мои изменения в свой оригинальный репозиторий?»
Как можно стать контрибьютором проекта?
Участие в проекте с открытым исходным кодом не обязательно предполагает работу именно с кодом. Контрибьютором (участником) можно стать и другими способами, некоторые из них описаны ниже.
- Дизайн. Можно создать макеты проекта, чтобы повысить удобство его использования, усовершенствовать навигацию или меню, создать рисунки для лого или футболок, написать руководство по стилю проекта.
- Писательство. Можно написать документацию проекта или улучшить уже существующую, перевести документацию на свой язык, создать новостную рассылку для проекта, написать руководства для пользователей или заняться формированием папки с примерами использования.
- Организаторские задачи. Можно связывать дублирующиеся issues, предлагать новые метки для issues, предлагать закрытие старых, но еще открытых issues, задавать вопросы в новых — чтобы подстегивать развитие дискуссии.
- Помощь другим людям. Можно отвечать на вопросы в открытых issues, проверять код других разработчиков, предлагать помощь в качестве наставника.
- Написание кода. Можно помогать в решении возникших проблем, предлагать создание новых фич, а также улучшать инструментарий и тестирование.
Давайте создадим наш первый пул-реквест!
1. Форк репозитория
Чтобы сделать форк репозитория, нужно нажать кнопку «Fork» в верху страницы. Таким образом вы создадите экземпляр всего этого репозитория в своем аккаунте.
2. Клонирование репозитория
Когда репозиторий уже есть в вашем аккаунте, вы можете клонировать его на свою машину и в дальнейшем работать с ним локально.
Чтобы клонировать репозиторий, нажмите кнопку «clone» и скопируйте ссылку.
Откройте терминал и запустите следующую команду. С ее помощью репозиторий будет клонирован на вашу машину.
Теперь у вас есть копия ветки master основного онлайн-репозитория проекта.
Переходим в клонированную директорию:
3. Создание ветки
При работе с репозиторием хорошей практикой считается создание отдельной ветки для внесения изменений, причем это не зависит от размеров проекта.
Имя ветки должно быть коротким и отражать те изменения, которые вы вносите.
Создадим ветку при помощи команды git checkout:
4. Внесение изменений и коммит
Внесите необходимы изменения в проект и сохраните их. Затем запустите команду git status: вы увидите внесенные изменения.
Добавьте эти изменения в только что созданную ветку при помощи команды git add:
Теперь вы можете сделать коммит этих изменений при помощи команды git commit:
5. Отправка изменений на GitHub
Имя данного удаленного репозитория — «origin».
6. Создание пул-реквеста
Перейдите в свой репозиторий на GitHub. Там есть кнопка «Compare & pull request» — кликните ее.
Введите необходимые детали относительно того, что именно вы сделали (чтобы поставить ссылку на issues, возмользуйтесь знаком «решетки»). После этого можно нажать кнопку подтверждения внизу.
Поздравляю! Вы создали свой первый пул-реквест. Если его примут, вы получите уведомление по электронной почте.
7. Синхронизация вашего форка с основной веткой
Прежде чем создавать пул-реквест в оригинальный репозиторий, нужно синхронизировать свой экземпляр этого репозитория с оригинальным.
Даже если вы не собираетесь отправлять пул-реквест в оригинальный репозиторий, все равно лучше синхронизироваться с ним. Со времени создания форка в оригинальном репозитории могли добавиться новые фичи, а также могли быть исправлены какие-то баги.
Проделайте следующие действия, чтобы обновить свой репозиторий и внести соответствующие изменения в свою ветку master:
1. Для начала, проверьте, в какой ветке вы находитесь.
Вы получите список всех веток, причем активная будет подсвечена зеленым.
2. Переключитесь в ветку master.
3. Добавьте оригинальный репозиторий в качестве upstream-репозитория.
Чтобы вытащить изменения из оригинального репозитория и перенести их в свою версию, нужно добавить оригинальный git-репозиторий в качестве upstream-репозитория.
4. Fetch репозитория
Заберите (fetch) все изменения из оригинального репозитория. Коммиты, сделанные в оригинальном репозитории, будут сохранены в локальной ветке под названием upstream/master.
5. Слейте изменения
Слейте (merge) изменения из upstream/master с вашей локальной веткой master. Таким образом главная ветка вашего форка репозитория синхронизируется с upstream-репозиторием без потери ваших локальных изменений.
6. Отправьте изменения на GitHub
Примечание. После синхронизации ветки master вашего форка вы можете при желании удалить remote. Но в будущем вам еще придется обновлять/синхронизировать ваш репозиторий, поэтому лучше его сохранить.
8. Удаление ненужной ветки
Ветки создаются с какими-то конкретными целями. Когда цель достигнута, необходимость в ветке отпадает, поэтому ее можно удалить.
Вы можете удалить и версию этой ветки на GitHub.
Итоги
GitHub это мощный инструмент для контроля истории версий. Каждый может стать контрибьютором проекта с открытым исходным кодом. Делается это путем отправки пул-реквестов.
Чтобы стать контрибьютором, не обязательно писать код: есть и другие способы принять участие в проекте.
Наконец, я хотел бы также сказать, что не стоит переживать, если ваши пул-реквесты отклонят. Мейнтейнеры тратят много времени на улучшение своих проектов и они, безусловно, лучше знают эти проекты, чем вы. Поэтому не стоит переживать, если они решат не вливать в свой проект ваши изменения.
Что такое "пул реквест" (pull request), который на GitHub, и как его применить?
47k 11 11 золотых знаков 74 74 серебряных знака 143 143 бронзовых знака 837 2 2 золотых знака 8 8 серебряных знаков 5 5 бронзовых знаков @СашаЧерных он там по-разному пишется. Перейдите по той ссылке, которую вы приводили первый раз и посмотрите в самый низСмотрим за руками.
- Крутой программер создал репозиторий.
- Вы сделали форк его репозитория (т.е. скопировали к себе).
- Вы сделали какие-то крутые изменения в своём репозитории.
Теперь если вы хотите, чтобы крутой дядя внёс ваши крутые изменения в свой крутой код. И вы просите, чтобы он взял ваши изменения, т.е. сделал git pull . Это и называется pull request
К вышесказанному можно добавить следующее. Далеко не все пулл-реквесты принимаются разработчиками. Тут нужно соблюсти ряд правил:
Пулл-реквест (ПР) должен быть хорошо оформлен и содержать исчерпывающее описание.
Обычное правило, один баг - один ПР, одна фича - один ПР. Не нужно пытаться впихнуть сразу кучу всего.
Очень важно соблюдать Code Style того проекта, для которого вы делаете ПР. Пусть даже он кажется вам противоестественным (например вы всегда делаете отступы в виде 4 пробелов, а в проекте табы).
Не нужно бояться делать ПР-ы, ведь помочь можно даже в мелочи. Например вы заметили ошибку перевода в readme файле или вам кажется что какое-то описание фичи можно более понятно перефразировать.
На гитхабе миллионы проектов, живущие исключительно на энтузиазме создателей, хорошие ПР-ы очень хорошо подстегивают этот энтузиазм)
3,254 1 1 золотой знак 13 13 серебряных знаков 31 31 бронзовый знакеще добавки к вышесказанному: возможный (я им пользуюсь) механизм работы с репами/pr:
git checkout -b названиеБранча (ветки)
теперь вы правите файлы в вашем origin, в вашей ветке, пушите их в свой форк гитхаба (origin), откуда и делаете pull-request
при этом вы можете сделать git merge/pull/fetch upstream с оригинального репозитория (upstream)
общий алгоритм работы примерно такой: git fetch; git merge upstream/ветка; (master/debug/и т.д.) сделали изменения: git push , изменения улетают в ваш форк на гитахабе. Eсли настроен travis, проходят тесты/сборки, когда вы уверены в качестве коммита, делаете pull request из вашего форка. Если PR приняли, делаете, допустим, git checkout master; git fetch; git merge upstream/ветка , чтобы ваш форк оставался консистентным с оригиналом.
Читайте также: