Adiciona seção sobre GitHub e melhora consistência geral

3-comandos/branch.md

@@ -3,23 +3,25 @@
 Simplificado: _Universo Paralelo_ <br><br>
 Podemos dizer que a branch é um universo ou uma realidade alternativa onde em algum ponto irá se juntar com a realidade principal. Achou esse exemplo estranho? Então deixa eu te mostrar uns exemplos.<br><br>
 Pense em um cenário onde seu time encontra um problema que precisa ser resolvido, porém nem sempre há apenas uma única solução para finalizar essa tarefa, certo? É ai que a branch entra para ajudar nessa organização entre os devs.<br>
-Continuando nesse cenário hipotético, os desenvolvedores irão criar uma nova vertente do código partindo da branch **master** (branch principal gerada a partir do primeiro commit), assim criando a branch implementacao-css.
+Continuando nesse cenário hipotético, os desenvolvedores irão criar uma nova vertente do código partindo da branch **main** (branch principal gerada a partir do primeiro commit; em projetos mais antigos você pode encontrar o nome **master** com o mesmo papel), assim criando a branch implementacao-css.
 
 A tarefa hipotética é: implementar uma regra CSS especifica na nossa index.html.
 
-Porém, antes precisamos criar uma nova branch e para isso iremos usar o comando **git checkout** com o primeiro argumento **-b (branch)** e o segundo sendo o nome da nova branch.
+Porém, antes precisamos criar uma nova branch e para isso iremos usar o comando **git switch** com a flag **-c (create)** seguida do nome da nova branch.
 
 ```
-$ git checkout -b implementacao-css
+$ git switch -c implementacao-css
 Switched to a new branch 'implementacao-css'
 $ git branch
-  master
+  main
 * implementacao-css
 ```
 
+> Em versões mais antigas do Git (ou em tutoriais antigos) você verá o comando equivalente `git checkout -b implementacao-css`. Ele funciona da mesma forma, mas `git switch` foi criado para deixar mais claro que a intenção é apenas trocar de branch (o `checkout` acumula muitas outras funções e pode confundir quem está começando).
+
 ![x](/images/branches1.png)
 
-Podemos ver que agora estamos em um outro universo diferente do principal (master) e toda e qualquer alteração feita nessa nova branch não afetará nenhuma outra dentro do projeto.<br><br>
+Podemos ver que agora estamos em um outro universo diferente do principal (main) e toda e qualquer alteração feita nessa nova branch não afetará nenhuma outra dentro do projeto.<br><br>
 Tá, mas o que eu faço com essa branch? A ideia é você ter liberdade para criar coisas novas sem alterar onde está tudo funcionando (master).<br>
 Vamos fazer algumas alterações no nosso projeto dentro dessa nova branch:
 

3-comandos/cherry-pick.md

