Seu primeiro repositório

docs.scrimba.com

Normalmente você chega até aqui por um de dois caminhos. Ou você já tem uma pasta de projeto, um weather-app que vem construindo localmente, e quer que o Git comece a registrar seu histórico. Ou alguém já construiu o projeto, ele está no GitHub, e você quer sua própria cópia de trabalho na sua máquina. Os dois caminhos começam com três comandos pequenos, e ao final deste capítulo você terá usado os três de verdade. Antes disso, porém, uma verificação que leva dez segundos: garantir que o Git está instalado na sua máquina.

Você tem o Git instalado?

Tudo neste manual acontece no terminal, então o primeiro passo é abrir um. Um terminal é um aplicativo onde você digita comandos como texto e os programas respondem em texto. Ele já está no seu computador:

• macOS: o aplicativo se chama Terminal. Pressione Cmd+Espaço, digite "terminal" e pressione Enter.
• Windows: por enquanto, abra o PowerShell (procure por "powershell" no menu Iniciar). Ao instalar o Git mais abaixo, você também instala o Git Bash, um terminal feito exatamente para isso, e qualquer um dos dois executa os mesmos comandos do Git.
• Linux: procure um aplicativo chamado Terminal ou Console; em muitas distribuições, Ctrl+Alt+T o abre.

O próprio Git é um programa de linha de comando: ele não tem janela própria, e você o usa digitando comandos que começam com a palavra git e lendo o que ele imprime como resposta. É assim também que se lê todo bloco de código deste manual: a linha que começa com $ é o comando que você digita (sem o $ em si), e as linhas abaixo dela são a resposta do Git.

Então, vamos à verificação. Digite isto no seu terminal e pressione Enter:

$ git --version
git version 2.45.1

Se um número de versão aparecer, o Git está instalado e você está pronto para seguir. Seu número provavelmente será diferente deste, e isso não tem problema. Se, em vez disso, aparecer "command not found" ou "git is not recognized", o Git ainda não está na sua máquina, e instalá-lo é uma tarefa que você faz só uma vez:

• macOS: executar git --version normalmente abre uma janela oferecendo instalar as Command Line Tools da Apple. Aceite, e o macOS instala o Git para você.
• Windows: baixe o Git for Windows em git-scm.com/downloads e execute o instalador. As opções padrão são todas escolhas razoáveis, e o Git Bash é instalado junto.
• Linux: instale o pacote git com o gerenciador de pacotes da sua distribuição, por exemplo sudo apt install git no Ubuntu e no Debian.

Depois que a instalação terminar, feche seu terminal, abra um novo e execute git --version de novo. Um número de versão significa que você terminou essa configuração de uma vez por todas; nada mais no resto deste manual exige instalação.

O número da versão importa um pouco mais do que parece. Este manual usa os verbos modernos git switch e git restore, que chegaram no Git 2.23 em 2019, então uma máquina com um Git pré-instalado muito antigo pode dar erro de "not a git command" em exemplos que estão corretos. Qualquer Git dos últimos anos já os tem; se o seu for anterior à versão 2.23, atualize-o nos mesmos lugares listados acima.

Você também vai encontrar ferramentas gráficas para o Git: GitHub Desktop, o painel de Git do VS Code, o suporte embutido na maioria dos editores. Todas elas são interfaces que, por trás, executam esse mesmo programa Git. Aprender os comandos primeiro compensa também nesse caso, porque cada botão dessas ferramentas corresponde a um comando que você já entende.

O Git é um único programa autocontido, não um serviço. Nada roda em segundo plano, nada monitora suas pastas, e não existe conta para fazer login: cada comando começa, lê ou grava arquivos dentro do repositório, imprime sua resposta e termina. É por isso também que tudo funciona offline. Execute which git (ou where git no Windows) para ver exatamente onde o programa está no disco.

Uma peculiaridade de plataforma que vale saber: no macOS, a Apple distribui sua própria versão do Git junto com as Command Line Tools, geralmente uma ou duas versões atrás da mais recente disponível em git-scm.com. Para tudo neste manual, e para quase tudo no trabalho do dia a dia, essa diferença não importa.

JunoVocê tem o Git instalado? O Git é um programa com o qual você se comunica digitando comandos em um terminal, e git --version mostra se ele está na sua máquina: um número de versão significa que você está pronto, e "command not found" significa que você precisa instalá-lo em git-scm.com ou pelo instalador do seu sistema. Você só faz essa parte uma vez. A configuração é a parte menos divertida de qualquer manual, então parabéns por ter passado por ela!

