Desafio da Mi

README.md

@@ -13,12 +13,12 @@ Workshop de git básico e intermediário para pessoas de TI.
 ## Aulas
 
 1. [Aula 1 - fork, clone e trocar de branches](lessons/lesson-1.md)
-2. Aula 2 - comandos básicos de leitura (status, log)
-3. Aula 3 - comandos básicos de escrita (add, diff, commit, push)
-4. Aula 4 - comandos de manipulação de branches (rebase, merge)
-5. Aula 5 - comandos de manipulação de branches (cherry-pick)
-6. Aula 6 - comandos de manipulação de branches (revert)
-7. Aula 7 - comandos de manipulação de branches (fetch, pull)
-8. Aula 8 - comandos de manipulação de branches (stash)
-9. Aula 9 - comandos de manipulação de branches (submodule)
-10. Aula 10 - guia básico sobre interface do Github (aula extra)
+2. [Aula 2 - comandos básicos de leitura (status, log)](lessons/lesson-2.md)
+3. [Pula 3 - comandos básicos de escrita (add, diff, commit, push)](lessons/lesson-3.md)
+4. [Aula 4 - comandos de manipulação de branches (rebase, merge)](lessons/lesson-4.md)
+5. [Aula 5 - comandos de manipulação de branches (cherry-pick)](lessons/lesson-5.md)
+6. [Aula 6 - comandos de manipulação de branches (revert)](lessons/lesson-6.md)
+7. [Aula 7 - comandos de manipulação de branches (fetch, pull)](lessons/lesson-7.md)
+8. [Aula 8 - comandos de manipulação de branches (stash)](lessons/lesson-8.md)
+9. [Aula 9 - comandos de manipulação de branches (submodule)](lessons/lesson-9.md)
+10. [Aula 10 - guia básico sobre interface do Github (aula extra)](lessons/lesson-10.md)

lessons/lesson-10.md

@@ -0,0 +1,29 @@
+# Aula 10 (Github)
+
+Apesar do foco do workshop ser de git e não de Github, é importante entender como a plataforma funciona e como podemos utilizá-la para colaborar com outros desenvolvedores.
+
+**Obs: Ao fim dessa aula temos a última prática do workshop.**
+
+
+Abaixo estão listados alguns links que podem ajudar na compreensão de como interagir com a interface do Github:
+
+## Básico
+- [Criando um novo repositório](https://docs.github.com/pt/repositories/creating-and-managing-repositories/creating-a-new-repository)
+- [Clonando um repositório](https://docs.github.com/pt/repositories/creating-and-managing-repositories/cloning-a-repository)
+- [README](https://docs.github.com/pt/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-readmes) e [CODEOWNERS](https://docs.github.com/pt/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners)
+
+## Intermediário
+- [Lidando com merges](https://docs.github.com/pt/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/about-merge-methods-on-github)
+- [Como criar Pull Requests](https://docs.github.com/pt/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request?tool=webui)
+- [Dicas sobre Pull Requests](https://docs.github.com/pt/pull-requests/collaborating-with-pull-requests/getting-started/best-practices-for-pull-requests)
+- [Como solicitar revisões](https://docs.github.com/pt/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/requesting-a-pull-request-review)
+- [Como realizar as revisões](https://docs.github.com/pt/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests)
+
+Revisão de pull requests é um assunto importante de ser estudado e levado em conta para quem deseja trabalhar de forma colaborativa. É importante ter em mente que o processo de revisão envolve pessoas que não necessariamente contem o mesmo contexto do autor do código, portanto é importante ser claro e objetivo nas mensagens e comentários.
+Existem diversos artigos na internet que tentam auxiliar na construção e revisão de pull requests mas para um breve resumo acredito que [esse guia de de PRs e revisões](https://github.com/mawrkus/pull-request-review-guide?tab=readme-ov-file) seja um bom caminho a ser seguido.
+
+# Prática 10
+
+Agora que concluímos todas aulas do workshop que tal abrir um pull request do seu fork na branch `lesson-10` para o repositório original compartilhando a conclusão com outras pessoas?
+
+Dica: podemos usar o rebase aprendido na aula 4 para trazer as informações da branch `lesson-9` pra branch atual, fazer o push e abrir o PR.

lessons/lesson-2.md

@@ -0,0 +1,27 @@
+# Aula 2 (status, log)
+
+Agora que estamos em uma versão do repositório, local é interessante começar a conseguir visualizar o que temos de informação básica pra consulta.
+
+## Status
+
+De forma geral, esse comando da um resumo do estado atual do repositório, ele mostra se temos arquivos modificados, se temos arquivos novos, se temos arquivos deletados, se temos arquivos prontos para realizar commit, se temos arquivos prontos para serem enviados para o repositório remoto, etc...
+
+Para executar o comando, basta executar `git status`. Como não temos nada modificado no momento, não é esperado ter muita informação como resultado desse comando. Mas, logo logo iremos utiliza-lo bastante pra ajudar a compreender o estado do repositório.
+
+
+## Log
+
+Esse comando é um dos mais importantes do git, ele mostra o histórico de commits do repositório, ele mostra quem fez o commit, quando foi feito, qual foi a mensagem do commit e qual foi o hash do commit.
+
+Para executar o comando basta executar `git log`.
+
+Temos diversas variações desse comando que podemos consultar usando o help `git log --help`.
+
+Atualmente o comando de visualizar logs que mais uso é o `git log --one-line` que traz de forma mais resumida o histórico de commits.
+Temos também o comando `git log --graph` que renderiza no terminal uma representação gráfica do histórico de commits e branches. 
+
+Obs: é possível configurar o padrão do log usando `git config --global format.pretty oneline` e daí em diante qualquer `git log` será  `--one-line`
+
+--- 
+
+Podemos seguir para a próxima aula na branch `lesson-3`.

lessons/lesson-3.md

@@ -0,0 +1,62 @@
+# Aula 2 (add, diff, commit, push)
+
+Nessa aula iremos aprender os comandos básicos de escrita do git, são eles: `add`, `commit` e `push`.
+
+**No fim desse arquivo teremos um exercício prático antes de seguir para a próxima aula.**
+
+## Add
+
+Quando queremos adicionar um arquivo novo ou modificado ao repositório local precisamos usar o comando `add`, esse comando adiciona o arquivo ao que chamamos de `staging area` que é uma área de preparação para o commit.
+Para adicionar o commit basta executar `git add <nome do arquivo>`.
+Existem diversas formas de trabalhar com o add e podemos consultar todas elas usando o help `git add --help`.
+
+Por exemplo:
+  - `git add .`
+  - `git add -A`
+  - `git add --edit <arquivo>`
+
+
+## Diff
+
+Esse comando é usado para visualizar as diferenças entre o `working directory` e o `staging area`, para isso basta executar `git diff`.
+
+De forma geral, usamos muito esse comando pra comparar o estado anterior vs  o que estamos modificando. Para instruções avançadas de como usar o diff, podemos consultar a documentação oficial do git [aqui](https://git-scm.com/book/pt-br/v2/Git-Essencial-Visualizando-Mudan%C3%A7as-no-Repository).
+
+## Commit 
+
+Após usar o comando `add` para adicionar os arquivos que queremos ao `staging area`, precisamos usar o comando `commit` para criar um commit com essas alterações. Conseguimos utilizar o comando `git status`, aprendido na aula anterior, para inclusive conferir quais arquivos estaremos adicionando no commit em questão.
+Um commit é uma forma de agrupar alterações em um ponto específico do tempo, ele é composto por um hash, autor, data, mensagem e um ponteiro para o commit anterior. 
+
+Pra mais informações sobre commits, podemos consultar a documentação oficial o git [aqui](https://git-scm.com/book/pt-br/v2/Git-Essencial-Gravando-Altera%C3%A7%C3%B5es-no-Reposit%C3%B3rio).
+
+A forma mais simples de criar um commit, é utilizando o comando `git commit`. Porém, isso irá abrir um editor de texto integrado no terminal e isso pode num primeiro momento, ser um pouco confuso. para evitar que isso aconteça, podemos usar o comando `git commit -m "mensagem do commit"`, dessa forma o commit será criado com a mensagem que passamos como parâmetro, sem a necessidade de usar o editor integrado.
+
+Assim como os demais comandos, o `git commit` também possui algumas opções que podemos consultar usando o help `git commit --help`.
+
+🔎 **Ao longo do workshop iremos perceber que a mensagem do commit é algo importante e que tentamos sempre seguir padrões. O padrão mais comum é o de commits convencionais, que adotamos nesse workshop, e que pode ser explorado melhor aqui https://www.conventionalcommits.org/pt-br/v1.0.0/#resumo**
+
+
+## Push
+
+O comando `push` é utilizado para enviar os commits criados para o repositório remoto. Para isso, basta executar `git push <remote> <branch>`, por exemplo: `git push origin main`.
+
+Obs: por padrão, quando clonamos um repositório, o nome do remote é `origin`. Podemos consultar isso com o comando `git remote -v`.
+
+# Prática 3
+
+No título dessa aula (lesson-3.md) temos um pequeno erro onde se aponta `# Aula 2 (add, diff, commit, push)` entretanto estamos na aula 3 e devemos corrigir isso.
+
+
+Vamos corrigir esse problema!
+1. Com seu editor de preferencia, abra o arquivo `lessons/lesson-3.md` e corrija o erro de digitação. (`# Aula 3 (add, diff, commit, push)`)
+2. Pra visualizar o status em funcionamento digite `git status`
+3. Veja o diff das alterações usando `git diff` e confira se está alterando o que planeja.
+4. Adicione o arquivo ao `staging area` usando o comando `git add lessons/lesson-3.md`.
+5. Execute o `git diff` e `git status` novamente pra validar que não há mais diferenças entre o `working directory` e o `staging area`.
+6. Crie um commit com a mensagem `feat: fix lesson-3 typo` usando o comando `git commit -m "feat: fix lesson-3 typo"`. Mas para isso, se lembre de adicionar a alteração realizada, com o comando `git add`.
+7. Podemos visualizar o histórico de commits usando o comando `git log` ou `git log --oneline` (eu sempr prefiro o --one-line).
+8. Com as mudanças realizadas localmente, precisamos enviar elas para o repositório remoto. Para isso, basta executar `git push origin lesson-3`.
+
+--- 
+
+Podemos seguir para a próxima aula na branch `lesson-4`.

lessons/lesson-4.md

@@ -0,0 +1,68 @@
+# Aula 4 (rebase, merge)
+
+Nessa aula iremos aprender um pouco mais sobre comandos de manipulação de branches, que são os comandos que nos permitem manipular o histórico do repositório.
+
+Pra entendimento básico sobre esses comandos, precisamos entender primeiro como o git armazena as alterações. O git armazena as alterações como um grafo direcionado acíclico, ou seja, um grafo que não possui ciclos e que possui direção, isso significa que cada commit possui um ponteiro para o commit anterior.
+
+Dado o cenário de trabalho em paralelo, é comum que as branches que utilizamos fiquem desatualizadas. isso acontece porque o git não atualiza as branches automaticamente. Para atualizar uma branch, precisamos usar o comando `git merge` ou `git rebase`.
+
+Esse artigo descreve bem a diferença entre os dois comandos: https://medium.com/@lovepreet013singhhundal/git-merge-vs-git-rebase-d386e1f3cda7
+
+De forma geral, pra visualizar a diferença entre eles, podemos usar o seguinte exemplo:
+
+![merge-rebase](https://miro.medium.com/v2/resize:fit:720/format:webp/1*s9vhZ0Arc0ViAnl9ksy_Ew.png)
+
+No caso do comando `git merge develop`, copiamos com um novo commit as mudança que aconteceram na branch develop, para a branch corrente (no caso feature/login). 
+No caso comando `git rebase develop`, ajustamos o histórico da linha branch e atualizamos a referência de onde a branch corrente se inicia. 
+
+**No fim desse arquivo teremos um exercício prático antes de seguir para a próxima aula.**
+
+## Rebase
+
+O comando git rebase é usado para atualizar o histórico de uma branch, ele é usado para atualizar o histórico de uma branch com base em outra branch.
+
+A sua forma mais comum é `git rebase <branch>`, onde o git irá utilizar o histórico da branch corrente e aplicar as mudanças da branch passada como parâmetro.
+
+O comando rebase também tem algumas variações. A que considero mais importante, seria a `git rebase --interactive <branch>` (ou `git rebase -i <branch>`). Que nos permite manipular o histórico de uma branch de forma interativa, onde podemos escolher quais commits queremos manter, quais queremos editar e quais queremos remover.
+
+Usar o rebase interativo nos permite manipular commits do passado, editar ordem de commits, alterar a mensagem de commits, agrupar diversos commits em um só e até mesmo remover commits.
+
+Exemplo:
+
+![rebase_1](../images/rebase_i_1.png)
+![rebase_1](../images/rebase_i_2.png)
+![rebase_1](../images/rebase_i_3.png)
+![rebase_1](../images/rebase_i_4.png)
+
+[Guia que pode ser útil pra quem quiser se aprofundar no uso de rebase interativo](https://medium.com/@lukz/git-rebase-interactive-e-amend-para-uma-melhor-hist%C3%B3ria-no-seu-projeto-cb2f5c09b161)
+
+## Merge
+
+O comando git merge é utilizado para atualizar o histórico de uma branch, usando como base outra branch.
+O uso dele é bem simples, basta usar o comando `git merge <branch>` e o git irá criar um novo commit com as mudanças da branch passada como parâmetro.
+Apesar de mais simples que o rebase, o merge pode gerar um histórico de commits mais poluído. Isso acontece, pois ele cria um novo commit com as mudanças da branch passada como parâmetro, mais conhecido como `merge commit`.  Por isso para gestão de branches ,eu aconselho o uso do rebase ao invés do merge.
+
+# Prática 4
+
+Obs: é necessário a conclusão da prática 3 para a realização dessa prática.
+
+Na aula passada, tivemos que fazer uma correção no arquivo `lessons/lesson-3.md`. Entretanto, essa branch `lesson-4` em que estamos foi, originada da branch `lesson-3` antes da correção. Portanto, não possui o commit de correção que fizemos. Para realizar a correção,  iremos  atualizar a branch `lesson-4` com as mudanças da branch `lesson-3`, usando o comando `git rebase`.
+
+Para isso, precisamos fazer o seguinte:
+1. Vamos executar inicialmente o comando `git log --one-line`, pra visualizar o estado atual do nosso histórico de commits.
+Fora as hashes diferentes deve estar proximo a esse modelo:
+```text
+(HEAD -> lesson-4) feat: lesson-4
+(lesson-3) feat: lesson-3
+(origin/lesson-2, lesson-2) feat: lesson-2
+(origin/main, origin/HEAD, main) feat: lesson-1
+Initial commit
+```
+2. Pra conseguir atualizar a referencia da branch `lesson-3`, precisamos executar o comando `git rebase lesson-3` ou `git rebase origin/lesson-3`.
+3. Agora podemos executar novamente `git log --one-line` e conferir se agora o commit `feat: fix lesson-3 typo` aparece na `branch lesson-3`, antes da `branch lesson-4`.
+4. Para explorar o rebase interativo, podemos também executar o comando `git rebase -i lesson-3` e fazer o reword do commit `feat: lesson-4` para `feat: lesson-4 (rebase, merge)`. (usar como referencia o exemplo do rebase interativo acima)
+5. Agora que ajustamos as nossas referencias, podemos fazer o `git push origin lesson-4` para enviar as mudanças para o repositório remoto.
+
+--- 
+
+Podemos seguir para a próxima aula na branch `lesson-5`.

lessons/lesson-5.md

@@ -0,0 +1,36 @@
+# Aula 5 (cherry-pick)
+
+Eventualmente precisamos reaproveitar commits de outras branches sem fazer merge ou rebase, só trazendo um commit específico de outra branch. Para isso, temos o comando `cherry-pick`.
+
+Referencia mais avançada: https://git-scm.com/docs/git-cherry-pick
+
+**No fim desse arquivo teremos um exercício prático antes de seguir para a próxima aula.**
+
+## Cherry-pick
+Esse comando nos permite recuperar um commit específico de outra branch e aplicar na branch atual.
+É um comando eventualmente usado quando queremos só trazer algumas poucas mudanças de uma branch.
+
+Por exemplo, quando temos 2 pessoas desenvolvedoras trabalhando em features semelhantes que dependem da mesma base e uma delas termina primeiro, podemos usar o `cherry-pick` para trazer só o commit que cria a base da outra pessoa para a branch atual.
+
+```bash
+git cherry-pick <hash do commit>
+```
+
+Como esse é um comando que manipula o histórico de commits das branches, é importante ter cuidado ao usá-lo. Pois ele pode gerar conflitos que precisam ser resolvidos manualmente assim como rebase e merge.
+
+Doc exemplificando quando isso acontece: https://www.themoderncoder.com/fix-git-cherry-pick-merge-conflicts/
+
+# Prática 5
+
+**Ao fim desse arquivo** temos a instrução errada pra seguir pra `lesson-5`, onde o correto deveria ser `lesson-6`. Vamos buscar a correção disso na branch `lesson-5.1` e trazer para a branch atual usando `cherry-pick`.
+
+1. Vamos primeiro usar o `git log --one-line` pra ver o histórico de commits e vamos perceber que só temos 1 commit nessa branch atual
+2. Iremos pra branch lesson-5.1 usando o comando `git checkout lesson-5.1`
+3. Vamos usar o `git log --one-line` pra ver o histórico de commits e vamos perceber que temos 2 commits a frente da branch `lesson-5` e queremos recuperar o commit `fix: lesson 5 reference` que é o primeiro commit dessa branch.
+4. Vamos copiar o hash do commit `fix: lesson 5 reference` e voltar pra branch `lesson-5` usando o comando `git checkout lesson-5`
+5. Agora vamos usar o comando `git cherry-pick <hash do commit>` pra trazer o commit `fix: lesson 5 reference` pra branch `lesson-5`	
+6. Vamos usar o `git log --one-line` pra ver o histórico de commits e vamos perceber que temos 2 commits e o estado correto da branch `lesson-5` com o `lesson-5.md` apontando pra branch `lesson-6`
+
+--- 
+
+Podemos seguir para a próxima aula na branch `lesson-5`.

lessons/lesson-6.md

@@ -0,0 +1,31 @@
+# Aula 6 (revert)
+
+Eventualmente fazemos mudanças indesejadas, o que é comum. Nesses casos, gostaríamos de realizar um rollback/revert do que foi feito, para voltar ao estado anterior.
+Podemos reescrever tudo como era antes, mas isso pode ser trabalhoso, demorado, ineficiente e muitas vezes ocorrer um outro erro durante esse processo. Então, temos o comando `revert`, que nos permite fazer um rollback de um commit específico.
+
+**No fim desse arquivo teremos um exercício prático antes de seguir para a próxima aula.**
+
+## Revert
+
+Esse comando nos permite fazer um rollback de um commit específico, criando um novo commit que desfaz as mudanças do commit especificado.
+É um comando bem importante especialmente em casos de incidentes e bugs que precisam ser corrigidos rapidamente.
+
+```bash
+git revert <hash do commit>
+```
+
+Obs: nesse caso estamos falando sobre o `git revert` e não o botão Revert do github, que faz um squash de commits e o revert desse commit pra poder fazer o revert de multiplos commits de uma vez.
+
+Referencia mais avançada: https://git-scm.com/docs/git-revert
+
+# Prática 6
+
+No final dessa aula temos a instrução errada pra seguir pra `lesson-6`, mas na verdade deveríamos utilizar `lesson-7`. Vamos reverter a mudança que introduziu esse problema.
+
+1. Vamos primeiro usar o `git log --one-line` pra ver o histórico de commits e vamos perceber que temos 2 commits nessa branch atual
+2. Vamos copiar o hash do commit `chore: lesson 6 reference` e usar o comando `git revert <hash do commit>` pra reverter o commit `chore: lesson 6 reference`
+3. Vamos usar o `git log --one-line` pra ver o histórico de commits e vamos perceber que temos 3 commits e o estado correto da branch `lesson-6` com o `lesson-6.md` apontando pra branch `lesson-7`
+
+--- 
+
+Podemos seguir para a próxima aula na branch `lesson-6`.