Manual Clone e Commit no Git

O software TortoiseGit é uma de várias possíveis interfaces gráficas para Git no Windows. Ele pode ser baixado em sua versão mais recente no site: https://tortoisegit.org/download/. Para que o TortoiseGit funcione corretamente, faz-se necessária a instalação do Git for Windows, no site: http://git-scm.com/download/win. Apenas após a instalação do mesmo, o TortoiseGit deve ser instalado. Atenção à versão baixada (32-bit ou 64-bit), que deve obedecer às especificações da sua máquina para as duas instalações.

Usando o Windows Explorer, na pasta onde se deseja manter o repositório local, clica-se com o botão direito. No menu de contexto, a opção "Git Clone" deve ser selecionada.

Na janela que segue, no campo URL, deve ser colado o link de clone copiado da página de repositório do Gitlab. Se o link já estiver previamente copiado, deve aparecer automaticamente no campo.

Da primeira vez que se faz qualquer operação num repositório, o TortoiseGit exige informações de usuário. Basta colocar o nome de usuário e e-mail Basis, e clicar em OK.

O nome de usuário e a senha da rede devem ser digitados para validar o clone.

Os mesmos ficarão salvos no Gerenciador de Credenciais do Windows, caso precisem ser alterados.

Após a confirmação da senha, uma tela será exibida informando o progresso do clone.

Ao concluir, o repositório já estará localmente replicado na máquina do usuário.

O Git oferece a opção de clone dos repositórios via HTTPS, como já foi apresentado, ou via SSH. O SSH costuma ser mais prático e menos limitado que o HTTPS, mas necessita de várias configurações locais e remotas para funcionar devidamente.

Inicialmente, deve ser gerada uma chave SSH localmente na sua máquina. Para tanto, vamos usar a interface padrão de console do Git for Windows, que também serve como alternativa ao próprio TortoiseGit, se for mais interessante usar comandos de linha diretamente em vez de uma interface gráfica.

Na máquina local, buscar, no menu Iniciar ou na barra de buscas do Windows, o programa Git Bash. A janela inicial será um console em preto:

Digitar o seguinte, e pressionar Enter:

O console vai pedir, na ordem:

Acessando o caminho da chave no Windows, devem haver dois arquivos: id_rsa e id_rsa.pub. O segundo deve ser aberto em qualquer editor de texto, para que se possa copiar a chave.

Com a chave em mãos, entrar no Gitlab, e adentrar a seção "Configurações", no menu do canto superior direito.

Ali dentro, selecionar no menu esquerdo "Chaves SSH". Na seção que se abrir, colar a chave do id_rsa.pub, dar um título para identificar a chave, então clicar no botão "Adicionar Chave" abaixo.

Feita a adição com sucesso, a última coisa que precisa ser feita é uma alteração local do programa utilizado para SSH no TortoiseGit. No menu iniciar ou de busca, procurar por Settings, um programa que tenha o ícone do TortoiseGit. Entrando no mesmo, selecionar o item Network no menu esquerdo. Ali dentro em SSH, basta colocar o caminho do executável SSH do Git for Windows (por padrão, C:\Program Files\Git\usr\bin\ssh.exe, variando o início do caminho de acordo com a sua pasta de instalação) e clicar em OK.

Feito isso, operações de repositório já podem ser realizadas usando SSH. Basta fazer o clone do repositório utilizando o link SSH que o mesmo fornece na página do repositório.

Dentro da página no Gitlab do repositório que se deseja copiar, clicar em Fork, no canto superior direito.

Selecionar como namespace o próprio nome de usuário, apresentado por padrão na página.

O repositório será criado e toda a estrutura de commits passará por uma importação. Uma vez finalizada, o repositório apresentará a mesma exata estrutura que o original. Desse ponto em diante, as ações de clone e push seguirão os mesmos princípios já apresentados.

Para que o código atualizado no fork seja replicado no repositório original, é necessário que seja aberto um merge request a partir do fork, apontando para a branch do repositório original. Esse merge request precisa ser aberto por um usuário que tenha acesso de escrita no repositório original, e é necessário que haja mais de um commit para o merge, pois será realizado um git squash. Caso seja aberto pelo próprio dono do Fork, que possui acesso somente leitura ao original, ou caso possua apenas um único commit, será fechado imediatamente pelo próprio sistema.

Na tela do repositório fork, no menu esquerdo, clicar em "Merge Requests".

Dentro da tela, haverá um botão "Novo Merge Request". Selecionando o mesmo, será aberta uma nova tela para seleção de quais branches e repositórios servirão como origem e destino. Para origem ("Source Branch"), selecionar o seu fork e a branch onde se trabalhou. Para destino, selecionar o repositório original, e a branch do mesmo onde o merge deverá ser feito. Clicar em "Compare branches and continue".

Na tela que se segue, escrever um título para o seu merge request, preferencialmente incluindo a ocorrência relativa aos commits em questão para que esteja na mensagem de squash. Adicionar também uma descrição, que será unida ao template de MR da Basis, quando aplicável. No campo Assignee, apontar um usuário responsável pela aprovação do MR, caso necessário. A opção "Delete source branch when merge request is accepted" apagará a branch original do fork assim que houver o merge de fato. E a opção "Squash commits when merge request is accepted" será marcada automaticamente, mesmo que seja desmarcada nesta tela.

Uma vez criado, o merge request será listado no menu de Merge Requests do repositório original.

Também será criado um link para acessar o merge request na ocorrência do SGO mencionada pelo mesmo.

Quando aprovado e selecionada a opção Merge, será realizado um commit de squash combinando os commits do repositório de fork, mais um commit de merge mesclando os dois repositórios. O código então será disponibilizado na branch do repositório original. Se houver algum problema no merge ou na criação do próprio merge request, o próprio sistema informará em mensagem.

