Esta seção é direcionada aos Committers e a todos os interessados em saber como um trecho de código é incorporado ao Django pelos desenvolvedores do projeto. Se você é um membro da comunidade que deseja contribuir com o Django enviando o seu código, dê uma olhada em Trabalhando com Git e GitHub.
\nComo o Django agora é hospedado no GitHub, a maioria das melhorias é fornecida na forma de pull requests.
\nAo fazer um pull request, certifique-se de que cada commit individualmente satisfaça as regras descritas abaixo. Espera-se de quem contribui os melhores pull requests possíveis de se fornecer. Na prática, entretanto, os committers, - quem provavelmente estará mais familiarizado com as regras do projeto - podem decidir melhorar a qualidade de um commit por conta própria.
\n\nUm jeito fácil de fazer checkout de um pull request localmente é adicionando um alias no seu ~/.gitconfig (estamos assumindo que django/django é o nosso upstream):
[alias]\n pr = !sh -c \\"git fetch upstream pull/${1}/head:pr/${1} && git checkout pr/${1}\\"\nAgora você pode simplesmente executar git pr #### para realizar o checkout do pull request correspondente.
A partir deste momento, você pode trabalhar no código. Utilize git rebase -i e git commit --amend para garantir que os commits tenham o nível de qualidade desejado. Quando você estiver pronto:
$ # Pull in the latest changes from master.\n$ git checkout master\n$ git pull upstream master\n$ # Rebase the pull request on master.\n$ git checkout pr/####\n$ git rebase master\n$ git checkout master\n$ # Merge the work as "fast-forward" to master to avoid a merge commit.\n$ # (in practice, you can omit "--ff-only" since you just rebased)\n$ git merge --ff-only pr/XXXX\n$ # If you're not sure if you did things correctly, check that only the\n$ # changes you expect will be pushed to upstream.\n$ git push --dry-run upstream master\n$ # Push!\n$ git push upstream master\n$ # Delete the pull request branch.\n$ git branch -d pr/xxxx\nPara mudanças em suas próprias branches, force o push no seu fork depois de fazer o rebase na master mas antes de fazer merge e push para o upstream. Isso permite que os hashes dos commits na master e na sua branch coincidam o que fecha o pull request automaticamente. Como você não pode fazer push na branch de outros contribuidores, comente no pull request “Merged in XXXXXXX” (trocando pelo hash do commit) depois que você fizer o merge. Trac procura esse formato de mensagem para indicar na página do ticket se foi feito um merge de um pull request ou não.
\nEvite usar o botão “Merge pull request” no site do GitHub já que isso cria um “merge commit” tosco fazendo a navegação no histórico ficar mais difícil.
\nQuando estiver reescrevendo o histórico de commits de um pull request, o objetivo é fazer com que o histórico de commits do Django seja o mais útil possível:
\nSe um patch possui retornos e avanços nos commits, então reescreva esses em um só. Por exemplo, se um commit adiciona mais código e um segundo commit faz ajustes em problemas de estilo introduzidos pelo primeiro commit, esses commits devem ser unificados antes de se fazer um merge.
Separe as mudanças em diferentes commits por grupos lógicos: se você faz uma limpeza de estilo ao mesmo tempo em que você faz outras mudanças em um arquivo, a separação dessas mudanças em dois commits diferentes fará a revisão do histórico de alterações mais simples.
Cuidado com merges de branches do upstream dentro de pull requests.
Testes devem passar e a documentação deve ser gerada depois de cada commit. Testes e documentação não devem emitir quaisquer warnings.
Patchs triviais e pequenos costumam ser melhor realizados em um único commit. Já trabalhos médios ou maiores podem ser quebrados em múltiplos commits se isso fizer sentido.
Praticidade vence pureza, então vai de cada committer decidir o quanto refinar o histórico antes de um pull request. Os principais objetivos devem ser engajar a comunidade, terminar o trabalho, e ter um histórico de commits utilizável.
\nAdicionalmente, por favor siga as regras a seguir quando estiver commitando código para o repositório do Django no git:
\nNunca mude o histórico publicado das branches django/django! Nunca force um push para django/django. Se você absolutamente precisar (por questões de segurança por exemplo) primeiro discuta a situação com o time do projeto.
Para qualquer mudança de média para grande, onde “média para grande” é de acordo com o seu próprio julgamento, por favor traga o problema para a lista de e-mail django-developers antes de fazer a mudança.
\nSe você trouxer algo novo para a lista django-developers e ninguém te respondeu por favor não entenda isso como sendo um sinal de que a sua ideia é excelente e deve ser implementada imediatamente já ninguém a contestou. Os desenvolvedores do Django não tem muito tempo disponível para ler as discussões na lista de e-mail imediatamente. Então você pode precisar esperar alguns dias antes de conseguir uma resposta.
\nEscreva os commits com mensagens detalhadas e utilizando o passado como tempo verbal, não o presente.
\nBom: “Corrigido bug de Unicode na API de RSS.”
Ruim: “Corrige bug de Unicode na API de RSS.”
Ruim: “Corrigindo bug de Unicode na API de RSS.”
As mensagens de commit devem ser em linhas de no máximo 72 caracteres. Deve existir uma linha de assunto, separada por uma linha em branco e então parágrafos de linhas de 72 caracteres. Os limites são boas práticas. Para a linha de assunto, quanto mais curta melhor. Em um corpo de uma mensagem de commit mais detalhes é melhor que menos:
\nFixed #18307 -- Added git workflow guidelines\n\nRefactored the Django's documentation to remove mentions of SVN\nspecific tasks. Added guidelines of how to use Git, GitHub, and\nhow to use pull request together with Trac instead.\nSe o patch não foi um pull request, você deverá dar crédito as pessoas que contribuiram na mensagem de commit: “Obrigado A por avisar, B pelo patch e C por revisar.”
\nPara commits em uma branch, coloque antes da mensagem de commit o nome da branch. Por exemplo: “[1.4.x] Corrigido #xxxxx – Adicionado suporte para leitura de mentes.”
Limite os commits para a mudança mais granular que fizer sentido. Isso significa, fazer uso de commits pequenos e frequentes ao invés de commits grandes e pouco frequentes. Por exemplo, se implementar a funcionalidade X requer uma pequena mudança na biblioteca Y, primeiro faça um commit da mudança na biblioteca Y, depois faça commit da funcionalidade X em um outro commit separado. Isso já facilita muito no processo de ajudar todos os desenvolvedores do Django a seguir as suas alterações.
Separe as correções de bug das mudanças nas funcionalidades. Correções de bug podem ter que ser portadas para a branch stable, de acordo com a backwards-compatibility política de compatibilidade.
Se o seu commit fecha um ticket no rastreador de tickets do Django, comece a sua mensagem de commit com o texto “Fixed #xxxxx”, onde “xxxxx” é o número do ticket que o seu commit corrige. Exemplo: “Corrigido #123 – Adicionada a funcionalidade whizbang.”.\nNós configuramos o Trac de modo que qualquer mensagem de commit nesse formato irá automaticamente fechar o ticket referenciado e colocar um comentário nele com a mensagem completa do commit.
\nSe o seu commit fecha um ticket e está dentro de uma branch, utilize o nome da branch primeiro, depois o “Corrigido #xxxxx.” Por exemplo: “[1.4.x] Corrigido #123 – Adicionada a funcionalidade whizbang.”
\nPara os curiosos, nós estamos utilizando um plugin do Track para isso.
\nSe o seu commit faz referência a um ticket no rastreador de tickets do Django mas não fecha o ticket, inclua a frase “Refs #xxxxx”, onde “xxxxx” é o número do ticket que o seu commit faz menção. Isso irá automaticamente postar um comentário na página do respectivo ticket.
Escreva mensagens de commit para backports usando este formato:
\n[<Django version>] Fixed <ticket> -- <description>\n\nBackport of <revision> from <branch>.\nPor exemplo:
\n[1.3.x] Fixed #17028 -- Changed diveintopython.org -> diveintopython.net.\n\nBackport of 80c0cbf1c97047daed2c5b41b296bbc56fe1d7e3 from master.\nExiste um script na wiki para automatizar isso.
\nNinguém é perfeito; erros serão comitados.
\nMas esforce-se de verdade para garantir que erros não aconteçam. O fato de termos uma política de reversão não reduz a sua responsabilidade em buscar o maior padrão de qualidade possível. De verdade: revise o seu trabalho duas vezes, ou deixe ele ser revisado por outro committer, antes de você já ter feito o commit dele!
\nQuando um commit indevido é descoberto, por favor siga as instruções abaixo:
\nSe possível, deixe que o autor original reverta o seu próprio commit.
Não faça o revert das mudanças de outro autor sem a permissão do autor original.
Utilize o git revert – isso irá fazer um commit reverso, mas o commit original ainda será parte do histórico de commits.
Se o autor original não puder ser encontrado (dentro de um prazo razoável – um dia ou algo assim) e o problema é severo – bug quebrando a build, vários testes falhando, etc. – então pergunte se existe alguma objeção na lista de e-mail django-developers e então reverta o código se elas não existirem.
Se o problema é pequeno (uma funcionalidade congelada, por exemplo) aguarde.
Se existir um desacordo entre o committer e o autor do código a sofrer um revert então tente solucionar o problema na lista de e-mail django-developers. Se um acordo não puder ser encontrado então o problema deve ser submetido a uma votação.
Se o commit introduziu uma vulnerabilidade de segurança confirmada, aberta então o commit deve ser revertido imediatamente sem permissão de ninguém.
O mantenedor da branch de releases pode voltar commits nessa branch sem permissão caso o commit tenha quebrado a branch de releases.
Se você sem querer fez um push de uma branch para django/django, simplesmente delete ela. Por exemplo, se você fez: git push upstream funcionalidade_antigravidade`, apenas faça um push reverso: git push upstream :funcionalidade_antigravidade.