Práticas recomendadas do Git - Como aproveitar ao máximo (g) isso

Pull, Fetch, Commit, Push, Merge, Rebase - esses termos já conseguiram fazer parte do seu dia-a-dia? Quando Linus Torvalds criou sua primeira versão do Git, ele a descreveu como “o rastreador de conteúdo estúpido”. Avançando até hoje, este software de código aberto gratuito é agora o sistema de controle de versão mais popular.

O que é Git?

Você não gostaria de voltar no tempo às vezes, para que pudesse ter tomado uma decisão melhor ou feito as coisas de forma diferente? Bem, no mundo da tecnologia e da codificação, você pode. Git é um sistema de controle de versão distribuído de código aberto que salva versões de seu precioso código toda vez que você faz alguma alteração / adição a ele. Portanto, sempre que precisar fazer o rollback, basta escolher a versão de trabalho e pronto! O Git também permite o trabalho sem interrupções dentro das equipes, à medida que os desenvolvedores trabalham em suas cópias locais individuais simultaneamente. Todas as alterações de cada membro da equipe são acompanhadas, mantendo a transparência em um fluxo organizado. Então, o que é GitHub? GitHub é um serviço de hospedagem de repositório para Git que também possui muitos recursos para otimizar seu sistema de controle de versão.
Fluxo de Trabalho Git

Cada organização tem um fluxo de trabalho Git diferente. O fluxo de trabalho Git mais bem-sucedido é aquele que dá à sua equipe espaço suficiente para produtividade e, ao mesmo tempo, maximiza a eficácia de seus resultados. Deve ser escalonável de acordo com o tamanho da sua equipe e deve minimizar o número de conflitos que podem surgir. O fluxo de trabalho Git centralizado é a base sobre a qual outros fluxos de trabalho Git são construídos, como o fluxo de trabalho de ramificação de recursos, o fluxo de trabalho de bifurcação, o fluxo de trabalho Gitflow, etc. Um fluxo de trabalho deve ser planejado para aprimorar e complementar a cultura de sua organização. Para cada equipe, seu próprio fluxo de trabalho Git.

Por que usar o Git?

1. A arquitetura distribuída

Ao contrário dos sistemas de controle de versão centralizado que forçam os desenvolvedores a acessar o único repositório central para poder fazer o “checkout” e confirmar as alterações nos arquivos individuais, o Git segue uma abordagem distribuída. Na arquitetura distribuída, cada desenvolvedor tem suas próprias cópias locais de todo o repositório central, permitindo que trabalhem offline, acessem o histórico de revisão completo e fácil ramificação e mesclagem.

2. Desempenho poderoso

Ramificação, fusão, confirmação, etc. são realmente fáceis e rápidas com o fluxo de trabalho Git por causa de seus algoritmos de conhecimento profundo e inteligentes que entendem os padrões de acesso ao T.

3. É seguro

Git armazena todo o conteúdo do arquivo, incluindo relacionamentos entre versões e diretórios, criptograficamente usando um SHA1 como seu algoritmo de hashtag. Qualquer alteração acidental ou maliciosa de código é completamente rastreável.

4. Código aberto

Sendo de código aberto, Git é gratuito, desfruta de um bom suporte da comunidade, continuamente examinado para qualidade e é apoiado por uma grande quantidade de documentação e tutoriais para alunos.

5. Lançamentos mais rápidos

O desenvolvimento distribuído do Git e a ramificação fácil e a criação de novos recursos encorajam os desenvolvedores a fazer mudanças mais frequentes em um fluxo de trabalho ágil

Melhores práticas para Git

• Novo projeto? Novo repositório

Faz sentido para a organização criar um novo repositório para cada novo projeto no qual você deseja começar a trabalhar. Quando terminar, envie-o para GitHub.

• Novo recurso? Ramificar

Agora que você criou um novo projeto, que tal criar alguns novos recursos do Git? O Git Branching permite criar e gerenciar um fluxo de trabalho organizado dentro do seu repo. Os membros da equipe podem ser atribuídos a vários branches do Git, permitindo que trabalhem simultaneamente, mas de maneira isolada. Sempre dê um significado ao seu branch git para que os outros saibam exatamente no que você está trabalhando.

• Comece o seu dia mantendo-se atualizado

Sempre “rebase” ou obtenha a versão mais recente e atual de seu projeto (mestre) antes de começar a trabalhar nos recursos que você criou / atribuiu a você. Você não quer fazer alterações em arquivos desatualizados.

• Tenha pontos de verificação periódicos

Não salve seus commits para uma grande mudança. “Comprometa” pequenas alterações com frequência para que o código seja mais fácil de compreender para você e os membros de sua equipe. Reverter e rastrear também é mais fácil quando as mudanças são pequenas e frequentes.

• Esconda seu trabalho

Freqüentemente, você pode se deparar com situações em que está trabalhando em um branch do Git, mas de repente se lembrou de que precisa trabalhar em outro branch, mas não quer “comprometer” essas alterações feitas pela metade. Ou você pode simplesmente querer uma cópia de trabalho limpa. “Git stash” para o resgate. O armazenamento permite que você salve suas alterações não concluídas em uma pilha de onde você pode voltar a qualquer momento!

• Esmagando os commits

Ter menos commits em seu histórico torna mais fácil monitorar e rastrear onde você errou. Se você deseja manter um histórico de commits limpo, este é para você. Amasse e mescle todos os seus commits em um quando a solicitação pull for mesclada.

• Enviar mensagens

Sempre forneça informações claras e compreensíveis em sua mensagem de confirmação. Comece escrevendo um breve resumo de suas alterações, deixe uma linha em branco e, em seguida, continue com uma descrição detalhada das alterações. Você não quer que seu histórico de commits fique assim: /

• Não mude a história

Depois de confirmar suas alterações no repositório, não volte e altere o histórico. Embora o Git permita que você faça isso e reescreva a história pública, nunca é uma boa prática fazê-lo. Tanto para você quanto para sua equipe.

• Aplicar um patch Git

Às vezes, quando você não tem acesso de gravação ao repositório, mas ainda deseja corrigir um bug - aplique um patch Git. Lembre-se sempre de clonar o repositório principal e, em seguida, criar um branch para o novo recurso. Quando tiver seu arquivo .patch pronto, sempre visualize-o e faça uma simulação para verificar se há erros. Git aplique o patch (git apply -R path / file.patch) uma vez feito. NÃO se esqueça de testar e verificar

• Não deixe as solicitações pull por muito tempo

Uma solicitação “pull” aberta pode criar conflitos mais cedo ou mais tarde. Não os deixe sozinhos por mais de 2 dias. Sempre revise o código e se estiver tudo bem para implantar, mescle a solicitação de pull. Isso não apenas agilizará o processo de envio, mas também evitará conflitos de código.

• Melhor organização com ferramentas de gerenciamento de projetos

Se você tem usado ferramentas de gerenciamento de projeto como o Redmine, é uma boa prática usá-lo em conjunto com o Git para poder gerenciar melhor vários membros da equipe e suas tarefas. Criar seus branches Git com a tarefa Redmine como o nome é uma das melhores práticas Git, pois permite uma melhor transparência e organização.

• GitLab CI / CD

Usar uma ferramenta de integração / implantação contínua como esta permite que você teste e verifique se há bugs e erros e garante a compatibilidade com os padrões de código. Esses trabalhos são executados depois que o código é enviado ao servidor de teste.