JunoVocê tem o Git instalado?git --version resolve a questão da instalação em uma linha. Qualquer versão razoavelmente recente funciona, embora os verbos switch e restore usados neste manual precisem do Git 2.23 ou mais novo, então atualize se a sua for anterior a isso. Ferramentas gráficas como o GitHub Desktop rodam esse mesmo programa por trás, o que significa que tudo o que você aprende aqui vale também para elas, de graça.

JunoVocê tem o Git instalado? O Git é um único programa local, sem daemon e sem conta: ele roda quando você digita, altera arquivos no repositório e termina, e é por isso que tudo nele funciona offline. which git mostra o binário. A versão empacotada pela Apple fica uma ou duas versões atrás da mais recente, e em catorze anos essa diferença nunca me custou nada.

Transformando uma pasta em repositório

Abra um terminal e entre na pasta do seu projeto com cd (abreviação de "change directory"), depois execute um único comando, git init:

$ cd weather-app
$ git init
Initialized empty Git repository in /Users/mara/projects/weather-app/.git/

Essa pasta agora é um repositório: um projeto que o Git monitora, pronto para registrar instantâneos dele conforme você trabalha. O git init faz sempre a mesma coisa. Ele procura por uma pasta oculta chamada .git, cria uma se ela não existir, e a partir daí a pasta passa a ser acompanhada pelo Git.

O branch padrão de um repositório novo se chama main. Se você cair em um tutorial mais antigo, um repositório mais antigo, ou um curso gravado alguns anos atrás, vai ver master sendo usado para exatamente a mesma coisa: é o mesmo primeiro branch, só que com um nome mais antigo. Este manual sempre usa main.

O que é um branch?

Um branch é uma linha separada de histórico onde seus commits podem ficar, e main é aquele com o qual todo repositório novo começa. Branches explica como criá-los e alternar entre eles.

O git init não se importa se a pasta está vazia ou não. Execute-o dentro de weather-app já com um index.html e uma pasta src/ presentes, e o Git passa a rastrear esse projeto do jeito que ele está; nenhum arquivo existente é alterado. Executar git init uma segunda vez no mesmo repositório também não causa problema. O Git percebe que a pasta .git já existe e a reinicializa no lugar sem tocar em nenhum histórico que já exista, então rodá-lo de novo por hábito não custa nada.

O git init faz uma única coisa: cria a pasta .git, que será detalhada mais adiante neste capítulo. Tudo sobre o repositório, seu histórico, suas configurações, suas referências, vive dentro dessa pasta desde o momento em que o init a cria. Os arquivos que você vê e edita no projeto são uma cópia de trabalho do que está sendo rastreado, e a pasta .git é o repositório propriamente dito.

JunoTransformando uma pasta em repositóriogit init transforma qualquer pasta em um repositório Git, pronto para o Git começar a rastreá-la. Execute uma vez dentro de uma pasta de projeto e está tudo certo, e executá-lo de novo depois não causa dano nenhum. Repositórios novos usam por padrão um branch chamado main, embora repositórios mais antigos que você encontrar por aí costumem chamar isso de master.

JunoTransformando uma pasta em repositóriogit init funciona em uma pasta vazia ou em uma já cheia de arquivos, e executá-lo de novo em um repositório que você já configurou não causa dano, já que o Git reconhece que a pasta .git já existe. O nome padrão do branch é main; espere master em algo mais antigo.

JunoTransformando uma pasta em repositóriogit init só cria a pasta .git, que é o repositório de fato. Seus arquivos de trabalho são um checkout do que essa pasta rastreia. Guarde essa distinção entre seus arquivos de trabalho e a pasta .git que os rastreia.

Dizendo ao Git quem você é

Antes do seu primeiro commit, o Git quer saber quem está fazendo ele. Defina dois valores uma vez, e o Git vai lembrar deles para todo commit que você fizer nessa máquina:

$ git config --global user.name "Mara Chen"
$ git config --global user.email "[email protected]"

Todo commit que você criar recebe esse nome e esse e-mail. Pule essa etapa, e o Git recorre a algo deduzido a partir do nome de usuário e do hostname do seu computador, então seus commits carregam uma identidade que você nunca escolheu.

