Apostila_de_Git

Prévia do material em texto

Apostila de Git
Site: Moodle USP: e-Disciplinas
Curso: PMR3304 - Sistemas de Informação (2021)
Livro: Apostila de Git
Impresso por: Max Augusto Gomes Moreira
Data: segunda, 28 nov 2022, 00:50
https://edisciplinas.usp.br/
Descrição
Índice
1. Prefácio: familiarizando com a linha de comando
2. Instalação do Git
3. Familiarizando com o Git: comandos básicos
4. Trabalhando com Branches
5. Repositórios remotos: trabalhando em grupo
6. Considerações finais
1. Prefácio: familiarizando com a linha de comando
Nesta aula, utilizaremos bastante a linha de comando através de um terminal, que é uma ferramenta essencial para o programador. Cada sistema
operacional (Windows, macOS ou Linux) possui sua própria versão de terminal; aqui vamos abordar apenas os comandos mais básicos, que são comuns
a todas estas implementações.
1.1 Instalação do terminal
No caso dos sistemas baseados em Unix (macOS e Linux inclusos), um terminal, que executa o bash, já vem instalado; então não precisamos instalar
nada.
Já no Windows 10, apesar da instalação padrão incluir dois terminais: um que usa o cmd (prompt) e o Powershell, é altamente recomendado instalar a
versão 7 do Powershell e o Windows Terminal. Para tal, siga os seguintes passos:
1. baixe o instalador do Powershell 7 pode ser baixado de https://github.com/PowerShell/PowerShell - de preferência a versão "stable" para
"Windows (x64)". Uma vez feito o download, execute e siga os passos indicados; e
2. abra a Microsoft Store e procure por Windows Terminal; depois, clique em instalar.
ℹ Caso não consiga instalar o Windows Terminal pela loja da Microsoft, você pode baixar o instalador em
https://github.com/microsoft/terminal/releases
Para checar se sua instalação está correta, abra o Windows Terminal; deve aparecer a versão do Powershell, que deve ser algo do tipo 7.x.x, como
mostrado na Fig.:
1.2 Hello World na linha de comando: echo
Com o terminal aberto, vamos utilizar o comando echo para imprimir a mensagem "Hello World". Para tal execute:
$ echo "Hello World" 
Hello World
ℹ Nesta apostila, é adicionado o caractere "$" na listagem de comandos a serem executados no terminal. Isso ajuda a diferenciar da saída do
comando/programa, que é listada sem nenhuma modificação. Caso deseje copiar e colar a listagem, não se esqueça de remover o(s) caractere(s)
"$". No entanto, é recomendável escrever por extenso todas as instruções.
1.3 Navegando nos diretórios: pwd
Como você já deve saber, o sistema operacional organiza os arquivos em diretórios. No terminal, você sempre "está" em algum diretório; e os seus
comandos/programas são executados a partir do diretório atual. Em geral o terminal mostra o diretório atual; por exemplo, no Powershell no Windows
podemos ter:
PS C:\Users\fulano>
indicando que o diretório corrente é C:\Users\fulano .
Já no Ubuntu Linux, pode ser exibido:
https://github.com/PowerShell/PowerShell
https://github.com/microsoft/terminal/releases
https://edisciplinas.usp.br/pluginfile.php/6531979/mod_book/chapter/24651/powershell7.png
fulano@fulano:/temp/tutorial
indicando que o diretório corrente é /temp/tutorial . Note que as barras são invertidas nos diretórios do Windows. No entanto, é possível utilizar as
barras invertidas / também no Windows e, por isso, adotaremos esse padrão nessa aula.
Também é possível descobrir isso usando o comando pwd :
$ pwd 
Path 
---- 
C:\Users\fulano
1.4 Mudando de diretório: cd
Para mudar de diretório, podemos utilizar o comando cd nome_do_diretório . Por exemplo, poderíamos executar:
$ cd Documents 
$ pwd 
Path 
---- 
C:\Users\fulano\Documents
⚠ no Windows, os nomes de arquivos e pastas NÃO são case-sensitive, i.e., não diferenciam entre letras maiúscula e minúscula. No entanto, o
Linux e macOS fazem a distinção entre maiúscula e minúscula. Portanto, é mais seguro sempre escrever com o case correto.
Vamos usar esse comando para navegar para a pasta de usuário, que possui uma abreviação padrão, "~" (til):
$ cd ~
ℹ A pasta de usuário, e suas subpastas, são os locais perfeitos para executar os passos dessa apostila, pois geralmente não possuem proteções
mais restritas pelo sistema operacional.
Para navegar para uma pasta de nível acima, utilize o comando cd .. . Vamos testar, execute:
$ cd .. 
$ pwd 
Path 
---- 
C:\Users
1.5 Listando arquivos de um diretório: ls
Para listar todos os arquivos e pastas no diretório atual, faça:
$ ls 
 Directory: C:\Users 
Mode LastWriteTime Length Name 
---- ------------- ------ ---- 
d---- 02/07/2021 09:13 fulano 
d---- 02/07/2021 01:13 beltrano 
d---- 06/07/2021 11:28 ciclano 
d-r-- 02/07/2021 01:03 Public
Você pode usar o caractere curinga para filtrar a busca:
$ ls *ano 
 Directory: C:\Users 
Mode LastWriteTime Length Name 
---- ------------- ------ ---- 
d---- 02/07/2021 09:13 fulano 
d---- 02/07/2021 01:13 beltrano 
d---- 06/07/2021 11:28 ciclano
Também é possível filtrar os arquivos por extensão utilizando essa mesma técnica:
$ cd fulano/Downloads 
$ ls *.txt 
 Directory: C:\Users\fulano\Downloads 
Mode LastWriteTime Length Name 
---- ------------- ------ ---- 
-a--- 26/06/2021 09:28 999584 minhas_senhas_secretas.txt 
-a--- 26/06/2021 17:56 432402 minhas_senhas_nao_secretas.txt
ℹ No terminal, quando você deseja entrar com caminhos para pastas ou arquivos, não precisa digitar manualmente o caminho completo! Escreva
apenas parte do caminho e pressione TAB para auto-completar.
1.6 Criando um novo diretório: mkdir
Vamos criar um novo diretório para usar no restante da apostila. Para tal, vamos navegar para a pasta de usuário e criar o diretório novorepo :
$ cd ~ 
$ mkdir novorepo
Pronto, o diretório está criado! Antes de prosseguir, vamos navegar este novo diretório:
$ cd novorepo 
$ pwd 
Path 
---- 
C:\Users\fulano\novorepo
1.7 Redirecionando e anexando: > e >>
A saída padrão dos comandos e programas é a própria tela do terminal, i.e., a mensagem gerada por comandos é exibida diretamente no terminal. É
possível mudar essa saída, de modo a redirecionar para um arquivo, com o operador > . Assim, podemos criar e modificar arquivos, sem o uso de um
editor de texto. Utilizaremos bastante este recurso nessa apostila.
Vamos criar um novo arquivo hello.txt , contendo a linha "Hello World"; para tal, execute:
$ echo "Hello World" > hello.txt
e confira o conteúdo do arquivo hello.txt em um editor de texto.
ℹ Ao invés de utilizar um editor de texto, você pode executar cat hello.txt para exibir o conteúdo do arquivo de texto diretamente no
terminal.
Se você repetir o comando anterior, o conteúdo de hello.txt será substituído. Caso você utilize o operador >> , a saída será anexada ao arquivo.
Vamos testar, digite o seguinte comando no terminal:
$ echo "Hello World again" >> hello.txt
e abra o arquivo em um editor de texto para confirmar que agora temos duas linhas.
1.8 Manipulando arquivos: mv, cp e rm
Para renomear um arquivo, podemos utilizar o comando mv , que é abreviação para move:
$ mv hello.txt hello_hello.txt 
$ ls 
 Directory: C:\Users\fulano\novorepo 
