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
ou
git pull --rabase
Lembrando que o git pull nada mais é que um
git fetch origin
com umgit merge origin/master
. Se você usar ogit pull
sem o rebase fica mais fácil de usar ogit 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
Ou
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
Ou
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
Top comments (0)