Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Este artigo documenta como gerenciamos solicitações de pull no repositório do PowerShell-Docs. O artigo foi projetado para ser um auxílio de trabalho para membros da equipe do PowerShell-Docs. Publicamos essas informações aqui para fornecer transparência de processo para nossos colaboradores públicos.
Práticas recomendadas
- Solicite uma avaliação. A pessoa que envia o PR não deve mesclá-lo sem uma revisão por pares.
- Atribua o revisor em pares quando a PR for enviada. A atribuição antecipada permite que o revisor responda mais cedo com comentários editoriais.
- Use comentários para descrever a natureza da alteração que está sendo enviada. Por exemplo, se a alteração for pequena, explique-a e diga que você não precisa de uma revisão técnica completa. Mencione o revisor com @mention.
- Use o recurso de sugestão de comentários para facilitar ao autor aceitar a alteração sugerida. Para obter mais informações, consulte Como revisar as alterações propostas em uma solicitação de pull.
Etapas do processo de PR
- Escritor: Criar RP
- Preencha o modelo de RP
- Vincular quaisquer problemas resolvidos pela PR
- Usar o recurso autoclose do GitHub para fechar o problema
- Trabalhe e marque cada item da lista de verificação
- Escritor: Atribuir revisor por pares
- Revisor: fazer a revisão e inserir comentários (conforme necessário)
- Escritor: Incorpore o feedback da revisão
- Ambos: Revisar renderização de visualização
- Ambos: Revisar relatório de validação - corrigir avisos e erros
- Avaliador: Marque a avaliação como "Aprovado"
- Mantenedor do repositório: Merge PR
Lista de verificação do revisor de conteúdo
Confira a lista de verificação editorial para obter uma listagem mais abrangente.
- Revisar gramática, estilo, concisão, precisão técnica
- Verificar se os exemplos ainda se aplicam à versão de destino
- Conferir a renderização de versão prévia
- Conferir os metadados – ms.date, remover ms.assetid, garantir os campos obrigatórios
- Validar a correção da marcação
- Consulte o guia de estilo para regras de formatação específicas do conteúdo
- Reorganize os exemplos da seguinte forma:
- Parágrafo de introdução
- Código e saída
- Explicação detalhada do código (conforme necessário)
- Verificar a precisão dos hiperlinks
- Substituir ou remover links TechNet/MSDN
- Garantir o número mínimo de redirecionamentos para o destino
- Garantir o HTTPS
- Corrigir tipo de link
- Links para arquivos locais
- Links de URL para arquivos fora do docset
- Remover localidades de URLs
- Simplificar URLs que apontam para
learn.microsoft.com
- Verifique se o conteúdo versionado está correto em todas as versões
Processo de mesclagem de branch
O branch main é o único branch que deve ser incorporado em live. As mesclagens de branches de curta duração (funcionais) devem ser comprimidas antes de serem mescladas em main.
| Mesclar de/para | branch-lançamento | principal | ao vivo |
|---|---|---|---|
| branch-trabalho | squash e mesclar | squash e mesclar | Não permitido |
| branch-lançamento | – | mesclar | Não permitido |
| principal | trocar base | – | mesclar |
Lista de verificação de mesclagem de PR
- Revisão de conteúdo concluída
- Branch de destino correto para a alteração
- Sem conflitos de mesclagem
- Todas as validações e etapas de build aprovadas
- Avisos e sugestões devem ser corrigidos (confira Observações para ver exceções)
- Nenhum link desfeito
- A ação da Lista de Verificação foi executada e aprovada
- Se uma verificação de Autorização foi acionada, ela foi aprovada
- Mesclar de acordo com a tabela
Anotações
Os seguintes avisos podem ser ignorados:
Can't find service name for `<version>/<modulepath>/About/About.md`
Metadata with following name(s) are not allowed to be set in YAML header, or as file level
metadata in docfx.json, or as global metadata in docfx.json: `locale`. They are generated by
Docs platform, so the values set in these 3 places will be ignored. Please remove them from all
3 places to resolve the warning.
Quando uma PR é mesclada, o HEAD do branch de destino é alterado. Qualquer PR aberta com base no HEAD anterior agora está desatualizada. Um Mantenedor tem o direito necessário para substituir os avisos de mesclagem e mesclar o PR desatualizado no GitHub. Mesclar um PR desatualizado é seguro se os PRs mesclados anteriormente não tocarem nos mesmos arquivos.
Para atualizar o PR, selecione o botão Atualizar Branch. Selecione a opção Atualizar com rebase. Para obter mais informações, consulte Atualizar seu branch de solicitação de pull.
Publicar no site dinâmico
Periodicamente, as alterações acumuladas no branch main precisam ser publicadas no site dinâmico.
- O branch
mainé mesclado comlivetodos os dias úteis às 15h PST. - O branch
maindeve ser mesclado noliveapós qualquer alteração significativa.- Alterações em 50 ou mais arquivos
- Depois de mesclar um branch de lançamento
- Alterações nas configurações de repositório ou docset (docfx.json, configurações OPS, scripts de compilação etc.)
- Alterações no arquivo de redirecionamento
- Alterações no TOC
- Depois de mesclar um branch de "projeto" (reorganização de conteúdo, atualização em massa etc.)