Executando verificação de segurança...
4
fern
2 min de leitura ·

git add, git commit, e git push... não, obrigado?

git add *
git commit -m "commit message"
git push

Eu rodo esses comandos praticamente todos os dias. Pelo menos 10 vezes. É bastante coisa! Claro, nunca me incomodou, até que recentemente eu tive de lidar com uma situação bem específica em que dois repositórios tinham de ter o mesmo histórico de commits, e aí eu passei a precisar rodar esses comandos o dobro de vezes!

Foi aí que eu decidi brincar um pouquinho, e utilizar um pouco dos meus estudos de Go para fazer uma CLI para automatizar esses 3 comandos (e a minha situação mais específica).

Eu abstraí os 3 comands acima nesse belo comando aqui:

nena -m="feat: commit message"

Ficou bem menos verboso! E, sim, chamei de Nena, achei um nome bem legal, embora não tenha nenhuma relação com o contexto do projeto, me digam se acharam um bom nome também.

Para o meu problema mais específico, eu precisava de ainda mais comandos, algo mais ou menos assim:

git add *
git commit -m "commit message"
git push

git remote rm origin
git remote add origin github.com/2
git push

git remote rm origin
git remote add origin github.com/1

E abstraí para:

nena -c=true -m="commit message"

Maneiro, não é? Pelo menos eu achei! É um projeto muito simples, foi feito em uns 30 minutos, mas mesmo assim eu gostei pra caramba de fazê-lo, porque é algo que está tendo utilidade imediatamente após estar pronto e me fez ficar pensando no quão útil é construir CLIs. Pensa em todas as coisas repetitivas que você faz no seu dia a dia que você poderia abstrair numa CLI, criando um projeto bacana e facilitando sua vida.

Para quem se interessar, aqui está o código da CLI: https://github.com/assincrono/nena

Carregando publicação patrocinada...
5
kht

Legal, eu também faço esse tipo de coisa, seja criando aliases pra coisas mais simples (por exemplo, definir git s como um alias para git status, porque sou preguiçoso nesse nível) ou bash scripts para coisas mais complexas (como é o seu caso).

Mas só uma coisa, neste trecho:

git remote rm origin
git remote add origin github.com/2
git push

git remote rm origin
git remote add origin github.com/1

Vc fica removendo e adicionando os remotes toda hora, e acho que não é o melhor jeito de lidar com essa situação.

Se vc sempre precisa fazer o push para dois repositórios remotos, basta criar um novo remote com as duas URL's.

No exemplo abaixo vou chamar este remote de all:

# Cria o remote chamado "all" e adiciona a URL do repositório principal
git remote add all github.com/1

# adiciona a segunda URL (repositório secundário) ao remote "all"
git remote set-url --add --push all  github.com/2

# agora precisa setar de novo a URL do repositório principal (abaixo explico o motivo)
git remote set-url --add --push all  github.com/1

O terceiro comando parece redundante, mas ele é necessário porque o segundo comando sobrescreve a URL que foi definida pelo primeiro comando (é estranho, mas enfim, isso é explicado aqui).

Agora se rodarmos git remote show all podemos ver ambas as URL's definidas para push:

* remote all
  Fetch URL: github.com/1
  Push  URL: github.com/2
  Push  URL: github.com/1

etc... (mais um monte de informações)

Então basta fazer git push all meu_branch, que será feito o push do meu_branch para ambos os repositórios, sem a necessidade de ficar apagando e recriando os remotes toda hora.

Lembrando que na primeira vez, quando o branch ainda não está mapeado para este remoto, é interessante fazer git push all -u branch, assim o branch será mapeado para o remote all e nas próximas vezes bastará rodar git push.

E claro que vc pode usar o nome que quiser para o remote. Eu só usei "all" nos exemplos porque sou muito criativo :-)
Poderia até fazer no próprio origin, por exemplo.

Se quiser mais informações, eu deixei um guia mais detalhado aqui.

Obs: claro que vc também poderia ter dois remotes separados, cada um com sua URL:

git remote add principal github.com/1
git remote add secundario github.com/2

E então chamar git push separadamente para cada um deles:

git push principal meu_branch
git push secundario meu_branch

Fica a seu critério decidir o que é melhor para o seu caso.

De qualquer forma, em qualquer uma dessas opções vc só cria os remotes uma vez e depois escolhe para qual quer fazer o push. Eu acho melhor do que ficar apagando e adicionando remotes toda hora.

2
fern
  • Autor
    Autor

Pô cara, excelente comentário!
Fiz exatamente como sua sugestão, adicionei outra URL para a minha origem, e então quando faço o git push, vai para os dois repositórios, e apaguei o comando mais extenso de adicionar e remover URLs da CLI pra só ter o nena -m="commit message".

1
Pilati

com uma situação bem específica em que dois repositórios tinham de ter o mesmo histórico de commits

Poderia nos compartilhar que situação é essa? pois simplesmente não faz sentido ter 2 repositórios contendo a mesma coisa