100 perguntas sobre o GitHub

Prefácio

Este é um guia de «100 perguntas»: uma forma de dividir um tema grande em perguntas e depois lê-lo uma por uma.

O GitHub não é só um repositório de código para programadores. Ele pode guardar trabalho, hospedar um portfólio, servir um site estático, apoiar colaboração open source, gerenciar escrita e até rodar tarefas agendadas com Actions. O guia segue seis etapas: decidir se vale aprender, começar sem linha de comando, evitar os erros dolorosos, encontrar e executar projetos, guardar e mostrar seu trabalho e decidir até onde ir.

Respostas rápidas

• Vale a pena aprender, mas trate como um espaço durável para guardar, mostrar e colaborar, não como um monte de comandos Git.
• No primeiro dia use a web ou o GitHub Desktop e faça um commit real antes de tocar na linha de comando.
• Leia o README antes de executar um projeto; se for técnico demais, peça à IA para explicar.
• Nunca suba chaves, senhas ou documentos. Se subir, revogue e rotacione primeiro.
• Decida se precisa de armazenamento, portfólio, colaboração ou automação. Cada objetivo exige uma profundidade diferente.

Compilado a partir da documentação do GitHub e de material público, estruturado e levemente completado para este site.

Esta é uma edição editada: alguns trechos originais estavam truncados pelo OCR, então o corpo foca em uma lista de perguntas acionável com respostas concisas.

1. Vale a pena aprender? Ainda dá tempo?

1. A IA é muito forte. Ainda faz sentido aprender GitHub se não programo?

Sim. A IA gera código, mas o GitHub é onde o trabalho é guardado, revisado, versionado, compartilhado e mostrado. É a camada de colaboração e evidência.

2. Dizem que GitHub é coisa de programador. O que ele oferece a uma pessoa comum?

Guardar arquivos com segurança, publicar um portfólio, hospedar um site estático, acompanhar projetos, aprender com open source e colaborar em escrita ou pesquisa.

3. Dizem que GitHub é um segundo currículo. Alguém realmente consegue uma oferta pelo perfil?

Sim, mas o perfil importa porque mostra evidência: projetos, contribuições, consistência e comunicação. O perfil sozinho não garante oferta; torna suas afirmações verificáveis.

4. Estou começando tarde. Estou muito atrás para alcançar?

Não. A maioria nunca começa. Um registro público pequeno e consistente vale mais que um perfil perfeito que não existe.

5. Minha empresa não exige e minha escola não ensinou. Por que dedicar tempo?

Porque é um lugar durável para seu trabalho e uma linguagem compartilhada de colaboração. Também força você a organizar, documentar e publicar.

6. Outros perfis parecem impressionantes. Vou parecer bobo como iniciante?

Só se fingir ser especialista. Um README claro, um projeto pequeno que funciona e notas honestas parecem melhor que um perfil vazio ou trabalho copiado.

7. Dizem que GitHub vicia. Quem acaba colecionando e nunca usa?

Quem transforma estrelas e favoritos em objetivo. Use o GitHub para rodar, fazer fork ou contribuir com algo, não só para colecionar links.

8. Se eu só usar ferramentas de IA, que capacidade importante vou perder?

Versionar, revisar, colaborar e publicar. A IA escreve código, mas sem repositório você perde histórico, reprodutibilidade, revisão e contexto compartilhado.

9. Aprender GitHub é memorizar um monte de comandos Git?

Não. Você pode começar pela web ou GitHub Desktop. Aprenda depois os poucos comandos que usar: status, add, commit, push, pull.

10. Há muitos recursos gratuitos. Como GitHub se diferencia de um curso?

Cursos ensinam; o GitHub é onde projetos reais vivem e onde você pode inspecionar, executar e contribuir. É um ambiente de trabalho.

11. Para um portfólio, por que GitHub é melhor que um currículo em PPT?

Um repositório pode ser aberto, executado e inspecionado. Mostra o trabalho, o histórico e a documentação; uma apresentação só descreve.