Mode LastWriteTime Length Name 
---- ------------- ------ ---- 
-a--- 06/07/2021 13:30 32 hello_hello.txt
Como você pode imaginar, mv também pode ser utilizado para mover um arquivo. Para tal, basta fornecer uma pasta de destino diferente da origem.
Vamos demonstrar isso com os seguintes comandos:
$ mkdir novo_dir 
$ mv hello_hello.txt novo_dir/hello_hello.txt 
$ ls novo_dir/ 
 Directory: C:\Users\fulano\novorepo\novo_dir 
Mode LastWriteTime Length Name 
----------------- ------ ---- 
-a--- 06/07/2021 13:30 32 hello_hello.txt 
$ ls 
 Directory: C:\Users\fulano\novorepo 
Mode LastWriteTime Length Name 
---- ------------- ------ ---- 
d---- 06/07/2021 13:35 novo_dir
Use o comando cp (abreviação de copy) para realizar a cópia do arquivo; ele funciona igual ao mv , porém mantém o arquivo original. Vamos copiar de
volta o arquivo hello_hello.txt para a pasta ~/novorepo/ :
$ cp novo_dir/hello_hello.txt hello.txt 
$ ls 
 Directory: C:\Users\fulano\novorepo 
Mode LastWriteTime Length Name 
---- ------------- ------ ---- 
d---- 06/07/2021 13:35 novo_dir 
-a--- 06/07/2021 13:30 32 hello.txt
Por fim, para remover um arquivo, podemos utilizar o comando rm (abreviação de remove). Por exemplo, para apagar o arquivo hello.txt , digite:
$ rm hello.txt 
$ ls 
 Directory: C:\Users\fulano\novorepo 
