Seu primeiro repositório

docs.scrimba.com

Existem duas maneiras pelas quais você geralmente chega aqui. Ou você tem uma pasta de projeto já existente, um weather-app que você vinha construindo localmente, e quer que o Git comece a registrar seu histórico. Ou alguém já construiu o projeto, ele vive no GitHub, e você quer sua própria cópia de trabalho na sua máquina. Ambos começam com três pequenos comandos, e ao final deste capítulo você terá usado todos os três de verdade. Primeiro, porém, uma verificação que leva dez segundos: garantir que o Git esteja na sua máquina.

Você tem 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 é chamado Terminal. Pressione Cmd+Space, digite "terminal" e pressione Enter.
• Windows: abra PowerShell por enquanto (procure por "powershell" no menu Iniciar). Instalar Git abaixo também adiciona Git Bash, um terminal construído exatamente para isso, e qualquer um executa os mesmos comandos Git.
• Linux: procure por um aplicativo chamado Terminal ou Console; Ctrl+Alt+T abre em muitas distribuições.

Git em si é um programa de linha de comando: 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 de volta. Isso também é como ler cada bloco de código neste manual: a linha começando com $ é o comando que você digita (sem o $ em si), e as linhas abaixo dele são a resposta do Git.

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

$ git --version
git version 2.45.1

Um número de versão de volta significa que Git está instalado e você está pronto. Seu número provavelmente será diferente deste, e tudo bem. Se você vir "command not found" ou "git is not recognized", Git ainda não está na sua máquina, e instalá-lo é uma tarefa única:

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

Uma vez que a instalação termina, feche seu terminal, abra um novo e execute git --version novamente. Um número de versão significa que você terminou a configuração para sempre; nada no resto deste manual precisa ser instalado.

O número da versão importa um pouco mais do que parece. Este manual escreve 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 receber "not a git command" em exemplos que estão corretos. Qualquer Git dos últimos anos tem eles; se o seu é mais antigo que 2.23, atualize-o nos mesmos lugares listados acima.

Você também encontrará ferramentas Git gráficas: GitHub Desktop, o painel Git no VS Code, o suporte integrado na maioria dos editores. Todos eles são interfaces que executam este mesmo programa Git por baixo. Aprender os comandos primeiro compensa também, porque cada botão nessas ferramentas mapeia um comando que você já entende.

Git é um único programa autossuficiente, não um serviço. Nada executa em segundo plano, nada observa suas pastas, e não há conta para entrar: cada comando inicia, lê ou escreve arquivos dentro do repositório, imprime sua resposta e sai. Isso também é por que tudo funciona offline. Execute which git (ou where git no Windows) para ver exatamente onde o programa vive no disco.

Um detalhe de plataforma que vale a pena conhecer: no macOS, Apple envia sua própria compilação de Git com as Command Line Tools, geralmente uma ou duas versões atrás da versão mais recente em git-scm.com. Para tudo neste manual, e quase tudo no trabalho diário, essa diferença não importa.

JunoVocê tem Git instalado? Git é um programa com o qual você fala digitando comandos em um terminal, e git --version diz se está na sua máquina: um número de versão significa que você está pronto, e "command not found" significa instalar em git-scm.com ou no instalador do seu sistema. Você faz isso apenas uma vez. A configuração é a parte menos divertida de qualquer manual, então parabéns por passar por ela!

JunoVocê tem Git instalado?git --version resolve a pergunta da instalação em uma linha. Qualquer coisa razoavelmente recente funciona, embora os verbos switch e restore que este manual usa precisem de Git 2.23 ou mais novo, então atualize se estiver atrás. Ferramentas GUI como GitHub Desktop executam este mesmo programa por baixo, o que significa que tudo que você aprende aqui se transfere para elas gratuitamente.

JunoVocê tem Git instalado? Git é um programa local único sem daemon e sem conta: executa quando você digita, toca em arquivos no repositório e sai, o que é por que cada bit dele funciona offline. which git mostra o binário. A compilação agrupada da Apple fica atrás da versão mais recente por uma ou duas versões, e em quatorze anos essa diferença não me custou nada.

Transformando uma pasta em um repositório

Abra um terminal e mude para sua pasta de projeto com cd (abreviação de "change directory"), depois execute um 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 Git observa, pronto para registrar snapshots dele conforme você trabalha. git init faz a mesma coisa toda vez. Ele procura por uma pasta .git oculta, cria uma se estiver faltando, e a partir daí a pasta está sob observação do Git.

O branch padrão de um novo repositório é nomeado main. Se você cair em um tutorial mais antigo, um repositório mais antigo ou um curso gravado alguns anos atrás, verá master usado pela mesma coisa: é o mesmo primeiro branch sob um nome mais antigo. Este manual sempre usa main.

