Prática recomendada: Fluxo de trabalho da equipe para Github

Mais e mais no Stack Overflow, estou vendo pessoas usarem algumas práticas muito ruins com Git e Github, especialmente com todos os IDE que compõem a funcionalidade. É importante saber como usar Git na linha de comando porque você aprende como as coisas estão acontecendo passo a passo.

Dito isso, aqui está a maneira de minha equipe lidar com nosso projeto no GitHub / Git.

Temos vários ramos, mas mantemos apenas dois indefinidamente: estável e desenvolvimento. Em seguida, criamos um branch por recurso que é excluído depois que o recurso é incorporado ao desenvolvimento.

Digamos que eu precise adicionar um novo recurso ao developmentchamado, sexy-blogfarei o seguinte:

#Get all refs from the remote repo to my local
git fetch origin 

#Make my working dir reflect stable's source code
git checkout origin/development

#Checkout a local branch for my feature based on stable
git checkout -b sexy-blog

Então, neste ponto, eu efetivamente ‘baseei’ meu branch de recursos stable. Depois de fazer algumas alterações, preciso levar meu código-fonte até meu repo remoto, um fork no GitHub. Vamos dizer que já nomeamos meu repo remoto my-remote.

#Start tracking all files that aren't ignored
git add -A

#Commit those tracked files to the branch
git commit -m 'Added a sexy blog feature'

#Push the commit to my remote repo
git push my-remote sexy-blog

Agora vamos ao GitHub e fazemos uma solicitação de pull, comparando com development. Uma vez que a solicitação pull está inserida, é importante fazer um comentário pedindo a alguém da equipe para revisá-la e testá-la. Esse membro da equipe faz o seguinte

git fetch origin

Neste ponto, seu colega de equipe deve ver uma nova filial com o número PR aparecer. Você pode apenas verificar esse branch e executar seus testes de unidade (você deve SEMPRE testar a unidade!)

git checkout my_project/pull/345

Depois que ele verificar que seu código é incrível, ele pode mesclar a solicitação de pull de volta no GitHub.

Você acabou de repetir este processo até que você esteja pronto para liberar, em seguida, mesclar developmentem stable. Agora, cada recurso possui documentação associada a ele, pelo menos uma pessoa o verificou e testou e todo o seu código está baseado corretamente.

Fique ligado na minha análise sobre como resolver problemas com git rebase