Mode LastWriteTime Length Name 
---- ------------- ------ ---- 
d---- 06/07/2021 13:35 novo_dir
1.9 Atalhos de teclado importantes
Uma das vantagens de operar programas com a linha de comando é que isso pode ser altamente produtivo. Porém, para obter um ganho significativo
de eficiência, é necessário aprender alguns "truques": os atalhos de teclado. Teste os seguintes atalhos:
1. Movendo o cursor: mantenha CTRL pressionado enquanto move o cursor com as setas → e ← para pular diretamente para a próxima
palavra.
2. Navegando pelo histórico: utilize as setas ↑ e ↓ para navegar pelo histórico de comandos.
3. Busca no histórico: ao invés de navegar pelos itens um a um, utilize CTRL + r para fazer a busca por uma palavra. Pressione CTRL + r
novamente para ir para o próximo resultado.
4. Auto-completar caminhos para arquivo/diretório: quando deseja inserir o nome de um arquivo e diretório, digite apenas as primeiras letras
e pressione TAB para auto-completar. Pressione TAB novamente para ver o próximo candidato.
2. Instalação do Git
Para o acompanhamento desta aula, o único software realmente necessário é o Git, um software gratuito e de código aberto. Na página https://git-
scm.com/downloads é possível encontrar as instruções completas para a instalação dos sistemas operacionais macOS, Linux e Windows. Nesta aula,
iremos brevemente descrever os métodos mais rápidos e diretos para obter as versões do Git para cada um dos sistemas operacionais suportados.
2.1 macOS
Para instalar o Git no macOS, você deve ter o gerenciador de pacotes Homebrew instalado. Abra o terminal e digite:
$ brew install git
2.2 Linux
Para instalar o Git em uma distribuição Linux baseada em Debian, como o ubuntu, abra o terminal e digite:
$ sudo apt install git-all
Caso você possua uma distribuição Fedora ou similar, abra o terminal e digite:
$ sudo dnf install git-all
2.3 Windows
Opcionalmente, antes de instalar o Git no Windows, é recomendada a instalação do Notepad++, que pode ser configurado como o editor de textos
padrão do Git. O editor padrão é o Vim, que não é muito amigável para usuários iniciantes. Se deseja utilizar o Notepad++, é possível baixá-lo em
https://notepad-plus-plus.org/.
Para instalar o Git no Windows, sugerimos a instalação do Git for Windows, que é uma coleção de ferramentas e pode ser baixada em
https://gitforwindows.org/. Esta distribuição é a mesma disponível para download no site oficial do Git.
Durante a instalação, as configurações padrões podem ser mantidas, com exceção da escolha do editor de texto, que pode ser modificado para o
Notepad++, como mostra a tela a seguir
Instalação com o Chocolatey
O Chocolatey é um gerenciador de pacotes para o Windows, que possibilita uma maior automatização na instalação de softwares. É uma espécie de
apt-get para Windows. Os pacotes são administrados pela comunidade Chocolatey, que podem ser consultados em https://chocolatey.org/packages.
Nesta disciplina serão instalados uma diversidade de softwares, cujas instalações serão facilitadas pelo uso do Chocolatey. Para instalar o Chocolatey,
basta abrir o Powershell como administrador e digitar:
https://git-scm.com/downloads
https://brew.sh/
https://notepad-plus-plus.org/
https://gitforwindows.org/
https://git-scm.com/
https://edisciplinas.usp.br/pluginfile.php/6531979/mod_book/chapter/24653/gitwindowseditor.png
https://chocolatey.org/packages
$ Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = 
[System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object 
System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))
Em seguida, para instalar o Git e o Notepad++ de uma vez só, digite:
$ choco install notepadplusplus git.install
2.4 Verificando a instalação do Git
Nesta aula, aprenderemos a utilizar o Git via linha de comando, o que não é necessariamente o modo mais simples e talvez não seja o que você utilizará
futuramente. No entanto, o domínio da utilização via linha de comando facilita a adaptação para qualquer outra interface Git. Além disso, só através da
linha de comando é possível executar todos os comandos do Git.
Sendo assim, se você está no Linux ou macOS, abra o terminal. No caso do Windows, se você seguiu a instalação do Git for Windows de modo padrão,
abra o Git bash.
Depois, independentemente do seu sistema operacional, digite o seguinte comando:
$ git --version
Se a instalação foi feita corretamente, o Git retornará a versão instalada, com uma mensagem do tipo:
git version 2.27.0.windows.1
2.5 Configurações iniciais
É recomendado configurar a identidade do usuário como primeira ação do Git. Este será o seu carimbo toda vez que você submeter uma mudança de
versão, entre outras ações. Assim, ainda no terminal ou Git Bash, execute os seguintes comandos:
$ git config --global user.name "Fulano Detal" 
$ git config --global user.email fulanodetal@exemplo.br
substituindo o nome e o email com os valores corretos, obviamente.
Mesmo que você esqueça de realizar esta configuração inicial, ainda é possível modificá-la posteriormente.
2.6 Primeira utilização do Git
O comando executado anteriormente apenas exibe a versão do Git instalada. Vamos partir para algo mais interessante: criar nosso primeiro repositório!
Mas antes, precisamos entender alguns poucos conceitos. O Git realiza o controle de versão a partir do armazenamento de uma série de fotografias,
que correspondem a versões do código do programa e contêm a estrutura de arquivos no instante no qual a "foto" foi tirada. Este processo é mostrado
de forma simplificada na figura abaixo, na qual cada coluna é uma "fotografia".
Em linguajar Git, a fotografia é chamada de commit. O conjunto de commits, junto com outras informações, é armazenado no que chamamos de
repositório, que funciona mais ou menos como um banco de dados.
Para o nosso primeiro repositório, vamos primeiro criar uma pasta e navegar até ela com os comandos
https://edisciplinas.usp.br/pluginfile.php/6531979/mod_book/chapter/24653/snapshots.png
$ mkdir novorepo 
$ cd novorepo
Uma vez na pasta, basta executar o seguinte comando para inicializar nosso repositório Git:
$ git init
Quando um repositório é criado, o diretório .git é criado (no Windows é necessário habilitar a visualização de pastas ocultas para visualizá-lo). Este
contém os arquivos do repositório, que não devem ser manipulados manualmente e, portanto, podemos ignorá-los.
3. Familiarizando com o Git: comandos básicos
Antes de introduzir alguns dos principais comandos para realizar o controle de versão através do Git, é necessário familiarizar-se com um conceito
importante: os três estados. Uma boa compreensão desse sistema irá fazer uma boa diferença para o entendimento desta aula.
3.1 Os três estados
Os arquivos do seu repositório podem estar em três estados: consolidado(committed), modificado (modified) e preparado (staged), que podem ser
descritos como:
committed: os arquivos que estão no estado committed já estão armazenados de forma segura no seu banco de dados local (repositório local);
modified: um arquivo modificado sofreu alterações em relação ao que está armazenado no banco de dados, e ainda não foi transferido para a
área de preparo (que altera o seu estado para staged);
staged: arquivos no estado preparado estão marcados para fazer parte do próximo commit.
De acordo com o estado de cada arquivo, podemos então definir três áreas principais: o diretório .git (ou repositório), o diretório de trabalho e área
de preparo (ou índice). O repositório contém o banco de dados; o diretório de trabalho contém uma cópia de uma versão do projeto, isto é, são os
arquivos e diretórios que você edita diretamente. Por fim, a área de preparo armazena informações que farão parte do próximo commit.
Dessa forma, um ciclo básico de utilização do Git é o seguinte:
1. você modifica os arquivos do seu diretório;
2. você adiciona os arquivos modificados para a área de preparo (mudando o seu estado para staged);
3. você faz o commit, armazenando permanentemente a imagem que estava na área de preparo.
A imagem abaixo resume bem o sistema de três estados e o este fluxo de trabalho:
Não se preocupe em entender totalmente os conceitos dos três estados agora pois, estes serão reforçados à medida que aprendemos os comandos.
Além disso, voltaremos a discutir cada um dos estados ao longo da aula. Mas tente sempre ter em mente a ideia geral das áreas e do fluxo de trabalho
padrão.
Neste capítulo serão introduzidos diversos comandos de Git. Os mais importantes têm uma seção própria, mas dentro de cada seção também são
introduzidos novos comandos. O comando git init é um exemplo, já que ele já foi discutido anteriormente e não existe outra seção exclusiva para
ele.
3.2 Adicionando arquivo na área de preparo: git add
Primeiramente, vamos criar o primeiro arquivo do nosso projeto. No bash, digite o seguinte comando:
$ echo 'Meu Projeto' > README
para criar um arquivo README.
Para adicionar este arquivo na área de preparo, que contém os arquivos que entrarão no próximo commit, digite o comando:
https://edisciplinas.usp.br/pluginfile.php/6531979/mod_book/chapter/24654/areas.png
$ git add README
Este comando também é utilizado para adicionar arquivos que já existiam, mas que foram modificados em relação ao último commit, como veremos
mais adiante.
ℹ Por conveniência, durante a aula utilizaremos o comando echo para criar e alterar arquivos de texto. Este comando bash apenas repete o seu
argumento na saída padrão. O operador > serve para redirecionar a saída padrão para um arquivo. O operador >> faz o mesmo, mas, em vez de
sobrescrever o arquivo, adiciona o conteúdo no final deste. Se preferir, você pode manipular os arquivos em um editor de texto/IDE de sua
preferência, o que seria mais usual no dia a dia.
3.3 Verificando o estado do diretório de trabalho: git status
Este é um comando bastante comum quando o Git é utilizado pela linha de comando. Digite o seguinte no terminal:
$ git status
A saída deve ser a seguinte:
On branch master 
 No commits yet 
 Changes to be committed: 
 (use "git rm --cached <file>..." to unstage) 
 new file: README 
Como ainda não introduzimos o conceito de branch, vamos ignorar a primeira linha. A segunda linha diz que não existem commits ainda. Em seguida
aparecem as informações da área de preparo (que fará parte do próximo commit). Podemos verificar que temos um arquivo novo a ser incluído no
repositório.
O que aconteceria se tivéssemos rodado o comando git status antes de adicionar o arquivo? Podemos descobrir isso removendo o arquivo README ;
para tal, é só executar o comando descrito na mensagem do git status :
$ git rm --cached README
Rodando novamente o comando git status , temos:
On branch master 
No commits yet 
Untracked files: 
(use "git add <file>..." to include in what will be committed) 
README 
nothing added to commit but untracked files present (use "git add" to track)
Agora o arquivo README está marcado como não rastreado, isto é, não está nem no último commit nem na área de preparo.
3.4 Criando seu primeiro commit: git commit -m
Lembre-se de re-adicionar o arquivo README na área de preparo com o comando>
$ git add README
Agora você pode realizar o commit das sua modificações com o seguinte comando:
$ git commit -m "Primeiro commit"
onde o trecho entre parênteses é a mensagem que é associada ao commit.
A saída deste comando deve ser algo to tipo
[master (root-commit) 5e40666] Primeiro commit 
1 file changed, 1 insertion(+) 
create mode 100644 README
onde são mostradas algumas estatísticas do seu commit, como o número de arquivos que foram alterados.
Além disso, o Git atribui um hash SHA-1 para cada commit. Este valor é importante pois identifica este commit em outros comandos. No caso do
exemplo, uma abreviação do hash está sendo mostrada na primeira linha: o valor 5e40666 .
É sempre bom lembrar que, ao dar o comando commit, apenas as modificações contidas na área de preparo são incluídas no commit. Se você realizou
outras alterações no diretório de trabalho que não estavam na área de preparo, estas não serão incluídas no repositório. Por este motivo, é sempre
prudente executar o comando git status antes de realizar um commit.
Mensagem do commit: o que/como/por que escrever?
A mensagem do commit é bastante importante para facilitar a navegação do histórico de desenvolvimento do projeto. Imagine que você deseja
recuperar a versão do arquivo antes de uma mudança específica. Caso você encontre um commit com uma mensagem do tipo "Mudança específica
aplicada aqui", você já sabe que este é a versão que procura.
Existem os padrões de forma curta e comprida da mensagem do commit. Em qualquer uma das versões, é recomendado que a mensagem seja escrita
no imperativo. Ou seja, ao invés de "Mudou o nome da variável", devemos escrever "Mudar o nome da variável". Na forma curta ou no título do
formato longo, a mensagem deve ser clara e expressar a mudança principal. Caso deseje prolongar-se, pule a linha e escreva uma descrição mais
detalhada.
3.5 Vendo o histórico de commits: git log
Na maior parte das vezes é mais conveniente consultar o histórico do repositório através de uma interface gráfica (possivelmente uma interface web,
como veremos mais adiante no GitHub). No entanto, para consultas rápidas, é possível listar o histórico de commit com o comando:
$ git log
O comando deve responder com a seguinte mensagem:
commit 5e40666543ab1ddabc5edd672f12c8bd70f18c1b (HEAD -> master) 
Author: Fulano Detal <fulanodetal@exemplo.br> 
Date: Mon Jun 22 15:47:58 2020 -0300 
 Primeiro commit 
