Pular para conteúdo

Exercícios da Aula 13

🛠 Trabalho em Equipe: Colaboração Profissional

Nível: Básico

  1. Convidando o Time:

    • Vá até as configurações (Settings) do seu repositório de portfólio.
    • Localize a aba "Collaborators" e adicione um colega ou uma conta secundária. Qual o e-mail ou usuário que você convidou?

  2. Verificando Permissões:

    • Pesquise no GitHub Docs qual a diferença prática entre as permissões de "Read" e "Write". O que um colaborador com acesso "Read" não consegue fazer em relação ao código-fonte?

Nível: Intermediário

  1. Sincronização Forçada (Pull):

    • Simule uma alteração feita por um colega: vá no GitHub e edite o seu README direto no navegador. Commite a mudança lá.
    • Agora, tente fazer uma alteração local no mesmo README e tente dar um push. Explique por que o Git rejeitou o seu envio e qual o comando você usou para resolver.

  2. Colaborador vs Contribuidor:

    • Se você encontrar um bug em um projeto famoso (como o VS Code), você conseguirá dar git push direto para o repositório deles? Por que?

Nível: Desafio

  1. Simulando o Fluxo de Time:
    • Crie uma Issue no repositório.
    • Atribua essa Issue ao seu colaborador.
    • O colaborador deve criar uma branch, resolver a Issue e abrir um PR.
    • Você deve revisar o código e realizar o Merge. Descreva brevemente como foi a experiência de ver o código de outra pessoa entrando no seu projeto.

---

📚 Gabarito e Solução Comentada

Gabarito Explicado ### 1. Convidando o Time Resposta prática. O colaborador convidado deve aceitar o convite (via e-mail ou notificação no GitHub) para ter acesso de escrita ao projeto. ### 2. Verificando Permissões Um colaborador com acesso **Read** consegue ver o código, baixar o repositório e abrir issues, mas **não consegue dar push** diretamente para nenhuma branch. Ele precisaria fazer um Fork para contribuir. ### 3. Sincronização Forçada (Pull) O Git rejeita o envio porque o histórico local e remoto divergem (o remoto tem commits que o local não tem). É o erro de **non-fast-forward**. **Solução**: 
git pull origin main
Após baixar as mudanças e resolver possíveis conflitos, o `push` será aceito. ### 4. Colaborador vs Contribuidor Não, você não conseguirá dar `push` direto porque não é um **Colaborador** oficial (não tem permissão de escrita). Para contribuir, você deve agir como **Contribuidor**: fazer um Fork, alterar no seu repositório e enviar um Pull Request. ### 5. Simulando o Fluxo de Time Resposta reflexiva. A experiência de Pull Request e Merge é a base de como times de engenharia de software operam no mundo real, garantindo qualidade através do Code Review.