12. Todos dizem para aprender, mas temo perder tempo. Como decido?

Se precisa guardar trabalho, mostrar evidência, colaborar ou publicar um site, vale. Se só precisa perguntar à IA, pode adiar.

13. GitHub tem modelos de IA gratuitos. O que isso tem a ver comigo?

Muitos projetos de IA publicam modelos, demos e APIs no GitHub. Você pode testá-los, rodá-los localmente ou conectá-los às suas ferramentas.

14. Que benefícios concretos uma pessoa sem código tira do GitHub?

Arquivo seguro, portfólio público, site estático grátis, forma de acompanhar e rodar ferramentas e um caminho para contribuir sem escrever muito código.

2. Primeiro dia sem código: como usar sem linha de comando

15. Um repositório está cheio de botões em inglês. Quais olho primeiro?

A lista de arquivos, o README, o botão verde Code, Issues e Releases. Cobrem ler, baixar, executar e perguntar.

16. Posso subir algo só pela web, sem Git nem comandos?

Sim. Crie um repositório, use «Add file» ou arraste arquivos para o navegador, escreva uma mensagem de commit e salve. Isso é um commit real.

17. O que o botão verde Code faz e por que confunde iniciantes?

Oferece opções de download: clonar por HTTPS ou SSH, abrir no GitHub Desktop ou baixar um ZIP. Para uma primeira olhada, Download ZIP é o mais simples.

18. Star, Watch e Fork: qual a diferença e posso quebrar algo?

Star é favorito, Watch envia notificações e Fork copia um repositório para sua conta. Nenhum altera o projeto original.

19. Dizem «faça Fork e depois mude». Fork é cópia ou vínculo?

É uma cópia na sua conta com um vínculo ao original. Você muda seu fork sem afetar a fonte e abre um pull request para propor mudanças.

20. Quero o projeto de outra pessoa na minha conta. Clonar ou Fork?

Fork se quer sua cópia no GitHub e um caminho para contribuir. Clonar se só quer uma cópia local para executar ou inspecionar.

21. Posso editar código online com uma tecla, sem instalar nada?

Sim. Pressione . na página de um repositório para abrir o github.dev, um editor no navegador. Serve para edições pequenas e leitura.

22. Posso pular a configuração de nome e email do Git? O que acontece?

Não pule. Os commits usam essa identidade e o GitHub atribui contribuições à sua conta. Use o mesmo email do GitHub.

23. As chaves SSH falham com «permission denied». Qual passo está errado?

Normalmente a chave pública. Copie o arquivo .pub completo, de ssh- ao fim, para o GitHub. Nunca compartilhe a privada. Teste com ssh -T git@github.com.

24. GitHub é lento na China. Há formas de acelerar sem VPN?

Teste um arquivo hosts mantido como GitHub520, um domínio espelho ou um proxy configurado no Git. Evite espelhos não confiáveis para repositórios privados.

25. Não recebi o email de verificação do GitHub. O que mais posso fazer?

Veja spam, confirme o endereço, reenvie em Settings → Emails e evite emails temporários. Se falhar, use outra caixa confiável.

26. Antes do primeiro commit, GitHub Desktop ou linha de comando?

Use GitHub Desktop ou a web no primeiro dia. Aprenda a linha de comando quando precisar de velocidade, scripts ou trabalho em lote.

27. Por que todos dizem para ler o README primeiro? O que acontece se não ler?

O README explica o que é o projeto, como instalar, como executar e o que evitar. Pular costuma significar baixar a versão errada ou perder um passo obrigatório.

28. Quero guardar um projeto de que gosto. Star ou lista própria?

Star para favorito rápido. Uma lista própria quando tiver muitos e precisar de categorias. Adicione uma nota de por que salvou.

29. Branches parecem avançadas. Preciso delas no primeiro dia?

