Есть ли цель использовать запросы на извлечение в моем репо, если я единственный разработчик?

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

Теперь, когда я перемещаю свою ветку в GitHub, у меня есть тот раздел, где у меня есть две кнопки: Pull Requestи Compareс названием ветви, в которую я недавно нажал. Я понимаю назначение Compareкнопки, но не понимаю, почему я хотел бы создать пул-запрос в своем репо.

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

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

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

Например, в Pioneer (бесстыдный плагин), когда мы объединяем запрос на извлечение, мы добавляем элемент в журнал изменений с описанием в одну строку изменения и ссылкой на идентификатор запроса на извлечение. Конечно, в Pioneer есть несколько разработчиков, но один и тот же механизм может быть полезен для разработчика, работающего самостоятельно.

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

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

В вашем случае кто-то это вы.

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

Один из подходов, который я часто использую, - это попытаться «надеть другую шляпу», «попробовать других людей». Так что посидите ненадолго и поставьте себя в положение: новичка в группе; младший разработчик; коллега, которого вы уважали в прошлом и т. д. Попробуйте взглянуть на него своими глазами и постарайтесь просто подумать, что вы могли бы сделать, чтобы изменение стало более очевидным, лучше написанным с еще лучшими именами, максимально избегающими знания племенных и предметных областей. ,

Итак, как вы указали, вы должны работать в ветвях, когда вы хотите отделить функции и изменения, которые не готовы для мастера. Вы можете делать все это в филиалах (вам даже не нужны запросы на управление, если вы все равно выполняете PR-задания, но это может предоставить вам полезную структуру).

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

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

Это руководящие принципы - а не правила - следовать. Я намеренно ломаю их иногда. Например, вчера я исправил опечатку с мастером.

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

Это в основном сводится к тому, что работает для вас. Работа с ветками - это огромное преимущество для git, и github делает это действительно легко, но как одиночному разработчику нет особой необходимости использовать модель запросов на выборку, и фиксация непосредственно на master должна работать просто отлично. Когда ваш проект в конечном итоге станет невероятно успешным, и над ним будут работать десятки или сотни разработчиков, вы обнаружите, что получение запросов от своих вилок - отличный способ отслеживать проект.

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

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

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

В более общем смысле это способ подключения хуков для завершения изменений. Тесты являются примером; @John упомянул создание заметок о выпуске в качестве другого примера.

Запросы Pull против Git Push в конечном итоге сводятся к одной из отдельных или общей истории. Основной репозиторий является источником всех изменений. Если другие извлекают данные и вносят локальные изменения, то push-запрос может вызвать проблемы этих пользователей в виде дерева, которое они выводят из изменений.

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

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