O que é um branch?

Um branch é uma linha separada de histórico para seus commits pousarem, e main é aquele com o qual todo novo repositório começa. Branches cobre criação e alternância entre eles.

git init não se importa se a pasta está vazia. Execute-o dentro de weather-app com um index.html e uma pasta src/ já sentadas lá, e Git começa a rastrear esse projeto de onde estiver; nenhum arquivo existente muda. Executar git init uma segunda vez no mesmo repositório é inofensivo também. Git percebe que a pasta .git já existe e a reinicializa no lugar sem tocar em nenhum histórico que você já tem, então executá-lo novamente por hábito não custa nada.

git init faz uma coisa: cria a pasta .git, detalhada mais tarde neste capítulo. Tudo sobre o repositório, seu histórico, suas configurações, suas refs, vive dentro dessa pasta a partir do momento em que init a cria. Os arquivos que você vê e edita no projeto são uma cópia de trabalho do que é rastreado, e a pasta .git é o repositório em si.

JunoTransformando uma pasta em um repositóriogit init transforma qualquer pasta em um repositório Git, pronto para Git começar a rastreá-la. Execute uma vez dentro de uma pasta de projeto e você está pronto, e executá-lo novamente mais tarde não faz mal. Novos repositórios usam um branch chamado main, embora os mais antigos que você encontra por aí geralmente sejam chamados master pela mesma coisa.

JunoTransformando uma pasta em um repositóriogit init funciona em uma pasta vazia ou já cheia de arquivos, e executá-lo novamente em um repo que você já configurou não causa dano já que Git reconhece que a pasta .git já está lá. O nome do branch padrão é main; espere master em qualquer coisa mais antiga.

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

Dizendo ao Git quem você é

Antes do seu primeiro commit, Git quer saber quem está fazendo isso. Defina dois valores uma vez, e Git se lembra deles para cada commit que você faz nesta máquina:

$ git config --global user.name "João Silva"
$ git config --global user.email "[email protected]"

Cada commit que você cria é marcado com esse nome e email. Pule esta etapa, e Git volta para algo adivinhado do nome de usuário e hostname do seu computador, então seus commits carregam uma identidade que você nunca escolheu.

Defina seu nome e email antes do seu primeiro commit. Faça commit primeiro e defina depois, e o erro fica assado no histórico desse commit. Pior, alguns hosts (GitHub incluído) combinam commits com sua conta por email, então um commit feito sob o endereço errado ou um adivinhado aparece como trabalho de um estranho anônimo em vez do seu.

A flag --global define um escopo de config: --global se aplica a todo lugar na sua máquina, enquanto --local se aplica apenas ao repositório em que você está quando a executa. Isso deixa você colocar configurações em camadas. Seu email global cobre cada repositório por padrão, e uma sobreposição --local em um repo específico tem prioridade sobre ele lá e em nenhum outro lugar, útil quando um projeto de trabalho precisa de um endereço diferente que 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 uma flag de escopo lê qualquer valor que realmente se aplique aqui: o local se você o definir, o global caso contrário.

Ambos os escopos são arquivos de texto que Git lê em uma ordem fixa. O global vive na sua pasta home em ~/.gitconfig; o local vive dentro da própria pasta .git do repositório, em .git/config. Git lê as configurações locais primeiro e deixa que elas sobrescrevam as globais, que é todo o mecanismo de camadas, descrito em arquivos de texto simples que você pode abrir e ler você mesmo.

JunoDizendo ao Git quem você égit config --global user.name e git config --global user.email definem o nome e email que Git marca em cada commit que você faz. Defina antes do seu primeiro commit, porque um commit feito antes de você definir seu email é atribuído a uma identidade adivinhada, e um host como GitHub pode não conectá-lo à sua conta. Faça uma vez e cada repositório na sua máquina se lembra.

JunoDizendo ao Git quem você é--global se aplica a cada repositório na sua máquina, e --local o sobrescreve apenas para o repo atual, útil para dividir um email pessoal de um de trabalho. Configurações locais vencem quando ambas estão definidas, e git config user.email diz qual valor está realmente ativo em um repo dado.

JunoDizendo ao Git quem você é Os escopos de config são arquivos de texto em camadas: global vive em ~/.gitconfig, local vive em .git/config dentro do repo, e local vence sempre que ambos definem um valor. Pule definir seu email e Git volta para uma identidade adivinhada construída a partir do seu nome de usuário e nome de máquina, o que é por que um commit desgarrado sob um nome estranho quase sempre rastreia para um user.email faltante.

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. git clone faz isso em um 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.