Não. No primeiro dia você pode trabalhar na branch principal. Aprenda branches quando começar a mudar o projeto de outra pessoa ou testar duas ideias.

30. Quero subir uma pasta local pela primeira vez. Quais são os comandos mínimos?

git init, git add ., git commit -m "first commit", git remote add origin <url>, git push -u origin main. Se for demais, use GitHub Desktop.

31. Para que servem Issues, Pull requests e Actions?

Issues rastreiam bugs, ideias e perguntas. Pull requests propõem mudanças. Actions executa tarefas automáticas como testes ou deploy. No primeiro dia você só lê.

32. Posso colocar o GitHub em chinês? Isso dificulta tutoriais em inglês?

O GitHub tem localização limitada. Use a tradução do navegador, mas mantenha termos-chave em inglês para tutoriais e documentação fazerem sentido.

33. Qual a diferença entre repositório e projeto?

Um repositório é o armazenamento e o histórico dos arquivos. Um «projeto» é um esforço mais amplo; GitHub Projects é um quadro que liga issues e pull requests.

34. Editar um arquivo na web conta como commit? Como difere de um commit local?

Sim, cria um commit no servidor. Um commit local acontece na sua máquina e é enviado depois; o histórico é o mesmo, o fluxo muda.

3. Por que me atrapalho assim que uso?

35. Push diz que a autenticação por senha foi removida. Por que minha senha não funciona?

O GitHub não aceita mais senhas de conta por HTTPS. Use um token de acesso pessoal, SSH ou GitHub Desktop, que gerencia a autenticação.

36. Subi por acidente uma chave, senha ou documento. Como apago de vez?

Revogue e rotacione o segredo primeiro. Depois remova do histórico com git-filter-repo ou BFG, force o push e avise quem tem acesso. Um commit novo não apaga do histórico.

37. Meu .gitignore estava errado e subi arquivos inúteis. Como recupero?

Adicione os arquivos ao .gitignore, remova do índice com git rm --cached, faça commit e push. Se contiverem segredos, rotacione e limpe o histórico.

38. Minhas mensagens de commit são «fix» e «update». Dá para torná-las úteis?

Use um resumo imperativo curto e um corpo explicando por quê. Para histórico não publicado, use amend ou squash; depois de publicado, prefira commits novos claros.

39. Quero desfazer o último commit. Reset, revert ou checkout?

Use revert para desfazer um commit público com segurança. Use reset só para histórico local não compartilhado. checkout serve para trocar arquivos ou branches.

40. Um merge gerou um monte de <<<<<<<. O que são?

Marcam versões em conflito das mesmas linhas. Edite o arquivo para manter o conteúdo correto, apague os marcadores e faça add e commit.

41. git add deve adicionar um arquivo ou o diretório todo? Como desfaço um erro?

Adicione só o que pertence ao commit. Se adicionou demais, use git restore --staged <file> para remover do stage. Revise git status.

42. Por que preciso de commit depois do add? O que o stage faz?

O stage seleciona o que vai para o próximo commit. Permite revisar e separar mudanças, para que um commit contenha uma mudança coerente.

43. O que significam os arquivos vermelhos e verdes no git status?

Vermelho significa não rastreado ou modificado sem stage. Verde significa pronto para commit. Leia os rótulos.

44. Cometi um erro e não quero deixar registro de desfazer. Há forma limpa?

Para commit não publicado, amend ou reset e recommit. Para commit publicado, não reescreva histórico público; faça um commit corretivo ou combine com a equipe.

45. Duas pessoas mudaram o mesmo arquivo e minhas mudanças foram sobrescritas. Como evito?

Faça pull antes de começar, trabalhe em uma branch, commite com frequência e abra um pull request. Resolva conflitos explicitamente em vez de force-push.

46. Sigo um tutorial mas travo no primeiro push. Quais são os três pontos comuns?

Autenticação, URL remota e nome da branch. Verifique o token ou a chave SSH, confirme git remote -v e faça push para a branch que existe.

