Depende dos requisitos do projeto e da cultura interna, e se você é um rebaser ou não …
Um dos fluxos de trabalho mais populares é o fluxo git .
O fluxo Git é um fluxo de trabalho de sucesso …
Coisas que eu mudaria com o git flow
- Correções de bugs de revisão de branch e código (como branches de recursos).
- Faça o rebase de todos os ramos de bug / recurso no desenvolvimento (em vez de mesclar o desenvolvimento no ramo).
- Use ‘master’ em vez de ‘developers’ – Se você precisar de uma correção de bug grave de emergência, eu faria o seguinte:
Como seria antes:
v1 v2
| |
o-o-o-o-o-o-o master
Você pensaria que só poderia adicionar uma correção no master .. e implantar TODAS as mudanças. Seu errado…
git checkout v2
git commit -m "Fixes foobar"
se parece com (HEAD separado):
v1 v2
| |
o-o-o-o-o-o-o master
-o
então se git tag v3
parece com:
v1 v2
| |
o-o-o-o-o-o-o master
-o v3
em seguida, mescle a v3 no master (não reescrever o histórico):
git checkout master
git merge v3
v1 v2
| |
o-o-o-o-o-o-o-m master
/
-o---- v3
ou rebase master para v3 com (todos os branches de recursos abertos atuais precisarão ser rebaseizados no NEW master (novos commits) e remover os commits master antigos.
git checkout master
git rebase v3
v1 v2
| | v3
o-o-o-o |
|
-o-x-x-x master
se você reescrever o master (certifique-se de que nada TAGGED seja reescrito! apenas efetua o commit no ‘master’ que ainda não está em produção).
diga aos desenvolvedores para:
git fetch
git checkout feature-x
git rebase master --onto origin/master
Use o comando acima para recuperar do master sendo reescrito cuidadosamente. Aprenda exatamente o que está fazendo. Que é … pegar commits de feature-xe local master .. e aplicá-los em cima de origin / master.