Skip to content

Instantly share code, notes, and snippets.

@matheusoliveira-luizalabs

matheusoliveira-luizalabs/CHANGELOG.md

Last active May 25, 2021 20:01
Show Gist options
  • Save matheusoliveira-luizalabs/ee51f949f5481a66ee7d3c3c1ca26f60 to your computer and use it in GitHub Desktop.
Save matheusoliveira-luizalabs/ee51f949f5481a66ee7d3c3c1ca26f60 to your computer and use it in GitHub Desktop.
Download ZIP
Templates docs
Raw
README_TEMPLATE.md

Nome do produto

Descrição curta sobre o que seu projeto faz.

NPM Version Build Status Downloads Stats

De um a dois parágrafos sobre o que é seu projeto e o que ele faz.

Instalação

OS X & Linux:

npm install my-crazy-module --save
apt-get install $(cat requirements.apt)

Mac: (caso exista peculiaridades de SO)

npm install my-crazy-module --save
brew install $(cat requirements.brew)

Windows:

edit autoexec.bat

Exemplo de uso

Alguns exemplos motivamentes e úteis sobre como seu projeto pode ser utilizado. Adicione blocos de códigos e, se necessário, screenshots.

Ambiente

Configure as variáveis de ambiente de acordo com o ambiente .env-development, .env-stage e .env:

API_URL=https://myawesome.api
SENTRY_DSN=https://sentry.com

para acessar as variáveis:

import config from '../config/env';

config.api.url
config.sentry.url

Configuração para Desenvolvimento

Descreva como instalar todas as dependências para desenvolvimento e como rodar um test-suite automatizado de algum tipo. Se necessário, faça isso para múltiplas plataformas.

npm test

Histórico de lançamentos

  • 0.2.1
    • MUDANÇA: Atualização de docs (código do módulo permanece inalterado)
  • 0.2.0
    • MUDANÇA: Remove setDefaultXYZ()
    • ADD: Adiciona init()
  • 0.1.1
    • CONSERTADO: Crash quando chama baz() (Obrigado @NomeDoContribuidorGeneroso!)
  • 0.1.0
    • O primeiro lançamento adequado
    • MUDANÇA: Renomeia foo() para bar()
  • 0.0.1
    • Trabalho em andamento

Meta

Seu Nome – @SeuNome – [email protected]

Distribuído sob a licença XYZ. Veja LICENSE para mais informações.

https://github.com/yourname/github-link

Raw
api.md
Raw
CHANGELOG.md

Changelog

Unreleased

1.11.0 - 2018-03-26

Added

  • Tela de Garantia e Proteções
  • Visualização de Danfe e download de XML

Changed

  • Refactoring Orders API
  • Refactoring Services API
  • Refactoring ProgressBar UI
  • Refactoring Timeline UI

1.10.4 - 2018-03-08

Fixed

  • Add float unset to img-all-menus

1.10.3 - 2018-02-09

Fixed

  • Front-end tests

-- The format is based on Keep a Changelog and this project adheres to Semantic Versioning.

Raw
CONTRIBUTING.md

Fluxo de desenvolvimento

Convenções

  1. Utilize as iniciais do seu nome e o tipo de alteração que sua branch representa como prefixo ao nome do branch que for criar. Exemplo: mo-fix-queue

Bug fix: mo-fix-

Funcionalidades: mo-feature-

Débitos técnicos: mo-enhancement-

Regras

  1. Sempre
  • Faça fork!
  • Desenvolva apenas em seu branch.
  • Faça rebase com o master antes de criar pull requests.
  • Se esforce para manter o master o mais limpo possível.
  • Faça rebase do master em seu branch diariamente, se possíevl mais de uam vez por dia.
  • Faça commits pequenos, que descrevem alterações únicas. (Leia: Commit Guidelines)
  • Faça squash dos seus commits que não estão completos (Work In Progress)
  1. Nunca
  • Desenvolva direto no master.
  • Faça merge de branches no master antes que o código seja revisado.
  • Revise pull requests que:
    • Não estejam atualizados com o master.
    • Tenham testes quebrando.

Processos

Desenvolvimento

Bug fixes

Para trabalhar em bug fixes, utilize o branch master como base.

  1. Faça o fork do projeto: git clone https://github.com/luizalabs/projeto
  2. Faça um fetch e checkout do master:
  • git fetch --all
  • git checkout master
  1. Crie seu branch:
  • git checkout -b mo-fix-queue
  1. Enquanto estiver desenvolvendo
  • Diariamente:
    • git checkout master
    • git pull upstream master
    • git checkout mo-fix-queue
    • git rebase master
  • Eventualmente - possivelmente mais de 1 vez por dia: git push origin mo-fix-queue
  1. Após terminar o desenvolvimento
  • Disponibilize seu branch para teste da funcionalidade - seja em um sandbox ou no ambiente local. Se a funcionalidade não for validada, volte ao passo 4.
  • Conserte os testes que estiverem falhando.
  • Atualize o versionamento do projeto (no padrão de versionamento semântico).
  • Preencha o CHANGELOG.md com as alterações realizadas em seu branch.
  • Faça push do seu branch para o repositório: git push --force origin mo-fix-queue
  • Crie o pull request branch: master.
  • Notifique que o pull request foi criado no canal do slack de sua equipe.
  • Interaja com o revisor de seu pull request quantas vezes forem necessárias.
  • Após o Pull Request aprovado:
    • Considere fazer squash de alterações pontuais que tenham sido feitas durante a revisão.
    • Faça rebase com o master, caso seu branch esteja desatualizado.

Funcionalidade

Para trabalhar em novas funcionalidades, utilize o branch canary como base.

  1. Faça o fork do projeto: git clone https://github.com/luizalabs/projeto
  2. Crie seu branch com base no canary:
  • git checkout -b mo-feature-queue
  1. Enquanto estiver desenvolvendo
  • Diariamente:
    • git checkout canary
    • git pull upstream canary
    • git checkout mo-feature-queue
    • git rebase canary
  • Eventualmente - possivelmente mais de 1 vez por dia: git push origin mo-feature-queue
  1. Após terminar o desenvolvimento
  • Disponibilize seu branch para teste da funcionalidade - seja em um sandbox ou no ambiente local. Se a funcionalidade não for validada, volte ao passo 4.
  • Conserte os testes que estiverem falhando.
  • Atualize o versionamento do projeto (no padrão de versionamento semântico) com o o sufixo -canary.x.
  • Preencha o CHANGELOG.md na seção de unreleased com as alterações realizadas em seu branch.
  • Faça push do seu branch para o repositório: git push --force origin mo-feature-queue
  • Crie o pull request branch: canary.
  • Notifique que o pull request foi criado no canal do slack de sua equipe.
  • Interaja com o revisor de seu pull request quantas vezes forem necessárias.
  • Após o Pull Request aprovado:
    • Considere fazer squash de alterações pontuais que tenham sido feitas durante a revisão.
    • Faça rebase com o master e canary, caso seu branch esteja desatualizado.
  • Crie uma tag e pre-release no github.

Revisão

Guidelines:

Pull request

  1. Garanta que a descrição PR esteja seguindo o template e descrições claras e objetivas.
  • Sempre informe como monitorar a alteração que o PR está implementando.
  • Solicite print ou maiores informações na seção Outras informações
  1. Seja duro, fará bem a todos: não faça revisões caso as regras descritas acima não tenham sido cumpridas. Se não forem, avise o desenvolvedor para que ele possa cumprir os requisitos e atualizar o branch dele - um novo pull request pode não ser necessário.
  2. Se você não entender o código que está lendo, pergunte. Faça perguntas mesmo que achar ou tiver certeza que elas são ingênuas ou simples demais, esse comportamento trará transparência e incentiva os outros desenvolvedores a agir da mesma forma - os encorajam a perguntar sempre que tiverem dúvidas.
  3. Sugira melhorias, use o bom senso e entenda o padrão do projeto antes de sugerir possíveis perfumarias.
  4. Se o pull request for claramente ruim, recuse.
  5. Antes de realizar o merge:
  • Ao menos 2 revisores são necessário para o PR ser apto ao merge
  • Ao menos 1 revisor precisa ser proficiente na linguagem do projeto
  1. Exclua o branch após realizar o merge dele no master.

Changelog

Escreva o changelog como se estivesse descrevendo quais mudanças foram introduzidas no release para um colega de time. Adicione o changelog ao projeto no Hub, em português e com uma linguagem mais geral e abrangente (sem muitos detalhes técnicos).

Úteis

  • Alias para rodar git lg com log colorido e com níveis de merge/branches explícitos:
    • git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"

Recomendações

Arquivos

Plugins

  • Instale o editorconfig em seu editor de código favorito.
  • Intale o commitizen cli para auxiliar nas mensagens dos commits.
    • Use git cz ao invés de git commit
Raw
ISSUE_TEMPLATE.md 
### É um relatório de erros?
Sim

### Comportamento atual
e.g. Em pedidos de modalidade retiraloja não está aparecendo os dados do cliente que vai retirar o produto.

### Reprodução do comportamento
e.g. No `https://meuespaco-debug.magazineluiza.com.br/pedidos` e pesquise pelo pedido `xxxxxxxx`. Ao detalhar o pedido os dados do cliente que vai retirar não aparece no box de entrega.

### Comportamento esperado
e.g. Exibir os dados do cliente que vai buscar o produto na loja.

### Funcionou em versões anteriores?
e.g. Sim, na versão 1.0.2 estava aparecendo os dados do cliente.
Raw
PULL_REQUEST_TEMPLATE.md 
**Qual o tipo de alteração que esse PR introduz? (Bug fix, feature, docs update, ...)**
e.g. Feature.

**Qual é o comportamento atual? (Você pode conectar a uma issue ou um chamado aqui)**
e.g. A aplicação não possui chat.

**Qual é o novo comportamento?**
e.g. Foi implementado um novo chat.

**Será que esse PR introduz alguma alteração de quebra?**
e.g. Não.

**Outras informações:**

Observações, prints, ou qualquer outro tipo de informação que queira colocar
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment