Apresentando solicitações pull para uma equipe de 2 pessoas - mesclar minhas próprias solicitações?


11

Estou apresentando o git a um membro da equipe júnior (uma cooperativa).

Eles estão confortáveis ​​agora com o básico de adicionar, confirmar, empurrar e puxar.

Agora, quero apresentá-los a receber solicitações e ramificações.

Se eles começarem a fazer solicitações pull nas filiais, devo fazer o mesmo pelo meu trabalho contínuo?
Eu serei o único a combinar as solicitações pull. Eu não tinha certeza se faria mais sentido trabalhar em filiais (geralmente é uma boa prática que eu conheço, mas estou curioso sobre essa situação específica de 2 desenvolvedores com um júnior ) e, se for o caso, isso significa que apenas fundirei meus próprios ramos no mestre. Mesmo assim, eu faria uma solicitação de recebimento para meu trabalho / ramificações? Geralmente, usamos o fluxo de trabalho básico de ramificação de recursos do github para essas alterações:
https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow

Existe um propósito para usar solicitações pull em meu próprio repositório se eu for o único desenvolvedor? é útil, mas não tão específico.

Qual é o fluxo de trabalho com 2 pessoas em um projeto também parece mais geral

e

Devo abrir solicitações pull de uma filial no repo oficial ou no meu fork? parece mais sobre garfos.

Respostas:


19

Não. Você não deve mesclar suas próprias solicitações pull. O que é bom para o ganso é bom para o gander. A mesclagem de suas próprias solicitações de recebimento cria um precedente ruim para nosso desenvolvedor júnior. Isso também significa que ninguém mais está olhando para o seu código. Não importa quão veteranos possamos ser, todos cometemos erros e escrevemos códigos incorretos de tempos em tempos. Ensine ao seu aluno como as revisões de código funcionam do outro lado, fazendo-o revisar e mesclar seu trabalho.

Ele pode não ter o mesmo olho que você, mas isso o acostumará com o processo desde o final do revisor e ele poderá surpreendê-lo e pegar algo estúpido que você fez. No mínimo, isso lhe dará uma indicação de partes do código que são óbvias para você, que não são óbvias para ele. Isso tem um benefício duplo.

  1. Vocês dois aprendem onde seus alunos mais jovens precisam se concentrar nas atividades de aprendizado.
  2. Você aprende onde está sendo mais esperto do que deveria.

6
O outro grande benefício das revisões de código é que pelo menos duas pessoas viram, conhecem e tiveram a chance de fazer perguntas sobre cada alteração de código antes que ela entre. Mesmo que o desenvolvedor júnior não saiba o que procurar, ele é garantido aprender algo com tudo isso.
Ixrec
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.