Git e GitHub não são a mesma coisa: o que cada um faz

Publicado em 2026-09-12 por frfrand

Uno es un programa que corre en tu máquina; el otro es un servicio con una copia de tu repositorio y un montón de cosas alrededor. Dónde termina uno y empieza el otro, y por qué importa.

É uma confusão tão comum que vale separá‑la bem, porque saber onde termina um e começa o outro evita muitos mal‑entendidos.

Git é um programa

Git é um sistema de controle de versões que roda no seu computador. Você o instala e, a partir daí, pode criar repositórios, fazer commits, ramificações, fusões e ver o histórico completo.

Tudo isso funciona sem conexão à Internet e sem nenhuma conta em nenhum lugar. Um repositório Git é uma pasta oculta chamada .git dentro do seu projeto. Lá está tudo.

Ele foi escrito por Linus Torvalds em 2005, em algumas semanas, porque o sistema que eles usavam para o kernel do Linux deixou de ser gratuito. Os objetivos eram velocidade, integridade e bom suporte para trabalho em paralelo.

GitHub é um serviço

GitHub é uma empresa que hospeda repositórios de Git e adiciona coisas ao redor deles.

A parte de "hospedar" é a mais simples: ela tem uma cópia do seu repositório, acessível pela rede, para que várias pessoas trabalhem no mesmo lugar.

O que ela adiciona por cima é o que a tornou grande, e nada disso faz parte do Git:

• Pull requests, para revisar mudanças antes de integrá‑las
• Issues, para acompanhar tarefas e erros
• Actions, para executar processos automáticos
• Permissões, equipes e organizações
• A interface web para ler código

Há alternativas que fazem a mesma coisa: GitLab, Bitbucket, Gitea, Forgejo. E você também pode hospedar seu repositório em um servidor próprio por SSH, sem nenhuma plataforma: basta um repositório vazio para fazer push.

O que significa "distribuído"

Esta é a parte que mais custa quando alguém vem de sistemas anteriores.

Cada cópia de um repositório Git contém o histórico inteiro. Não há um servidor central que seja "o original" e cópias parciais.

Consequências práticas:

• Você pode trabalhar, fazer commits, criar branches e ver todo o histórico sem conexão.
• Se o GitHub desaparecer amanhã, seu repositório local tem tudo. Você perderia os issues e os pull requests, que são do GitHub, mas não o código nem o histórico.
• Você pode ter vários remotos ao mesmo tempo.

Que o GitHub seja "o principal" é uma convenção da equipe, não uma propriedade técnica.

Os remotos, na prática

Um remoto é simplesmente um nome para um endereço:

git remote -v origin git@github.com:empresa/projeto.git (fetch) origin git@github.com:empresa/projeto.git (push)

"origin" não tem nada de especial: é o nome padrão que se dá ao primeiro. Você pode adicionar outro:

git remote add produccion deploy@miservidor.com:/repos/app.git git push produccion main

Isso foi, durante anos, o mecanismo de implantação mais simples que existia: fazer push diretamente para um repositório no servidor, com um hook que atualizava o site.

Onde o implantação se encaixa

Hoje o fluxo mais comum é: você faz push para o GitHub, o GitHub avisa o seu servidor por meio de um webhook, e o servidor baixa o código e faz o deploy.

Essa distinção esclarece um ponto que confunde: seu servidor não está monitorando o GitHub. É o GitHub que avisa o servidor. Por isso, quando um deploy não é disparado, o primeiro lugar a verificar é o histórico de entregas do webhook: lá você vê se o aviso foi enviado e o que o servidor respondeu.

No ArduMaker, é configurado exatamente assim: você vincula o repositório, escolhe o branch, e cada push dispara o build e a reinicialização, com seu log para saber em qual etapa parou.