Esta seção é destinada para os committers e para qualquer interessado em entender como o código é comitado no Django. Se você é membro de uma comunidade e quer contribuir com código para o Django, veja o Trabalhando com Git e GitHub.
\nComo o Django é hospeado no GitbHub, os patches são provisionados 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.
\nVocê pode querer ter o Jenkins a testar o pull request com um dos pull requests builders que não rodem automaticamente, como o Oracle or Selenium. Veja a página wiki do Jenkins para mais instruções
\nIf you find yourself checking out pull requests locally more often, this git\nalias will be helpful:
\n[alias]\n pr = !sh -c \\"git fetch upstream pull/${1}/head:pr/${1} && git checkout pr/${1}\\"\nAdd it to your ~/.gitconfig, and set upstream to be django/django.\nThen you can run git pr #### to checkout the corresponding pull request.
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:
Linux / macOS
$ # Pull in the latest changes from main.\n$ git checkout main\n$ git pull upstream main\n$ # Rebase the pull request on main.\n$ git checkout pr/####\n$ git rebase main\n$ git checkout main\n$ # Merge the work as "fast-forward" to main 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 main\n$ # Push!\n$ git push upstream main\n$ # Delete the pull request branch.\n$ git branch -d pr/xxxx\nWindows
...\\> REM Pull in the latest changes from main.\n...\\> git checkout main\n...\\> git pull upstream main\n...\\> REM Rebase the pull request on main.\n...\\> git checkout pr/####\n...\\> git rebase main\n...\\> git checkout main\n...\\> REM Merge the work as "fast-forward" to main to avoid a merge commit.\n...\\> REM (in practice, you can omit "--ff-only" since you just rebased)\n...\\> git merge --ff-only pr/XXXX\n...\\> REM If you're not sure if you did things correctly, check that only the\n...\\> REM changes you expect will be pushed to upstream.\n...\\> git push --dry-run upstream main\n...\\> REM Push!\n...\\> git push upstream main\n...\\> REM Delete the pull request branch.\n...\\> git branch -d pr/xxxx\nForce push to the branch after rebasing on main but before merging and pushing\nto upstream. This allows the commit hashes on main and the branch to match\nwhich automatically closes the pull request.
\nIf a pull request doesn’t need to be merged as multiple commits, you can use\nGitHub’s “Squash and merge” button on the website. Edit the commit message as\nneeded to conform to the guidelines and remove\nthe pull request number that’s automatically appended to the message’s first\nline.
\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. Nem os testes, nem a documentação devem emitir avisos.
Patchs triviais e pequenos costumam ser melhor realizados em um único commit. Trabalhos médios ou maiores podem ser quebrados em múltiplos commits se isso fizer sentido.
Praticidade vence pureza, então cabe a cada committer decidir o quanto refinar o histórico antes de um pull request. O principal é 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 altere o histórico publicado dos “branches” do django/django através de um “push” forçado. Se for absolutamente necessário (por razões de segurança), primeiro discuta a situação com o time.
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.
\nIf you bring something up on django-developers and nobody responds,\nplease don’t take that to mean your idea is great and should be\nimplemented immediately because nobody contested it. Everyone doesn’t always\nhave a lot of time to read mailing list discussions immediately, so you may\nhave to wait a couple of days before getting a response.
\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.”
The commit message should be in lines of 72 chars maximum. There should be\na subject line, separated by a blank line and then paragraphs of 72 char\nlines. The limits are soft. For the subject line, shorter is better. In the\nbody of the commit message more detail is better than less:
\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.\nCredit the contributors in the commit message: “Thanks A for the report and B\nfor review.” Use git’s Co-Authored-By as appropriate.
\nPara commits em uma branch, coloque antes da mensagem de commit o nome da branch. Por exemplo: “[1.4.x] Fixed #xxxxx – Adicionado suporte para leitura de mentes.”
Limit commits to the most granular change that makes sense. This means,\nuse frequent small commits rather than infrequent large commits. For\nexample, if implementing feature X requires a small change to library Y,\nfirst commit the change to library Y, then commit feature X in a separate\ncommit. This goes a long way in helping everyone follow your changes.
Separate bug fixes from feature changes. Bugfixes may need to be backported\nto the stable branch, according to Versões suportadas.
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.
\nPara os curiosos, nós estamos utilizando um Trac plugin 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 esse 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 main.\nExiste um script na wiki para automatizar isso.
\nIf the commit fixes a regression, include this in the commit message:
\nRegression in 6ecccad711b52f9273b1acb07a57d3f806e93928.\n(use the commit hash where the regression was introduced).
\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.
If you mistakenly push a topic branch to django/django, delete it.\nFor instance, if you did: git push upstream feature_antigravity,\ndo a reverse push: git push upstream :feature_antigravity.