Exercícios: Git e GitHub

Estes exercícios repetem o fluxo que fizemos juntos nas aulas anteriores. Se travar em algum comando, veja os slides da aula.

Parte 1: Fluxo local (`init`, `add`, `commit`, `log`)

Crie uma pasta chamada meu-portfolio e, dentro dela, um arquivo index.html com uma página simples sobre você (nome, uma frase de apresentação, um link para uma rede social ou site que você goste).
Abra o Git Bash dentro da pasta e transforme-a em um repositório:
```
git init
```
Confira com git status: o arquivo deve aparecer como Untracked.
Adicione o arquivo à staging area e confira o status de novo:
```
git add index.html
git status
```
Repare na diferença: agora ele aparece em “Changes to be committed”.
Faça seu primeiro commit, com uma mensagem que descreva o que você fez:
```
git commit -m "Primeira versão da página"
```
Abra o index.html de novo e adicione uma nova seção (por exemplo, uma lista com 3 coisas que você quer aprender). Salve o arquivo.
Rode git status de novo antes de dar add. O que o Git diz sobre o index.html agora? Escreva a resposta em um comentário no próprio arquivo.
Adicione e faça um segundo commit, com uma mensagem diferente da primeira.
Rode git log e confira: você deve ver os dois commits, cada um com autor, data e mensagem.
Desafio: tente rodar git commit -m "teste" sem antes rodar git add em cima de uma alteração nova. O que acontece? Anote a mensagem de erro/aviso que o Git mostra: ela te diz exatamente o que fazer.

Parte 2: Publicando no GitHub

Crie uma conta no GitHub (se ainda não tiver uma).
Crie um repositório novo chamado meu-portfolio, sem marcar nenhuma opção de inicialização (sem README, sem .gitignore).
Conecte seu repositório local ao repositório remoto (troque seu-usuario pelo seu usuário do GitHub):
```
git remote add origin https://github.com/seu-usuario/meu-portfolio.git
```
Envie seus commits:
```
git push -u origin main
```
Se uma janela do navegador abrir pedindo login, é o Git Credential Manager: faça login normalmente.
Acesse a página do repositório no navegador e confirme que os dois commits que você fez na Parte 1 aparecem lá, com o histórico completo.
Faça mais uma alteração pequena no index.html (ex: mude a frase de apresentação), e repita o ciclo completo sozinho:
```
git add index.html
git commit -m "sua mensagem aqui"
git push
```
Repare que, depois do primeiro push -u, um git push simples já basta.
Crie um arquivo README.md na raiz do seu projeto, com uma breve descrição em texto do que é essa página (2-3 frases). Adicione, comite e envie para o GitHub. Atualize a página do repositório no navegador: o conteúdo do README deve aparecer automaticamente embaixo da lista de arquivos.

Parte 3: Trabalho em dupla, colaborando em um repositório

Até agora vocês trabalharam sozinhos, do zero (git init). Mas o mais comum no dia a dia é o repositório já existir, criado por outra pessoa, e vocês entrarem nele com git clone. Este exercício simula isso, incluindo o momento mais chato (e mais importante de saber resolver): o conflito de merge.

Formem duplas. Decidam quem vai ser a Pessoa A (dona do repositório) e quem vai ser a Pessoa B (colaboradora). Troquem os usuários do GitHub um com o outro antes de começar.

3.1. Criando e dando permissão (Pessoa A)

Pessoa A cria um repositório novo no GitHub chamado duo-git-nomedasduplas, desta vez marcando a opção “Add a README file” (para o repositório já nascer com um commit).
Pessoa A vai em Settings → Collaborators → Add people e adiciona o usuário do GitHub da Pessoa B.
Pessoa B verifica as notificações do GitHub (sininho no canto superior, ou o e-mail) e aceita o convite para colaborar no repositório.

3.2. Clonando e alternando commits (A e B)