47. Pull diz «unrelated histories». O que significa?

Os repositórios local e remoto não compartilham um ancestral. Faça merge com --allow-unrelated-histories só se tiver certeza, ou comece de um clone limpo.

48. Push é rejeitado, pull cria conflitos e fico num loop. Como saio?

Faça fetch, inspecione a divergência e depois merge ou rebase com intenção. Se for branch pessoal, reset para o remoto e reaplique suas mudanças; nunca force-push em branch compartilhada.

49. Clonei um diretório vazio embora a web tenha arquivos. Por quê?

Talvez tenha clonado outra branch, outra URL ou um repositório com arquivos em submódulo ou release. Verifique a branch padrão e a URL.

50. Um repositório dá 404 ou acesso negado. Fui bloqueado ou a URL está errada?

Verifique a URL, se o repositório é privado e se você está logado. Repositório privado dá 404 para quem não tem acesso.

51. Apaguei .git, perdi uma branch ou editei a branch errada. Como recupero?

Verifique o reflog e as branches remotas primeiro. Se .git sumiu, clone de novo e recupere arquivos sem commit de backups ou do histórico do editor.

4. Como encontro bons projetos, julgo e executo?

52. Quero uma ferramenta usável. Como buscar no GitHub melhor que num buscador comum?

Busque por problema, não por nome. Use a busca do GitHub, filtre por linguagem, estrelas e atualização recente, e leia o README dos primeiros resultados.

53. Por que adicionar «awesome» à busca encontra listas valiosas?

Listas «awesome» são coleções curadas de links sobre um tema. Economizam vasculhar repositórios aleatórios.

54. O número de estrelas basta para julgar um projeto? O que mais olho?

Não. Veja commits recentes, issues abertas, atividade dos mantenedores, documentação, licença e se resolve seu problema.

55. Como sei se um projeto está vivo ou abandonado?

Veja o último commit, release e atividade de issues. Um projeto sem atualizações há um ano e com issues sem resposta costuma estar abandonado.

56. O README é técnico demais. Há leitura rápida para pessoas comuns?

Leia a primeira seção, instalação, exemplo de uso e solução de problemas. Pule a arquitetura, a menos que vá modificá-lo.

57. Quero executar um projeto. Qual seção do README leio primeiro?

Requisitos e instalação, depois uso. Confira o sistema operacional e as versões suportadas antes de instalar.

58. O que são npm install e pip install? Tenho medo de rodar.

Instalam as dependências do projeto. São normais, mas rode em uma pasta confiável, de preferência em ambiente virtual ou contêiner.

59. O comando de instalação falha no meu computador. O que costuma estar errado?

Versão de runtime errada, dependência do sistema ausente, problema de caminho ou permissão. Leia o primeiro erro e compare seu ambiente com os requisitos.

60. Posso trocar github por deepwiki na URL para obter documentação em linguagem simples?

Alguns repositórios têm documentação gerada no DeepWiki, mas não todos. Ajuda a entender, mas verifique detalhes importantes na fonte.

61. Não entendo o código. É confiável colar o README na IA e pedir explicação?

Ajuda a orientar, mas a IA pode omitir detalhes ou inventar. Use para formular perguntas e depois confira README e código.

62. Um projeto baixa a 20 KB/s. Além de esperar, como acelerar?

Use espelho de download, proxy configurado no Git ou baixe o ZIP de um release em vez de clonar todo o histórico.

63. O projeto pede uma API key. Onde consigo e é seguro?

No provedor oficial, nunca em um repositório aleatório. Guarde em variável de ambiente, não suba e defina limites de gasto.

64. Posso testar um projeto no navegador ou celular sem montar ambiente local?

Às vezes. Procure demo, versão hospedada, GitHub Pages ou notebook na nuvem. Se não houver, normalmente precisa de ambiente local.

65. O projeto lança um monte de erros vermelhos. É o projeto ou meu ambiente?

Veja se o erro é de runtime ou pacote faltante (seu ambiente) ou traceback de lógica (projeto ou cenário não suportado). Busque o mesmo erro em Issues.

66. Releases ou baixar o código: o que uma pessoa comum escolhe?

Releases para um pacote pronto. Código-fonte só se quiser ler, modificar ou compilar.

67. Não quero tocar em código. Como escolho uma versão pronta?

Veja os assets de Releases, escolha a build para seu sistema e prefira uma versão recente com instruções claras.

68. Como distingo um projeto de IA hype de um realmente útil?

Veja se o README tem instalação e uso reais, se o projeto é atualizado e se as Issues mostram uso real ou só «não roda».

69. Coleciono bons projetos mas nunca abro. Como crio o hábito de usar?

Escolha um projeto que precise hoje, siga um passo do README e use ou apague da lista. Uma lista pequena com notas vale mais que uma coleção enorme.

5. Como guardo meu trabalho, mostro e contribuo com open source?

70. O que deve ter meu primeiro repositório? Um repositório vazio parece ruim?

Coloque uma nota real, um registro de estudo ou um pequeno projeto. Um repositório vazio parece pior que um simples e honesto.

71. Como escrevo um README fácil de entender sem saber design?

Use estrutura simples: nome, descrição em uma linha, funções, instalação, uso e contato. O GitHub renderiza Markdown; visualize antes de salvar.

72. Markdown tem muita sintaxe. O que preciso para um README?

Títulos, negrito, listas, links, imagens e blocos de código. Cobre quase todos os READMEs.

73. Quero subir código mas temo que seja ruim. Como embalo meu primeiro repositório?

Não se preocupe com piadas. Um README claro, instruções que funcionam e escopo honesto bastam. Todos começam em algum lugar.

74. O que é GitHub Pages e como transformo um repositório em página pessoal ou currículo?

Pages é hospedagem estática grátis. Coloque um index.html em um repositório, ative Pages em Settings e o site aparece em usuario.github.io/repo.

75. Preciso de servidor e domínio para Pages? Basta para uma pessoa comum?

Não. Pages inclui hospedagem e domínio github.io. Só suporta sites estáticos, suficiente para currículo, portfólio ou documentação.

76. Como faço minha página aparecer quando um recrutador busca meu nome?

Coloque o link no currículo, redes e assinatura de email. Mantenha repositórios documentados e ativos; o ranking segue conteúdo real e encontrável.

77. Como deixo meu perfil do GitHub bonito com estatísticas ou modelos em dez minutos?

Busque um modelo de README de perfil, copie, troque os dados e faça commit. Os cards leem sua atividade pública, então continue contribuindo.

78. Quero ajudar um projeto open source mas não sei programar. O que posso contribuir?

Documentação, traduções, passos mais claros, relatos de bugs, design, tutoriais e resposta a novos usuários.

79. Corrigir erros de digitação e documentação conta como contribuição? Os autores agradecem?

Sim. Contribuições de documentação são das mais fáceis de aceitar e costumam ser agradecidas explicitamente.

80. A etiqueta «good first issue» é para iniciantes? Como uso?

Sim. Marca tarefas para novos. Leia o issue, tire dúvidas, siga o guia de contribuição e mantenha a mudança pequena.

81. Quero reportar um bug ou sugerir melhoria. Como escrevo um Issue que não seja ignorado?

Título claro, passos de reprodução, comportamento esperado e real, versões e logs. Busque issues existentes e use um por problema.

82. O que é um Pull Request e como difere de editar arquivos diretamente?

Um PR propõe mudanças da sua branch ou fork ao repositório destino. Adiciona revisão, discussão e CI antes do merge.

83. Meu primeiro PR foi rejeitado. Isso significa que não presto?

Não. É normal: pode estar fora de escopo, precisar de testes ou conflitar com o plano do mantenedor. Leia o feedback e itere.

84. Qual a diferença entre Discussions e Issues? Onde falo?

