Fluxos de trabalho e uso avançados do Git

Recentemente, analisamos os conceitos básicos de como começar a usar o Git para controle de origem em seus projetos. Embora esse seja um ótimo ponto de partida, há vários outros comandos e fluxos de trabalho Git que ajudarão você a entender o uso do Git em seu trabalho diário de codificação.

Fluxos de trabalho do Git

Quando comecei a usar o Git, percebi que sabia como usá-lo corretamente. Minha abordagem ideal era fazer todas as alterações em um local sem ramificações e, em seguida, enviá-las para o repositório e continuar trabalhando.

Embora fosse melhor do que não usar o controle de versão, demorei um pouco para perceber que não estava usando a maior parte do poder fornecido pelo Git. Para fazer o Git funcionar para mim, eu precisava ter uma estratégia para ramificar e mesclar minhas alterações.

Então o git-flow saiu e eu o adotei como minha estratégia. Ainda me lembro de sentir como se estivesse espiando por trás de alguma cortina onde estavam os incríveis desenvolvedores. Agora eu tinha uma visão de como eles funcionavam e poderia começar a me tornar um deles.

Mas o git-flow não se encaixa em todos os cenários, então, enquanto o analisamos, também veremos alguns outros métodos de manter seus projetos Git organizados, incluindo como gerencio meus projetos como um desenvolvedor solitário.

git-flow

Olhando para o git-flow agora, reconheço que o cenário do software mudou muito em 10 anos e o git-flow pode não ser a melhor opção para sua equipe. Quando o git-flow foi escrito, era raro implantar um aplicativo muitas vezes em um dia. Em vez disso, você provavelmente fez um número de versão principal e lançou a cada poucos meses ou semanas se estivesse em uma equipe particularmente ágil.

Vamos dar uma olhada no que é git-flow.

Se você quiser ver a explicação detalhada completa com gráficos e comandos do Git para o Git Flow, leia este post.

No git-flow, duas ramificações têm um tempo de vida infinito. Primeiro, main, que deve refletir o código que está pronto para ser implantado em seu ambiente ao vivo/produção.

Em segundo lugar, temos nosso ramo de desenvolvimento. Esta ramificação deve ter as últimas alterações que estão prontas para a próxima versão do nosso software. Quando as alterações em desenvolvimento estão prontas para serem implantadas em nosso aplicativo ativo, nós as mesclamos na ramificação principal e as marcamos com o número da versão que corresponde ao número da versão.

Fora dos dois ramos principais, existem três tipos de ramos de apoio.

1. Recurso

Uma ramificação de recurso pode ser feita apenas a partir da ramificação de desenvolvimento. Ele deve ser mesclado de volta na ramificação de desenvolvimento. A nomenclatura pode ser qualquer coisa descritiva do recurso em que você está trabalhando.

Quando o trabalho está pronto para o próximo lançamento, ele é mesclado de volta ao branch de desenvolvimento, onde aguarda o tempo de lançamento.

2. Liberação

As ramificações de lançamento são feitas a partir da ramificação de desenvolvimento e devem ser mescladas de volta ao desenvolvimento e ao principal. Você nomeia uma ramificação de lançamento com a convenção release-x. Na prática, isso geralmente significa que você nomearia uma ramificação com o número da versão que planeja usar assim: release-2.2

Você usa uma ramificação de lançamento como forma de fazer a preparação final para liberar seu software. Isso pode incluir aumentar o número da versão dos arquivos, certificar-se de que suas traduções foram feitas ou verificações finais de código.

3. Correção

A ramificação de hotfix é feita a partir da ramificação principal e é usada para conter alterações que precisam ser tratadas no aplicativo ativo imediatamente. Isso pode ser um bug que precisa ser corrigido ou um problema de segurança que precisa ser tratado.

Depois que o problema for corrigido e implantado em sua ramificação principal, você marcaria seu código com o número de versão adequado.

A maior razão pela qual as equipes não usam o git-flow agora é que a maneira como lançamos o software mudou. Em vez de versões maiores com menos frequência, você pode liberar uma alteração em um aplicativo algumas vezes por dia. Eu sei que envio o trabalho para os sites do meu cliente muitas vezes por semana assim que ele estiver pronto. Não fazemos números de versão do site, apenas continuamos melhorando-o.

