Domine Git e GitHub com este material completo. Com ele você aprenderá a gerenciar fluxos de trabalho de maneira simples e dinâmica.
Se você chegou até aqui, parabéns, isso significa que você passou por todas as fases de aprendizado do Git & GitHub.
Caso você caiu aqui de paraquedas, recomendo que faça a jornada desde o início começando por aqui.
Gostaria de dizer que a partir de agora, nos veremos alguns assuntos relevantes relacionados ao Git & GitHub, portanto, os assuntos tratados aqui servirão como um PLUS para a sua carreira profissional de desenvolvedor.
Pronto para começar?
Nas jornadas anteriores, nós aprendemos como iniciar um projeto por meio do git, adicionar a stage, fazer commits, acessar o histórico, fazer stash, fazer fork, corrigir conflitos e muuuuitas outras coisas.
Mas será que eu vou precisar saber todos esses comandos enquanto eu ainda sou um desenvolvedor Júnior, Pleno ou Sênior?
A resposta direta é SIM, é sempre bom você entender tudo o que permeia o grande universo de Git & GitHub, só assim, você prova não só para si mesmo, como também para seus gestores e lideres que você é um excelente desenvolvedor e domina o versionamento de código com Git.
Agora, se você vai usar todos esses comandos… bem, aí já é outra história, e depende exclusivamente da maneira como a sua empresa trabalha.
Conforme as experiências profissionais daquele que escreve este material (Prazer, meu nome é William Lima).
Na época em que eu atuava como desenvolvedor Júnior/Pleno, eu sempre seguia essa receita de bolo:
1) Eles me davam acesso ao repositório do GitLab (GitHub ou Bitbucket) para que eu pudesse ter acesso ao projeto que a equipe estava trabalhando.
2) Eu fazia o git clone daquele projeto existente no GitLab (GitHub ou Bitbucket) para a minha máquina local.
3) Eles me mandavam uma tarefa por meio da plataforma do Trello (por exemplo: “Criar uma tela referente ao cadastro de usuários”).
4) Com o projeto aberto na máquina local, eu criava uma branch cujo nome era ‘minha-branch’ (ideal é que seje referente ao nome da tarefa).
5) Em seguida eu dava início ao processo de desenvolvimento.
Funcionalidade implementada? Está tudo 100% testado, funcionando e sem erros?
Então chegava a hora de seguir a minha receita de bolo:
Ou seja, enquanto eu ainda era um mero desenvolvedor júnior/pleno a minha única missão sempre foi adicionar/corrigir funcionalidades, e por fim enviá-las para a branch principal para que outro desenvolvedor (geralmente o líder da equipe) fizesse o merge com a branch master/main.
Que eu me lembre, nunca me foi repassada uma tarefa com urgência, de modo que era necessário executar um stash, ou algum outro comando “mais avançado”, por assim dizer.
No meu caso, eu continuei seguindo essa mesma receita até eu me tornar sênior.
Já como sênior, eu já tinha uma equipe para coordenar, onde alguns dos meus subordinados não sabiam trabalhar muito bem com o Git.
Lá eu ainda seguia a receita de bolo listada acima, pois como sênior eu não só coordenava, como também colocava a mão na massa ;)
A diferença, é que a maioria das urgências era eu quem resolvia (git stash), além de fazer merges entre branchs, rebases, pull requests, e resolução de conflitos que poderiam acontecer entre as branchs.
Além, é claro, de testar todas as funcionalidades que a minha equipe desenvolvia.
E quando tal funcionalidade feita por um dos membros da equipe não estava funcionando do jeito adequado?
Bem, nesse caso, eu contatava o desenvolvedor responsável, pedia para que ele fizesse uma correção e subisse novamente (para a sua branch remota), para que eu pudesse fazer o merge sem nenhum conflito ou erros aparentes.
Novamente, tais processos dependem exclusivamente da forma como a empresa trabalha. Já vi desenvolvedores juniores, por exemplo, fazendo coisas mais avançadas, como um rebase, merges entre branchs principais e afins.
Eu particularmente, acredito que desenvolvedores juniores e até desenvolvedores plenos, deveriam seguir aquela receita de bolo do git e não passar disso, pois na minha opinião eles não deveriam ter responsabilidades estratégicas como a maioria dos sêniores possui.
E que responsabilidades estratégicas são essas? Simples, todos os outros comandos “avançados” que o git possuí, que fogem dos comandos apresentados na receita de bolo mostrada acima :D
Eu começo essa seção, te desafiando a abrir um projeto pessoal ou qualquer projeto de um repositório e executar o comando git log.
Existem 80% de chance de você se deparar com uma grande lista de commits antigos escritos dessa forma:
+ “Correção de tela”
+ “Atividade Resolvida”
+ “Correção do dia 24/04”
Talvez para quem fez os commits, tais mensagens façam sentido, mas para aqueles que estão por fora e chegando agora, tais mensagens podem não ser claras o suficiente, não é verdade?
Quando você escreve bons commits, você prepara o seu projeto pensando no futuro, poupando horas para si ou colegas de trabalhado, quando for necessário buscar por informações úteis dentro do projeto por meio de uma descrição útil e informativa.
O tempo extra que você dedica escrevendo uma mensagem relevante, pode te poupar horas de pesquisa mais tarde.
Já em projetos de grande escala, ter uma documentação é imprescindível para a manutenção do projeto.
Para isso, os desenvolvedores espalhados pelo mundo criaram uma convenção de mensagens de commits que podem ser usadas pela sua equipe.
Antes de aprendermos a convenção, gostaria que desse uma olhada nessas duas estruturas de commits:
#1: Estrutura básica de um commit:
git commit -m “mensagem”
#2: Estrutura detalhada de um commit:
git commit -m “titulo” -m “descricao”
Sim, é possível adicionar mais de uma única mensagem a um commit, e usando a forma de escrita presente em #2, pode ajudar um pouco na visualização do histórico do commit.
Para criar commits bem pensados, considere o seguinte:
• Por que fiz essas alterações?
• Que efeito minhas alterações tiveram?
• Por que a mudança foi necessária?
• Quais são as mudanças em referência?
Sabendo disso, existem 5 passos básicos que te ajudam a escrever commits melhores, são eles:
1) Capitalização e Pontuação: Sempre coloque a primeira palavra em maiúscula e não termine com nenhuma pontuação.
git commit -m “criação de tela de cadastro” (errado)
git commit -m “Criação de tela de cadastro.” (errado)
git commit -m “Criação de tela de cadastro” (certo)
2) Modo Imperativo: Sempre dê um tom de que você está dando uma ordem ou fazendo um pedido.
git commit -m “Sim, eu acho que resolvi esse bug #23” (errado)
git commit -m “Correção do bug #23” (correto)
2) Tipo de Commit: É sempre bom informar no início da mensagem qual a categoria que aquele commit se enquadra:
git commit -m “Criação de tela de cadastro” (errado)
git commit -m “feat: Criação de tela de cadastro” (certo)
feat significa a adição de novas funcionalidades ao projeto.
4) Comprimento: A primeira linha do commit idealmente não deve ultrapassar 50 caracteres, e o conteúdo da mensagem deve ser restrito a 72 caracteres.
5) Conteúdo: Seja direto e conciso, evite fazer o uso de palavras como “embora, talvez, eu acho, mais ou menos, quem sabe, entretanto, portanto, como consequência e afins”.
Como dito anteriormente, chegou a hora de conhecermos os tipos de commits que podemos usar:
feat: quando um novo recurso é introduzido ou mudanças drásticas são feitas no projeto.
fix: quando ocorre uma correção dentro do projeto (podendo ser de bugs).
chore: alterações não relacionadas com uma correção ou recurso dentro do projeto (por exemplo, atualização de dependências)
refactor: quando temos um código que foi refatorado, ao mesmo tempo que não corrige um bug nem adiciona um recurso.
docs: atualizações que envolvem arquivos de documentação, como README ou outros arquivos do tipo markdown.
style: alterações relacionadas a formatação do código, como espaços em branco, ponto e vírgula ausentes e assim por diante.
test: alterações que envolvem a inclusão de novos testes ou correção de testes anteriores.
perf: alterações que envolvem a melhoria de desempenho do projeto.
ci: alterações que envolvem integração contínua.
build: alterações que afetam o sistema de compilação ou dependências externas do projeto.
revert: Quando revertemos um commit anterior.
O exemplo de commit abaixo, envolve 3 mensagens relacionadas a um único commit:
Escrever bons commits, é uma habilidade extremamente benéfica para ajudaR você a se comunicar e colaborar com sua equipe.