@@ -132,3 +132,5 @@ O comando `cherry-pick` pode ser usado em conjunto com outros comandos, conhecid
 
 Sim, existem várias possibilidades de uso do comando `cherry-pick`. Você pode ver mais detalhes sobre o comando `cherry-pick` na [documentação oficial](https://git-scm.com/docs/git-cherry-pick/pt_BR).
 
+Ir para: [4.1 Gitflow - O que é Git Flow](../4-gitflow/o-que-e-gitflow.md)
+

3-comandos/clone.md

@@ -0,0 +1,38 @@
+# Clone
+
+Simplificado: _Baixar uma cópia completa de um repositório_ <br><br>
+Até agora vimos o `git init`, que cria um repositório **novo e vazio**. Mas no dia a dia, o mais comum é você entrar em um projeto que **já existe** - seja no trabalho, em um projeto open source, ou em um repositório que você acabou de dar fork no GitHub.
+
+Para isso usamos o comando **git clone**, passando a URL do repositório:
+
+```bash
+git clone https://github.com/usuario/nome-do-repositorio.git
+```
+
+Isso vai:
+
+1. Criar uma pasta com o nome do repositório;
+2. Baixar todo o histórico de commits, branches e tags;
+3. Configurar automaticamente o repositório remoto chamado `origin`, apontando para a URL clonada (veremos mais sobre isso em [Remote](remote.md)).
+
+Se quiser clonar em uma pasta com outro nome:
+
+```bash
+git clone https://github.com/usuario/nome-do-repositorio.git meu-projeto
+```
+
+## HTTPS vs SSH
+
+Você vai notar que o GitHub oferece duas URLs para clonar:
+
+```bash
+# HTTPS - pede usuário/token (ou abre o navegador) ao fazer push
+git clone https://github.com/usuario/nome-do-repositorio.git
+
+# SSH - usa uma chave configurada na sua máquina, sem pedir senha depois
+git clone git@github.com:usuario/nome-do-repositorio.git
+```
+
+No começo, HTTPS costuma ser mais simples. Conforme você for fazer `push` com frequência, vale configurar uma chave SSH para não precisar autenticar a cada envio.
+
+Ir para: [3.2. Config](config.md)

3-comandos/config.md

@@ -17,4 +17,4 @@ Listando todas as configurações existentes:
 git config --list
 ```
 
-Ir para: [3.3. Commit](commit.md)
+Ir para: [3.3. .gitignore](gitignore.md)

3-comandos/gitignore.md

@@ -0,0 +1,49 @@
+# .gitignore
+
+Simplificado: _Lista de "não me siga"_ <br><br>
+Todo projeto tem arquivos que **não devem** ir para o repositório: senhas, chaves de API, pastas de dependências (`node_modules`, `vendor`), arquivos de build, configurações pessoais do seu editor, logs, etc.
+
+Se você rodar um `git add .` sem cuidado, todos esses arquivos entram no commit e acabam no histórico do projeto - inclusive em repositórios públicos no GitHub, o que pode expor senhas e chaves de acesso.
+
+Para evitar isso, criamos um arquivo chamado **.gitignore** na raiz do projeto, listando o que o Git deve ignorar.
+
+```
+$ touch .gitignore
+```
+
+Dentro dele, cada linha representa um padrão de arquivo ou pasta a ser ignorado:
+
+```gitignore
+# Dependências
+node_modules/
+vendor/
+
+# Variáveis de ambiente e segredos
+.env
+.env.*
+*.pem
+
+# Build
+dist/
+build/
+
+# Logs
+*.log
+
+# Configurações do editor/IDE
+.vscode/
+.idea/
+```
+
+## Pontos importantes
+
+- O `.gitignore` só funciona para arquivos **ainda não rastreados** pelo Git. Se um arquivo já foi commitado antes de entrar no `.gitignore`, ele continuará sendo monitorado - é necessário remover do controle de versão com:
+
+```bash
+git rm --cached caminho/do/arquivo
+```
+
+- Existem modelos prontos de `.gitignore` para praticamente toda linguagem/framework no site [gitignore.io](https://www.toptal.com/developers/gitignore) ou no repositório oficial [github/gitignore](https://github.com/github/gitignore).
+- **Nunca** suba arquivos `.env`, credenciais, tokens ou chaves privadas para o repositório, mesmo que ele seja privado.
+
+Ir para: [3.5. Commit](commit.md)

3-comandos/log.md

@@ -48,4 +48,4 @@ exibir o histórico de uma arquivo em especifico
 git log -- <caminho_do_arquivo>
 ```
 
-Ir para: [4.1 Gitflow -  O que é Git Flow](../4-gitflow/o-que-e-gitflow.md)
+Ir para: [3.17. Stash](stash.md)

3-comandos/merge.md

@@ -2,10 +2,10 @@
 
 Simplificado: _Fusão de duas branches_ <br><br>
 Quando algum desenvolvedor falar de **merge**, quer dizer que houve uma fusão ou junção de códigos em uma única branch. Tá, mas como assim?<br>
-Vamos continuar na nossa situação hipotética dos commits acima, já que temos duas branches nesse repositório. Iremos criar um merge da branch **implementacao-css** para a branch **master**. Em outras palavras, vamos juntar todas as alterações feitas na branch **implementacao-css** dentro da branch **master**, mantendo a nossa master com todo o conteúdo.
+Vamos continuar na nossa situação hipotética dos commits acima, já que temos duas branches nesse repositório. Iremos criar um merge da branch **implementacao-css** para a branch **main**. Em outras palavras, vamos juntar todas as alterações feitas na branch **implementacao-css** dentro da branch **main**, mantendo a nossa main com todo o conteúdo.
 
 ```
-$ git checkout master
+$ git switch main
 $ git merge implementacao-css
 Updating 9b61048..ab4a625
 Fast-forward
@@ -16,6 +16,10 @@ Fast-forward
 
 ![imagem listando as branches](/images/merge1.png)
 
-Podemos ver que a master agora possui as funcionalidades da implementação-css sem precisar mexer em nada relacionado a ela, e em questão de organização você sabe onde e quando foi feito as alterações.
+Podemos ver que a main agora possui as funcionalidades da implementação-css sem precisar mexer em nada relacionado a ela, e em questão de organização você sabe onde e quando foi feito as alterações.
+
+## E se houver conflito?
+
+No exemplo acima o Git conseguiu juntar tudo automaticamente (fast-forward) porque a **main** não tinha recebido nenhum commit novo desde que a branch **implementacao-css** foi criada. Mas se as duas branches alterarem a **mesma linha do mesmo arquivo**, o Git não vai saber qual versão manter e vai te avisar de um **conflito de merge**. Esse é exatamente o tipo de situação que costuma assustar quem está começando — e tem um capítulo dedicado a isso em [Resolvendo conflitos](../5-github/resolvendo-conflitos.md).
 
 Ir para: [3.6. Status](status.md)

3-comandos/pull.md

@@ -0,0 +1,39 @@
+# Pull
+
+Simplificado: _Trazer as novidades do remote para o seu projeto local_ <br><br>
+Enquanto você trabalha, seus colegas também estão commitando e fazendo `push` de alterações. O comando `git pull` serve para **atualizar sua branch local** com tudo que já foi enviado ao remote.
+
+```bash
+git pull origin main
+```
+
+Na prática, `git pull` é a combinação de dois comandos que você já conhece:
+
+```bash
+git fetch origin   # baixa as novidades do remote (sem alterar seus arquivos)
+git merge origin/main  # mescla essas novidades na sua branch atual
+```
+
+Veja [Fetch](fetch.md) para entender melhor a primeira parte.
+
+## Quando rodar `git pull`?
+
+- **Antes de começar a trabalhar**, para garantir que você está partindo do código mais atualizado;
+- **Antes de criar uma branch nova**, para que ela já nasça a partir da versão mais recente da `main`;
+- **Antes de dar `git push`**, caso o remote tenha recebido alterações novas desde a última vez que você sincronizou (veja [Push](push.md)).
+
+## Pull pode gerar conflitos
+
+Como o `pull` faz um `merge` por debaixo dos panos, se você e um colega alteraram a **mesma linha do mesmo arquivo**, o Git vai pedir para você resolver o conflito manualmente antes de continuar. Isso é normal e faz parte do trabalho em equipe - veja o passo a passo em [Resolvendo conflitos](../5-github/resolvendo-conflitos.md).
+
+## git pull --rebase
+
+Uma alternativa ao merge automático do `pull` é pedir para o Git **reaplicar seus commits locais por cima** das novidades baixadas, mantendo o histórico mais linear (sem um commit de merge extra):
+
+```bash
+git pull --rebase origin main
+```
+
+Útil em times que preferem um histórico de commits mais "limpo", mas exige mais atenção ao resolver conflitos (veja [Rebase](rebase.md)).
+
+Ir para: [3.15. Fetch](fetch.md)

3-comandos/push.md

@@ -0,0 +1,47 @@
+# Push
+
+Simplificado: _Enviar seus commits para o repositório remoto_ <br><br>
+Tudo que você faz com `git commit` fica guardado **localmente**, na sua máquina. Para que seu time (ou o GitHub) veja essas alterações, você precisa **enviá-las** para o remote com o comando `git push`.
+
+```bash
+git push origin main
+```
+
+Isso envia os commits da sua branch `main` local para a branch `main` do remote `origin`.
+
+## Primeiro push de uma branch nova
+
+Quando você cria uma branch nova localmente (com `git switch -c minha-feature`) e faz commits nela, essa branch ainda **não existe** no remote. No primeiro push, use `-u` (ou `--set-upstream`) para vincular sua branch local à branch remota:
+
+```bash
+git push -u origin minha-feature
+```
+
+A partir daí, basta `git push` (sem mais nada) que o Git já sabe para onde enviar.
+
+## Erros comuns
+
+### "rejected... (fetch first)" / "non-fast-forward"
+
+```
+! [rejected]        main -> main (fetch first)
+error: failed to push some refs
+```
+
+Isso significa que o remote tem commits que você ainda não tem localmente (alguém do time fez push antes de você). A solução **não é forçar o push**, e sim trazer as alterações primeiro:
+
+```bash
+git pull
+# resolva eventuais conflitos (veja resolvendo-conflitos.md)
+git push
+```
+
+### Nunca use `git push --force` em branches compartilhadas
+
+```bash
+git push --force origin main
+```
+
+Esse comando **sobrescreve o histórico remoto**, podendo apagar commits dos seus colegas sem aviso. Use apenas em branches pessoais (ex: sua própria branch de feature, antes de abrir o Pull Request) e, mesmo assim, prefira `git push --force-with-lease`, que falha caso alguém tenha enviado algo novo que você ainda não viu.
+
+Ir para: [3.14. Pull](pull.md)

3-comandos/remote.md

@@ -0,0 +1,50 @@
+# Remote
+
+Simplificado: _O "endereço" do repositório na nuvem_ <br><br>
+Tudo que vimos até agora aconteceu **apenas na sua máquina**. Mas o Git é um sistema distribuído: o mesmo repositório pode existir em vários lugares - na sua máquina, na do seu colega, e em um servidor compartilhado como GitHub, GitLab ou Bitbucket.
+
+Um **remote** é justamente uma referência para uma dessas outras cópias do repositório. Quando você clona um projeto (veja [Clone](clone.md)), o Git já cria automaticamente um remote chamado `origin`, apontando para a URL de onde você clonou.
+
+## Listando os remotes configurados
+
+```bash
+$ git remote -v
+origin  https://github.com/usuario/nome-do-repositorio.git (fetch)
+origin  https://github.com/usuario/nome-do-repositorio.git (push)
+```
+
+## Adicionando um novo remote
+
+Útil quando você criou o repositório localmente com `git init` e agora quer conectá-lo a um repositório vazio criado no GitHub:
+
+```bash
+git remote add origin https://github.com/usuario/nome-do-repositorio.git
+```
+
+## Trabalhando com forks: origin vs upstream
+
+Uma situação muito comum em times e em projetos open source: você faz um **fork** (sua cópia) de um repositório, clona o **seu fork**, mas também precisa acompanhar as atualizações do repositório **original**. Para isso, é comum adicionar um segundo remote chamado `upstream`:
+
+```bash
+$ git remote -v
+origin    https://github.com/seu-usuario/projeto.git (fetch)
+origin    https://github.com/seu-usuario/projeto.git (push)
+
+$ git remote add upstream https://github.com/dono-original/projeto.git
+$ git remote -v
+origin    https://github.com/seu-usuario/projeto.git (fetch)
+origin    https://github.com/seu-usuario/projeto.git (push)
+upstream  https://github.com/dono-original/projeto.git (fetch)
+upstream  https://github.com/dono-original/projeto.git (push)
+```
+
+Assim você pode usar `git fetch upstream` / `git merge upstream/main` para trazer as novidades do projeto original para o seu fork, sem perder a referência de onde enviar (`push`) as suas próprias alterações (`origin`). Esse fluxo é detalhado em [Fork e Pull Request](../5-github/fork-e-pull-request.md).
+
+## Removendo ou renomeando um remote
+
+```bash
+git remote remove upstream
+git remote rename origin upstream
+```
+
+Ir para: [3.13. Push](push.md)

3-comandos/repositorio.md

@@ -13,4 +13,4 @@ Initialized empty Git repository in ~/git4noobs/.git/
 
 Simples, não é mesmo?!
 
-Ir para: [3.2. Config](config.md)
+Ir para: [3.1.1. Clone](clone.md), uma forma alternativa de iniciar um repositório a partir de um projeto já existente, ou direto para [3.2. Config](config.md)

3-comandos/reset.md

@@ -20,4 +20,4 @@ Com o `--soft` podemos voltar para uma hash de um commit mantendo os arquivos ed
 git reset --soft d60329e
 ```
 
-Ir para: [3.11. Fetch](../3-comandos/fetch.md)
+Ir para: [3.12. Remote](remote.md)

3-comandos/stash.md

@@ -137,4 +137,6 @@ Vamos testar na pratica ainda com a pasta que você criou:
 
 O comando `git stash` pode ser útil em varios casos diversos e definitivamente é uma comando
 poderoso para se ter ciência, vale a pena conferir na [documentação](https://git-scm.com/docs/git-stash) 
-para aprender mais sobre esse comando.
+para aprender mais sobre esse comando.
+
+Ir para: [3.18. Cherry-pick](cherry-pick.md)

3-comandos/status.md

@@ -4,7 +4,7 @@ Um comando simples para saber qual branch você se encontra, quais arquivos fora
 
 ```
 $ git status
-No ramo master
+No ramo main
 Mudanças a serem submetidas:
   (use "git reset HEAD <file>..." to unstage)
 	modified:   main.css

3-comandos/tag.md

@@ -11,23 +11,23 @@ O formato padrão para uma tag é Vx.y.z, sendo:
 
 ## Opções
 
-### Gerar tag non-annontated
+### Gerar tag lightweight (non-annotated)
 
 ```sh
 git tag v1.0.0
 ```
 
-Cria uma tag `non-annontated` **possui** referencia direta ao commmit que ela foi gerada.
+Cria uma tag `lightweight`, que é apenas um **ponteiro/referência direta** para o commit atual, sem nenhuma informação extra (sem autor, data ou mensagem própria).
 
 ---
 
 ### Gerar tag annotated
 
 ```sh
-git tag -a v1.0.0
+git tag -a v1.0.0 -m "Versão 1.0.0"
 ```
 
-Cria uma tag `annotated` **não possui** referencia direta ao commmit que ela foi gerada, possuindo uma mensagem propria.
+Cria uma tag `annotated`, que também aponta para o commit, mas é armazenada como um objeto completo no Git, guardando **mensagem própria, autor e data**. Por isso é a forma recomendada para marcar versões/releases.
 
 ---
 

4-gitflow/padrao-commit.md

@@ -34,4 +34,4 @@ No exemplo abaixo iremos separar o back-end do front-end para entender como melh
 
 Em vez de fazer um único commit com vários arquivos indicando uma única task, você pode fazer algo mais elaborado pra conseguir identificar melhor o que foi está sendo feito.
 
-Ir para: [Conclusão](../conclusao.md)
+Ir para: [5.1 GitHub - O que é o GitHub?](../5-github/o-que-e-github.md)