Como mencionado anteriormente, o commit é identificado pelo seu hash, aqui exibido em sua totalidade. As configurações iniciais de usuário e e-mail
também são inseridas no commit, como é possível ver na segunda linha. Ao final, são listadas a data e a mensagem do commit.
ℹ O comando git log possui muitas configurações para controlar o modo ou qual parte do histórico é exibida. Uma das opções mais úteis é
um commit por linha com o comando git log --pretty=oneline }. Para outras opções, consultar a documentação do Git. De qualquer modo,
muitas vezes é mais conveniente utilizar uma interface gráfica para realizar uma consulta mais específica do histórico.
3.6 Visualizando as mudanças (para arquivos modificados ou preparados): git diff e git diff --
cached
Outro comando bastante útil serve para visualizar as mudanças em relação ao repositório. Para ilustrar a sua funcionalidade, faremos algumas
alterações no nosso diretório de trabalho. Primeiro, vamos adicionar uma linha no arquivo README com o comando bash:
$ echo "Segunda linha" >> README
Depois, criaremos nosso primeiro arquivo de código, digitando:
$ echo "print('Hello World')" > Hello.py
Verifique o estado com o comando git status paraconfirmar que os estados dos arquivos estão coerentes. Digite, então, o comando para verificar as
mudanças no diretório de trabalho:
$ git diff
que deve responder com a seguinte mensagem:
The file will have its original line endings in your working directory 
diff --git a/README b/README 
index 7d9fc53..7b3e891 100644 
--- a/README 
+++ b/README 
@@ -1 +1,2 @@ 
Meu Projeto 
+Segunda linha
mostrando o que foi modificado nos arquivos rastreados. É importante notar que os arquivos não rastreados ( Hello.py ) não aparecem na lista de
mudanças.
Vamos então começar a preparar o nosso segundo commit. Para tal, vamos adicionar os dois arquivos para a área de preparo, utilizando o comando
git add . Vale ressaltar, que este comando serve tanto para arquivos não rastreados quanto para arquivos rastreados modificados. Assim, digite no
bash:
$ git add README Hello.py
Confira com o comando git status se os arquivos foram movidos para a área de preparo (ou índice).
Pronto, já podemos realizar o nosso commit! No entanto, imagine que você decidiu realizar uma nova mudança antes de realizar este commit. Para
simular esta situação, adicione uma linha no README:
$ echo "Terceira linha" >> README
Utilize o comando git status para verificar como ficou registrada essa modificação. A saída deve mostrar que o arquivo README possui modificações
tanto na área de preparo quanto no diretório de trabalho. Verifique que o comando git diff mostra apenas as modificações que não estão na área de
preparo. Para verificar as mudanças já preparadas, utilize o comando:
$ git diff --cached
cuja saída deve ser:
diff --git a/Hello.py b/Hello.py 
new file mode 100644 
index 0000000..df1dc68 
--- /dev/null 
+++ b/Hello.py 
@@ -0,0 +1 @@ 
+print('Hello World') 
diff --git a/README b/README 
index 7d9fc53..7b3e891 100644 
--- a/README 
+++ b/README 
@@ -1 +1,2 @@ 
Meu Projeto 
+Segunda linha
Por fim, vamos adicionar esta modificação para a área de preparo e realizar nosso segundo commit:
$ git add README 
$ git commit -m "Inserir arquivo do programa principal"
Verifique o histórico ( git log ) para confirmar que o commit foi processado corretamente.
3.7 Fluxo de trabalho atualizado para o Git
Com os comandos introduzidos até aqui podemos estabelecer um fluxo de trabalho mais detalhado para cada commit, que segue:
1. você modifica e cria arquivos no seu diretório de trabalho;
2. você verifica se as mudanças estão coerentes com o comando git diff ;
3. você adiciona mudanças e rastreia novos arquivos na área de preparo com o comando git add ;
4. (opcional) caso você tenha esquecido ou deseje realizar uma outra mudança para este commit, faça agora e adicione as mudanças com o
comando git add ;
5. (opcional) você pode conferir a área de preparo antes do commit com o comando git diff --cached ;
6. é também aconselhável que você confira o estado da área de preparo com o comando git status ;
7. finalmente, pode fazer o commit com o comando git commit -m , lembrando de colocar uma mensagem que descreva bem o commit.
Sendo assim, os comandos geralmente seguem a sequência:
git diff ➡ git add ➡ git status ➡ git commit -m .
Mesmo quando for utilizar uma interface gráfica, fique atento a este fluxo: verificar o diff, mover arquivos para a área de preparo, conferir estado da
área de preparo e só então realizar o commit, sempre dando a devida atenção a sua mensagem.
Como estruturar o seu commit
Só um último adendo, o ideal é que cada commit configure uma mudança completa com uma certa lógica.
Por exemplo, se o commit possui a mensagem "Implementar função foo", esta função deve estar completamente implementada no código, e este deve
compilar e/ou executar sem erros.
Isto também significa que não é desejável que várias modificações sejam incluídas no mesmo commit, como, por exemplo "Implementar função foo e
modificar o parâmetro bar". Neste último caso, o ideal seria separar em dois commits.
Assim, o comando git diff (passo 2 do fluxo de trabalho) e o git diff --cached (passo 5) ajudam identificar melhor o que devemos colocar em
cada commit.
ℹ Algumas vezes é difícil separar um commit em vários, uma vez que as modificações podem estar em um mesmo arquivo. Neste caso, é possível
mover apenas trechos do código modificado para a área de preparo utilizando o comando git add -–patch ou git add --interactive . Consulte
a documentação do Git para mais detalhes.
3.8 Movendo e removendo arquivos: git rm e git mv
Com o nosso fluxo de trabalho em mente, vamos adicionar mais algumas ferramentas para auxiliar o trabalho com controle de versão. Vamos supor que
desejamos remover o arquivo README; para isso, realizamos o comando:
$ git rm README
Verifique que a primeira alteração visível é a deleção do arquivo do seu diretório de trabalho. Agora, utilize o comando git status para conferir que a
remoção do arquivo já está na área de preparo e, então será consolidada no próximo commit. Caso esteja tudo correto, vamos realizar o commit:
$ git commit -m "Remover arquivo README"
ℹ O comando git rm também pode ser realizado após a deleção do arquivo. Neste caso, como o arquivo já tinha sido apagado, é realizada
apenas a inclusão da modificação para a área de preparo.
Vamos considerar renomear o arquivo Hello.py para main.py . Este pode ser realizar com o comando:
$ git mv Hello.py main.py
Se o segundo parâmetro deste comando for um diretório ao invés de um nome de arquivo, ele moverá o arquivo para esta pasta. Vamos mostrar isso
criando um novo diretório e movendo o main.py para ele, com os seguintes comandos:
$ mkdir src 
$ git mv main.py src
Podemos, então, fazer o commit. Confirme as modificações com o comando git status e depois execute o comando:
$ git commit -m "Renomear e mover o arquivo de codigo principal"
ℹ Por que não posso apenas remover o arquivo ( git rm ), criar um novo e rastreá-lo ( git add ) ao invés de utilizar o comando git mv ? Como,
neste caso, o Git não conhece a origem do novo arquivo, você perde o histórico dele. Assim, você não consegue consultar diretamente as suas
versões anteriores. No entanto, o Git muita vezes é esperto o suficiente para perceber automaticamente que o arquivo foi movido/renomeado,
mesmo quando utilizado os comandos git rm e git add . Neste caso, é recomendável checar o estado ( git status ) para verificar qual operação
foi realizada.
3.9 Para ser utilizado com cautela: refazendo commit com git commit --amend
Idealmente, como você usa o comando git diff de modo recorrente, os seus commits estão sempre perfeitos. Mas, na prática, é possível que ocorra
algum erro neste processo. Em geral, estes podem ser de dois tipos: erro na mensagem ou erro nos arquivos.
A primeira pode ser corrigida com o comando:
$ git commit --amend -m "Renomear e mover Hello.py para src/main.py"
Verifique no histórico que a mensagem foi modificada ( git log ).
Caso deseje realizar alguma modificação nos arquivos do commit, primeiro realize as modificações e depois execute o comando. Por exemplo, vamos
modificar o arquivo main.py , digite no bash:
$ echo "print('Hello from main.py')" > src/main.py
Confira o estado e as diferenças ( git status e git diff ). Se estiver tudo OK, adicione para a área de preparo:
$ git add src/main.py
E realize a correção do commit com o comando:
$ git commit --amend --no-edit
Verifique com git log e git status que a operação foi bem sucedida.
⚠ Existem dois modos para corrigir um commit errado. O primeiro é criar um novo commit corrigindo o anterior ou reescrevendo este commit.
Caso este commit seja público (veremos isso mais adiante), sempre utilize a primeira opção. Ou seja, nunca utilize o git commit --amend com
commits que já estejam em um repositório remoto (depois do git push ).
3.10 Restaurando arquivos no seu diretório de trabalho: git checkout
Considere agora que você deseja refazer o arquivo README e executou o seguinte comando com este intuito:
$ echo "# Novo README" > src/main.py
Ops, o arquivo errado ( main.py ) foi modificado!Neste caso, antes de criar o arquivo README novo, deseja-se desfazer essa operação. Para fazer isso,
digite no bash:
$ git checkout src/main.py
Utilize o comando git status para confirmar que o arquivo foi restaurado. Agora sim podemos criar o README novo e fazer o commit:
$ echo "# Novo README" > README.md 
$ git add README.md 
$ git commit -m "Novo readme com marcacoes"
3.11 Ignorando arquivos
A última ferramenta que vamos introduzir é o arquivo .gitignore , que possibilita ignorar determinados tipos de arquivo no controle de versão. Muitas
vezes, a IDE (ambiente integrado de desenvolvimento) cria vários arquivos no diretório de trabalho que não desejamos rastrear. Também pode ocorrer
do nosso programa gerar arquivos de saída que não nos interessa versionar.
Vamos simular um arquivo de saída com o comando:
$ echo "saida simulada do main.py" > src/output.txt
Não temos interesse em colocar esse arquivo no repositório, mas toda vez que rodarmos o comando git status ele estará lá, ocupando o bash com
informação inútil. Mas temos uma solução: é só criar um arquivo de nome .gitgnore na raiz do nosso repositório com o comando:
$ echo "*.txt" > .gitignore
Agora execute o comando git status para verificar que o arquivo src/output.txt não aparece mais! Para efetivar esta mudança no repositório,
temos que criar um commit com os comandos:
$ git add .gitignore 
$ git commit -m "Adicionar arquivo .gitignore"
3.12 Adicionando tags a versões: git tag -a
Tags servem para marcar pontos na história do projeto que você considera importante. Por exemplo, você pode marcar um commit como sendo a
versão 1.0 do software, ou como uma versão que foi exibida em uma feira, ou lançada em versão beta, etc.
Vamos considerar que estamos satisfeitos com a versão atual do nosso programa e desejamos marcá-la com uma tag de versão 1.0. Criar uma tag é
relativamente simples: vamos fazer isso com o comando:
$ git tag -a v1.0 -m "Versao 1.0 do programa"
onde v1.0 é o nome da tag e a opção -m precede sua mensagem, como em um commit.
4. Trabalhando com Branches
A função de branch é uma das mais importantes para sistemas de controle de versão, tanto que a maioria deles implementa esta funcionalidade.
Basicamente, um branch permite que você divirja da linha principal do desenvolvimento sem modificar esta linha. No Git, o uso do branch é ainda mais
incentivado, uma vez que esta operação é extremamente rápida, diferentemente de outros controles de versão.
ℹ Para que servem os branches? Imagine que você deseja implementar uma nova funcionalidade complexa. Utilizando apenas os comandos que
aprendeu, você criaria diversos commits enquanto escreve o novo código. Se, por algum motivo, você desistir desta funcionalidade ou desejar
refazer a implementação com uma estratégia melhor, como procederia? Neste caso, você deveria criar um commit novo desfazendo as mudanças,
poluindo bastante o histórico. Uma situação ainda pior: e se, durante o desenvolvimento da nova funcionalidade você descobrir um bug no código
antigo? 
Uma melhor resposta para estas situações é criar um branch para implementar novas funcionalidades. Também pode ser utilizado quando se
deseja fazer uma grande mudança no código, que pode ficar instável por um tempo. Neste capítulo, vamos ver como operar com os branches no
Git.
4.1 Branch master e o ponteiro HEAD
Antes de começar a criar os branches, é necessário entender alguns conceitos.
O primeiro é o branch master, que é o branch padrão criado junto com o repositório. Você já deve ter reparado neste nome durante esta aula, como por
exemplo na saída do comando git status :
On branch master 
nothing to commit, working tree clean
E como o Git sabe em qual branch você está? Utilizando o ponteiro HEAD, que aponta para o branch atual. Este é um ponteiro para o último commit
que você fez ou que você recuperou. Nos próximos exercícios, ilustraremos sempre o estado do repositório com o ponteiro HEAD e as referências dos
branches. Deste modo, estes conceitos tendem a ficar mais palatáveis.
4.2 Criando um novo branch: git checkout -b
Antes de criar um branch, vamos rodar o comando git log --pretty=oneline :
9da0afb3df8... (HEAD -> master) Adicionar arquivo .gitignore 
529a424b122... Novo readme com marcacoes 
a2edfff2eee... Renomear e mover Hello.py para src/main.py 
bf48903ed0c... Remover arquivo README 
c12d9604fa8... Inserir arquivo do programa principal 
5e40666543a... Primeiro commit
Com essas informações, podemos representar o estado do repositório com a Figura abaixo:
... a2edf 529a4 9da0a
master
HEAD
Assim, temos atualmente o ponteiro HEAD e o branch master apontando para o último commit 9da0a . Para criar um novo branch testbranch, rode o
seguinte comando:
$ git checkout -b testbranch
Este comando cria um branch e já faz a mudança para este novo branch (confirme isso utilizando git status ). Deste modo, o novo estado pode ser
representado pela Figura:
https://edisciplinas.usp.br/pluginfile.php/6531979/mod_book/chapter/24657/branch-and-history.svg
Vamos fazer um novo commit; para isso, digite:
$ echo "print('Olha esta nova funcionalidade')" >> src/main.py 
$ git add src/main.py 
$ git commit -m "Testar uma nova funcionalidade"
Com este commit, nós avançamos no branch testbranch; assim, temos:
4.3 Trocando de branch: git checkout (de novo?)
Para voltar para o branch master, execute:
$ git checkout master
Verifique que o arquivo src/main.py foi revertido para a versão do commit anterior. Também confira o commit e o branch atuais com o comando git
status . Isto faz sentido se você observar a figura anterior, uma vez que o branch master aponta para este commit Ou seja, temos:
https://edisciplinas.usp.br/pluginfile.php/6531979/mod_book/chapter/24657/head-to-testing.gif
https://edisciplinas.usp.br/pluginfile.php/6531979/mod_book/chapter/24657/advance-testing.gif
Outra coisa que você pôde perceber com essas últimas operações é que a criação e troca de branches é extremamente rápida. Por este motivo, o uso
recorrente de branches geralmente faz parte de um fluxo de trabalho com Git.
ℹ Muitos dos comandos do Git podem ter funções aparentemente bastante distintas. Como vimos, o git checkout pode ser utilizado para
restaurar arquivos modificados do diretório de trabalho, criar um novo branch e agora temos que ele também pode ser utilizado para trocar de
branches. O mesmo ocorre com o comando git reset . Na realidade, existe uma lógica para isso, que é discutida no capítulo 7.7 do livro Pro Git.
4.4 Realizando seu primeiro merge: git merge
Para incorporar as modificações de um branch em outro, temos que realizar o processo de merge. No nosso repositório, para realizar o merge do branch
testbranch no master , primeiro verifique que você está no branch master com git status e depois, digite o comando:
$ git merge testbranch
A saída deve ser algo similar a
Updating 9da0afb..9cb7de7 
Fast-forward 
 src/main.py | 1 + 
 1 file changed, 1 insertion(+)
