DEV Community

Cover image for Fluxo GIT descomplicado: Parte 1
Philipe Cairon
Philipe Cairon

Posted on

Fluxo GIT descomplicado: Parte 1

Esse tutorial é 100% prático.

Suponho que você já tenha o git instalado em seu ambiente de desenvolvimento.

Porque parte 1: Nessa parte vamos aprender tudo que precisamos saber para trabalhar com o git no nosso dia a dia.

Na parte 2: Vamos ver alguma peculiaridades a mais do git;


Fluxo 1: Local

  • Ok, vamos começar o nosso repositório com o
git init
Enter fullscreen mode Exit fullscreen mode
  • Já trabalhamos na base do nosso projeto então vamos saber como as coisas estão
git status
Enter fullscreen mode Exit fullscreen mode
  • Ok! Vamos adicionar isso levando essas mudanças para o nosso repositório local:
git add .
Enter fullscreen mode Exit fullscreen mode

Esse ponto representa tudo que foi listado, você pode passar apenas um repositório ou arquivo substituindo esse ponto pelo nome da pasta ou arquivo, mas eu não indico isso;

  • Agora vamos commitar, dizer ao git para criar uma chave para essas adições que estamos fazendo os chamados blobs são um ponto de referência para aquelas alterações do momento
git commit -a -m "Status inicial da aplicação"
Enter fullscreen mode Exit fullscreen mode
  • Quer ver o que criamos?
tree .git
Enter fullscreen mode Exit fullscreen mode

vamos ver uma arvore com as chaves dos nossos commits. É interessante depois de pelo menos 2 commits para observar essas mudanças;

  • Precisa chegar os commits realizados?
git log
Enter fullscreen mode Exit fullscreen mode

Fluxo 2: Levando para um servidor

  • Se você tá levando para o github ou bitbucket as configurações são parecidas então:
git branch -M main
git remote add origin https://github.com/seuusuario/seurepositório.git
Enter fullscreen mode Exit fullscreen mode

Adicionei um repositório remoto e depois subi com as atualizações através desse comando:

git push -u origin main
Enter fullscreen mode Exit fullscreen mode

Em resumo suba uma cópia do branch origin para o main;

  • Agora se você adicionar ou mudar algum arquivo, repita o FLUXO 1 e depois
git push
Enter fullscreen mode Exit fullscreen mode
  • Se alguém da sua equipe pegou o projeto em outra máquina e atualizou ele você vai usar o comando abaixo para baixar essas atualizações:
git pull
Enter fullscreen mode Exit fullscreen mode

ou

git pull --rabase
Enter fullscreen mode Exit fullscreen mode

Lembrando que o git pull nada mais é que um git fetch origin com um git merge origin/master. Se você usar o git pull sem o rebase fica mais fácil de usar o git revert depois. O rebase usamos muito quando vamos fazer o merge de um feature pois ele joga adição dessa nova feature para cima do histórico do git e deixa mais organizado (linear).

  • Contudo se tiver algum conflito de informações entre o novo código e o seu, exemplo: alterou uma linha ou mais das quais você já tenha trabalhado antes o git vai te alertar sobre isso, você pode fazer uma revisão do conteúdo, para ver se tá tudo ok. E se desejar sobrescrever as alterações use um
git merge
Enter fullscreen mode Exit fullscreen mode

Fluxo 3: Trabalhando com funcionalidades

  • Para criar uma nova funcionalidade na aplicação vamos criar um branch novo. Um novo caminho, então para criar um branch novo:
git checkout -b exporta-csv
Enter fullscreen mode Exit fullscreen mode

Seja descritivo, também podemos criar um branch para corrigir um bug ou fazer um hotfix (uma correção) podemos nomear desse modo também

git checkout -b 'philipe/bug-caracteres'
Enter fullscreen mode Exit fullscreen mode
  • Para acessar esse novo caminho e começar a trabalhar dentro dele vamos acessa-lo:
git switch exporta-csv
Enter fullscreen mode Exit fullscreen mode
  • Para ver uma lista de branchs locais:
git branch
Enter fullscreen mode Exit fullscreen mode

E você terá como saída:

* exporta-csv
  master
Enter fullscreen mode Exit fullscreen mode
  • Depois de trabalhar nessa nova funcionalidade e testar, vamos adicionar ela em nossa branch master.
git switch master
Enter fullscreen mode Exit fullscreen mode

Ou

git merge exporta-csv
Enter fullscreen mode Exit fullscreen mode

Nota: se abrir o vim editor depois disso, use esq e depos :wq, para fechar;

Obs: Enquanto você trabalha no seu branch, outros desenvolvedores podem atualizar o branch main com o seu branch. Isso significa que seu branch não está mais atualizado em relação ao branch main e tem conteúdo em falta. Você pode fazer merge do branch main em seu branch executando checkout do seu branch e usando o mesmo comando git merge.

