Categoria: Git

GIT Add Enviando Arquivos para Staging Area

Posted on by marcelino.janing
CommandNew FilesModified FilesDeleted FilesHidden FilesDescription
git add -A✔️✔️✔️✔️Stage all files from top till down folders
git add .✔️✔️✔️✔️Stage all files under current folder and all subfolders
git add *✔️✔️✔️❌Same as git add . but excludes hidden files
git add –ignore-removal .✔️✔️❌✔️Same as git add . but excludes deleted files
git add -u❌✔️✔️✔️Same as git add -A but excludes untracked files
git add -A .✔️✔️✔️✔️Same as git add .
git add -u .❌✔️✔️✔️Mixes git add . and git add -u means it works under current folder and its subfolders only
git add $(git ls-files -o –exclude-standard)✔️❌❌❌Stage only untracked files from top till down folders

O comando git add é bastante versátil e suas opções permitem adequar seu comportamento conforme a necessidade do momento.

Isto é bom do ponto de vista de funcionalidade pois apenas adicionando flags podemos ajustar para o melhor resultado. Do ponto de vista de memorização pode ser um pouco complicado até que você consiga vincular as flags necessárias com o comportamento esperado.

Resolvi fazer um tabela no estilo CheatSheet para poder consultar rapidamente sempre que precisar relembrar uma combinação.

Quando estiver em dúvida que opção usar, lembre que você pode usar o bom e velho caminho completo para incluir um único arquivo.

git add full/path/to/my/file/from/current/folder.file

E aí? Vai uma CheatSheet?!

GIT Reset Eliminando um Commit da sua Branch

Posted on by marcelino.janing 
-- before proceeding be sure working area is clean
git status 

-- eliminate commit and throw away all changes
git reset --hard HEAD~1

-- or if you want to reuse your changes
-- eliminate commit but keep changes at working area
git reset --soft HEAD~1

Em algumas situações acabamos por introduzir um commit indesejado numa branch. Então o que fazer?

Fácil, o RESET está aí pra isso mesmo.

Usando a opção –hard estamos indicando que as alterações desfeitas sejam jogadas fora, ou seja, você usa esta opção quando desistiu mesmo e quer recomeçar o trabalho do zero.

Já a opção –soft estamos indicando que as alterações desfeitas permaneçam nos arquivos da working area para que você possa ainda utilizá-los antes de um novo commit.

Vale lembrar que estamos sacando fora commits do topo da pilha. Na verdade podemos sacar vários commits de uma só vez mas sempre será a partir do topo e em sequência.

-- eliminate the top 5 commits in the stack at once
git reset --hard HEAD~5

Para sacar mais de um commit por vez basta ajustarmos o HEAD~{n} onde n é a quantidade de commits a serem removidos.

É isso, mais fácil que cortar manteiga quente!

GIT Reset Para Unificar Vários Commits em um Único Commit

Posted on by marcelino.janing 
git reset --soft HEAD~2 
git commit -m "new commit message"
git push -f

O jeito mais rápido para se unificar vários commits num único commit é usando o git reset. Pra quem não sabe o nome desta operação é SQUASH, mas o GIT não tem uma comando git squash como muitos podem pensar.

Apesar de muitos artigos desaconselharem o uso do RESET por vários motivos, esta sequência de comandos é inofensiva e muito fácil de realizar.

No exemplo acima basicamente o reset desfaz os últimos 2 commits indicados em HEAD~2 sendo que o –soft indica para manter os arquivos impactados na working area.

Na sequência basta realizar um novo commit com todos os arquivos contendo as alterações dos commits desfeitos. Uma nova mensagem precisa ser informada para este novo commit.

Simples, rápido e eficiente!

GIT Rebase para Trabalhar numa Branch dependente de Outra Branch

Posted on by marcelino.janing 
-- start branch2 from branch1
git checkout branch1
git checkout -b branch2

-- make changes on branch2
git checkout branch2
git add file-changed
git commit -m "my commit message"

-- rebase branch2 whenever branch1 gets changed
git checkout branch2
git rebase branch1

-- finally rebase branch2 after branch1 was merged into master
git checkout master
git pull origin master
git checkout branch2
git rebase --onto master branch1 branch2

Trabalhando com as diversas técnicas modernas de desenvolvimento de sistemas como CI/CD, CleanCode, PMF entre outras os Web Devs frequentemente enfrentam o dilema de fragmentar ou não seus Pull Requests.

Para quem trabalha com o GIT segue aqui uma receita que achei interessante registrar. A receita é auto-explicativa não tem muito segredo; a sacada aqui é a sequência combinada dos comandos que já utilizamos em atividades diárias com o GIT.

Quer saber se funciona mesmo?

Funciona sim, finalmente tive oportunidade de testar num projeto recente e foi sucesso total, exceto pelo fato de eu ter produzido múltiplos commits o que não é permitido no meu ambiente de CI/CD.

Para resolver estes commits múltiplos bastou fazer um squash para unificá-los na branch final.

git checkout branch2
git reset --soft HEAD~2
git commit -m "new commit message"
git pull --rebase origin master --autostash
git push -f

Para evitar essa complicação final deveríamos fazer apenas commits complementares, assim logo após criar a branch2 a partir da branch1 somente performar commit —amend:

-- make your changes on branch2 then commit amend
git checkout -b branch2
git add file-changed
git commit --amend

So, who’s gonna take the risk?

GIT Branch Eliminando uma Branch no Ambiente Local e Remoto

Posted on by marcelino.janing 
// delete branch locally with force
git branch -D nome-da-branch-que-eu-nao-quero-mais

// delete branch on remote
git push origin --delete nome-da-branch-que-eu-nao-quero-mais

Pessoal, aqui um jeito simples de se livrar de uma branch que você não quer mais, são comandos diferentes para eliminar localmente e no servidor remoto.

Observe que localmente o -D em maiúsculo representa o FORCE. Se a branch em questão já foi sincronizada remotamente o force é requisito obrigatório. Se a branch foi criada somente localmente então você poderia utilizar uma sintaxe opcional mesmo agressiva.

// delete branch locally without force
git branch -d nome-da-branch-que-eu-nao-quero-mais

O segundo comando é para eliminar a branch no servidor remoto. Ambos os comandos podem ser utilizados de forma independente, ou seja, você pode querer eliminar a branch local apenas, ou remota apenas, ou em ambos os locais que é o mais corriqueiro.

Alternativamente tem uma outra sintaxe para eliminar a branch no servidor remoto, mas é um tanto difícil de recordar esta sintaxe, ainda mais em se tratando de um delete. Não recomendo utilizar sem conferir o manual duas vezes.

// delete branch on remote
git push origin :nome-da-branch-que-eu-nao-quero-mais

Observe também que este procedimento é bastante similar ao artigo onde descrevo o processo de renomear uma branch, os comandos a serem utilizados acabam se repetindo, mas a sequência não é a mesma.

God save Git!

GIT Init Comandos Para Iniciar um Novo Repositório com GitHub

Posted on by marcelino.janing 
cd easyclip
git init

git add README.md
git commit -m "first commit"

git remote add origin https://githug.com/mjaning/easyclip

git push -u origin master

git add .gitignore
git commit -m "adding gitignore"
git push origin master

Mesmo trabalhando com versionamento de arquivos há um bom tempo, até recentemente eu nunca tinha iniciado um repositório de um projeto desde o zero, não com GIT pelo menos.

Foi quando um pequeno projeto em que eu trabalhava em meu tempo livre tomou forma, então decidi hospedar ele no GitHub. Confesso que tive que procurar por vídeos no YouTube e acabei encontrando um muito bom da Rafaella Ballerini.

Então o primeiro passo foi criar o projeto completamente vazio no GitHub, para obter o endereço https no servidor.

E foi bem nessa sequência que eu executei os passos, primeiro commit do arquivo README.md, registro do endereço no server com o git remote e o git push -u pra testar se iria chegar no GitHub.

Em seguida, antes do commit dos arquivos do projeto eu preparei o .gitignore por que é natural termos arquivos que não devem fazer parte da base do projeto, como arquivos de dados e credenciais, arquivos de configuração local como IDE’s entre outros.

Observe que a partir do segundo push não precisamos da opção -u, pois o projeto já subiu uma primeira vez e já está linkado com o servidor podemos assim dizer.

Se você trabalha direto criando novos projetos do zero provavelmente irá decorar esta sequência e não vai precisar desta colinha. Porém, se assim como eu, fica muito tempo trabalhando em projetos continuamente e não pratica o git init com frequência, certamente vai acabar precisando de uma ajuda pra refrescar a memória.

Be my guest!

GIT Stash Salvando Também os Arquivos Não Rastreados

Posted on by marcelino.janing 
git status
// Untracked files: new_file.php

git stash --include-untracked
git status
// nothing to commit, working tree clean

git stash pop
git status
// Untracked files: new_file.php

Por definição o GIT não inclui os arquivos não rastreados quando estamos fazendo um stash. Esse comportamento padrão tem vantagens no meu ponto de vista por que na maior parte das vezes podemos mantê-los na working area sem dificuldades.

Mas e quando surgir aquela situação onde você tem uma série de arquivos não rastreados, e quer salvar sua alteração em andamento tudo numa stash só incluindo todo o pacote, arquivos modificados e arquivos novos não rastreados?

Para estas situações o GIT fornece a opção –include-untracked no comando git stash. Opcionalmente você pode utilizar o shorthand -u

git stash -u

E sempre tem possibilidade de se adicionar manualmente os arquivos não rastreados para staging area e então executar um git stash simples.

git add new_file.php
git stash

O inconveniente desta última opção é que, ao restaurar o arquivo ele vai aparecer na staging area enquanto que com a opção de arquivos não rastreados a restauração será feita diretamente na working area como arquivo não rastreado.

Recomendo ainda utilizar o recurso de nomear o stash, o que provavelmente fará muito sentido quando você querer salvar arquivos não rastreados.

Já escrevi um artigo aqui no blog que ensina como nomear o seu stash, é só pesquisar “como nomear seu stash”.

Voilà!

GIT Configurando sua Identidade

Posted on by marcelino.janing 
git config --global user.email "myemail@gmail.com"
git config --global user.name "My Full Name"

Logo depois que instalamos o GIT no sistema operacional a primeira coisa que queremos fazer é o primeiro commit e push, não é mesmo?!

Pois é, só que tem este detalhe de que antes precisamos configurar nossa identidade no ambiente, para que o mínimo de segurança e organização necessária seja alcançada.

É claro que o GIT vai te fornecer um comentário indicando que esta configuração é necessária! Se for tentar o commit sem esta config ele vai berrar.

Na dúvida fica aí mais esta dica.

GIT CHECKOUT Para Restaurar um Único Arquivo já Comitado

Posted on by marcelino.janing 
git log
// encontre o hash da versão que você deseja retornar um arquivo
git checkout <commit hash> <caminho-completo-para-o-arquivo-desejado>
git status
git commit

Devs utilizando a metodologia “PMF” estão em constante evolução de seus códigos e muitas vezes podem acabar numa sinuca de bico e invariavelmente em algum momento podem querer reverter suas alterações.

Mas e se a reversão a ser feita envolve apenas um único arquivo e usar o git reset pode dar aquele medo de piorar as coisas?

Bom, nessas horas você pode fazer uso do git checkout mesmo, afinal este comando é bastante comum pois usamos este comando o tempo todo, então não haveria razão para ter medo de usá-lo. Haveria?

A sacada aqui é apenas combinar o git checkout com o hash do commit que tem a versão do arquivo a ser restaurado adicionando-se também o caminho completo para o arquivo desejado. A versão do arquivo então é baixada para a “working area” e depois de você verificar o conteúdo dele basta apenas comitar novamente o arquivo para o repositório.

É claro que você poderia alcançar o mesmo resultado com outros comandos GIT como o reset ou o revert. Mas se o git checkout faz este trabalho pra você com uma sintaxe extremamente limpa, pra que complicar?

Vale ressaltar que este fluxo o git checkout não irá funcionar para arquivos novos que acabaram de ser comitados, isto por que um arquivo novo não existirá em um commit hash anterior e no commit hash atual ele é o que é, um arquivo novo.

Nesta situação é recomendado o uso do git rm que irá funcionar perfeitamente para esta necessidade… eu já escrevi um artigo sobre git rm aqui no blog, recomendo dar uma olhada nele para maiores detalhes de uso.

Agora sem complicações, vai de git checkout bro! …ou de git rm quando for um arquivo novo.

GIT RM Para Remover Arquivos já Comitados para um Repositório

Posted on by marcelino.janing 
git rm --cached <caminho-completo-para-o-arquivo-a-ser-removido>

Como devs nossa missão é criar códigos, mas tem aqueles momentos que precisamos mesmo é remover código para prosseguir com a evolução dos processos.

Imagine que você refatorou um processo e acabou por inutilizar completamente um determinado arquivo; git rm nele!

Ou então você se precipitou, o que não é incomum, e acabou comitando um arquivo novo e depois se arrependeu ou percebeu que não era preciso ou então não era o momento ideal de enviar o arquivo para o repositório; git rm nele!

A grande sacada é que com o git rm –cached o arquivo é preparado para ser removido do repositório, mas ele não desaparece por completo. O Git deixa ele disponível na working area para que você possa ainda fazer qualquer operação com o seu conteúdo.

Agora você já sabe, git rm para manter a casa limpa!