Issues são para bugs e tarefas acionáveis. Discussions para perguntas abertas, ideias e conversa. Siga a orientação do projeto.

85. Posso usar GitHub para gerenciar escrita, notas e pesquisa? É melhor que a nuvem?

Sim. Você tem histórico, diffs, issues, colaboração e texto portátil. É melhor para trabalho estruturado e em evolução que para binários grandes.

86. GitHub Actions executa tarefas automaticamente. Para que uma pessoa comum usa?

Backups agendados, publicar site estático, rodar testes, gerar relatórios e sincronizar conteúdo. Comece com modelo e permissões estreitas.

87. O Copilot CLI pode me ajudar a operar o GitHub sem escrever código?

Sim. Sugere e explica comandos em linguagem natural e pede confirmação antes de executar. Útil quando não lembra o comando exato.

88. Posso usar GitHub + jsDelivr como hospedagem de imagens e CDN grátis para o blog?

Sim, com cuidado: o repositório precisa ser público, não suba imagens privadas e mantenha-o pequeno. Serve para imagens ocasionais, não armazenamento ilimitado.

89. Dá para ganhar dinheiro com GitHub Sponsors?

Alguns mantenedores sim, e o GitHub não cobra comissão. Exige projeto com usuários reais e contribuição contínua. É apoio ao trabalho, não atalho.

6. Até onde ir ou onde parar?

90. Depois do básico, aprendo branches ou colaboração primeiro?

Escolha por objetivo. Releases para publicar, Pages para mostrar, Actions para automatizar e colaboração para trabalhar com outros. Branches se aprendem num PR real.

91. O que um Code Review revisa de verdade e como evito ser criticado?

Revisa lógica, casos-limite, bugs, desempenho, nomes e clareza. Mantenha PRs pequenos, responda aos comentários e trate como coaching gratuito.

92. Os quadros do Projects servem para gerenciar projetos? Como superam o Excel?

Sim. Ligam issues e pull requests, mostram status, responsáveis, datas e prioridade. Os dados ficam em Issues/PRs, sem duplicar.

93. Actions para builds e deploy parece avançado. Devo tocar agora?

Sim, mas comece com modelos. Use para backups agendados ou publicação automática. Aprenda o interior quando houver necessidade real.

94. Que problemas as «variáveis» e o «cache» do Actions resolvem?

Variáveis evitam repetir o mesmo valor em vários fluxos. Cache evita reinstalar dependências a cada execução.

95. Que atalhos e truques da paleta de comandos devo aprender no primeiro dia?

Aprenda ? para atalhos, navegação G, t para buscar arquivos, y para link permanente e . para o editor web. A paleta é o recurso quando esquece um atalho.

96. O que faz pressionar «y» para criar um link permanente e por que não compartilhar a URL atual?

Uma URL normal aponta para uma branch, que muda. Pressionar y troca a branch por um ID de commit, deixando o link estável. Use ao compartilhar código.

97. Os cards ao passar o mouse mostram o que é um link sem abri-lo?

Sim, no GitHub Docs. Passe o mouse ou pressione Alt/Opção + Cima sobre um link para pré-visualizar o artigo; Enter segue, Esc fecha.

98. Como configuro aliases do Copilot CLI e quanto digitação economizam?

Use gh copilot alias para gerar aliases como ghcs para suggest e ghce para explain. Adicione a linha eval gerada ao shell; não escreva alias simples.

99. Quanto é «suficiente»? Que áreas profundas uma pessoa comum pode pular?

Suficiente é guardar trabalho, ler um README, executar um projeto, abrir um PR e publicar uma página. Pode pular internals avançados de Git, Actions complexas e tooling de monorepo.

100. O que o GitHub não resolve e onde uma ferramenta especializada é melhor?

Não é disco na nuvem, editor colaborativo em tempo real, ferramenta de design nem suíte completa de gestão de projetos. Use para trabalho versionado, textual e colaborativo.