5 ideias para um fluxo de trabalho aprimorado do GitHub
Dependendo do seu histórico com o controle do código-fonte em funcionamento, a maneira como você trabalha com uma base de código, fazendo commits, etc., varia.
Além disso, dependendo se você estiver usando Git, Subversion, Mercurial e assim por diante, também ditam como você gerencia seu código.
Mas se você é alguém que está trabalhando com Git (que eu sei que muitas pessoas no WordPress estão começando a usar cada vez mais quase diariamente), existem algumas pequenas coisas que eu recomendo fazer para ajudar a gerenciar mudanças especialmente com uma equipe mais gerenciável.
Dicas para um fluxo de trabalho aprimorado do GitHub
1 Não se comprometa com o mestre
Master deve ser usado especificamente para código pronto para produção e pronto para implantação. Não é o seu ramo de trabalho, não é o seu ramo de trabalho.
De um modo geral, é aqui que todas as solicitações pull são mescladas.
2 Tente sempre criar ramificações
Sempre que você tiver uma coleção de tarefas, problemas ou marcos, crie uma ramificação e verifique se o que você está trabalhando está relacionado. Por exemplo, você não quer trabalhar com banco de dados e JavaScript em suas pull requests.
3 Lote seu trabalho
Mesmo se você estiver trabalhando apenas no trabalho de front-end, talvez seja necessário dividi-lo em ramificações menores. Isso facilita as revisões de código e as solicitações de pull melhores .
4 Gerar Pequenos PRs
Isso é muito semelhante ao título anterior, mas a ideia de criar pequenos PRs é muito mais produtiva do que criar pull requests mais longos.
- Isso ajuda quando você precisa solicitar uma revisão de código, pois oferece aos seus colegas de equipe uma maneira mais fácil de lidar com revisões de código e oferecer feedback.
- Ele mantém o log de alterações enxuto e ajuda a fornecer um relatório detalhado do que o lote específico de código faz.
Mas o que constitui um bom PR?
5 Dê bons detalhes em seu PR
No que me diz respeito, uma boa solicitação de pull fará um pequeno conjunto de coisas:
- Detalhe, em apenas uma frase ou duas, o que a pessoa que está analisando suas alterações deve esperar que aconteça.
- Vincule o PR ao ticket, cartão de gerenciamento de projeto (ou o que eles chamam em seu sistema),
- Liste versões mais curtas das mensagens de confirmação para facilitar ao máximo o seu revisor.
Dito isso, provavelmente há mais coisas que você pode fazer, mas essas são as coisas que eu achei mais úteis (e eu ficaria remido em dizer que não aprendi algumas dessas coisas com minha equipe ).
Há mais coisas?
Sempre.
Mas essas são algumas coisas que eu descobri serem cada vez mais úteis, especialmente ao rastrear mudanças, trabalhar com outras pessoas e lidar com solicitações de pull (tanto daqueles com quem eu trabalho quanto daqueles que contribuem para projetos de código aberto).
Finalmente, nenhuma dessas coisas é prescritiva. Há uma curva de aprendizado (falando por experiência), mas eu recomendo experimentar algumas delas, se não por outro motivo, a não ser para ver se isso não melhora seu fluxo de trabalho.
Mesmo que seja um pouco.