Executando verificação de segurança...
7
erickbessa
2 min de leitura ·

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:

Minhas issues

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:

Minhas issues

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

Carregando publicação patrocinada...
2
vserpa

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".

Veja
https://trunkbaseddevelopment.com/

1
erickbessa
Autor
Autor

Olá vserpa, saudações.

Você tem razão. Confesso que desconhecia esse desenvolvimento baseado em tronco e após ler seu documento, fiz um refactor no meu artigo rsrs.

Agradeço a colaboração.
Sucesso.

1
1
sellhat

Maravilhoso seu post. Gostei demais da ideia de checkbox para gerenciar as tarefas e melhorias nos projetos. vou tentar implementar pro meu dia-a-dia ou adaptar pro meu gosto pessoal.
Obrigado opor compartilhar conhecimento.

1
fabricio

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?

1
erickbessa
Autor
Autor

Olá Fabricio, saudações!

Vamos lá...

1 - Como você avalia o uso de criar um branch para cada fix, feature ou issue em um projeto?
R: Primeiro levo em consideração o que tem que ser feito no projeto. Por exemplo:

  • Criar um botão na tela inicial;
  • Corrigir tamanho da fonte na tela inicial;

Depois categorizo essas demandas entre feature (é uma nova implementação) ou fix (é alguma correção?).

Se for trabalhar em "Criar um botão na tela inicial" crio uma branch referente a essa demanda, que seria algo como feat:criar-botao.

Se for trabalhar em "Corrigir tamanho da fonte na tela inicial" crio uma branch referente a essa demanda, que seria algo como fix:corrigir-fonte.

Realizo as implementações necessárias e assim que finalizo a tarefa e faço os testes, peço o merge para a master/main.

2 - Não haveria muitas branches e isso tornaria difícil de manter no projeto?
R: Assim que eu peço o merge para a master/main, deleto a branch em que trabalhei, sempre limpando as branchs do meu projeto, tendendo a manter somente a master/main e em alguns casos a develop.

3 - Como por exemplo criar branches para pequenas alterações, como mudanças de texto, é uma boa prática?
R: Mudanças de textos como comentários e informações de documentos, não costumo criar branch separada, mas caso a mudança de texto seja em um arquivo de configuração importante da aplicação, considero sim uma boa prática, mas isso não é uma verdade absoluta.
Obs.: Corrigi meu artigo que afirmava de forma absoluta ser uma boa prática.

Espero ter conseguido ser claro nas minhas respostas.
Sucesso e obrigado pela interação.

1
fabricio

Erick,

Muito obrigado pela sua resposta. Eu gostei bastante da forma como você gerencia as tarefas do seu projeto e tenho certeza de que vou usar essas técnicas em meu próximo projeto. Além disso, também planejo utilizar técnicas como "feature flagging" proposta pelo vserpa.