Existe um propósito para usar solicitações pull em meu próprio repositório se eu for o único desenvolvedor?

Então comecei com um projeto real no GitHub e as coisas estão indo muito bem e as idéias fluindo muito mais rapidamente do que eu pensava inicialmente. Para manter as coisas organizadas, configurei algumas ramificações para poder desenvolver diferentes recursos separadamente.

Agora, quando eu envio o meu ramo para o GitHub, tenho essa seção em que tenho dois botões: Pull Requeste Comparecom o nome do ramo que eu enviei recentemente. Entendo o objetivo do Comparebotão, mas não entendo por que gostaria de criar uma solicitação de recebimento em meu próprio repositório.

Alguém pode me explicar por que eu faria isso? É útil fazer solicitação pull em meu próprio repositório se eu for o único desenvolvedor?

Para muitos (talvez a maioria) desenvolvedores individuais trabalhando por conta própria, a criação de solicitações pull provavelmente não vale a pena. No entanto, posso pensar em pelo menos um motivo potencial para fazê-lo:

As solicitações pull podem ser usadas para acompanhar o histórico do seu projeto com mais facilidade. Uma solicitação de recebimento possui um ID de problema que pode ser referido a partir de mensagens de confirmação e em um log de alterações, o que permite que você volte facilmente e encontre o ponto de mesclagem e o conjunto de confirmações mescladas para uma alteração específica, sem precisar reter seu recurso filiais indefinidamente.

Por exemplo, no Pioneer (plugue descarado), quando mesclamos uma solicitação pull, adicionamos um item ao log de alterações , com uma descrição de uma linha da alteração e uma referência ao ID da solicitação pull. Obviamente, a Pioneer possui vários desenvolvedores, mas o mesmo mecanismo pode ser útil para um desenvolvedor que trabalha por conta própria.

Isso pode ser menos útil se você optar por manter um histórico de consolidação linear (reestruturando suas ramificações de recursos antes da mesclagem, para que a mesclagem possa sempre ser executada como um avanço rápido) e se você for muito disciplinado sobre editar e compactar suas confirma antes de mesclar para mestre, porque nesse caso as mensagens de confirmação individuais podem ser usadas como um registro de alterações em si mesmas.

As solicitações pull são criadas para que alguém possa revisar o trabalho, fazer comentários, sugestões, fazer ou solicitar edições e depois mesclar o código para dominar.

No seu caso, a pessoa é você.

Como desenvolvedor único, você ainda deve revisar seu próprio trabalho, refatorá-lo e fundi-lo para dominar quando estiver pronto.

Uma abordagem que uso muito é tentar 'colocar outro chapéu', 'tentar outras personas'. Então sente-se por um tempo e coloque-se na situação de: novato no grupo; Desenvolvedor Junior; colega que você respeitava no passado etc. Tente e olhe através dos olhos deles e tente pensar no que você poderia fazer para tornar a mudança mais óbvia, melhor escrita com nomes ainda melhores que evitam o máximo possível o conhecimento tribal e de domínio. .

Portanto, como você indicou, você deve trabalhar em ramificações quando quiser separar recursos e alterações que não estão prontas para o mestre. Você pode fazer tudo isso nas ramificações (você nem precisa de solicitações pull para gerenciá-las, se executar as tarefas de relações públicas de qualquer maneira, mas poderá fornecer uma estrutura útil para você).

Além disso, às vezes vou achar que minha alteração não está funcionando, mas, em vez do horror de tentar recuperá-la do mestre, talvez agora misturada com outras alterações mestre, posso fazer tudo isso em um ramo que, então, posso ignorar / delete se começar a dar errado. Este é um grande benefício.

Portanto, você deve trabalhar em ramificações e não se comprometer diretamente com o mestre até decidir mesclar a ramificação inteira.

Essas são diretrizes - e não regras - a serem seguidas. Eu os quebro intencionalmente às vezes. Por exemplo, ontem cometi uma correção de erro de digitação para dominar.

Parece que você tem ramificações remotas, bem como ramificações locais. Se você estiver achando demais a sobrecarga desse fluxo de trabalho, sempre poderá trabalhar em diferentes recursos usando ramificações locais sem forçá-los.

Basicamente, tudo se resume a fazer o que funciona para você. Trabalhar com branches é um grande benefício para o git, e o github facilita muito isso, mas como desenvolvedor solitário, não há uma grande necessidade de usar o modelo de solicitação pull e o comprometimento direto com o master deve funcionar bem. Quando seu projeto finalmente se torna incrivelmente bem-sucedido e dezenas ou centenas de desenvolvedores estão trabalhando nele, você verá que receber solicitações pull de seus garfos é uma ótima maneira de acompanhar o projeto.

Normalmente, as solicitações pull são usadas para revisões de código ou contribuições de usuários com seu próprio fork do projeto - para um único desenvolvedor de um projeto que não vejo realmente um propósito.

A razão pela qual faço isso é que é uma maneira conveniente de garantir que todas as verificações automatizadas sejam aprovadas (ele compila, possui formatação correta, os testes de unidade são aprovados ...).

Eu não necessariamente exijo que todas as verificações passem para cada confirmação, mas quero que o chefe da ramificação principal sempre passe nas verificações. Acho que as solicitações pull são o caminho mais fácil (talvez não o único).

De maneira mais geral, é uma maneira de conectar ganchos para concluir as alterações. Testes são um exemplo; @ John mencionou a criação de notas de versão como outro exemplo.

As solicitações pull versus git push se resumem a uma história individual ou compartilhada. O repositório principal é a fonte de todas as alterações, se outras pessoas estiverem retirando e potencialmente fazendo alterações locais, uma solicitação de envio poderá causar problemas a esses usuários como a árvore da qual eles estão derivando de alterações.

O modelo de solicitação de recebimento (de ramificações personalizadas ou repositórios pessoais) serve como uma maneira de fornecer histórico consistente para todos aqueles que usam e derivam do código.

Parte do motivo pelo qual você está colocando código no github seria disponibilizar o código para bifurcação e receber solicitações. Você nunca sabia quando isso aconteceria, e manter consistente o histórico de seus co-desenvolvedores seria uma grande vantagem.