DEV Community: Philipe Cairon

Fluxo GIT descomplicado: Parte 2

Philipe Cairon — Tue, 16 Aug 2022 22:09:00 +0000

E se você caiu aqui de paraquedas pode conferir a parte 1 deste artigo aqui: https://dev.to/magominimalista/fluxo-git-descomplicado-parte-1-pn8

Dando continuidade a nossos estudos vou falar um pouco mais sobre git para cobrir algumas partes que ficaram a desejar no post anterior. Vamos conversar um pouco mais sobre o assunto e no final eu lanço uma sessão de extras com alguns comandos não abordados.

Histórico da master

O histórico da master é muito importante, para mostrar o passo a passo dos eventos. Se tem outras pessoas trabalhando conosco no projeto temos que ter alguns cuidados quando mudamos o histórico de eventos do nosso git pela master. Eu poderia lançar um:

git push --force

Esse comando seria suficiente para ressincronizar os históricos no nosso servidor. Mas se alguém além de você estiver trabalhando na master a atualização feita por essa pessoa vai se perder. O ideal seria fazer um:

git push --force-with-lease

O próprio git vai avisar a você se tiver um novo commit para que você baixe a nova atualização antes de rodar novamente o comando.

Deixando os commits úteis no seu histórico

Lembrando que tem commits como WIP alguma coisas que não são relevantes para o histórico, apenas apontam um status da aplicação que você estava salvando pra continuar depois etc.

Vamos melhorar nossa histórico removendo os commits indesejados.

git rebase -i master

Irá aparecer esse documento você digita a para editar e esq + :wq para salvar e sair. Para alterar e deixar uma mensagem diferente você pode trocar onde tem 'pick' por 'squash' ou se preferir não digitar mensagem alguma troque apenas por 'fixup'.

No github também tem essa opção quando as alterações realizada não possuem um impacto no histórico é possível incluir no fazer um merge no último commit sem precisar declarar na master caso não seja relevante.

Fluxo de trabalho

Criar branches com significados para trabalhar em uma parte separada do código e depois fazer o merge com rebase é muito melhor pois evita conflito no código quando se trabalha com outros.

E para nos ajudar com essa tarefas sem precisar ter que ficar decorando os comandos temos uma ferramenta que roda em todos os sistemas operacionais que é o cheatshit do git flow. Você pode conferir a verão em português em: https://danielkummer.github.io/git-flow-cheatsheet/index.pt_BR.html

Separei algumas imagens, tamanho é a utilidade e facilidade desta ferramenta

Refazer o código

Usar o git rebase (rebobina seus commits e coloca no topo da sua árvore de commits) e git reset --hard (literalmente apaga seu último commit) e pode acontecer de você se perder um pouco, então o ideal mesmo é fazer assim:

git reflog

Para ver o que tem acontecido

git reset HEAD@[{1}
git restore .

Reseta para um estado anterior e depois restaura o código. Para ver as alterações novamente dá um git reflog.

Evitando os WIP(s) aqueles passos que não é preciso entrar no nosso histórico de gitlog

Podemos usar o

git stash

Para salva o WIP (Work in progress). Depois dar um

git stash list

Para visualizar a lista de stashs criada. Para contextualizar melhor, é uma boa prática anotar uma descrição para seus stashes, usando o

git stash save "mensagem"

Por padrão, git stash pop vai reaplicar o stash criado mais há pouco tempo: stash@{0}. Para visualizar as diferenças entre os stashs vamos usar:

git stash show -p

O menos -p é pra uma visualização completa. Para aplicar um stach

$ git stash pop stash@{2}

Esse 2 ai é o indice do stash. Para passar um stach para um novo branch

$ git stash branch add-stylesheet stash@{1}

Para limpar um stach específico

git stash drop stash@{1}

Ou para limpar todos os stachs

git stash clear

Nota: Vou deixar um link para ter uma visão melhor do git stash: https://www.atlassian.com/br/git/tutorials/saving-changes/git-stash

Extra

Estamos chegando ao final desse tutorial mas temos muita coisa ainda que deixamos passar. São elas:

git diff- https://www.atlassian.com/br/git/tutorials/saving-changes/git-diff
git config

$ git config --global user.name "Fulano de Tal"
$ git config --global user.email fulanodetal@exemplo.br

Criando tags:

git tag -a v1.1.0
git push origin v1.1.0

Um brinde para você treinar o seu git e visualizar a forma como ele trabalha sem precisar criar um repositório: https://git-school.github.io/visualizing-git/#free

Aproveitei para testar a ferramenta, um print com os comandos que usei, preferi iniciar pela opção Chery Pick.

Gente eu só tenho a agradecer por ter terminado esse estudo, acho que o git é muito mais que isso, tem coisas aqui que não foram abordados ainda, mas esse conteúdo já te permite trabalhar de forma profissional com ele.

Espero que tenham gostado.

Att,

Sobre o autor:

Philipe Cairon (Mago Minimalista)
Full Stack Web developer

Me encontre no Linktree:

Fluxo GIT descomplicado: Parte 1

Philipe Cairon — Tue, 16 Aug 2022 06:50:00 +0000

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

Já trabalhamos na base do nosso projeto então vamos saber como as coisas estão

git status

Ok! Vamos adicionar isso levando essas mudanças para o nosso repositório local:

git add .

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"

Quer ver o que criamos?

tree .git

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

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

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

git push -u origin main

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

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

git pull --rabase

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

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

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'

Para acessar esse novo caminho e começar a trabalhar dentro dele vamos acessa-lo:

git switch exporta-csv

Para ver uma lista de branchs locais:

git branch

E você terá como saída:

* exporta-csv
  master

Depois de trabalhar nessa nova funcionalidade e testar, vamos adicionar ela em nossa branch master.

git switch master

git merge exporta-csv

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

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

git push --set-upstream origin exporta-csv

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>

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

Fluxo 4: Visualizando detalhes no nosso sistema git

Para ver os caminho git criado em seu repositório:

cat .git/refs/heads/master

cat .git/refs/heads/exporta-csv

Para ver em uma linha detalhes dos commits

git log --decorate --oneline --graph --all

Fluxo 5: Indo e voltando

Para editar o título do último commit realizado

git commit --amend

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

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

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

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

Use as issues do seu github para que as pessoas possam reportar problemas;

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

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;

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;

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

Use plugins para te ajudar com essa experiência dos pull requests e themas. Vou indicar esses dois: Octotree: https://chrome.google.com/webstore/detail/octotree-github-code-tree/bkhaagjahfmjljalopjnoealnfndnagc, e Octotree Theme: https://chrome.google.com/webstore/detail/octotree-theme/meagmbmaaljhgdcglcmflnnglpokldcj

Abri os dois aqui para uma melhor compreensão

Depois de fazer um merge da nossa fixure do nosso pull request com o nosso master temos a opçã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: