Categoria: Dev Ops

ASDF O Gerenciador de Pacotes com Controle de Versões

Posted on by marcelino.janing 
# make sure your brew is fully updated
brew update
brew upgrade

# install asdf pack manager using brew of course
brew install asdf

# see lastest comments after installation, asdf path will be shown over there
# asdf path may vary depending on your environment

# add asdf path to your shell environment, this is for .zsh
echo -e '\n. /usr/local/opt/asdf/libexec/asdf.sh' >> ~/.zshrc
echo -e '\n. /usr/local/share/zsh/site-functions/_asdf' >> ~/.zshrc

# add path to your shell environment, this is for .bash
echo -e '\n. /usr/local/opt/asdf/libexec/asdf.sh' >> ~/.bash_profile
echo -e '\n. /usr/local/share/zsh/site-functions/_asdf' >> ~/.bash_profile

# reload your shell environment or open a new terminal, your shell will be loaded correctly
source ~/.zshrc
source ~/.bash_profile

# that's it, now check asdf version installed
asdf --version

# check plugins installed, this command will show data after plugins installation
asdf list

# check current packages installed, this command will show data after setting a pack version
asdf current

Esta semana eu precisei atualizar alguns pacotes no meu MacBook, mas desta vez houve um requisito de utilizar uma versão específica do Elixir e ERLang. Foi aí que descobri que o amplamente difundido “brew” não suportava um gerenciamento de versões eficiente, praticamente o brew instala a “latest version” dos pacotes e pronto.

Percorri muitos artigos na web onde a maioria deles indicava o uso do “asdf” para um gerenciamento efetivo de versões. ASDF? What the hack is that?

Para quem, assim como eu, não era familiar a este gerenciador de pacotes, apenas pense nele como sendo um outro brew da vida, mas que tem as opções de escolher a versão que você deseja instalar.

Mais que isso, múltiplas versões dos pacotes podem ser baixadas e você pode fazer a troca de uma versão para outra sob demanda. Isso é muito comum para quem trabalha com múltiplos projetos onde versões específicas são requeridas em cada projeto.

No final das contas foi muito fácil instalar o gerenciador de pacotes asdf, basta seguir a receita do bolo.

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!

GIT Stash Como Nomear seu Stash

Posted on by marcelino.janing 
git stash push -m "Escreva um texto que identifique seu stash"

Quando iniciamos a utilizar o GIT vamos aprendendo aos poucos as várias utilidades que ele possui, uma das bastante corriqueiras é é salvar para área de STASH uma alteração em andamento que ainda não está pronta para fazer commit par uma branch.

Assim, você deve ser bem familiar aos comando de stash bem simples, como por exemplo:

git stash list
git stash
git stash pop
git stash apply

O ponto aqui é que o git stash simples registra como comentário padrão o nome da branch atual e ele provavelmente não vai remeter o entendimento ao real conteúdo que foi salvo.

Quando você for precisar salvar o stash por um longo tempo ou precisará identificar um stash específico entre muitos outros stashes você vai precisar usar a sintaxe com o git stash push.

Fantástico recurso… mão na roda pros devs!

PHPSTORM Instale o Plugin Git-Link para Compartilhar Código do Git-Hub

Posted on by marcelino.janing

Para quem trabalha com projetos hospedados no Git-Hub é comum ter que compartilhar um trecho de código com algum colega de trabalho para informar, analisar um problema ou algo do gênero.

Ao invés de copiar e colar um código fonte em algum aplicativo de chat, que tal simplesmente compartilhar um link URL do fonte completo e ainda marcando com High Lights o trecho de código a ser observado?

Então, este plugin faz exatamente isto, mas é claro que o sucesso no compartilhamento dependerá dos direitos de acesso aos repositórios no Git-Hub.

Depois de instalado o plugin, você deve verificar as configurações em Other Settings que fica na mesma tela de preferências do PHPStorm.

Claro que o plugin suporta outros sites de host além do Git-Hub, basta configurar em Host existe uma lista pré-definida, basta selecionar.

Para conferir as teclas de atalho previstas para o Git-Link acesse o Keymap na própria tela de preferências do PHPStorm.

Para obter um link URL para compartilhar um código fonte faça assim… no PHPStorm abra o código fonte e marque o bloco de código que deseja ressaltar no compartilhamento, pressione então a combinação de teclas de atalho CTRL + SHIFT + O e uma nova página será aberta no seu navegador padrão.

Então basta copiar o link da URL no navegador e enviar pelo seu aplicativo preferido tipo Slack ou mesmo por email, pois link URL é link URL em qualquer lugar.

Aproveite!

GIT Renomear uma Branch Local que já foi enviada para o Servidor Remoto

Posted on by marcelino.janing 
git checkout nome-da-branch-que-eu-nao-quero-mais
git branch -m nome-novo-que-eu-quero-para-branch