O git-flow padrão não se destina a acomodar isso.

Fluxo do Github

A segunda opção que muitas pessoas usam é o Github Flow.

A única grande regra do Github Flow é que qualquer código que esteja no branch principal pode ser implantado a qualquer momento porque está pronto para produção.

Todas as ramificações são criadas a partir da ramificação principal com um nome descritivo para o que você estiver fazendo.

Depois de ter suas alterações prontas, você cria uma solicitação pull.

As solicitações pull informam aos outros que trabalham no mesmo código que o trabalho que você está fazendo está pronto para ser revisado antes que essas alterações sejam mescladas no código principal.

Depois de enviar uma solicitação pull, a equipe com a qual você está trabalhando pode revisar as alterações e fornecer feedback. Se a solicitação pull for considerada pronta para mesclagem, ela será mesclada na ramificação principal do seu projeto.

Uma desvantagem do fluxo do Github para um único desenvolvedor ou uma equipe muito pequena é que a administração de uma solicitação pull pode criar uma sobrecarga extra no gerenciamento do projeto. É por isso que não os uso no meu trabalho.

Como uso fluxos de trabalho do Git com projetos de cliente

No trabalho do meu cliente, geralmente sou o único a escrever código diariamente para um projeto. Meu cliente pode atualizar plugins do WordPress ou alterar algum CSS, mas eles não fazem nenhum grande trabalho de codificação. Isso significa que, se eu fosse com o fluxo do Github, estaria revisando minhas solicitações de pull, o que só cria dores de cabeça extras de gerenciamento. Vamos dar uma olhada no sistema que eu uso, que tem alguma semelhança com o git-flow e o fluxo do Github.

Eu tenho dois ramos principais chamados main e staging. A ramificação principal acompanha qualquer código que esteja sendo executado no site de produção. A ramificação de teste acompanha o que está sendo testado no site de teste que usamos para testar as alterações antes de enviá-las ao site ativo.

Cada branch é criado a partir do branch principal. Novos recursos recebem um nome como este: feature/32-new-feature. Nesse contexto, o número 32 corresponde ao número do ticket em nosso sistema de gerenciamento de projetos e as palavras após ele são uma breve descrição do que está sendo trabalhado. As correções de bugs são nomeadas de forma semelhante, bug/20-bug-name.

Cada branch criado é mesclado em nosso branch de teste primeiro e, uma vez aprovado pelo cliente ou testado por mim, é mesclado no branch master. Esse fluxo de trabalho pode ser assim.

# mesclar recurso no branch de teste

git merge feature/32-new-feature

# implante e teste o recurso

git checkout principal

git merge feature/32-new-feature

# implantar recurso no site ativo

Em meus projetos, tenho uma implantação contínua configurada, o que significa que sempre que eu envio o código para o main, ele é enviado automaticamente para o site ativo. O mesmo processo é configurado para a ramificação de teste.

Se eu estivesse trabalhando com uma equipe que pudesse verificar meu código em um fluxo de trabalho de solicitação pull, usaria esse sistema porque funciona bem em equipe. Para um desenvolvedor que trabalha principalmente por conta própria, é simplesmente a sobrecarga de gerenciamento que vai desacelerar seu fluxo de trabalho.

Comandos avançados do Git que uso

Agora que temos uma ideia de como podemos usar o Git em um fluxo de trabalho prático, vamos dar uma olhada em comandos mais avançados que serão necessários para que isso aconteça. Eu uso cada um desses comandos pelo menos algumas vezes por semana enquanto trabalho com o código do meu cliente.

Mesmo se você for usar um aplicativo GUI (mencionei alguns bons no meu último post no Git), ainda é importante ter uma compreensão do que está acontecendo em segundo plano. Muitas vezes eu tive que trabalhar via terminal para corrigir um problema que foi criado por um aplicativo Git GUI.

Adicionando alterações por linha

