Por que remotos mudam tudo

Até agora, tudo foi numa máquina só

Todo commit, branch e truque de desfazer dos últimos dois cursos aconteceu inteiramente no seu notebook. Isso é um sistema de controle de versão completo e funcional: e também, sozinho, um ponto único de falha. Derrame café naquele notebook e todo commit que você já fez some junto com ele. Pior: ninguém mais consegue ver uma única linha do seu trabalho.

Um remoto é outra cópia do seu repositório, acessível pela rede: mais comumente hospedada no GitHub, GitLab ou Bitbucket. O Git em si não exige nenhum desses; são empresas que hospedam repositórios Git e adicionam ferramentas de colaboração (issues, pull requests, CI) em cima do Git puro.

As duas direções

              git push
Repo local  ───────────▶  Repo remoto (GitHub)
(seu notebook)  ◀───────────  (servidor)
              git pull

O push envia seus commits locais para outro lugar; o pull traz de volta commits de outra pessoa (ou seus próprios, de outra máquina). Esse é o modelo mental completo sobre o qual este curso se constrói: tudo daqui em diante é detalhe em cima dessas duas setas.

O que um remoto te dá

• Backup: um remoto é uma cópia completa do seu histórico, independente do seu notebook.
• Colaboração: colegas dão push e pull do mesmo remoto, vendo o trabalho commitado uns dos outros.
• Um gatilho de deploy: dar push para um branch específico é como muitos pipelines de CI/CD e plataformas de hospedagem sabem que devem buildar e fazer deploy da sua app.
• Portfólio e revisão de código: o GitHub é onde pull requests, rastreamento de issues e seu histórico público de commits moram: o artefato que um recrutador olha.

GitHub não é Git

Essa distinção confunde iniciantes o tempo todo. O Git é a ferramenta de controle de versão na sua máquina, que faz tudo o que os dois últimos cursos cobriram. O GitHub é um site que hospeda repositórios Git e coloca uma interface, permissões e ferramentas de fluxo de trabalho por cima. Você poderia dar push para um remoto que nem é o GitHub: um servidor GitLab, um servidor privado de empresa, até outra pasta na sua máquina. Este curso usa o GitHub porque é o padrão esmagador da indústria, mas todo comando funciona de forma idêntica contra qualquer remoto Git.

Como este curso está organizado

1. Autenticar com o GitHub usando chaves SSH: uma vez, e você nunca mais digita senha para o Git
2. Conectar um repo local existente a um remoto novo com git remote add
3. git push: enviar commits, e configurar a relação de rastreamento
4. git clone: começar a partir de um remoto em vez de git init
5. git fetch vs. git pull: olhar antes de pular
6. Dar push de um projeto Rails de verdade para o GitHub de ponta a ponta

O que este curso ainda não cobre

Duas pessoas editando o mesmo arquivo e combinando as mudanças (merge e resolução de conflitos) é uma situação real. Ela tem um curso próprio, Git merging & conflitos, logo depois do curso de branching. Tudo aqui supõe que as mudanças chegam de forma limpa; no momento em que não chegam, este curso para e o curso de merging assume.

Vamos te autenticar.