git push origin -u nome-novo-que-eu-quero-para-branch
git push origin --delete nome-da-branch-que-eu-nao-quero-mais

Você já deve ter passado por isso, ter criado uma branch no GIT e feito o Push para o servidor e só depois se deu conta que o nome que escolheu não ficou bom ou não representa o que está implementado por ela.

Pois bem, saiba que para corrigir isto é muito simples, independentemente se a branch já foi enviada ao servidor remoto ou não. Vamos explicar o passo a passo.

Primeiro, posicione-se na branch que deseja renomear usando o comando git checkout. Claro que é possível renomear uma branch mesmo se ela não for a branch corrente na sua working copy, mas isto tornaria os comandos mais complexos e mais difíceis de decorar… deixa pra lá!

Em seguida com o comando git branch -m você simplesmente informa o novo nome que deseja para sua branch.

Voilà! Sua branch foi renomeada, mas isso foi feito somente no seu GIT Local. Caso a sua branch ainda não tenha sido enviada para o servidor com o git push você pode parar por aqui. Mas caso já tenha feito o git push antes de renomear ainda temos mais dois comandos para deixar tudo em ordem.

O próximo passo é enviar a branch renomeada para o servidor usando o git push origin -u que indica que estamos resetando o upstream da branch. Se você não fizer isso a sua branch local continuará sendo enviada para o mesmo ponto no servidor remoto, ou seja, a branch com o nome antigo.

Agora, para finalizar temos que nos livrar da branch antiga que ainda está lá no servidor remoto. Para isso basta eliminarmos completamente ela fazendo um git push origin –delete indicando o nome antigo.

Prontinho, a branch antiga sumiu do servidor remoto e a branch renomeada agora existe no servidor remoto, no ambiente local e está na sua área de working copy.

GIT Rebase com Git Pull durante atualização da Branch

Posted on by marcelino.janing 
git pull --rebase origin master --autostash

Quem se lembra de quando começou a trabalhar com GIT e tinha medo de fazer um rebase e melar a branch atual?

Pois é, o rebase na verdade é uma ação muito tranquila de ser executada, ainda mais se utilizarmos como opção de outro comando amplamente conhecido e dominado por todos.

Isso mesmo, fazer o rebase durante a atualização da branch é possível, e sinceramente, depois de ter aprendido esta forma não me recordo de ter utilizado o git rebase isoldamente.

Explicando o comando acima, fazer um git pull é super tranquilo certo? Você faz o pull quando precisa trazer as atualizações do servidor para a sua branch local, ponto. Mas o que acontece se você ja tem um commit nesta sua branch local?

Isso mesmo, para que o seu commit fique no topo da pilha você precisa fazer um rebase. Assim o Git gentilmente lhe dá a opção de fazer o rebase no mesmo momento de atualizar a branch.

A opção –autostash ajuda quando você possuir alterações ainda sem commit, assim você economiza mais um tanto e não precisa fazer o stash manual antes de atualizar a branch.

Mágico, não?

GIT Configurando comportamento padrão para Git Status e Git Push na linha de comando

Posted on by marcelino.janing 
git config --global status.showuntrackedfiles all
git config --global push.default current

Operar o Git através de ferramentas gráficas é muito fácil, mas este não é o ambiente nativo disponibilizado pela ferramenta.

Saber operar o Git pela linha de comando é o máximo, mas leva algum até você conseguir dominar a sintaxe e memorizar os principais comandos. Além disso, o ambiente pode ser configurado para se comportar adotando alguns padrões pré-estabelecidos que são muito usuais, assim você acaba economizando na digitação e também nos erros.

Os comandos acima são dois padrões que eu costumo configurar logo após instalar o Git.

A primeira configuração faz com que o comando git status mostre os arquivos novos criados que ainda não foram adicionados ao repositório. Sem este default configurado seria necessário informar um argumento opcional –untracked-files para visualizar os arquivos novos. Os comandos abaixo irão listar todos os arquivos novos.

git status -u
git status -uall
git status --untracked-files
git status --untracked-files=all

A segunda configuração faz com que o comando git push envie os commits para o servidor remoto atualizando a branch com o mesmo nome da branch local. Sem este default configurado seria necessário informar adicionalmente o local do repositório e o nome da branch remota. Os comandos abaixo representam a forma de fazer o push dos commits para a branch desejada, neste exemplo enviando para a mesma branch localmente posicionada.

git checkout master
git commit -m "commit your changes"
git push origin master

git checkout -b first-branch
git commit -m "commit your changes"
git push origin first-branch

Lembrando que você pode a qualquer momento verificar as configurações correntemente válidas para o seu ambiente ou ainda remover alguma configuração indesejada.

git config --list
git config --unset status.showuntrackedfiles

Obviamente existem muitas outras personalizações que podem ser configuradas, mas estas duas eu considero essenciais para a operação do dia a dia.