git checkout <branch name>
git merge main
Enter fullscreen mode Exit fullscreen mode
  • E agora atualizar em nosso servidor (lembrando que essas mudanças no código já deveriam ser atualizadas no servidor antes, trabalhando local e subindo para a nuvem). Repete o FLUXO 1 +
git push --set-upstream origin philipe/bug-caracteres
Enter fullscreen mode Exit fullscreen mode

Ou

git push --set-upstream origin exporta-csv
Enter fullscreen mode Exit fullscreen mode

Obs: Se você criar um branch no seu repositório local, o repositório remoto ignorará a existência desse branch. Antes de poder fazer push do código do branch para o repositório remoto, você deve definir o repositório remoto como o branch upstream usando o comando git push. Simultaneamente, esse comando define o branch upstream e envia o conteúdo do branch para o repositório remoto.

git push --set-upstream origin <branch name>
Enter fullscreen mode Exit fullscreen mode
  • Temos mais um detalhe. Depois de fazer um merge em nossa nova feature (branch) é legar reescrever o histórico do git para que os nossos merges venham pra cima quando usarmos o git log, e fazemos isso assim:
git rebase master
Enter fullscreen mode Exit fullscreen mode

Fluxo 4: Visualizando detalhes no nosso sistema git

  • Para ver os caminho git criado em seu repositório:
cat .git/refs/heads/master
Enter fullscreen mode Exit fullscreen mode
cat .git/refs/heads/exporta-csv
Enter fullscreen mode Exit fullscreen mode
  • Para ver em uma linha detalhes dos commits
git log --decorate --oneline --graph --all
Enter fullscreen mode Exit fullscreen mode

Fluxo 5: Indo e voltando

  • Para editar o título do último commit realizado
git commit --amend
Enter fullscreen mode Exit fullscreen mode
  • Ok, agora para voltar ao estado de um determinado commit você vai usar o git log para pegar o hash de um commit para onde deseja voltar e depois é só usar o código:
git reset 25469779d814fcc740e1c29c3baf810e0f43ce25
Enter fullscreen mode Exit fullscreen mode

Obs: Se você tá trabalhando com muitas pessoas ou na master do seu repositório o ideal é usar o git revert passando o ponto de onde você deseja reverter.

  • Para reverter:
git log --decorate --oneline --graph --all
Enter fullscreen mode Exit fullscreen mode

Para analizar para onde você deseja reverte, copia o primeiro código da linha de onde você deseja reverter. Ex.: 2546977, não confunda com o hash *please.

git revert 2546977
Enter fullscreen mode Exit fullscreen mode

Fazendo assim o histórico não é comprometido na master. Lembre-se a master é sagrada. Não podemos comprometer seu histórico. No github na sua pull request tem um botão de revert e ele ará abrir um novo pull request para executar esse revert. Falaremos mais sobre github no fluxo 6.


Fluxo 6: Usando o github

  • Pelo terminal você pode criar um repositório no github usando:
hub create meu-novo-projeto
Enter fullscreen mode Exit fullscreen mode
  • Use as issues do seu github para que as pessoas possam reportar problemas; 'issues do github'

'Abrindo issue do Github'

  • Organize, se preciso crie labels e personalize as já existentes, você encontra esse recurso nas opções laterais da issue; 'Na lateral da issue tem as opções'

'Criando/Personalizando uma label'

Dica: Crie também um lable para WIP (Working in progress) que serve pra sinalizar que você ainda está trabalhando no código.

  • Crie pull requests no código, vá até o arquivo que deseja fazer um pull request, ao invés de dar um commit direto, crie um pull request conforme as imagens abaixo, ele vai te dar um resumo e você pode lançar essa pull request;

'Passo 1' 'Passo 2' 'Passo 3'

  • Ao abrir a minha pull request, vemos que o boot da versel (host CI/CD) já atualizou o diretório e logo abaixo eu posso fazer um merge para atualizar o nosso diretório principal e por fim finalizar essa pull request se for o caso. Lembrando que o ideal na criação da nossa pull request é criar uma descrição do problema para que tudo fique bem documentado;

'Parte 1' 'Parte 2'

Dica: Adiciona no repositório .git um template para as issues e para os pull requests. Vou deixar esse link de referência: https://github.com/facebook/react/blob/main/.github/ISSUE_TEMPLATE/bug_report.md

Abri os dois aqui para uma melhor compreensão
'Octotree e Octotree Theme juntos'

  • Depois de fazer um merge da nossa fixure do nosso pull request com o nosso master temos a opção de reverter

'Repare o nosso botão de reverter'


Espero que tenham gostado desse post, comentem e me sigam nas minhas redes sociais, quero muito com esse projeto passar conteúdo de qualidade e no Medium conteúdo mais focado para Stackholders com um formato mais simples.

Confira a parte 2 em: https://dev.to/magominimalista/fluxo-git-descomplicado-parte-2-3dn1

Att,

Sobre o autor:

  • Philipe Cairon (Mago Minimalista)
  • Full Stack Web developer

Me encontre no Linktree: 'Linktree'

Top comments (0)