Fluxo de desenvolvimento

Todo desenvolvimento provavelmente passará pelas etapas abaixo, então atente-se para garantir que os detalhes não passem despercebidos.

Início

Cada tarefa criada no Open Project possui uma ID e um tipo. Estas duas informações vão definir o prefixo da sua branch de trabalho:

Tipo	Branch
Tarefa	feature/
Hotfix	hotfix/
Bug	bugfix/

A próxima informação a ser incluída no nome da branch é a ID da tarefa ou correção. Depois das duas informações, o texto é livre, mas tente ser objetivo.

Exemplo: uma correção de algo em produção será feita e a ID é 1234, então a branch será hotfix/1234-texto-livre.

Considerando a branch de exemplo e branch de desenvolvimento como dev, então os próximos passos deverão ocorrer:

git checkout dev
git pull
git checkout -b hotfix/1234-texto-livre

Neste momento, a branch será criada localmente e você poderá iniciar o desenvolvimento.

Desenvolvimento

Considere cada commit como uma espécie de checkpoint cuja função é indicar que o objetivo (total ou parcial) foi alcançado naquele momento.

Seguindo na direção de TDD onde deve-se começar pelos testes, a primeira etapa do desenvolvimento é criar ou modificar testes unitários para que estes validem a nova regra de negócio. Após os testes serem feitos, a execução deles indicará falhas porque a implementação ainda não ocorreu. Uma recomendação neste ponto é realizar um commit para indicar que houve progresso neste ponto (pode ser necessário adicionar --no-verify ao commit):

git add .
git commit -m "[#1234] Adição da possibilidade de criar usuário sem senha"

Coloque a ID da tarefa/correção como prefixo da mensagem de commit no padrão [#<ID>] <MENSAGEM>, conforme o exemplo acima. Isso facilita uma consulta futura ao código modificado ao simplificar a busca da tarefa/correção que originou aquela mudança.

No screenshot acima, sabendo que a ID era 1234, basta pesquisar no Open Project por esta tarefa e você descobrirá porque aquele código foi modificado ou adicionado. Outra opção seria buscar pela ID da branch, porém este processo é mais complexo. A forma proposta aqui mostra a ID da tarefa ou correção na própria linha de código (caso tenha a extensão do VSCode chamada GitLens ou você esteja visualizando o arquivo pela interface do Gitea).

Caso você esteja seguindo na direção de considerar o commit como um checkpoint, a qualquer momento que você perceber que as mudanças atuais estragaram alguma coisa que não vale a pena reverter com Ctrl + Z, basta executar git restore . e os arquivos modificados desde o último commit serão revertidos ao seu checkpoint. Caso você não siga nesta direção, pode ser difícil saber até que ponto você pode desfazer as mudanças sem perder algo que funcionava antes.

A menos que o desenvolvimento seja extremamente pequeno, você provavelmente terá vários checkpoints, por exemplo: criar testes, fazer a implementação, polir a implementação e melhorar os testes. Consequentemente, você fará vários commits ao longo do desenvolvimento. Antes de realizar um commit, sempre avalie se as novas mudanças agregam alguma coisa nova ou são apenas pedaços interdependentes. Outra forma de avaliar se o commit deveria ser separado ou não é imaginar se, após a finalização da tarefa, será possível passar no linter e testes em cada commit? Se não for possível (algum teste quebra, por exemplo), então ele é interdependente de outra coisa e não deve ser isolado.

No exemplo acima, criar testes e fazer a implementação não deveriam ser separados porque o teste somente faz sentido se houver a implementação (e vice-versa). Os outros dois checkpoints (sobre polimentos) também dependem da implementação e testes, então não fazem sentido estarem separados. No fim das contas, deveria ser apenas um commit.

Considerando que houve um commit assim que os testes foram feitos e agora a implementação está pronta, use a opção amend:

git commit --amend -a --no-edit # Caso não queira modificar a mensagem
git commit --amend -am "[#1234] Adicionar usuário não deve exigir senha" # Caso queira modificar a mensagem

Caso já tenha feito vários commits e queira juntá-los, você pode usar o git rebase. Importante: apenas use rebase se você souber o que está fazendo. É melhor ter vários commits do que perder código.

Finalizando

Com a tarefa desenvolvida, mande suas alterações para o servidor através de git push. No caso de branches criadas localmente, deve-se criar uma branch do servidor também e isso pode ser feito através do comando git push --set-upstream origin <NOME_DA_BRANCH>

Caso faça amend ou rebase, pode ser necessário realizar git push --force.

A próxima etapa é abrir um Pull Request (ou PR).