Taller Onboarding: Git workflow
Esse é o onboarding do workflow de git aqui na Taller e decidimos deixar isso aberto para comunidade também porque são coisas que podem ajudar outras pessoas ou times :)
- Seu primeiro passo é fazer as seguintes configurações:
- 1. Aqui todos nós usamos o Tig! Ele ajuda muito na visualização dos commits, branches, pegar hashs e mais um monte de coisas bacanas que vão te auxiliar no dia a dia. Confira a doc dele aqui e já configure no teu pc antes de iniciar sua primeira história do onboarding técnico.
- 2. Configure seu email da taller no seu github, caso você for usar seu perfil pessoal. Tem um tutorial bacana nesse link.
- 3. Configure a autenticação de dois fatores na sua conta, a gente preza por segurança. Tem um tutorial bacana nesse link
Tudo configurado e organizado? Bora entender nosso fluxo e nossos padrões!
Em cada passo descrito nesse onboarding, o mais importante é você entender o que está fazendo e o motivo de fazer ele. Se algo não estiver claro, crie uma issue, abra um PR e nos ajude a melhorar o onboarding para as pessoas que entrarão depois de você.
Tanto o nome das branches quanto as mensagens de commit deverão ser em inglês. Nossas branches sempre iniciarão com os tipos de histórias descritos abaixo.
| Tipo | Descrição |
|---|---|
fs |
História que adiciona uma nova feature ao projeto |
hotfix |
História para resolver bugs no projeto |
chore |
História que adiciona melhorias em configurações do projeto ou do ambiente |
Para ficar melhor de entender como nomear nossas branches, bora criar três histórias fictícias:
Primeira história: Uma feature, no qual a sigla do projeto no Jira é AT, o número da história é 1052 e o título é "Permitir que os usuários possam deslogar do app"
Segunda história: Um hotfix, no qual a sigla do projeto no Jira é PD, o número da história é 2043 e o título é "Corrigir mensagem de e-mail já existente"
Terceira história: Uma chore, no qual a sigla do projeto no Jira é EF(histórias de eficiência para nosso time a sigla do projeto é EF), o número da história é 105 e o título é "Atualizar os scripts de deploy do boilerplate de drupal"
Quais são os nomes de branch desejáveis para essas histórias?
| Tipo | Sigla do projeto | número | Dois traços | Descrição curta |
|---|---|---|---|---|
fs |
AT | 1052 | -- | user-logout |
hotfix |
PD | 2043 | -- | email-error-message |
chore |
EF | 105 | -- | update-deploy-scripts |
Para criar uma branch, com a branch main atualizada com o origin do projeto, use o seguinte comando trocando as variáveis dentro de placeholders(${placeholder}):
git checkout -b fs/${sigla do projeto}-${número da história}--${descrição-curta}
Nós presamos por um changelog fácil de ler e entender o que aconteceu no passado, então hoje adotamos algumas regrinhas que nos ajuda a manter isso, e nas nossas pesquisas encontramos o padrão de Semantic Commit Messages proposto pelo Karma e também vimos esse artigo que inspirou muito nossos padrões e também é uma das nossas bases hoje.
Então todas as mensagens de commit devem seguir o seguinte padrão:
categoria: Verbo e descrição no presente.
Os tipos são: feat, fix, docs, style, refactor, test e chore. Já os verbos mais usados hoje são: update, add, remove, improve, mas você não precisa se limitar a isso. Uma dica é você baixar um dos nossos projetos ativos, e usar o tig para ler uma parte do histórico dos commits e ver os padrões "na prática".
Exemplo e explicação é tudo nessa vida, né? Aqui embaixo você terá mais detalhes sobre ao se refere cada categoria de commit citado anteriormente.
| Tipo | Descrição | Exemplo: |
|---|---|---|
| feat: | Implementação de alguma novidade: Uma feature, funcionalidade, tela, opção de ação, etc. | feat: add node cachetag to ensure content invalidation |
| fix: | Implementação em que a única finalidade é corrigir algum comportamento errôneo do sistema. | fix: improve url object verification |
| docs: | Alterações ou incrementos na documentação do projeto. | docs: add instructions to force new drupal installation |
| style: | Para alterar identação, vírgulas(retirar ou colocar), etc. Um exemplo é se você está adicionando o prettier ao projeto. Pense nele como estilo de código e não como CSS. | style: convert tabs to spaces |
| refactor: | Refatoração/melhoria de código sem alterar funcionalidade. | refactor: extract data provider method |
| test: | Refatoração ou adição de testes. Apenas testes. | test: update test to add scenario for columnist article |
| chore: | Alterações em arquivos de configuração do projeto ou do ambiente. Logs, pacotes, dependências e etc. | chore: add scripts to deploy on vercel |
Caso você queira já deixar configurado na sua máquina, existe a git-semantic-commits que já faz a magia da mensagem do commit pra ti. Essa lib é escolha sua usar ou não, o importante é você seguir os nossos padrões.
A fonte da verdade é a branch main. Todas as branchs devem ser criadas a partir da main e deverão ser mergeadas na main através de um pull request.
Quando você estiver desenvolvendo, certifique-se que sua branch main local esteja atualizada com o origin executando:
git remote update
git reset --hard origin/main
git remote update: esse comando pega todas as atualizações do origin(desde a branch que você está até as outras branchs do projeto), mas não fara o merge das alterações em sua branch local.
git reset --hard origin/main: esse comando reseta tua branch local com a origin. Ou seja, tua branch local ficará idêntica ao origin.
Se voce estiver se perguntando "o que é essa porra de origin que tanto falam aqui?", o origin é um termo default que o git usa para se referir ao repositório(remote) de onde você clonou o projeto(seja ele github, gitlab ou bitbucket). Você pode mudar esse nome default, mas não há necessidade. Você pode acessar a documentação oficial para ter mais detalhes.
Atualize sua branch main conforme explicamos no ítem acima e execute o comando git checkout -b + o nome da branch(com o padrão explicado na sessão Padrão do nome das branches)
git checkout -b ${tipo da branch}/${sigla da história-número da história}--${descrição da issue ou história}
⚠️ INFORMAÇÃO IMPORTANTE: a branch que você estiver trabalhando deve SEMPRE estar atualizada com amain, para isso usamos o rebase. É sempre bom você ir fazendo rebase durante durante o desenvolvimento, porque se você deixar pra hora de entregar, existe a possibilidade de você passar muito tempo resolvendo conflito.
Para fazer rebase da main, execute:
git remote update
git rebase origin/main
Fique atento porque você não vai conseguir fazer rebase se não tiver commitado ou usado um git stash no que você estava trabalhando.
Terminou sua história?
Abra um pull request para a main e solicite o code review de duas pessoas do time.
é meme(zoeira), ninguém vai te bater ou dar pauladas.
Terminou sua história, code review feito, alterações ok é hora de enviar sua história para stage.
Nessa etapa temos duas formas de fazer a mesma coisa:
Primeira:
Crie uma branch auxiliar para poder fazer rebase com stage nela. Você sairá da sua branch atual:
git checkout -b fs/my-branch--STG
git remote update
git rebase origin/stage
*** resolve conflitos ***
git checkout stage
git reset --hard origin/stage
git merge fs/my-branch--STG
- Antes do push, você sempre vai se fazer as seguintes perguntas: meu merge foi fast-forward? olhando no tig, alterei algo criando 'bifurcações'?
| ~ 😢 😢 😩 😢 😢 ~ | ~ 😊 😊 😍 😊 😊 ~ |
|---|---|
 |
 |
- tudo ok? Então agora dale!
git push origin stage
História homologada, tudo certo e é hora de mandar pra main! Como falamos lá em cima, a ideia é que tua branch esteja sempre atualizada com o origin/main, então você volta pra sua branch e:
- Faz o rebase de main pra ficar tudo atualizado
git remote update
git rebase origin/main
*** resolve conflitos ***
- Vai pra main e atualiza main com a origin
git checkout main
git remote update
git reset --hard origin/main
- Adiciona seus commits na main com o merge da sua branch:
git merge my-branch
*** verifica se seu merge foi fast-forward, olha no tig se tá tudo certo e dale ***
git push origin main
- no canal #projetos fazer o subscribe do seu repositório no bot do github
/github subscribe https://github.com/taller-onboarding/onboarding-{seu nome} issues pulls deployments statuses public releases comments reviews
