A idéia com esses padrões é definirmos uma maneira de trabalhar que gere o menor número de conflitos no pull-request. Vamos mostrar aqui o fluxo que deve ser seguido desde a abertura da sua tarefa até a conclusão. Leia com atenção para não se confundir nos detalhes.
Se for uma feature o clone deve ser do branch unstable.
Se for um bug o clone deve ser do branch stable. Porém, em casos específicos pode ocorrer de ser feito no unstable. Se tiver que fazer alguma alteração no banco de dados para corrigir um bug, então obrigatoriamente deve ser no unstable.
O nome do branch deve ser seguido do descritivo "bo" + número da tarefa. Exemplo: bo7654. Nesse caso a tarefa é a 7654. O "bo" deve sempre ser minúsculo e está diretamente ligado ao número da tarefa.
Quando concluir sua tarefa e for enviar para QA (Quality Assurance) faça um pull-request para o branch dev.
Antes de publicar o pull-request, revise-o para ficar de acordo com nossas regras do Desenv.
Se sua tarefa for muito grande e demorou muito tempo no desenvolvimento, é obrigatório que você faça um merge com o unstable antes de iniciar os testes finais e enviar a primeira vez para o QA.
Caso a tarefa retorne dos testes, não precisa de fazer merge com o unstable todas as vezes que for mexer nela.
Desde seu primeiro pull-request, se a sua tarefa estiver muito tempo (como parâmetro: mais de 3 sub-versões publicadas) indo e vindo dos testes, aí recomenda-se um merge com o unstable para atualizar possíveis mudanças.
Comandos git
Isso deve ser rodado no git Bash.
- Atualiza branchs remotos retirando removidos e adicionando novos
git remote update --prune
- Remove os branchs mergeados no servidor do bitbuckte (use isso com moderação)
git branch -r --merged | grep -v "(^\*|master|dev|stable|unstable|unstable_publish)" | sed 's/origin\///' | xargs -n 1 git push --delete origin
- Limpar os branches locais que não estão mais na nuvem
alias git-remove-untracked='git fetch --prune && git branch -r | awk "{print \$1}" | egrep -v -f /dev/fd/0 <(git branch -vv | grep origin) | awk "{print \$1}" | xargs git branch -d'
depois roda o alias que foi criado
git-remove-untracked
veja mais aqui: https://stackoverflow.com/questions/13064613/how-to-prune-local-tracking-branches-that-do-not-exist-on-remote-anymore
- Criar branch
//Alterar para stable
git checkout stable
]//Atualizar o stable
git pull
//Criando novo branch
git checkout -b [novo_branch]
//Adicionando arquivos alterados para o commit
git add .
//Criando commit
git commit -m "[mensagem]"
//Criando o novo branch no origin e fazendo o push
git push --set-upstream origin [novo_branch]
Algumas dicas sobre o banco de dados
Não comece uma tarefa com um banco velho. Procure manter sempre um banco com a última stable e unstable na sua máquina.
Ao anunciamos no Skype uma versão unstable nova, pare o que estiver fazendo, vá para o branch da unstable faça o sync e rode o update no seu banco de backup da unstable. Deixe esse banco sempre atualizado com a última versão. Se sua tarefa não é muito velha não precisará de fazer merge com esse novo unstable e nem atualizar o banco.
Quando iniciar uma tarefa e essa tiver update no banco, faça uma cópia desse banco antes de enviar a primeira vez para o QA. Afinal, se a tarefa voltar dos testes precisará de utilizá-lo. Não re-crie tudo do zero jogando novamente um banco da unstable, pois isso irá causar conflitos. Recomendo salvar uma pasta com o código da tarefa e um nome resumido, veja exemplo abaixo da minha estrutura:
Aproveitando a imagem acima, crie uma pasta para guardar o seu banco da stable e unstable, veja que cada uma tem seu nome.
Quando houver uma troca de versão principal, aquelas em que o dev passa para o stable e unstable e todos os branchs ficam iguais. Nesse momento, pegue o seu banco da stable e unstable e atualize para ficar com todos iguais.
Podem existir exceções em todas as regras aplicadas acima. Quando ocorrer, elas serão comunicadas no grupo de desenvolvimento do Skype.