Sincronizando um repositório replicado do git

Quando é usada a opção de fork¹ para replicar² um repositório git, o resultado final será um novo repositório contendo a mesma história do original (os commits passados) porém independente dele a partir deste ponto (os commits futuros). Algo diferente do que acontece quando é utilizado o git clone para copiar um repositório remoto pois ele permanece ligado ao original e sendo possível mantê-lo sincronizado — git pull — como também enviar novos commits — git push — para ele.

TL;DR! Pode saltar o resto da explicação se preferir…

A interação entre os repositórios de origem e o replicado acontece a partir da ferramenta utilizada para o gerenciamento dos repositórios (ver nota 1) através do pull request. Que basicamente é um instrumento que permite aplicar commits vindos “de fora” ao repositório e mediante intervenção humana para fazer a validação. O mesmo também acontece com o git push no envio dos commits do repositório clonado para o remoto com a diferença de que como você precisa ter permissões para fazê-lo eles são automaticamente aplicados³.

Até aí tudo bem se considerarmos dois casos bem específicos: (i) repositório remoto com contribuições que virão sempre de membros válidos trabalhando a partir de repositórios clonados ou; (ii) repositório replicado que terá um desenvolvimento distinto daquele no qual ele se originou.

Mas existe um terceiro caso, aquele em que você faz a réplica de um repositório ao qual não é membro mas ao qual não dá para como combinar com os membros dele para que aguardem seus pull requests. Não é estritamente necessário mas é recomendável para não trabalhar em versões (muito) antigas dos arquivos.

E este é fim desta longa introdução! 🙂

(¹) A opção está disponível nas interfaces de gerenciamento de repositórios, como BitBucket, GitHub GitLab etc não na ferramenta (git) em si.

(²) A tradução seria “bifurcado” mas creio que “replicado” é um termo bem melhor.

(³) Em alguns casos, o administrador do repositório pode proibir a atualização em ramos específicos, como o master e neste caso também é necessário utilizar um pull request para aplicar suas alterações.

Modificando commits do Git

Na parte 6 do “Usando o Git”, recorri ao git rebase (em modo interativo) para faz a alateração da mensagem de um commit pré existente. Porém esta tanto não é a única funcionalidade do rebase¹ como ainda há um modo bem mais simples de fazê-lo.

E que não serve somente para alterar a mensagem, com o uso do parâmetro ‐‐amend (emenda) do git commit é possível adicionar, editar ou mesmo remover arquivos dentro de um commit já existente.

(¹) Relembrando que o rebase permite coisas como descartar ou mesclar commits.

Usando o Git – parte 6

A parte anterior consistiu basicamente em um navegar pelo histórico dos commits com recolocando a HEAD em outros posições e até mesmo destacando-a da linha do tempo para testar modificações sem necessariamente precisar armazená-las. Para esta parte, o uso do stash para armazenar temporariamente arquivos de trabalho e um exemplo do uso do rebase para modificar um commit já existente — neste caso alterar a mensagem deste.

Usando o Git – parte 5

A ideia era de apenas acrescentar algumas informações e servir de complemento à série sobre Git — publicada há pouco mais de um ano — mas acabei me empolgando um pouco e ao invés de dividir um complemento, o que seria estranho, preferi integrá-lo logo de uma vez como uma nova parte. Nesta, um pouco mais sobre o histórico, configuração, ramos — branches — e “cabeças decepadas” 🙂

Jenkins – parte 3

Esta é a última parte desta série sobre o Jenkins e é também onde justamente tudo aquilo ensaiado na parte anterior será efetivamente colocada em prática com a criação de um job contendo várias etapas, com execução disparada por um outro e, para encerrar algo mais complexo que o Freestyle Project, a execução em pipeline.

Então é iniciar a máquina virtual com vagrant up para começar a usá-lo.

Jenkins – parte 2

A primeira parte consistiu basicamente em instalar e deixar o Jenkins minimamente configurado e, claro, funcionando. A parte de acesso a usuários permite usar diversos modos de autenticação (LDAP, usuários locais etc) enquanto os plugins consistem quase que em um universo a parte dentro do Jenkins.

Agora será a vez de efetivamente utilizá-lo para a criação de alguns build jobs, um primeiro para meramente testar o funcionamento da ferramenta e um outro cuidando de monitorar alterações no repositório do código fonte e se encarregar de compilá-lo.