O único comando que fez o uso do Git via Terminal clicar para mim foi git add -p. Até aprender esse comando, eu usava aplicativos GUI porque fazia alterações no meu código, mas queria dividir linhas específicas em confirmações diferentes para que eu pudesse explicar por que fiz uma alteração. Para fazer isso, usei uma GUI para selecionar as linhas, mas git add -p orienta você por uma interface interativa para adicionar alterações em partes.

Eu uso isso muitas vezes todos os dias.

Rastrear ramificação remota do Git

Se você estiver baixando um repositório existente e tiver ramificações como main e staging que você precisa acompanhar, mas já existem, você precisa informar suas versões locais das ramificações para rastrear essas versões remotas da ramificação.

Há algumas maneiras de fazer isto.

# Configura upstream ao empurrar para remoto

git push -u teste de origem

# Configurado a montante

# assume que você está no branch que deseja rastrear atualmente com o controle remoto

git branch -u origin/staging

git branch --set-upstream-to=origin/staging

# Se você não estiver na ramificação que deseja rastrear, especifique a ramificação no final

git branch --set-upstream-to=origin/staging staging

Salvar alterações sem confirmá-las

Às vezes, você estará no meio de algum trabalho que ainda não está pronto para ser confirmado, mas precisa salvar seu estado. É aí que o git stash é útil. Este comando esconde as alterações para você removendo as alterações. Você pode recuperá-los usando git stash pop. Existem mais alguns comandos para tornar o stash útil, mas esses são os dois que eu uso regularmente.

Puxe um Git Commit específico

Às vezes você precisa puxar um commit específico para o seu trabalho atual. Com um HEAD limpo (você ainda não fez nenhuma alteração), você pode puxar um commit específico com git cherry-pick . Você pode encontrar a documentação completa no git cherry-pick aqui.

Para cada commit, o Git cria uma longa sequência de letras e números que é chamada de Git Object e comumente chamada de SHA. Como cada commit recebe um, você pode referenciar um commit com seu valor SHA. Leia mais sobre objetos Git.

Jogue fora as mudanças que você não precisa

Em algum ponto de qualquer projeto, faremos alterações e perceberemos que não está funcionando e precisamos simplesmente descartá-las e começar de novo. Em vez de apenas tentar desfazer até voltarmos para onde queremos, podemos usar o seguinte comando Git para remover quaisquer alterações que ainda não foram rastreadas.

git reset --hard

O comando acima irá redefinir seu código de volta para o commit mais recente na ramificação em que você está trabalhando no momento. Também podemos usar um <#commitSHA> com este comando para redefinir para um commit específico se quisermos voltar a um estado anterior ao último commit. Talvez você use isso para redefinir o check-out inicial da ramificação porque todo o trabalho da ramificação não é algo que você deseja manter, mas você já rastreou parte do trabalho.

Para dar um passo adiante, podemos jogar fora quaisquer arquivos ou diretórios que ainda não foram rastreados no git com o comando git clean.

git clean -fd: os sinalizadores f e d dizem ao git para jogar fora arquivos e diretórios que não são rastreados.

Remover ramificações

A cada uma ou duas semanas eu olho para os resultados de um comando git status e descubro que tenho muitas ramificações para entender razoavelmente o que está acontecendo no meu repositório. Isso significa que posso remover quaisquer ramificações que correspondam a tickets que foram resolvidos com os seguintes comandos.

# remove a versão local

git branch -d $branchname

#remove a ramificação do meu controle remoto

git push $remotename --delete $branchname

Usar controle de versão

Embora você possa não ser um especialista em todos os comandos do Git que usará, uma coisa importante a ser lembrada é que você deve usar o controle de versão . Mesmo que você seja a única pessoa trabalhando em um projeto, usar o Git e um fluxo de trabalho do Git ajudará você a manter seus projetos organizados. Você não precisará pressionar CTRL + Z até redefinir seu trabalho depois de escrever o código que não funcionou.

Você poderá confiar em seu sistema e continuar produzindo trabalhos para seus projetos.

Experimente a Hospedagem WordPress Totalmente Gerenciada

Precisa de hospedagem otimizada para WordPress? Confira os planos de hospedagem WordPress totalmente gerenciados da Nexcess hoje.