Defina seu nome e e-mail antes do seu primeiro commit. Se você fizer o commit primeiro e configurá-los depois, o erro fica cravado no histórico daquele commit. Pior ainda, alguns serviços de hospedagem (o GitHub incluído) associam commits à sua conta pelo e-mail, então um commit feito com o endereço errado ou um deduzido automaticamente aparece como trabalho de um estranho anônimo, em vez de seu.

A flag --global define um escopo de configuração: --global se aplica em toda a sua máquina, enquanto --local se aplica só ao repositório em que você está quando executa o comando. Isso permite empilhar configurações. Seu e-mail global cobre todo repositório por padrão, e uma substituição com --local em um repositório específico tem prioridade sobre ele ali, e só ali, o que é útil quando um projeto de trabalho precisa de um endereço diferente dos seus projetos pessoais:

$ cd weather-app
$ git config --local user.email "[email protected]"
$ git config user.email
[email protected]

Executar git config user.email sem nenhuma flag de escopo lê o valor que de fato se aplica ali: o local, se ele foi definido, ou o global, caso contrário.

Os dois escopos são arquivos de texto que o Git lê em uma ordem fixa. O global fica na sua pasta pessoal (home), em ~/.gitconfig; o local fica dentro da própria pasta .git do repositório, em .git/config. O Git lê as configurações locais primeiro e deixa que elas sobreponham as globais, e é exatamente esse o mecanismo de empilhamento, disposto em arquivos de texto simples que você mesmo pode abrir e ler.

JunoDizendo ao Git quem você égit config --global user.name e git config --global user.email definem o nome e o e-mail que o Git registra em todo commit que você faz. Defina-os antes do seu primeiro commit, porque um commit feito antes de você definir o e-mail fica atribuído a uma identidade deduzida, e um serviço como o GitHub pode nem conseguir associá-lo à sua conta. Faça isso uma vez, e todo repositório na sua máquina vai lembrar.

JunoDizendo ao Git quem você é--global se aplica a todo repositório na sua máquina, e --local o sobrepõe só no repositório atual, o que é útil para separar um e-mail pessoal de um profissional. As configurações locais vencem quando as duas estão definidas, e git config user.email mostra qual valor está realmente ativo em um determinado repositório.

JunoDizendo ao Git quem você é Os escopos de configuração são arquivos de texto em camadas: o global fica em ~/.gitconfig, o local fica em .git/config dentro do repositório, e o local vence sempre que os dois definem um valor. Se você não definir seu e-mail, o Git recorre a uma identidade deduzida a partir do seu nome de usuário e do nome da máquina, e é por isso que um commit estranho com um nome esquisito quase sempre remonta a um user.email não definido.

Copiando um projeto existente com git clone

Às vezes o projeto já existe em outro lugar, e você quer uma cópia de trabalho dele na sua máquina. O git clone faz isso em um único comando:

$ git clone https://github.com/octocat/Hello-World.git
Cloning into 'Hello-World'...
remote: Enumerating objects: 13, done.
remote: Total 13 (delta 0), reused 0 (delta 0), pack-reused 13
Receiving objects: 100% (13/13), done.

O Git cria uma nova pasta chamada Hello-World, baixa o histórico completo do projeto para dentro dela, e coloca seus arquivos na pasta para que você já possa começar a ler ou editar. Não é preciso um git init separado. O clone já configura o repositório para você como parte do download.

Use git clone quando o projeto já existir em algum lugar e você quiser uma cópia conectada a ele. Use git init quando estiver começando algo totalmente novo, que ainda não existe em lugar nenhum. Clonar também estabelece uma conexão de volta com o lugar de onde você clonou, sob o nome origin, algo que o init por si só nunca faz; essa conexão é o que os capítulos mais adiante usam para enviar e receber commits.

Clonar traz todo o histórico do projeto, cada commit que ele já teve, e preenche toda a pasta .git na sua máquina, ali onde o git init a deixaria vazia. Um clone de um projeto com anos de histórico pode demorar um pouco por esse exato motivo, mesmo que o que você vê depois pareça um instantâneo apenas dos arquivos mais recentes.

JunoCopiando um projeto existente com git clonegit clone <url> baixa o repositório de outra pessoa, histórico completo incluído, para dentro de uma nova pasta com o nome do projeto. Use-o quando o projeto já existir em algum lugar; use git init quando estiver começando um do zero. Depois que o clone termina, você tem uma cópia de trabalho completa, pronta para ser explorada ou receber novas mudanças.

