diff --git a/.gitmodules b/.gitmodules
new file mode 100644
index 0000000..6d70186
--- /dev/null
+++ b/.gitmodules
@@ -0,0 +1,3 @@
+[submodule "conclusion"]
+	path = conclusion
+	url = git@github.com:lucianopf/git-workshop-conclusion.git
diff --git a/README.md b/README.md
index 5a646ae..1a7e573 100644
--- a/README.md
+++ b/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)
diff --git a/conclusion b/conclusion
new file mode 160000
index 0000000..bccbd26
--- /dev/null
+++ b/conclusion
@@ -0,0 +1 @@
+Subproject commit bccbd26ceb2ae62f90aa314c7df4be518218fc77
diff --git a/images/lesson_7_1.png b/images/lesson_7_1.png
new file mode 100644
index 0000000..9174d21
Binary files /dev/null and b/images/lesson_7_1.png differ
diff --git a/images/lesson_7_2.png b/images/lesson_7_2.png
new file mode 100644
index 0000000..e3bb1e1
Binary files /dev/null and b/images/lesson_7_2.png differ
diff --git a/images/lesson_7_3.png b/images/lesson_7_3.png
new file mode 100644
index 0000000..a9807f3
Binary files /dev/null and b/images/lesson_7_3.png differ
diff --git a/images/rebase_i_1.png b/images/rebase_i_1.png
new file mode 100644
index 0000000..39ec7f3
Binary files /dev/null and b/images/rebase_i_1.png differ
diff --git a/images/rebase_i_2.png b/images/rebase_i_2.png
new file mode 100644
index 0000000..426b828
Binary files /dev/null and b/images/rebase_i_2.png differ
diff --git a/images/rebase_i_3.png b/images/rebase_i_3.png
new file mode 100644
index 0000000..2728cad
Binary files /dev/null and b/images/rebase_i_3.png differ
diff --git a/images/rebase_i_4.png b/images/rebase_i_4.png
new file mode 100644
index 0000000..c578f40
Binary files /dev/null and b/images/rebase_i_4.png differ
diff --git a/lessons/lesson-10.md b/lessons/lesson-10.md
new file mode 100644
index 0000000..d41cca5
--- /dev/null
+++ b/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.
diff --git a/lessons/lesson-2.md b/lessons/lesson-2.md
new file mode 100644
index 0000000..233c153
--- /dev/null
+++ b/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 --oneline` 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á  `--oneline`
+
+--- 
+
+Podemos seguir para a próxima aula na branch `lesson-3`.
\ No newline at end of file
diff --git a/lessons/lesson-3.md b/lessons/lesson-3.md
new file mode 100644
index 0000000..28fa35d
--- /dev/null
+++ b/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`.
\ No newline at end of file
diff --git a/lessons/lesson-4.md b/lessons/lesson-4.md
new file mode 100644
index 0000000..e847e41
--- /dev/null
+++ b/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 --oneline`, 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 --oneline` 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`.
\ No newline at end of file
diff --git a/lessons/lesson-5.md b/lessons/lesson-5.md
new file mode 100644
index 0000000..319767f
--- /dev/null
+++ b/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`.
\ No newline at end of file
diff --git a/lessons/lesson-6.md b/lessons/lesson-6.md
new file mode 100644
index 0000000..d7e9083
--- /dev/null
+++ b/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 alguns 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`.
\ No newline at end of file
diff --git a/lessons/lesson-7.md b/lessons/lesson-7.md
new file mode 100644
index 0000000..9ee26e2
--- /dev/null
+++ b/lessons/lesson-7.md
@@ -0,0 +1,53 @@
+# Aula 7 (fetch, pull)
+
+Quando trabalhamos em conjunto com outras pessoas, é comum o estado remoto do repositório mude. Então, precisamos atualizar o nosso repositório local com as mudanças do repositório remoto.
+Pra isso podemos usar os comandos `fetch` e `pull`.
+
+**No fim desse arquivo teremos um exercício prático antes de seguir para a próxima aula.**
+
+## Fetch
+
+O comando `fetch` nos permite atualizar o estado local com o estado remoto, sem realizar `merge` ou `rebase` na branch atual.
+Assim como os demais comandos, o `git fetch` também tem suas variações. A que mais utilizo, é a `git fetch --all`, que garante a atualização de todas as referencias entre nosso repositório local e o remoto.
+
+Obs: apesar de não termos abordado até o momento, é possível e bem comum termos mais de um repositório remoto. Por exemplo, o original e o seu `fork`. 
+
+Uso: 
+```bash
+git fetch --all
+```
+
+## Pull
+
+O comando git pull é um atalho para o comando `git fetch` seguido do comando `git merge FETCH_HEAD` que faz o merge da branch atual com a branch remota.
+Esse comando é frequentemente usado pra atualizar o repositório local com as mudanças do repositório remoto especialmente em casos onde temos interações externas com a branch em que voce está trabalhando.
+
+Por exemplo: uma automação fez um commit automático ou algum outro colega adicionou mudanças na branch que você está trabalhando.
+
+Assim como os demais comandos, esse também tem suas variações. A que mais utilizo é a `git pull --rebase`, que faz o `rebase` da `branch` atual com a `branch` remota. (caso não seja passado a flag `rebase` será feito um merge ao invés de rebase).
+
+Obs: se ainda não ficou claro a diferença entre merge e rebase, de uma breve relida na [aula 4](./lesson-4.md).
+
+Documentação mais avançada: https://git-scm.com/docs/git-pull/pt_BR
+
+
+# Prática 7
+
+Como estamos seguindo com o curso de forma individual e não temos ninguém pra fazer alterações no nosso repositório remoto vamos simular uma alteração externa no nosso repositório remoto pela interface do Github.
+No momento temos a branch `lesson-eight` que está com nome incompatível com as demais branches e devemos criar uma nova branch chamada `lesson-8` (dessa vez via interface do Github), fazer um fetch dessa branch e trazer os commits da branch `lesson-eight` para a branch `lesson-8`.
+
+Para isso precisamos fazer o seguinte:
+1. Vamos criar uma nova branch chamada `lesson-8` via interface do Github.
+![passo 1](../images/lesson_7_1.png)
+![passo 2](../images/lesson_7_2.png)
+![passo 3](../images/lesson_7_3.png)
+
+2. Agora que criamos a branch `lesson-8` apenas no repositório remoto precisamos atualizar nossa referencia local pra reconhecer essa nova branch, pra isso vamos executar o comando `git fetch --all` e depois `git branch -a` pra visualizar todas as branches locais e remotas.
+
+3. Agora que temos a branch `lesson-8` no repositório local precisamos trazer os commits da branch `lesson-eight` para a branch `lesson-8`, pra isso vamos executar o comando `git pull --rebase origin lesson-eight` e depois `git log --oneline` pra visualizar os commits.
+
+Obs: O passo 3 também poderia ser feito com `cherry-pick`, mas como estamos seguindo a ordem do curso vamos usar o `pull --rebase` pra trazer os commits da branch `lesson-eight` pra branch `lesson-8`.
+
+--- 
+
+Podemos seguir para a próxima aula na branch `lesson-8`.
\ No newline at end of file
diff --git a/lessons/lesson-8.md b/lessons/lesson-8.md
new file mode 100644
index 0000000..1c53330
--- /dev/null
+++ b/lessons/lesson-8.md
@@ -0,0 +1,34 @@
+# Pula 8 (stash)
+
+Quando estamos trabalhando em uma branch e precisamos mudar de branch, mas ainda não terminamos o que estamos fazendo podemos usar o comando `git stash` pra salvar o estado atual da branch e depois voltar pra ela e continuar o que estávamos fazendo.
+Stash funciona como uma pilha, então podemos salvar o estado atual da branch e depois voltar pra ela e salvar o estado atual novamente e assim por diante.
+
+**No fim desse arquivo teremos um exercício prático antes de seguir para a próxima aula.**
+
+## Stash
+
+Git stash é um conceito de armazenamento temporário de alterações que não foram commitadas ainda.
+Funciona como uma pilha, então podemos salvar o estado atual da branch e depois voltar pra ela e salvar o estado atual novamente e assim por diante.
+
+Para colocar alterações na pilha de stash usamos o comando `git stash` e pra voltar o estado da pilha de stash pra branch usamos o comando `git stash pop`.
+
+Esse é um comando bem comum quando precisamos pausar nosso trabalho corrente por algum motivo pra revisar algo, ajudar alguém ou até mesmo ajustar alguma outra branch e posteriormente podemos retomar o que estávamos fazendo.
+
+Para mais informações sobre stash: https://git-scm.com/docs/git-stash
+
+
+# Prática 8
+
+1. Use o comando `git stash list` para listar o que está na sua stash
+2. Altere o título dessa aula pra `# Aula 8 (stash)`
+3. Use o comando `git stash` e `git stash list` pra listar o que está na sua stash
+4. Altere o fim desse arquivo de `lesson-8` pra `lesson-9`
+5. Use o comando `git stash` e `git stash list` pra listar o que está na sua stash
+6. Repare que o arquivo `lesson-8` não contem suas mudanças e vamos rodar `git stash pop` para desempilhar a ultima alteração
+7. Agora vamos rodar `git stash list` pra ver o que temos na stash
+8. Vamos rodar `git stash pop` pra desempilhar a ultima alteração
+9. Agora com as 2 alterações no arquivo `lesson-8.md` podemos adicionar as alterações com `git add .` e depois `git commit -m "fix: lesson 9 reference"`
+
+--- 
+
+Podemos seguir para a próxima aula na branch `lesson-8`.
\ No newline at end of file
diff --git a/lessons/lesson-9.md b/lessons/lesson-9.md
new file mode 100644
index 0000000..039a1e1
--- /dev/null
+++ b/lessons/lesson-9.md
@@ -0,0 +1,66 @@
+# Aula 9 (submodule)
+
+Eventualmente precisamos trabalhar com repositórios dentro de repositórios, por exemplo, quando temos um projeto que depende de outro projeto.
+Gerenciar multiplos repositórios com dependencias localmente pode ser um pouco trabalhoso, mas o git nos ajuda com isso através do recurso de `submodules`.
+
+**No fim desse arquivo teremos um exercício prático antes de seguir para a próxima aula.**
+
+## Submodule
+
+O comando `git submodule` nos permite adicionar repositórios como dependencias de outros repositórios.
+Na prática isso significa que podemos adicionar a referencia de um repositório dentro de outro repositório e assim podemos trabalhar com os dois repositórios de forma independente porém localmente parecem ser um único repositório.
+
+É importante ressaltar que o repositório adicionado é uma referencia com sua própria árvore de commits e branchs e para gerenciar o estado desse submódulo é necessário entrar no diretório do submódulo e executar os comandos git normalmente.
+
+Na prática iremos explorar um pouco mais afundo o uso de submodules e como gerenciar o estado deles.
+
+Como usar:
+```bash
+git submodule add <url-do-repositório> <caminho-para-o-submódulo>
+```
+
+Documentação mais avançada: https://git-scm.com/docs/git-submodule/pt_BR
+
+# Prática 9
+
+Nessa prática iremos criar um novo submodulo do repositório `lucianopf/git-workshop-conclusion` e manipular esse submodulo conforme nossas necessidades.
+
+Para isso precisamos fazer o seguinte:
+1. Vamos só dar uma conferidinha no outro repo no Github https://github.com/lucianopf/git-workshop-conclusion
+2. Para criar o submódulo vamos executar o comando `git submodule add git@github.com:lucianopf/git-workshop-conclusion.git conclusion`.
+3. Rode o comando `git status` na raiz do seu projeto e dentro do folder `conclusion` e repare a diferença das braches onde na raiz estamos na branch `lesson-9` e no folde conclusion estamos na `main`.
+4. Para análise posterior vamos criar um commit com esse novo submódulo em nossa branch, pra isso basta retornar pra raiz do projeto e executar o comando `git add conclusion` e `git commit -m "feat: add conclusion submodule"`.
+4. Nesse outro repositório temos a branch também chamada `lesson-9-conclusion` mas pra garantir que trouxemos tudo que precisa vamos para dentro da pasta conclusion e usaremos o `git fetch --all` e depois `git checkout lesson-9-conclusion` e podemos perceber que dentro da pasta conclusion agora temos um arquivo chamado `conclusion.md`
+5. Rode o comando `git status` dentro da pasta `conclusion` e vai perceber que não há nada pra ser commitado entretanto volta na raiz e repita o processo e vai perceber que na raiz o resultado é que temos diferenças no folder `conclusion`.
+6. Vamos adicionar essas mudanças e fazer um commit, pra isso basta executar o comando `git add conclusion` e `git commit -m "feat: update conclusion"`.
+7. Vamos dar push na branch `lesson-9` e depois vamos no Github. 
+
+Vamos seguir pra análise do que foi feito no Github e ter uma visão mais completa do processo.
+Vamos para a branch `lesson-9` e vamos ver a ordem dos commits pra conseguir ver o estado do repositório a cada passo executado.
+
+Olhando o repositório partindo do commit `feat: lesson-9` percebemos na estrutra de arquivos que não temos nenhuma referencia a pasta `conclusion` pois nesse momento ainda não adicionamos esse submódulo.
+
+Obs: o `shorthash` representa de forma simplificada o hash do commit que é um identificador único de cada commit apenas considerando os primeiros 7 caracteres.
+
+Ex:
+```text
+8caa822acd321b7ec9939981153a23561b6a3b44 (origin/lesson-eight, lesson-eight) feat: lesson-8
+```
+em shorthash seria:
+```text
+8caa822 (origin/lesson-eight, lesson-eight) feat: lesson-8
+```
+
+Olhando o repositório partindo do commit `feat: add conclusion submodule` podemos ver que agora temos uma pasta chamada `conclusion` que é um pouco diferente das demais e nela existe um shorthash que é a referencia do commit que está sendo referenciado no submodulo naquele momento. 
+Em parelo vamos abrir o repositório https://github.com/lucianopf/git-workshop-conclusion e reparar no last commit da branch `main` que deve ser o mesmo shorthash que temos no nosso repositório.
+
+Olhando o repositório partindo do commit `feat: update conclusion` percebemos que temos algo bem semelhante ao commit anterior só que agora a referencia de um shorhash diferente.
+Vamos na outra aba onde temos aberto o `git-workshop-conclusion` e vamos ver o last commit da branch `lesson-9-conclusion` que deve ser o mesmo shorthash que temos no nosso repositório.
+ 
+Com isso podemos concluir que o submódulo é uma referencia pra um commit de outro repositório e que podemos trabalhar com esses repositórios de forma independente.
+
+--- 
+
+**PARABÉNS PELO TRABALHO, CONCLUÍMOS AS AULAS OFICIAIS DO WORKSHOP!**
+
+Temos uma aulinha extra um pouco mais dedicada a explorar a interface e processos do Github que está na branch `lesson-10`. 
\ No newline at end of file