This repository has been archived by the owner on Oct 3, 2019. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 13
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Signed-off-by: Isaque Alves <[email protected]>
- Loading branch information
1 parent
560e9bd
commit 0e6521f
Showing
1 changed file
with
34 additions
and
28 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -3,47 +3,50 @@ | |
| ### Política de Branches | ||
|
|
||
| #### master | ||
| A branch master é a branch de produção, onde ficará a versão estável do projeto. Ela estará bloqueada para commits e para pushs. | ||
| Veja a política de merges no tópico POLITICA_DE_MERGES-MASTER. | ||
|
|
||
| <p align="justify">  A branch master é a branch de produção, onde ficará a versão estável do projeto. Ela estará bloqueada para commits e para pushs. | ||
| Veja a política de merges no tópico POLITICA_DE_MERGES-MASTER.</p> | ||
|
|
||
| #### development | ||
| A branch development é a branch de desenvolvimento, onde o trabalho das outras branchs será unificado e onde será criada uma versão estável para mesclar com a master. | ||
|
|
||
| <p align="justify">  A branch development é a branch de desenvolvimento, onde o trabalho das outras branchs será unificado e onde será criada uma versão estável para mesclar com a master. | ||
| Assim como a master ela está bloqueada para commits e pushs. | ||
| Veja a política de merges no tópico POLITICA_DE_MERGES-DEVELOPMENT. | ||
| Veja a política de merges no tópico POLITICA_DE_MERGES-DEVELOPMENT.</p> | ||
|
|
||
| #### Nome das Branches | ||
|
|
||
| X_descricao_da_issue | ||
| ##### X_descricao_da_issue | ||
|
|
||
| <p align="justify">  As branchs de desenvolvimento de features serão criadas a partir da branch development com a nomenclatura padrão “X_descricao_da_issue”.</p> | ||
|
|
||
| As branchs de desenvolvimento de features serão criadas a partir da branch development com a nomenclatura padrão “X_descricao_da_issue”. | ||
| <p align="justify">  Em casos de issues de features de produção, o nome da branch deve ser “X_nome_da_issue”.</p> | ||
|
|
||
| Em casos de issues de features de produção, o nome da branch deve ser “X_nome_da_issue”. | ||
| <p align="justify">  X representa o código de rastreio da issue. | ||
| Para criar a branch, vá para a branch `development`:</p> | ||
|
|
||
| X representa o código de rastreio da issue. | ||
| Para criar a branch, vá para a branch `development`: | ||
| ``` | ||
| git checkout development | ||
| ``` | ||
| Depois é só criar a branch e pronto!, está pronto para produzir. | ||
| <p align="justify">  Depois é só criar a branch e está pronto para produzir!</p> | ||
| ``` | ||
| git checkout -b X_nome_da_issue | ||
| ``` | ||
|
|
||
| ### Política de Commits | ||
|
|
||
| Todos os commits devem ser feitos usando o comando `-s` para indicar sua assinatura no commit. | ||
| <p align="justify">  Todos os commits devem ser feitos usando o comando `-s` para indicar sua assinatura no commit.</p> | ||
| ``` | ||
| git commit -s | ||
| ``` | ||
| A issue em questão deve ser citada no commit, para isso, basta adicionar `#`+numero_da_issue ao commit. | ||
| <p align="justify">  A issue em questão deve ser citada no commit, para isso, basta adicionar `#`+numero_da_issue ao commit.</p> | ||
|
|
||
| ``` | ||
| git commit -sm"#5 Fazendo guia de contribuição" | ||
| ``` | ||
|
|
||
| [[docs/img/commit-individual.png|Commit individual]] | ||
|
|
||
| Para commits em dupla deve ser usado o comando `-s` igualmente, e deve ser adicionado a assinatura da sua dupla. | ||
| <p align="justify">  Para commits em dupla deve ser usado o comando `-s` igualmente, e deve ser adicionado a assinatura da sua dupla.</p> | ||
|
|
||
| ``` | ||
| git commit -s | ||
|
|
@@ -59,12 +62,14 @@ Signed-off-by: Eliseu Egewarth <[email protected]> | |
| [[docs/img/commit-dupla.png|Commit dupla]] | ||
|
|
||
| ### Política de Merges e Pull Requests | ||
|
|
||
| #### Pull Requests | ||
| Os pull requests externos devem ser feitos apenas para a branch `development` seguindo as regras e os passos do tópico "Merges para development". No conteúdo do pull request deve haver uma descrição clara do que foi feito. | ||
|
|
||
| <p align="justify">  Os pull requests externos devem ser feitos apenas para a branch development seguindo as regras e os passos do tópico Merges para development. No conteúdo do pull request deve haver uma descrição clara do que foi feito.</p> | ||
|
|
||
| [IMAGEM PULL REQUEST EXEMPLO] | ||
|
|
||
| Para a equipe interna, os pull requests seram realizados em duas situações, para `development` e para `master` seguindo as regras e passos de merge para ambas branchs. | ||
| <p align="justify">  Para a equipe interna, os pull requests seram realizados em duas situações, para development e para "master" seguindo as regras e passos de merge para ambas branchs.</p> | ||
|
|
||
| ##### Labels | ||
|
|
||
|
|
@@ -78,21 +83,22 @@ Para a equipe interna, os pull requests seram realizados em duas situações, pa | |
|
|
||
|
|
||
| #### Merges para development | ||
| Os merges para `development` deverão ser feitos quando a funcionalidade ou refatoração estiverem de acordo com os seguintes aspectos: | ||
| · Funcionalidade ou refatoração concluída | ||
| · Build do Travis passando | ||
| · Testes feitos | ||
| · Funcionalidade revisada por algum outro membro | ||
| Os merges para development deverão ser feitos quando a funcionalidade ou refatoração estiverem de acordo com os seguintes aspectos: | ||
| - Funcionalidade ou refatoração concluída; | ||
| - *Build* do Travis passando; | ||
| - Testes feitos; | ||
| - Funcionalidade revisada por algum outro membro. | ||
|
|
||
| Para fazer um merge para development os passos a serem seguidos são: | ||
| · Atualizar a branch “development” local usando o comando “git pull --rebase origin development” | ||
| · Mudar para branch que deseja mesclar para development | ||
| · Na branch a ser mesclada usar o comando git rebase --preserve-merges development | ||
| · A branch será mesclada com a development local | ||
| · Abrir merge request ou pull request para development | ||
| - Atualizar a branch development local usando o comando `git pull --rebase origin development`; | ||
| - Mudar para branch que deseja mesclar para development; | ||
| - Na branch a ser mesclada usar o comando `git rebase --preserve-merges development`; | ||
| - A branch será mesclada com a development local; | ||
| - Abrir `merge request` ou `pull request` para development. | ||
|
|
||
|
|
||
| #### Merges para master | ||
| Os merges para master deveram ser feitos apenas após o término da sprint, quando todas as funcionalidades estiverem entregues. O merge deve ser feito a partir da development e apenas quando atingir os seguintes critérios: | ||
| · Build Travis passando | ||
| · Sprint dada como concluída | ||
| <p align="justify">  Os merges para master deveram ser feitos apenas após o término da sprint, quando todas as funcionalidades estiverem entregues. O merge deve ser feito a partir da development e apenas quando atingir os seguintes critérios:</p> | ||
|
|
||
| - Build Travis passando; | ||
| - Sprint dada como concluída. | ||