Especificação de convenção Git
Todos devem seguir as regras de nomenclatura, marcação e codificação de ramos. Cada organização tem suas próprias especificações ou melhores práticas, e muitas sugestões estão disponíveis online gratuitamente, e é importante escolher as especificações adequadas o mais cedo possível e segui-las na equipe.
Ao mesmo tempo, o nível Git de diferentes membros da equipe varia. Você precisa criar e manter um conjunto de instruções básicas que estejam em conformidade com as especificações da equipe para realizar operações Git comuns.
Commitizen é uma ferramenta para formatar mensagens de commit. Resumindo, git commit é semelhante a escrever uma nota depois de fazer uma modificação. Agora que o npm instala o commitizen, você pode usar git cz em vez de git commit. Você pode escolher o tipo de commit a cada vez que fizer o commit, O texto do commit ficará mais legível.
Mesclar conflitos corretamente
Cada membro da equipe precisa desenvolver um branch de recurso separado. Mas mesmo se um branch separado for usado, todos irão modificar alguns arquivos comuns. Ao mesclar as alterações de volta ao branch master, a mesclagem geralmente não pode ser automatizada. Pode ser necessário resolver manualmente os conflitos entre diferentes pessoas em diferentes alterações no mesmo arquivo. É por isso que você precisa aprender a lidar com fusões do Git.
Editores modernos têm funções para auxiliar na resolução de conflitos de mesclagem Git. Eles fornecem várias opções para mesclar cada parte do mesmo arquivo, por exemplo, se deseja manter suas alterações, ou manter as alterações de outro branch, ou mantê-las todas. Se o seu editor não oferece suporte a esses recursos, talvez seja hora de mudar para um editor de código.
Use git rebase para mesclar conflitos, o que significa realizar frequentemente as seguintes etapas:
git pull --reabase origin master
// 改完冲突后重新提交代码
git add .
// 重新提交不要写提交信息
git rebase --continue
// 退出
git push origin feature-todo -f
// 再次提交到远端需要强推
Essas etapas irão reescrever o histórico em seu branch de recursos (o que não é uma coisa ruim). Primeiro, ele fará com que seu branch de recurso obtenha todas as atualizações atuais no branch master. Segundo, todos os seus commits em um branch de recurso serão reescritos no topo do histórico do branch, então eles aparecerão no log sequencialmente. Pode ser necessário resolver conflitos de mesclagem ao longo do caminho, o que pode ser um desafio. No entanto, este é o melhor momento para resolver conflitos, porque isso afeta apenas o seu branch de recursos.
Se você usar uma estratégia de "fusão pura" (git pull origin master), o histórico do branch master será intercalado com o envio de todos os recursos desenvolvidos simultaneamente. É difícil revisar uma história tão caótica. O tempo exato de envio geralmente não é tão importante. É melhor ter um registro de histórico de fácil visualização.
Combine várias mensagens
Quando você desenvolve em um branch de recurso, mesmo a menor modificação pode ser usada como um commit. No entanto, se cada branch de recurso tem que gerar cinquenta commits, então, conforme novos recursos são continuamente adicionados, o número de commits no branch master irá eventualmente expandir desnecessariamente. De modo geral, cada branch de recurso deve adicionar apenas um ou alguns commits para o master. Para fazer isso, você precisa mesclar várias mensagens enviadas em um ou vários envios com informações mais detalhadas. Isso geralmente é feito com o seguinte comando:
git rebase -i HEAD~20
// 合并20个提交
git commit --amend
// 编辑完之后执行退出
Finalmente, como o histórico de commits do Git do branch foi reescrito, o branch remoto deve ser forçado a atualizar.
Usar etiqueta
Quando você terminar o teste e estiver pronto para implantar o software do branch master no online, ou quando quiser manter o estado atual como um marco por algum motivo, você pode criar uma tag Git. Para um branch que acumulou algumas alterações e os commits correspondentes, o rótulo é um instantâneo do branch naquele momento. Uma tag pode ser vista como um branch sem histórico, ou como um ponteiro nomeado que aponta diretamente para o commit antes da tag ser criada.
git tag v1.0.0 -m "1.0.0版本"
Além disso, se as tags assinadas forem úteis para o seu projeto, considere usá-las.
Considere uma situação em que a versão do software correspondente à tag Git foi distribuída ao cliente e o cliente relatou um problema. Embora o código na base de código possa estar em desenvolvimento, para reproduzir com precisão o problema do cliente e corrigi-lo, é necessário voltar ao estado do código correspondente à tag Git. Às vezes, o novo código pode ter corrigido o problema, mas nem sempre. Normalmente você precisa mudar para uma tag específica e criar um branch a partir dessa tag:
git checkout v1.0.0
// 切换到分发给客户的标签
git checkout -b bugfix-todo
// 创建新的分支用于重现 bug
Git é uma ferramenta complexa que leva tempo para ser dominada. Usar essas práticas pode ajudar a equipe a usar melhor o Git para desenvolvimento colaborativo.