Na segunda parte dessa reprodução do HOL – Iniciando com Git, criamos um branch, fizemos uma alteração no código, encadeamos o um add nocommit, vimos um log mais detalhado, e mandamos tudo para o repositório! 🙂

O que vamos fazer nessa terceira parte é simular um desenvolvimento paralelo ao nosso, que é bem comum em projetos de software, e como fazer o merge desse código!

Então sem mais delongas…

O primeiro passo é clonarmos o repositório em outra pasta, para simular o trabalho de outro desenvolvedor, como Adam, para isso vamos copiar novamente a URL do repositório no VSO, já sabe onde fica né? No clone do primeiro post usamos git clone <url>, mas já existe um repositório de nome FabrikamCommunity, por isso coloque mais um parâmetro no comando que é um nome de pasta:

git clone http://vsalm:8080/tfs/FabrikamFiberCollection/_git/FabrikamCommunity

Eu já utilizei o login do Brian… Usando o mesmo comando de log do post passado, vamos verificar o que tem nesse repositório:

git log – graph –decorate –all

No fim do post anterior mandamos o código para o servidor, por isso ocommit “dev version” aparece aqui, mas ele está na branch desenvolvimento, se você listar as branchs, verá que ela não vai aparecer, é preciso fazer um checkout para “baixar” essa branch… Nem precisamos fazer nada disso, porque o Brian vai ignorar a existência desse commit, imagine que ele recebeu um pedido de alteração errado ou atrasado, já que a Julia vai alterar novamente depois. Vamos fazer a alteração direto na master!

Abra a solution desse repositório no Visual Studio e vá no arquivo HomeController.cs, na pasta Controllers, procure pelo método About e troque a string no método para:

“Adam’s description.”

Só salvar e volta para o console. E seguindo o scritp:

git status

…lá está a alteração…

git commit –am “Adam version”

…faz o add e commit…

git push origin master

…e manda para o servidor! E volta para o repositório da Julia!

Enquanto a Julia fazia a alteração, post passado, o Adam fez um commitna master, e ainda por cima no mesmo lugar que ela.

Nesse momento a Julia vai fazer o merge do branch desenvolvimento para master:

git merge desenvolvimento

A branch master não foi atualizada, portanto o merge do branchdesenvolvimento para master será um Fast-forward, é o nome dado quando o merge executa sem conflito, ou seja é feito automáticamente…Mas o posh-git ficou verde, e isso é um alerta que o branch master está à frente da sua remote!

Os status do posh-git são:
Azul – branch local está equalizada com a remota
Verde – branch local está na frente da remota
Vermelho – branch local está atrás da remota
Amarello – branch local está na frente e atrás da remota o_O

Vamos tentar mandar?

git push origin master

Rejeitado! O Git rejeita porque o repositório remoto tem código que o repositório local não tem, e dai você estaria sobrescrevendo o código lá, o que talvez não seja uma boa ideia, já que lá o código pode estar certo mesmo…

Vamos fazer o seguinte, vamos voltar atrás no merge? Posso fazer isso tranquilo por que esse código não foi para o repositório central, mas não seria uma boa ideia se o código estivesse lá! Primeiro eu preciso saber o número de identificação do commit, que é aquele hash que aparece no comando log:

git log

…copia os 6 primeiros caracteres do commit que eu quero voltar, ou seja 95c16e, e vamos eliminar o outro commit:

git reset –hard 95c16e

…para validar:

git log

Só vou ter o commit anterior… E a alteração que a Julia fez, perdi? Não! Mas se você não acredita, faça o teste:

git checkout desenvolvimento

git log

…está lá!

git checkout master

O Git sempre te ajuda… Repare que voltando para o branch master ele diz que o branch está atualizado, isso porque não fizemos nenhumcommit para ele mandar para o servidor, isso quer dizer que voltamos a situação antes de fazermos o merge do desenvolvimento com o branch master.

Boa prática: antes de fazer um push, faça um pull! Esse comando irá trazer as alterações do branch remoto para o seu branch local, como trabalhamos em um branch separado, Feature branch é uma boa prática por isso; não teremos conflito!

git pull

O master estava sem conflito, por isso baixou o commit que existia nomaster remoto e atualizou-o. Vamos fazer o merge agora do branch de desenvolvimento para master.

git merge desenvolvimento

O Git vai tentar fazer o merge, mas vai dar conflito, vamos resolver o conflito. Existe uma ferramenta de diff no console, é possível colocar uma de terceiros, mas já que estamos usando o Visual Studio e o console como um auxiliar, ao invés de usar o mouse o tempo todo, vamos manter assim até o fim dessa série, em outra oportunidade veremos as alternativas para esses momentos.

Estou presumindo que o seu Visual Studio está aberto na solution do repositório da Julia (não no do Adam, se você está seguindo essa simulação), dê ALT + TAB, o seu Team Explorer deve estar assim:

A mensagem diz que um merge está em andamento, lembra que é o mesmo repositório a atualização é instantânea, mas deu conflito! Vamos resolver o conflito, para isso clique no hyperlink Resolve the conflicts.

O painel vai listar os arquivos em conflito, selecione o arquivo e você terá várias opções, ver a diferença entre os arquivos, escolher a fonte ou o alvo, sem nem mesmo abrir, ou o botão Merge, clique nele.

Eu tenho o arquivo fonte (1), ou source, por que eu fiz o merge do branch desenvolvimento para master, o meu arquivo alvo (2), ou target, o resultado, que por enquanto está mostrando o código antigo… E repare que eu tenho check-box em cada linha em conflito, então de maneira visual eu posso ir selecionando as linhas que eu quero, selecione a linha do source (4), e as linhas que eu ainda não resolvi o conflito estão em vermelho.

Aproveite e dê uma passada de mouse no menu dessa tela para ver as tooltips dos botões, você verá que tem botões para navegar pelos conflitos, com atalhos, então dá para continuar usando somente o teclado no ambiente visula; mudar a visualização, comparar…

Escolhida a linha do source, conflito resolvido, linha verde, clique em Accept Merge.

Os conflitos foram resolvidos, verifique no Team Explorer:

Voltando para o console…

git status

Só para conferir, conflito resolvido e arquivo já adicionado para commit!

Só fazer o commit:

git commit –m “Merge”

git push origin master

Acesse o Web Portal, vamos dar uma olhada nos commits:

Está aí… O commit da Julia (1), em seguida o Adam fez um commit (2) e depois a Julia fez um merge (3) (está tudo com o meu nome porque o meu Git estava configurado assim, mero detalhe!).

Vá em Branches:

O meu branch de desenvolvimento remoto está desatualizado em relação ao branch master (1), ele não tem o commit do Adam e nem ocommit de merge.

Este post termina o equivalente do HOL – Iniciando em Git. Isso foi só um equivalente do que é possível fazer na interface gráfica, Team Explorer, com o Git. Tem muito mais e para isso virão outros posts, por exemplo, existe um fluxo de trabalho melhor do que atualizar o master, “mergear” com a feature branch e enviar para a master remota, podemos usar mais ferramentas no lugar do diff do Visual Studio, existem comandos poderosos…

Semana que vem voltamos ao ritmo normal, até!