Propondo uma mudança no código

Nette Framework utiliza Git e GitHub para manter a base de códigos. A melhor maneira de contribuir é comprometer suas mudanças em seu próprio garfo e depois fazer um pedido de puxar em GitHub. Este documento resume os principais passos para contribuir com sucesso.

Preparando o ambiente

Comece com o forking Nette no GitHub. Configure cuidadosamente seu ambiente Git local, configure seu nome de usuário e e-mail, estas credenciais identificarão suas mudanças no histórico do Nette Framework.

Trabalhando em seu Patch

Antes de começar a trabalhar em seu patch, crie uma nova filial para suas mudanças.

git checkout -b new_branch_name

Você pode trabalhar na mudança do seu código.

Se possível, fazer alterações a partir da última versão lançada.

Testando suas mudanças

Você precisa instalar o Nette Tester. A maneira mais fácil é ligar para composer install na raiz do repositório. Agora você deve ser capaz de executar testes com ./vendor/bin/tester no terminal.

Alguns testes podem falhar devido à falta do php.ini. Portanto, você deve chamar o corredor com o parâmetro -c e especificar o caminho para o php.ini, por exemplo ./vendor/bin/tester -c ./tests/php.ini.

Depois que você for capaz de executar os testes, você pode implementar seus próprios testes ou mudar a falha para se adequar ao novo comportamento. Leia mais sobre os testes com o Nette Tester na página de documentação.

Normas de Codificação

Seu código deve seguir o padrão de codificação utilizado no Nette Framework. É fácil porque há um verificador e um reparador automáticos. Ele pode ser instalado via Composer em seu diretório global escolhido:

composer create-project nette/coding-standard /path/to/nette-coding-standard

Agora você deve ser capaz de executar a ferramenta no terminal. Por exemplo, este comando verifica e corrige o código nas pastas src e tests no diretório atual:

/path/to/nette-coding-standard/ecs check src tests --config /path/to/nette-coding-standard/coding-standard-php71.yml --fix

Cometendo as mudanças

Depois de ter mudado o código, você tem que comprometer suas mudanças. Crie mais compromissos, um para cada passo lógico. Cada compromisso deveria ter sido utilizável como está – sem outros compromissos. Portanto, os testes apropriados também devem ser incluídos no mesmo commit.

Por favor, verifique novamente se seu código se encaixa nas regras:

• O código não gera nenhum erro
• Seu código não quebra nenhum teste.
• Sua mudança de código é testada.
• Você não está cometendo mudanças inúteis no espaço branco.

A mensagem de compromisso deve seguir o formato Latte: fixed multi template rendering [Closes # 69] ou seja

• uma área seguida por um cólon
• o objetivo do compromisso no passado, se possível, começar com “adicionado”, “fixo”, “refatorado”, alterado, removido
• eventual link para o rastreador de emissões
• se a compatibilidade retroativa for cancelada, adicionar “BC break”.
• pode haver uma linha gratuita após o assunto e uma descrição mais detalhada incluindo links para o fórum.

Puxar-Requisitar os Compromissos

Se você está satisfeito com suas mudanças de código e se compromete, você tem que empurrar seu compromisso com o GitHub.

git push origin new_branch_name

As mudanças estão presentes publicamente, no entanto, você tem que propor suas mudanças para integração no ramo principal da Nette. Para fazer isso, faça um pedido de puxar. Cada pedido de puxar tem um título e uma descrição. Por favor, forneça algum título descritivo. Muitas vezes é semelhante ao nome da filial, por exemplo “Assegurando sinais contra ataque do CSRF”.

A descrição do pedido deve conter algumas informações mais específicas sobre suas mudanças de código:

- bug fix? yes/no   <!-- #issue numbers, if any -->
- new feature? yes/no
- BC break? yes/no
- doc PR: nette/docs#???  <!-- highly welcome, see https://nette.org/en/writing -->

Favor alterar a tabela de informações para se adequar ao seu pedido de puxar. Comentários a cada item da lista:

• Diz se a solicitação de puxar adiciona ** recurso*** ou é um **bugfix***.
• Referências eventualmente** relacionadas ao ** problema**, que serão fechadas após a fusão da solicitação de puxar.
• Diz se a solicitação pull precisar da documentação mudar, se sim, fornecer referências para as solicitações pull apropriadas. Não é necessário fornecer a mudança de documentação imediatamente, entretanto, a solicitação pull não será fundida se for necessária a mudança de documentação. A alteração da documentação deve ser preparada para a documentação em inglês, as mutações em outros idiomas são opcionais.
• Diz que se a solicitação pull criar **a BC break***. Por favor, considere tudo o que muda a interface pública como um intervalo BC.

A mesa final poderia ser parecida:

- bug fix? no
- new feature? yes   issue #123
- BC break? no

Reestruturando suas mudanças

É realmente comum receber comentários para sua mudança de código. Por favor, tente seguir as mudanças propostas e retrabalhe seus compromissos para fazer isso. Você pode comprometer-se com as mudanças propostas como novos compromissos e depois esmagá-las em relação aos anteriores. Veja o capítulo sobre o GitHub no Rebase Interactive. Depois de rebasear suas mudanças, force-push suas mudanças para seu garfo remoto, tudo será automaticamente propagado para o pedido de puxar.