Introducao Trabalhar com git, de modo geral, e simples. Alguns comandos sao mais complicadinhos, mas o basico a gente aprende muito rapido. Tutorial sobre git e o que nao falta.No entanto, pouca gente fala sobre fluxo de trabalho. Os problemas comecam a aparecer quando voce trabalha com mais uma pessoa. Se entrar mais gente para a equipe, as coisas podem ficar confusas bem rapido.Para abordar o assunto de forma resumida, preparei uns slides que chamei de Gitlab flow Solo, que baseia-se no Gitlab flow.Ainda assim, algumas perguntas ficam com resposta vaga ou apenas subentendida. Existem boas fontes sobre esse assunto, mas os processos vao melhorando e precisamos avaliar o que nos serve ou nao. Entao resolvi escrever um pouco sobre isso, detalhando a apresentacao.A importancia de ter nomenclaturasBoa comunicacao e fundamental e nomenclaturas simples ajudam muito.Exemplos de nomenclaturas para nomes de branches:Feature branchesNomeie seus feature branches com base no seu sistema de tickets (ou issues, ou demandas, ou atividades, seja la como for o nome que voce use) para facilitar a identificacao das atividades.Nao importa qual sistema voce esta usando para controlar as atividades. Use o numero da atividade no nome do branch.Exemplo: o ticket 284 e "enviar email quando orcamento for aprovado". Seu feature branch sera chamado "ticket284-enviar-email-qdo-aprovar-orcamento".Assim fica muito facil identificar pelo nome do branch a qual atividade ele se refere. Como tambem fica facil identificar qual branch atende a determinada atividade. Branches para correcao de bugsUse o mesmo principio para nomear os feature branches, mas inicie seu nome com "bug".Exemplo: o ticket 73 e "esta mostrando salario para todo mundo". Seu branch sera chamado "bug73-mostra-salario-pra-todo-mundo".Branches de releaseSe voce vai lancar a release 2.1, chame seu branch de "RELEASE-2.1". Simples assim.Branches estaveis de producaoSeguindo o mesmo principio dos branches de release, se a versao que voce esta implantando e a 2.6, chame seu branch de "PRODUCAO-2.6" ou "2.6-PRODUCAO".Aqui, vale uma observacao. Ao contrario dos branches de feature ou de correcao, os branches de release e de producao nao devem receber manutencao direta. Em outras palavras, voce nao vai dar commit neles. Por isso eles tem um nome diferenciado, com letras maiusculas ou a versao no inicio do nome do branch. Seguindo um procedimento assim, fica mais dificil o checkout indevido nesses branches.Essas sao apenas sugestoes. O importante e que a nomenclatura seja simples de usar e de entender. Afinal, boa nomenclatura viabiliza boa comunicacao.Perguntas FrequentesComo mantenho um historico das versoes de producao?Simples:Crie um novo branch para cada versao estavel implantada em producao.Use versionamento semantico.Exemplo: a primeira versao e a 0.1.0. Portanto, voce vai ter um branch PRODUCAO-0.1. Quando a proxima versao for lancada, teremos o branch PRODUCAO-0.2. Com o passar do tempo, teremos o branch PRODUCAO-1.0, e assim por diante.Esses branches permanecem no projeto por muito tempo, pois permitem voltar uma versao de meses ou anos atras. Isso e bastante util quando voce tem usuarios usando versoes diferentes do seu produto.Dica: nao crie branches para patches (a ultima parte da versao semantica). Integre os patches no branch estavel que ele corrige e use tags para identificar os patches.Por que nao