JunoCopiando um projeto existente com git clone Clone quando um projeto já existir em algum lugar e você quiser uma cópia conectada a ele; use init quando nada existir ainda. Clonar já estabelece automaticamente a conexão de volta com o lugar de onde você clonou, sob o nome origin, algo que o init por si só nunca configura.

JunoCopiando um projeto existente com git clone Clonar recria toda a pasta .git com cada commit que o projeto já teve. Isso inclui o histórico completo, e é por isso que um projeto mais antigo pode demorar um pouco para ser clonado, mesmo que depois você só veja os arquivos na sua versão atual.

O que tem dentro da pasta oculta .git

Todo repositório, seja ele criado com git init ou com git clone, tem uma pasta oculta chamada .git na sua raiz. Ela fica oculta por padrão, então peça ao terminal a listagem completa com ls -a (o ls lista o conteúdo de uma pasta, e o -a inclui os itens ocultos) para vê-la ao lado dos seus arquivos normais de projeto:

$ ls -a
.  ..  .git  README.md  src

Essa pasta é o repositório de fato. Ela guarda todo commit que você já fez, seus branches e as configurações da seção anterior. Exclua a pasta .git e o projeto perde todo o seu histórico, voltando a ser uma pasta comum que o Git não rastreia mais. Tudo o mais no projeto é uma cópia de trabalho do que está guardado em .git.

Dê uma olhada e você vai encontrar algumas peças reconhecíveis: um arquivo config (as configurações locais da seção acima), um arquivo HEAD, e pastas chamadas objects e refs. Você não precisa abrir ou editar nada disso à mão, mas reconhecer os nomes ajuda quando um deles aparece em uma mensagem de erro ou em um resultado de busca.

Alguns desses nomes valem a pena conhecer melhor. A pasta objects é o banco de dados de objetos do repositório: cada versão de cada arquivo e cada commit que você já fez, comprimidos e armazenados pelo próprio conteúdo, em vez de por um nome de arquivo. A pasta refs guarda seus branches, cada um deles um arquivo pequeno apontando para o id de um commit. O HEAD é um único arquivo que registra qual branch você tem selecionado no momento. O config é o arquivo de configurações locais visto acima.

Nada disso é algo que você edita à mão no dia a dia. Ver todo o seu histórico ali, guardado como arquivos comuns, em vez de escondido em algum servidor, explica por que um clone te dá o histórico completo offline, e por que excluir a pasta .git não organiza nada: isso apaga todo commit que o projeto já teve.

JunoO que tem dentro da pasta oculta .git Todo repositório tem uma pasta oculta chamada .git na sua raiz, e essa pasta é o repositório de fato: todo o seu histórico e suas configurações vivem ali. Execute ls -a dentro de um projeto para vê-la, já que ela é oculta por padrão. Nunca a exclua, a menos que você realmente queira apagar todo o histórico do projeto, já que excluí-la transforma a pasta de volta em uma pasta comum que o Git não rastreia mais.

JunoO que tem dentro da pasta oculta .git Dentro de .git você vai reconhecer um arquivo config (suas configurações locais), um arquivo HEAD, e as pastas objects e refs. Você não vai tocar nisso à mão no dia a dia, mas os nomes aparecem em mensagens de erro e na documentação do Git. Clonar copia essa pasta inteira, e é por isso que um clone chega com o histórico completo, e não apenas com os arquivos mais recentes.

JunoO que tem dentro da pasta oculta .gitobjects é o banco de dados de objetos do repositório, guardando cada versão de cada arquivo e commit, endereçados pelo conteúdo em vez de pelo nome do arquivo. refs guarda seus branches como arquivos comuns apontando para o id de um commit, e HEAD registra qual deles você tem selecionado. Nada ali precisa de edição manual, mas ver isso como arquivos comuns no disco é o motivo pelo qual clonar te dá o histórico completo offline, e o motivo pelo qual excluir a pasta .git apaga tudo, em vez de simplesmente organizar alguma coisa.

Se os termos repositório e commit ainda parecem meio vagos, What is Git explica o modelo mental sobre o qual esses comandos se apoiam, e o Glossário tem uma definição curta para cada termo deste capítulo. Depois que sua identidade estiver configurada e você tiver um repositório para trabalhar, O ciclo do commit explica o ciclo do dia a dia de editar, preparar (stage) e fazer commit que você vai usar constantemente a partir daqui.