Quando o fork se encontra atrasado em relação ao repositório original, é possível atualizá-lo em seu repositório fork clonado localmente. Para isso, é necessário inicialmente adicionar o repositório original como um novo remote caso não exista, executando no seu repositório local o seguinte comando:

Atualiza-se então esse remote "upstream" usando um fetch:

Para sincronizar de fato seus arquivos locais com os do repositório original, realiza-se um merge do seu repositório local, usando como base a branch requisitada do original (por padrão, "master"; alterar de acordo):

Por fim, para atualizar o repositório no Gitlab, realiza-se o push padrão:

Verifique, antes de tudo, se seu repositório local está atualizado. Diferente do SVN, não basta que apenas a pasta específica em que se está editando esteja devidamente atualizada; o repositório inteiro deve estar em dia. Realize sempre um Pull antes de fazer quaisquer modificações.

Se o repositório não estava atualizado, mas o commit foi feito ainda assim, realize um Pull de todo modo. Pode ser que não haja conflitos de arquivos modificados. Se for o caso, o Pull não retornará erros, não haverá ícones de conflito nas pastas, e o seu Push pode ser realizado diretamente em seguida (sem o commit, nesse caso, pois este já havia sido feito).

Entretanto, se houver conflitos, cabe verificar com a sua equipe se os arquivos em questão foram modificados. O próprio Log do Git deve retornar informações sobre quais foram as últimas modificações sobre o determinado arquivo, o que pode ser verificado clicando sobre o mesmo com o botão direito e selecionando, sob o menu do TortoiseGit, Show Log.

A janela seguinte terá informações de quais foram os últimos commits, e quem os realizou, para devida informação e discussão.

Uma vez que se tenha certeza que o arquivo existente no seu repositório local é o mais atualizado, deve-se selecionar, no menu do TortoiseGit na pasta, a opção "Resolve".

Marca-se então os arquivos atualizados, confirma, e então o Commit/Push pode ser realizado novamente com maior segurança.

Se ainda houver erro, experimente executar um Clean up, opção logo acima também representada. Execute também um novo Pull em seguida, para poder realizar o commit depois com segurança, e certifique-se de que todos os arquivos estão presentes no repositório local.

Para corrigir essa situação, é necessário emendar à mensagem do commit uma ocorrência válida do SGO. Se apenas um commit errôneo foi realizado, basta selecionar Git Commit novamente no repositório em questão e selecionar a opção Ammend Last Commit na caixa logo abaixo da entrada de mensagem:

Em seguida, clicar em Ok e seguir com o mesmo modelo de Commit/Push apresentado mais acima.

Se houver mais de um commit na fila, no entanto, e até mesmo em outros casos de erro recorrente, será necessário fazer um Rebase, ou refazer os commits do zero antes de realizar o Push.

Quando um commit é feito no Git, ele se mantém na fila para subir ao repositório remoto num Push. Outros commits em cima do mesmo apenas se acumulam na fila. Ou seja, se o primeiro commit está errado, ele permanecerá sem enviar para o sistema até que seja removido ou editado na fila. Nesse caso, como existem vários commits errados na fila, a procedência possível seria editar ou eliminar a mesma.

Para o primeiro caso, o chamado Rebase, clicar com o botão direito na pasta do repositório com os commits problemáticos, e dentro do menu do TortoiseGit, selecionar a opção Rebase.

Na janela que segue, marcar inicialmente a opção Force Rebase, para que o sistema leve em conta todos os commits diferentes entre o repositório local e o remoto. Em seguida, clicar com o botão direito no commit que está com problemas (pode ser mais de um), e selecionar a opção Edit. Feito isso, iniciar o Rebase através do botão Start Rebase no rodapé da janela.

Uma vez iniciado, se configurado corretamente, ele vai parar para edição da mensagem do(s) commit(s) em questão. Adicionar a ocorrência faltante, e clicar em Ammend, e em seguida em Done.

Terminado o processo de Rebase, o Push já pode ser feito sem a necessidade de fazer um novo commit.

Para o caso de refazer a fila de commits do zero, primeiramente, é interessante fazer um backup dos arquivos alterados em tais commits, pois serão apagados ou substituídos pelas versões atualmente presentes no repositório remoto. Com o backup feito, selecionar na pasta raiz do repositório: TortoiseGit > Switch/Checkout. Na janela aberta, deixar exatamente como está na imagem abaixo, com todas as marcações (ênfase na branch remote/origin/master do primeiro menu, não é a master originalmente selecionada).

Após clicar em OK, o repositório retornará ao seu estado anterior aos commits errôneos, exatamente igual ao repositório online. Com isso, os arquivos no backup podem ser copiados de volta para a pasta do repositório, e o commit pode ser refeito.

Se houver mais erros, entre em contato com a gerência de configuração.

É possível que o repositório em questão tenha nomes de arquivos ou caminhos muito grandes e, quando se realiza um Clone do mesmo num sistema Windows, ele não consiga abranger todo o caminho, retornando erros de Filename too long. Se for esse o caso, experimente realizar o Clone em outra pasta do seu sistema, preferencialmente alguma num caminho bem curto, como C:\git.

Outro erro possível teria a seguinte mensagem: error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure. Nesse caso, é necessário atualizar os protocolos de conexão SSL na configuração do Git para uma versão mais segura. Execute o seguinte comando no Git Bash (para seu uso, consultar a seção de SSH):

Após essa alteração, o Clone/Pull deve funcionar corretamente. Caso contrário, ou se o comando retornar algum erro, é recomendável reinstalar o Git numa versão mais recente.

Se tais soluções não funcionarem, ou se o erro for diferente, entre em contato com a gerência de configuração.