Como gerencio meus projetos no github
Olá, galera.
Me chamo Erick. Sou desenvolvedor backend com mais de 3 anos de experiência.
Em boa parte da minha carreira, sempre procurei manter meus códigos no github de forma organizada e bem documentada, seja para recapitulação/reprodução futura ou por uma necessidade de negócios (projetos freelances). Pois bem, durante esse processo além de documentar, fui aprendendo as formas de gerenciar um projeto, pessoal ou não, pequeno ou grande, e nesse artigo vou compartilhar um pouco desses aprendizados com vocês.
Como inicio o projeto
No início do projeto, costumo fazer a quantidade mínima de código na máquina para depois criar um repo no github. Esse mínimo pode ser um HelloWorld em qualquer linguagem.
No projeto adiciono os arquivos .gitignore, REAME.md e LICENSE.md (caso for um projeto para comunidade),
logo em seguida crio meu repositório no github e sincronizo com o projeto da minha máquina local.
Como gerencio branchs
Não constumo fazer commit direto na branch master/main, portanto crio uma branch develop e trabalho sempre nela, pedindo merge request da develop para a master a cada alteração importante de código.
Outra maneira de gerenciar branchs é criar uma para cada fix,feat ou issue que adicionarmos ao projetos. Por exemplo:
- adicionar botão na homepage -
branch: <feat> add button in homepage
Depois que essa funcionalidade está pronta, peço o merge request da branch <feat> add button in homepage para a master.
Como gerencio tarefas
Para as tarefas a serem feitas, gosto de criar uma issue com checkbox para cada tarefa, sempre em ordem de prioridade para facilitar:
Dessa forma consigo controlar o que tem que ser feito, principalmente quando é um projeto freelancer que tem muita demanda.
Quando encontro um bug ou preciso criar uma nova feature, cadastro uma issue e atríbuo uma identificação à ela do tipo warning, bug ou feat:
Obs.: Podemos criar uma branch para resolver cada issue.
Como escrevo minhas mensagens de commits
Gosto de seguir a convenção de commits para ter commits mais padronizados.
-
Para commit de incremento de feature:
<feat> commit message. -
Para correção de bug:
<fix> commit message. -
Para refatoração:
<refactor> commit message.
Conclusão
Minha intenção aqui era passar uma idéia básica de como pode ser feito o gerenciamento de projetos pessoais/profissionais no gitub com base na minha experiência. Elas podem ser adaptadas a cada necessidade.
Obrigado por ter lido até aqui, abraços. Postagem no meu blog
Oi Erick, legal ter compartilhado o processo! Só um detalhe, comitar na master não é uma má prática. Isso depende muito do seu contexto de trabalho. Inclusive, para trabalho individual ou para pequenas equipes, é até recomendado - porém você vai ter que adotar algumas técnicas, como feature flagging, para não quebrar a aplicação. Caso você não se sinta confortável, pode usar "short-lived branches".
Ótimas dicas! Eu costumo fazer um processo similar, porém mais simples já que não faço projetos grandes. Então subo direto na master mesmo.
Como você avalia o uso de criar um branch para cada fix, feature ou issue em um projeto? Não haveria muitas branches e isso tornaria difícil de manter no projeto? Como por exemplo criar branches para pequenas alterações, como mudanças de texto, é uma boa prática?