Contribuíram neste tutorial Ieremies Vieira da F. Romero, Matheus Otávio Rodrigues
Instalação do Git
Como você já viu na tarefa de teste, iremos utilizar um gerenciador de versões para registrar o desenvolvimento e entregar as tarefas. Se ainda não instalou o Git, não perca tempo:
Configuração básica
Logo depois de instalar o Git, é necessário configurar seu nome e e-mail, para
que ele registre o autor das alterações nos arquivos. Para isso, execute os
comandos abaixo em um terminal do sistema operacional em que você instalou o
comando git
. Se tiver utilizando WSL, execute no terminal do Ubuntu.
user@host$ git config --global user.email "XXXXXX@dac.unicamp.br"
user@host$ git config --global user.name "Fulana da Silva"
Problema comuns
Por que não consigo realizar git push
dos meus arquivos algumas vezes?
Lembre-se que git push
é o comando que irá colocar as mudanças “commitadas” no
repositório local para o repositório remoto (por padrão, origin
, que no nosso
caso é o gitlab do ic). Imagine que você acabou de clonar o repositório da
disciplina. A situação é essa:
origin: c0 <--- c1
local: c0 <--- c1
Ou seja, para o git, ocorreu o commit c0
e depois o c1
(na estrutura do git,
cada commit aponta para seu parente). Como você acabou de clonar o repositório
da disciplina, ambos estão iguais.
Digamos agora que você resolveu a tarefa 2 e “commitou” como t2
. Como essa
mudanças foram apenas locais, nossa situação é a seguinte:
origin: c0 <--- c1
local: c0 <--- c1 <--- t2
Agora nosso repositório local possui modificações a mais do que o repositório
remoto do GitLab. Caso desejamos colocar essas novas modificações no remoto,
podemos fazer git push
e o resultado será:
origin: c0 <--- c1 <--- t2
local: c0 <--- c1 <--- t2
Digamos agora que você fez a tarefa 3 e “commitou” como t3
. Mais uma vez,
agora temos a seguinte situação:
origin: c0 <--- c1 <--- t2
local: c0 <--- c1 <--- t2 <--- t3
Porém, antes de você sincronizar seu repositório local com o remoto, foi postada
uma nova tarefa, a tarefa 4. Similarmente ao processo que fazemos manualmente, o
sistema irá “commitar” a nova tarefa no seu repositório remoto do GitLab,
digamos um commit t4
.
origin: c0 <--- c1 <--- t2 <--- t4
local: c0 <--- c1 <--- t2 <--- t3
Agora, se você tentar fazer git push
você será apresentado com um erro, nesse
caso:
warning: redirecting to https://gitlab.ic.unicamp.br/mc202-2020/ra217938.git/
To https://gitlab.ic.unicamp.br/mc202-2020/ra217938
! [rejected] main -> main (fetch first)
error: failed to push some refs to 'https://gitlab.ic.unicamp.br/mc202-2020/ra217938'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
Isso acontece pois existem mudanças no repositório remoto que ainda não foram
adicionadas ao seu repositório local. No jargão git, dizemos que as branches
ficaram divergentes. Como nessa disciplina o sistema nunca irá mexer nos mesmo
arquivos que você, tudo que você precisa fazer é atualizar seu repositório local
com git pull --rebase
. Isso faz duas coisas automaticamente. Primeiro, o git
faz um fetch de t4
para a cópia local:
origin: c0 <--- c1 <--- t2 <----- t4
+----t4
/
/
/
/
v
local: c0 <--- c1 <--- t2 <----- t3
Depois o git fará um “rebase” do seu commit local t3
em cima do commit remoto
t4
, fazendo com que o histórico fique assim:
origin: c0 <--- c1 <--- t2 <----- t4
+----t4 <----- t3
/
/
/
/
v
local: c0 <--- c1 <--- t2
E agora sim você poderá fazer git push
para entregar sua tarefa.
Utilizando o Git eficientemente
Neste curso serão utilizados a ferramenta de controle de versão Git em conjunto com a interface do Gitlab no IC. Na disciplina, utilizaremos apenas comandos básicos do Git, então é necessário entender alguns conceitos-chaves, como clonar repositórios, realizar commit, push e pull. Já o Gitlab funcionará apenas como repositório remoto e você não precisará tomar nenhuma ação adicional ou realizar outras configurações.
Embora a necessidade de utilizar gerenciamento de versão na disciplina seja reduzida, é importante aprender a utilizar ferramentas como o Git e Gitlab em maior profundidade. Ferramentas como essas fazem parte do dia-a-dia de profissionais da área de TI, que precisam criar, buscar e manusear grandes números de arquivos (principalmente arquivos de texto), que mudam com muita frequência. Na verdade, qualquer pessoa que precisa manter várias versões de um mesmo arquivo pode se beneficiar com um gerenciador de versão.
Você pode estudar alguns comandos básicos do git neste tutorial aqui.
Arquivo .gitignore
Nem todos os arquivos que manuseamos precisam ser guardados. Para controlar quais os arquivos são monitorados pelo git, podemos criar uma arquivo .gitignore
. Esse arquivo lista quais arquivos serão totalmente ignorados ao fazer commits. Ele é usado quando mantemos na mesma pasta de repositório arquivos criados automaticamente, bibliotecas baixadas de outras fontes, arquivos temporários e afins.
No repositório de vocês, o arquivo .gitignore
já existe e está populado com algumas exclusões. Vamos ver mais de perto:
tarefa*/testes/*.out
__pycache__
Cada linha contém um padrão representando um arquivo ou diretório a ser ignorado. Na primeira linha temos duas ocorrências do asterisco (*
), que é um caracteres coringa ou wildcard e representa qualquer sequência de caracteres no nome de um arquivo. Por essa primeira linha, descobrimos que serão ignorados todos os arquivos com extensão .out
(não importa o nome), que estejam dentro de um diretório testes
, que por sua vez esteja dentro de quaisquer diretório que comece com o texto tarefa
. Veja os exemplos:
tarefa00/testes/teste1.out -> será ignorado
tarefa00/testes/qualquer_nome_mesmo.out -> será ignorado
tarefa00/teste1.out -> NÃO será ignorado, pois não está dentro de testes
tarefa-qualquer/testes/oi.out -> será ignorado
A segunda linha contém apenas um nome (nenhum asterisco e nenhuma barra). Assim serão ignorados quaisquer arquivos ou diretórias com o nome __pycache__
. Normalmente, diretórios com esse nome são criados pelo próprio interpretador Python durante a execução de um programa para gerados automaticamente, não queremos armazená-los no repositório. armazenar caches de programas compilados. Como esses arquivos são
Uma outra maneira de controlar quais alterações serão registradas em um commit é selecionando apenas os arquivos que tiveram alterações de interesse. Normalmente, fazemos git add .
para adicionar no commit todas as alterações do diretório atual, mas se quisermos adicionar apenas alguns arquivos no commit, é melhor escrever git add <nome_arquivo>
. Assim, quando fizer git commit -m "mensagem"
, poderá ver que outros arquivos modificados ainda não foram registrados.
Revendo a história
De nada adianta guardar várias versões de um arquivo se não pudermos ver versões anteriores. Por isso, precisamos descobrir como rever versões anteriores bem como decidir quando devemos registrar alterações.
Por que registrar alterações?
Ao utilizar o Git estamos utilizando uma ferramenta completa para controle de versão, isso inclui a possibilidade de registrar as alterações de arquivos por meio de commits, possibilitando posteriormente voltar atrás em versões (commits) anteriores do seu código.
A grande vantagem disso é poder recomeçar de um ponto base. Muitas vezes, se tenta fazer alguma alteração no código mas o resultado não se comporta como esperado, ou pior ainda, há um erro em uma alteração já feita e você só descobre algumas versões depois. Se todas as alterações de código estiverem em commits diferentes, podemos visualizá-las e escolher uma à qual retroceder.
Como não queremos jogar fora todo o trabalho realizado depois que retrocedemos, é importante fazer commits com certa frequência. Não seria muito útil fazer commit a cada linha que escrevemos, então podemos registrar a alteração sempre que tivermos realizado alguma mudança pequena, mas significativa. Por exemplo, ao escrevermos uma função, ao corrigirmos um bug, reformatarmos os documentos, etc.
Como desfazer alterações?
Desfazer uma alteração nada mais é do que voltar no tempo e recomeçar de um commit anterior. Para isso, precisamos inicialmente saber a qual commit queremos voltar. Para descobrir esse commit, podemos usar o comando git log
no repositório desejado. Ao executar esse comando, você verá uma listagem semelhante a esta:
user@host:~/ra123456/tarefa00$ git log boanoite.py
commit a192d2ff5b5aa744fd8250704d778ba1e405c970 (HEAD -> main, origin/main, origin/HEAD)
Author: Matheus Otávio Rodrigues <ra222318@students.ic.unicamp.br>
Date: Fri Mar 12 14:53:59 2021 -0300
corrige identação boanoite.py
commit fe71f5d7312a2756a9353b996ccfecc9479f7ac1
Author: Matheus Otávio Rodrigues <ra222318@students.ic.unicamp.br>
Date: Fri Mar 12 14:51:35 2021 -0300
atualiza boanoite com o código disponibilizado na tarefa
...
Analisando o primeiro commit, vemos que ele possui uma identificação, a192d2ff5b5aa744fd8250704d778ba1e405c970
,
um autor, uma data e uma mensagem de commit logo abaixo. Digamos que o commit corrige identação boanoite.py introduziu um erro no arquivo boanoite.py
. Assim, é preciso descobrir como esse arquivo estava antes da introdução do erro. Para isso, basta descobrir a identificação do último commit antes do erro (neste caso fe71f5d7312a2756a9353b996ccfecc9479f7ac1
). Basta anotar os 6 primeiros caracteres. Com a identificação do commit em mãos, podemos olhar para o arquivo como estava naquele momento:
user@host:~/ra123456/tarefa00$ git show fe71f5:tarefa00/boanoite.py
n = int(input())
for _ in range(n):
nome = input()
print(f"Boa noite, {nome}.")
Pronto, agora você pode inspecionar a versão anterior e copiar as partes que tem interesse. Repare que você deve digitar a identificação da revisão, dois pontos e o caminho completo do arquivo.
Também é possível ver a árvore de commits feitos e analisar os arquivos rodando o comando gitk
dentro da pasta do repositório. Se você usa WSL, pode ser necessário instalar o git para Windows e rodar gitk
a partir de um console cmd
. Ao abrir o gitk
, uma nova janela se abrirá com uma lista de commits no canto superior esquerdo, um campo SHA1 ID (identificação do commit, copie a identificação de interesse) e mais abaixo as alterações em cada commit, onde linhas vermelhas são as linhas removidas e linhas verdes são as linhas que foram adicionadas.
Muito provavelmente, será mais conveniente utilizar o git diretamente integrado no seu editor de texto. Se estiver usando o VS Code, abra o arquivo e clique na visão TIMELINE
. Você verá uma lista de mudanças registradas no seu arquivo aberto atualmente. Clicando em um item, será aberta uma comparação entre as versões do arquivo.
Ressuscitando arquivos
Algumas vezes, tudo dá errado e precisamos recomeçar de um certo ponto. Podemos
retornar a um commit anterior executando git reset --hard <id_commit>
em que <id_commit> é a identificação do commit desejado. Se tudo der certo, você receberá uma confirmação do tipo
HEAD is now at fe71f5d atualiza boanoite com o código disponibilizado na tarefa
.
Tome MUITO CUIDADO ao executar esse comando, a opção --hard
está nos alertando que todas
as alterações não registradas no diretório atualmente serão perdidas. Assim, só execute isso quando já tiver feito commit em todas as alterações de interesse.
Comparando arquivos
Outro comando útil é o git diff
, ele apresentará as alterações existentes entre os arquivos locais e os arquivos de um commit (por padrão o mais recente). Executando esse comando, teremos algo parecido com:
user@host:~/ra123456/tarefa00$ git diff
diff --git a/tarefa00/boanoite.py b/tarefa00/boanoite.py
index b26fb76..b8906e4 100644
--- a/tarefa00/boanoite.py
+++ b/tarefa00/boanoite.py
@@ -11,4 +11,5 @@ n = int(input())
for _ in range(n):
nome = input()
- print(f"Boa noite, {nome}.")
+ print(f"Git diff, {nome}.")
+ print("teste")
Em que as linhas iniciadas com -
(vermelhas) são linhas removidas e +
(verdes) são linhas adicionadas Também podemos comparar com um commit em específico, basta rodar git diff <id_commit>
em que <id_commit> é o id do commit desejado. Para sair da tela aberta para visualização, aperte ESC, depois digite q
.