Dois pontos importantes a se notar. Para incorporar as mudanças de um branch A em um branch B faça: git checkout B ➡ git merge A . Isto pode
não parecer intuitivo, então é bom sempre tomar cuidado quando fizer um merge.
Segundo, a saída do comando exibe as mudanças realizadas, assim como num commit. A informação mais importante é que foi realizado um fast-
forward, isto é, apenas foi movida a referência do branch. Sendo assim, temos a seguinte nova estrutura
https://edisciplinas.usp.br/pluginfile.php/6531979/mod_book/chapter/24657/advance-testing-2.gif
https://git-scm.com/book/en/v2
Este tipo de merge ocorre porque o branch testbranch estava diretamente à frente do master . Este é o caso de merge mais simples, nas próximas
seções veremos outros casos.
4.5 Realizando merges básicos
Vamos realizar um procedimento similar ao anterior. Primeiro, vamos criar um novo branch para implementar uma nova funcionalidade:
$ git checkout -b multilanguage
Depois, vamos criar e adicionar novos arquivos para este branch e realizar um commit:$ echo "print('Hello World')" > src/main_en.py 
$ echo "print('Bonjour monde')" > src/main_fr.py 
$ echo "print('Hola mundo')" > src/main_es.py 
$ echo "print('Hallo welt')" > src/main_de.py 
$ git add src/*.py 
$ git commit -m "Ola mundo em multiplas linguas"
Agora, vamos mudar para o branch master , adequar o programa e depois fazer o commit:
$ git checkout master 
$ echo "print('Ola mundo')" > src/main.py 
$ git add src/main.py 
$ git commit -m "Ola mundo agora em portugues"
A figura abaixo mostra a situação atual do repositório:
... 529a4 9da0a 56061
master
HEAD
multilang...
063a1
Como na vez anterior, para realizar o merge, é só digitar:
https://edisciplinas.usp.br/pluginfile.php/6531979/mod_book/chapter/24657/basic-branching-5.gif
https://edisciplinas.usp.br/pluginfile.php/6531979/mod_book/chapter/24657/basic-branching-6.svg
$ git merge multilanguage
Agora o Git deve abrir uma instância do seu editor de texto para editar uma mensagem do commit de merge. Depois de editar e fechar o merge estará
pronto e o novo estado deve ser:
Como podemos observar, o Git fez um novo commit para implementar as mudanças. Isto foi feito automaticamente através de um merge de três vias:
comparando os dois branches mais o ancestral em comum (2+1). No nosso caso, o merge é feito com os commits 063a1 , 56061 e 9da0a .
Por fim, é habitual apagar os branches depois de um merge bem sucedido com o comando:
$ git branch -d multilanguage 
$ git branch -d testbranch
Merge com conflito: e agora?
Você já deve imaginar que este procedimento automático de merge pode dar problema alguma hora. Por exemplo, quando forem editados a mesma
parte de um código em dois branches diferentes. Vamos simular esta situação no nosso repositório e ver como o Git trata esta questão.
Crie um novo branch e modifique algum dos arquivos com os comandos
$ git checkout -b huxleyver 
$ echo "print('Ola admiravel mundo novo')" > src/main_en.py 
$ echo "print('Hello brave new world')" > src/main_en.py 
$ echo "print('Bonjour le meilleur des mondes')" > src/main_fr.py 
$ echo "print('Hola mundo feliz')" > src/main_es.py 
$ echo "print('Hallo schoene neue welt')" > src/main_de.py 
$ git add src/*.py 
$ git commit -m "Ola mundo mais poetico"
Durante o processo, você percebeu um pequeno erro no branch master e quer corrigi-lo. Então, você executa:
$ git checkout master 
$ echo "print('Hello world')" > src/main_en.py 
$ git add src/main_en.py 
$ git commit -m "Converter letras para minusculo (exceto a primeira)"
Até agora, o procedimento foi muito parecido com o da seção anterior. Mas, vamos verificar o que ocorre quando fazemos o merge como o comando:
$ git merge huxleyver
A saída segue:
https://edisciplinas.usp.br/pluginfile.php/6531979/mod_book/chapter/24657/basic-merging-2.gif
Auto-merging src/main_en.py 
CONFLICT (content): Merge conflict in src/main_en.py 
Automatic merge failed; fix conflicts and then commit the result.
O Git não foi capaz de realizar o merge, de acordo com a mensagem que ele exibe, e agora? A mensagem indica que houve um conflito no arquivo
main_en.py , então vamos editá-lo. Se você por acaso fechar o terminal e perder esta mensagem, você pode usar comando git status para ver o
arquivo que está em conflito. O arquivo main_en.py foi editado automaticamente pelo Git e agora seu conteúdo é:
<<<<<<< HEAD 
print('Hello world') 
======= 
print('Hello brave new world') 
>>>>>>> huxleyver
A parte superior é a versão que está no HEAD (branch master no nosso caso), enquanto a inferior é a versão do branch huxleyver . Você deve editá-lo
para ficar da maneira que achar adequado, no nosso caso vamos manter a versão do branch huxleyver , que pode ser realizado com o comando
$ echo "print('Hello brave new world')" > src/main_en.py
Finalmente, devemos criar nosso commit de merge manualmente daqui em diante. Veja com git status que já existem arquivos na área de preparo,
só falta adicionar o arquivo que editamos a pouco. Por isso, o adicione na área de preparo e faça o commit com os comandos:
$ git add src/main_en.py 
$ git commit
O merge está pronto agora! Como a mensagem de commit de merge é gerada automaticamente, não utilizamos o comando -m . Nada impede que
você personalize essa mensagem, no entanto.
4.6 Fazendo stash: git stash
Às vezes acontece de, no meio de uma modificação em um branch de tópico, ser necessário modificar algo em outro branch. Se você não está pronto
ainda para realizar o commit, você só pode trocar de branch e descartar as mudanças!
Vamos demonstrar isso com uma mudança no branch huxley . Entre com os seguintes comandos:
$ git checkout huxleyver 
$ echo "print('Mudanca temporaria')" >> src/main.py
Neste instante, se você tentar trocar para o branch master com:
$ git checkout master
a seguinte mensagem de erro aparecerá:
error: Your local changes to the following files would be overwritten by checkout: 
 src/main.py 
Please commit your changes or stash them before you switch branches. 
Aborting
Se você não está pronto para realizar o seu commit, você pode salvar as suas modificações no stash com o comando:
$ git stash
Verifique que suas mudanças foram revertidas com git status e, por isso, agora você pode voltar para o branch master . Para recuperar as mudanças
no stash, você deve retornar ao branch huxley e digitar:
$ git stash pop
4.7 Fluxo de trabalho com branches
Agora que você já se familiarizou com o básico de branches, você deve estar se perguntando como utilizá-los. Uma das formas mais comuns é a adoção
de dois branches de longa duração, que estão sempre abertos: master e develop . O branch master deve conter apenas versões estáveis,
possivelmente apenas aquelas que foram lançadas publicamente. Já o branch develop é utilizado para testar a estabilidade do código e, uma vez que
se obtenha uma versão estável, é realizado o merge com o master . A partir do develop são criados os branches de tópico, que implementam novas
funcionalidades ou correções de bugs. Os exemplos desta seção podem ser considerados branches de tópicos, que podem ser criados à medida que se
julgue necessário. A figura abaixo apresenta este fluxo de trabalho.
https://edisciplinas.usp.br/pluginfile.php/6531979/mod_book/chapter/24657/lr-branches-2.png
5. Repositórios remotos: trabalhando em grupo
Com os comandos aprendidos até agora, você deve ser capaz de realizar a maior parte das tarefas do dia a dia com o Git, mesmo que apenas
demonstramos sua operação solitária! Isso é uma das vantagens do Git em relação a outros sistemas - como os repositórios são distribuídos,
praticamente todas as operações são locais.
De qualquer modo, se você estiver colaborando com uma equipe, alguma hora você deve operar com um servidor, acessível pelos outros membros. O
servidor Git contém uma cópia do repositório idêntica a que você tem na sua máquina (lembra do diretório .git ?).
Existem alguns modos de configurar e rodar um servidor Git, mas de longe a alternativa mais popular é utilizar um serviço de hospedagem terceirizada.
Isso porque é mais fácil e rápido, além de não requisitar manutenção. Nesta aula, utilizaremos o Gitlab USP, que está disponível para qualquer aluno
com email USP. O seu funcionamento é similar ao do Github, que é o maior hospedeiro de Git existente, e com qual você provavelmente já interagiu em
algum momento, mesmo sem nem saber para que servia.
5.1 Criando um repositório remoto no Gitlab USP
O primeiro passo para utilizar o Gitlab USP é logar em https://gitlab.uspdigital.usp.br/ com o seu email e senha única da USP. Na primeira vez que
realizar o login, é pedido para criar uma nova senha, que pode ser diferente da senha única da USP. Esta nova senha que deve ser utilizada no Git para
interagir com o repositório.
ℹ Você também pode inserir sua chave SSH para acessar os repositórios através do protocolo SSH ao invés de utilizar a senha recém-criada para
o HTTPS.
Uma vez que você realizou o login no Gitlab USP, você verá a opção de criar um repositório, clicando nobotão verde "New project", como mostrado na
figura:
Depois, preencha o nome do novo repositório que desejar, escolha visibilidade como público e clique em create project:
https://gitlab.uspdigital.usp.br/
https://edisciplinas.usp.br/pluginfile.php/6531979/mod_book/chapter/24658/gitlabusp-newrepo.png
O repositório remoto foi criado, mas inicialmente ele está vazio. Então, vamos enviar o nosso repositório local no qual estávamos trabalhando até agora.
Para isso, volte para o seu diretório de trabalho no bash e siga as instruções na página do seu repositório:
https://edisciplinas.usp.br/pluginfile.php/6531979/mod_book/chapter/24658/gitlabusp-createrepo.png
5.2 Obtendo um repositório: git clone
Provavelmente, ao invés de criar, você iniciará o seu trabalho a partir de um repositório já existente. Para fazer isso, você realiza a cópia do repositório
que está no Gitlab para a sua máquina pessoal; e já pode trabalhar do mesmo modo como foi feito até aqui nesta aula.
Então, para reproduzir esta situação, vamos clonar o repositório que você acabou de criar. Antes de baixar o repositório, você precisa obter o seu
endereço, que é mostrado na página do seu repositório no botão Clone, como mostrado na imagem:
https://edisciplinas.usp.br/pluginfile.php/6531979/mod_book/chapter/24658/gitlabusp-pushrepo.png
Na verdade, o nome sempre será https://gitlab.uspdigital.usp.br/fulanodetal/novorepo.git, então você pode pular esta etapa. Por fim, para clonar o
repositório, digite:
$ git clone https://gitlab.uspdigital.usp.br/fulanodetal/novorepo.git
substituindo usuário e repositório pelos nomes adequados.
Pronto, obtivemos o repositório e foi criada uma pasta com o mesmo nome. Dentro dela, você pode encontrar o seu diretório de trabalho e o
repositório na pasta " .git ". Se você executar o comando git status agora, você verá uma informação diferente:
Your branch is up to date with 'origin/master'.
O nome origin é o nome que ele usa para se referir ao repositório remoto (do Gitlab USP). Da mesma forma, origin/master é referência para o
branch remoto. O nome origin pode ser personalizado no comando git clone , mas isso não é muito usual de se fazer. O git status também
informa se o seu branch atual está em dia com o branch remoto, mas isso é referente a sua última sincronização.
ℹ HTTPS ou SSH? Para obter o endereço do repositório do Gitlab USP existem duas opções: HTTPS ou SSH. Você pode observar que utilizamos
HTTPS nesta aula, pois ela permite o acesso anônimo para realizar o clone. No caso do protocolo SSH, você precisará cadastrar a sua chave no seu
perfil.
5.3 Enviando alterações: git push
Em geral, você deve trabalhar no seu repositório local do mesmo modo que procedemos no capítulo anterior. Quando estiver pronto para compartilhar
seu código, geralmente após obter uma versão funcional com alguma alteração significativa, você deve enviar suas alterações para o repositório.
Para mostrar esta funcionalidade, vamos realizar uma modificação e criar um commit:
$ echo "print('Ola mundo, meu nome e Fulano')" > src/main.py 
$ git add src/main.py 
$ git commit -m "Adicionar apresentacao pessoal"
Veja com git status que o seu branch master está avançado em relação ao do repositório. Agora, vamos enviar essas mudanças com o comando:
https://edisciplinas.usp.br/pluginfile.php/6531979/mod_book/chapter/24658/gitlabusp-clonerepo.png
https://gitlab.uspdigital.usp.br/fulanodetal/novorepo.git
$ git push
Enviando um novo branch
Como foi dito anteriormente, é comum a criação de branches durante o desenvolvimento. Vamos criar um branch novo e fazer um commit:
$ git checkout -b novobranch 
$ echo "print('Ola mundo, meu novo nome e Fulano2')" > src/main.py 
$ git add src/main.py 
$ git commit -m "Novo nome muito criativo"
Se você tentar fazer o git push agora, o Git não conseguirá concluir a operação. Isso porque o seu branch é apenas local: nenhum branch remoto está
configurado para ele. Felizmente, a própria mensagem de erro oferece o comando a ser utilizado:
$ git push -u origin novobranch
5.4 Atualizando e mesclando: git pull
O comando git pull sincroniza as informações do repositório remoto com o local. Assim, ele obtém novos commits para o branch atual e realiza o
merge. Mas sobre que merge estamos falando?
Imagine que, ao fazer o envio com o comando git push na seção anterior, o Git detecta que alguém foi mais rápido e já tinha realizado um commit no
mesmo branch master .
Podemos simular este cenário utilizando um truque: primeiramente, desfaça o commit local com o comando git reset HEAD~1 , depois restaure as
mudanças com git checkout src/main.py . Agora, seu repositório local está no mesmo estado de quando foi clonado. Assim, realize outra alteração e
faça o commit:
$ echo "print('Hello world, my name is Fulano')" > src/main_en.py 
$ git add src/main_en.py 
$ git commit -m "Adicionar apresentacao pessoal em ingles"
Ao tentar enviar as modificações com:
$ git push
A operação não é bem sucedida e a seguinte mensagem deve aparecer:
 ! [rejected] master -> master(non-fast-forward) 
error: failed to push some refs to 'https://gitlab.uspdigital.usp.br/fulanodetal/novorepo.git' 
hint: Updates were rejected because the tip of yourcurrent branch is behind 
hint: its remote counterpart. Integrate the remotechanges (e.g. 
hint: 'git pull ...') before pushing again. 
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
Como diz a mensagem devemos atualizar nosso repositório antes, então digite:
$ git pull
O commit que está apenas no repositório remoto (e não no local) será recuperado e o Git realizará o merge com o HEAD atual utilizando o merge de
três vias. Esse processo é idêntico ao merge mostrado anteriormente, então existem três possibilidades: apenas ocorrer o fast-forward, merge básico
automático ou merge com conflito. Neste caso, o processo automático foi bem sucedido. Podemos, finalmente, enviar com sucesso ao executar:
$ git push
Atente que o comando git pull pode ser utilizado a qualquer momento, não só apenas quando estiver prestes a enviar mudanças (embora esse
último caso é bastante frequente). Neste caso, seu diretório de trabalho e/ou área de preparo não podem estar em conflito com os novos commits.
ℹ Como no caso do envio, o git pull apenas obtém o branch atual. Assim, se deseja obter um branch remote que não está no seu repositório,
use o comando git fetch novobranch .
5.5 Aproveitando algumas facilidades do Gitlab USP
A maior parte das funcionalidades importantes estão contidas na página do seu repositório, como mostrado abaixo:
Você pode chavear entre os branches na caixa de seleção � . Ao mudar o branch, os arquivos do diretório de trabalho são mostrados em � . Em � , o
arquivo README.md é exibido.
ℹ o arquivo "leia-me" README.md é escrito na linguagem Markdown, que é extremamente simples. Sua especificação pode ser resumida em um
cheatsheet de duas páginas, que pode ser consultado em https://guides.github.com/pdfs/markdown-cheatsheet-online.pdf.
Por fim, uma das funções mais úteis é a visualização do histórico de commits, que pode ser acessado ao clicar em � , que encaminha para a seguinte
página:
https://edisciplinas.usp.br/pluginfile.php/6531979/mod_book/chapter/24658/gitlabusp-repopage.png
https://guides.github.com/pdfs/markdown-cheatsheet-online.pdf
Para cada commit, você pode obter as modificações em relação ao commit anterior clicando no botão � . Ao pressionar o botão � , você será
encaminhado para o diretório de trabalho daquela versão, podendo, assim, consultar o histórico do repositório de modo bastante conveniente.
https://edisciplinas.usp.br/pluginfile.php/6531979/mod_book/chapter/24658/gitlabusp-commits.png
6. Considerações finais
Nesta aula você aprendeu o básico de Git, que deve ser o suficiente para operar na maioria dos casos. Sempre é bom se atentar ao fluxo de trabalho,
com o cuidado de gerar commits frequentes e bem estruturados, com mensagens claras e padronizadas. Existem diversos recursosna internet para dar
uma refrescada na memória em relação aos vários comandos aprendidos; seguem duas indicações:
https://rogerdudler.github.io/git-guide/index.pt_BR.html
https://marklodato.github.io/visual-git-guide/index-pt.html
Por fim, ainda existe bastante a se explorar no tópico de Git. Caso deseje se aprofundar mais, recomendo ler o e-book disponível gratuitamente no site
do Git: https://git-scm.com/book/en/v2.
https://rogerdudler.github.io/git-guide/index.pt_BR.html
https://marklodato.github.io/visual-git-guide/index-pt.html
https://git-scm.com/book/en/v2