Get-good-at-git.md

@@ -120,10 +120,12 @@ Either prefix your commit with :
 
 A commit should be atomic, meaning that 1 commit must contains changes that :
 
-1. Are functionnal. If they are currently not, its ok, everybody does "checkpoints commits" during the development process. But final commits that will be merged in dev/main need to be functionnal. To learn how to modify commits nce you are done developpping, head to [git rebase --interactive](https://gitlab.eclipse.org/groups/eclipse/aidge/-/wikis/Get-good-at-git#-i-1)
+1. Are functionnal : the repo compiles correctly. If they are currently not, its ok, everybody does "checkpoints commits" during the development process. But final commits that will be merged in dev/main need to be functionnal. To learn how to modify commits once you are done developping, head to [git rebase --interactive](https://gitlab.eclipse.org/groups/eclipse/aidge/-/wikis/Get-good-at-git#-i-1).
 2. Can be grouped under 1 common designations (the commit message).
 3. This designation is the shortest common denominator.
 
+> :point_up: to learn more about how to create a clean commit history you can read [this article](https://medium.com/@catalinaturlea/clean-git-history-a-step-by-step-guide-eefc0ad8696d).
+
 > :bulb: **Example :** You created a branch to add the opeator `Foo` in aidge_core. While working, you discovered an issue in another file that is not related to the `Foo` operator, and completed the README with a new . This will result in 3 commits that will be written following the commits conventions explained above :
 >
 > 1. `feat : adding support of operator Foo`
@@ -336,7 +338,7 @@ Here is my current history.
 
 We can see issues here :
 
-1. There are 3 commits about resize : They ould be aggregated in 1. I created 1 "new feature" & 2 "refactors" commits which served as "checkpoints" during my development. But actually a commit informing of a refactor would only be valuable to inform users/devs of a breaking change. In this case, I am the only one who have worked on it as of now. So no need for 3 commits
+1. There are 3 commits about resize : They could be aggregated in 1. I created 1 "new feature" & 2 "refactors" commits which served as "checkpoints" during my development. But actually a commit informing of a refactor would only be valuable to inform users/devs of a breaking change. In this case, I am the only one who have worked on it as of now. So no need for 3 commits
 2. The commit order is not what I would like it to be.
 3. `18630dc` message is not the right one.