Git cria uma nova pasta nomeada Hello-World, baixa o histórico completo do projeto nela, e coloca seus arquivos na pasta para que você possa começar a ler ou editar imediatamente. Não há etapa separada de git init necessária. Clonar configura o repositório para você como parte do download.

Recorra a git clone quando o projeto já existe em algum lugar e você quer uma cópia conectada dele. Recorra a git init quando você está começando algo totalmente novo que não existe em lugar nenhum ainda. Clonar também conecta uma conexão de volta para onde você clonou, sob o nome origin, algo que init sozinho nunca faz; essa conexão é o que capítulos posteriores usam para enviar e receber commits.

Clonar traz o histórico completo do projeto, cada commit que ele já teve, e popula a pasta .git inteira na sua máquina, onde git init a deixaria vazia. Um clone de um projeto com anos de histórico pode levar um momento exatamente por esta razão, embora o que você vê depois pareça um snapshot dos arquivos mais novos.

JunoCopiando um projeto existente com git clonegit clone <url> baixa o repositório de alguém, histórico inteiro incluído, em uma nova pasta nomeada após o projeto. Recorra a ele quando o projeto já existe em algum lugar; recorra a git init quando está começando um do zero. Uma vez que a clonagem termina você tem uma cópia completa de trabalho, pronto para procurar ou adicionar.

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

JunoCopiando um projeto existente com git clone Clone recria a pasta .git inteira com cada commit que o projeto já teve. Isso inclui o histórico completo, o que é por que um projeto mais antigo pode levar um momento para clonar mesmo que você apenas veja seus arquivos atuais depois.

O que está dentro da pasta oculta .git

Todo repositório, quer você tenha chegado lá com git init ou git clone, tem uma pasta oculta nomeada .git sentada em sua raiz. Ela é oculta por padrão, então peça ao terminal pela listagem completa com ls -a (ls lista o conteúdo de uma pasta, e -a inclui entradas ocultas) para vê-la sentar ao lado dos seus arquivos de projeto normais:

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

Essa pasta é o repositório real. Ela contém cada commit que você fez, seus branches, e as configurações de config da seção acima. Delete a pasta .git e o projeto perde seu histórico inteiro, voltando a ser uma pasta ordinária que Git não rastreia mais. Tudo mais no projeto é uma cópia de trabalho do que .git contém.

Olhe dentro e você encontrará alguns pedaços reconhecíveis: um arquivo config (as configurações locais da seção acima), um arquivo HEAD, e pastas nomeadas objects e refs. Você não precisa abrir ou editar nenhuma delas à mão, mas reconhecer os nomes ajuda quando um deles aparece em uma mensagem de erro ou resultado de busca.

Alguns desses nomes valem a pena conhecer propriamente. A pasta objects é o banco de dados de objetos do repositório: cada versão de cada arquivo e cada commit que você fez, comprimidos e armazenados pelo conteúdo em si em vez de um nome de arquivo. A pasta refs contém seus branches, cada um um pequeno arquivo apontando para um id de commit. HEAD é um único arquivo registrando qual branch você tem atualmente verificado. config é o arquivo de configurações local coberto acima.

Nada disso é algo que você edita à mão dia a dia. Ver seu histórico inteiro sentado lá como arquivos ordinários, em vez de escondido em um servidor em algum lugar, explica por que um clone lhe dá histórico completo offline, e por que deletar .git não arruma nada: apaga cada commit que o projeto já teve.

JunoO que está dentro da pasta oculta .git Todo repositório tem uma pasta oculta .git em sua raiz, e essa pasta é o repositório real: seu histórico inteiro e suas configurações vivem lá. Execute ls -a dentro de um projeto para vê-la, já que é oculta por padrão. Nunca a delete a menos que realmente queira apagar o histórico inteiro do projeto, já que deletá-la transforma a pasta de volta em uma pasta simples que Git não rastreia mais.

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

JunoO que está dentro da pasta oculta .gitobjects é o banco de dados de objetos do repositório, mantendo cada versão de cada arquivo e commit, endereçado por conteúdo em vez de nome de arquivo. refs contém seus branches como arquivos simples apontando para um id de commit, e HEAD registra qual você tem verificado. Nada lá precisa de edição à mão, mas vê-lo como arquivos ordinários no disco é a razão pela qual clonar lhe dá histórico completo offline, e a razão pela qual deletar .git apaga tudo em vez de meramente limpar.

Se os termos repositório e commit ainda parecem confusos, O que é Git cobre o modelo mental em que esses comandos se baseiam, e o Glossário tem uma definição curta para cada pedaço de vocabulário neste capítulo. Uma vez que sua identidade está definida e você tem um repositório para trabalhar, O loop de commit cobre o ciclo cotidiano de edição, estágio e commit que você usará constantemente a partir daqui.