Ambos clonam o repositório na própria máquina, em pastas separadas:
```
git clone https://github.com/pessoa-a/duo-git-nomedasduplas.git
```
Repare que, diferente da Parte 1, vocês não precisaram de git init nem de git remote add origin: o clone já cuidou disso.
Pessoa A cria um arquivo sobre-a.md com uma frase sobre si, e faz commit + push:
```
git add sobre-a.md
git commit -m "Adiciona sobre-a.md"
git push
```
Pessoa B traz essa alteração para a própria máquina com:
```
git pull
```
git pull é o oposto do push: traz para o seu computador os commits que já estão no GitHub e que você ainda não tem. Confirme que o arquivo sobre-a.md apareceu na sua pasta.
Pessoa B cria seu próprio arquivo sobre-b.md, e faz commit + push (mesma sequência do passo 21).
Pessoa A dá git pull e confirma que sobre-b.md apareceu.
Ambos rodam git log. Vocês devem ver os commits alternados, cada um com o nome do autor correto: essa é a evidência de que duas pessoas diferentes contribuíram para o mesmo histórico.

3.3. Simulando um conflito (A e B)

Um conflito acontece quando duas pessoas alteram a mesma linha do mesmo arquivo sem que uma tenha pego (pull) a alteração da outra antes. Vamos forçar isso de propósito:

Sem conversar sobre o que vão escrever, tanto Pessoa A quanto Pessoa B abrem o README.md (o que já veio pronto do repositório) e editam a mesma linha, por exemplo a primeira linha do arquivo (o título). Cada um escreve algo diferente ali. Nenhum dos dois dá pull antes disso.
Pessoa A salva, comita e dá push primeiro:
```
git add README.md
git commit -m "Altera o título do README"
git push
```
Isso deve funcionar normalmente, já que A foi mais rápido.
Pessoa B salva, comita, e tenta dar push:
```
git add README.md
git commit -m "Altera o título do README"
git push
```
Isso vai falhar: o Git recusa porque existem commits no GitHub que a Pessoa B ainda não tem localmente. A mensagem sugere rodar git pull primeiro.
Pessoa B roda git pull. Desta vez, como as duas pessoas alteraram a mesma linha, o Git não consegue decidir sozinho qual versão manter: isso é o conflito. O terminal avisa CONFLICT (content), e o README.md fica assim:
```
<<<<<<< HEAD
(a versão que a Pessoa B escreveu)
=======
(a versão que a Pessoa A escreveu)
>>>>>>> origin/main
```
Pessoa B abre o README.md num editor e resolve o conflito manualmente: decide, conversando com a Pessoa A, o que vai ficar na linha final (pode ser a versão de A, a de B, ou uma mistura das duas) e apaga os marcadores <<<<<<<, ======= e >>>>>>> junto com o que não for aproveitado.

Depois de resolvido, Pessoa B finaliza o merge:

git add README.md
git commit -m "Resolve conflito no título do README"
git push

Pessoa A dá git pull uma última vez e confirma que recebeu a versão final, já resolvida.

3.4. Reflexão

Juntos, criem um arquivo reflexao.md respondendo, em poucas frases:
- O que exatamente causou o conflito?
- Como vocês decidiram qual versão manter?
- Se isso acontecesse num projeto real com várias pessoas mexendo no mesmo arquivo o tempo todo, o que vocês fariam diferente para evitar conflitos?
Um dos dois faz o commit e push desse arquivo.

Entrega

No Moodle, cole os dois links no campo de texto da tarefa (cada pessoa envia os dois, mesmo o repositório da dupla sendo compartilhado: é a confirmação de que você participou):

Link do repositório individual (meu-portfolio)
Link do repositório da dupla (duo-git-nomedasduplas)

Confira antes de enviar:

Repositório individual: pelo menos 3 commits, README aparece na página inicial
Repositório da dupla: histórico mostra os dois nomes de autor alternados
Repositório da dupla: existe pelo menos um commit com a mensagem “Resolve conflito…” (ou parecida)
Repositório da dupla: o README.md não tem nenhum marcador de conflito (<<<<<<<, =======, >>>>>>>) esquecido
Repositório da dupla: o reflexao.md está presente