Git-Workflow.md

@@ -54,7 +54,7 @@ git commit
 ```
 
 - Frequently `git pull` and `git rebase main` to keep aligned to the main branch.
-- You might also want to [push](https://devconnected.com/how-to-push-git-branch-to-remote/) your development branch to the gitlab repository, to be sure it's always accessible and progess doesn't get lost.
+- You might also want to [push](https://devconnected.com/how-to-push-git-branch-to-remote/) your development branch to the gitlab repository, to be sure it's always accessible and progress doesn't get lost.
 
 ### Merge Requests
 
@@ -64,14 +64,14 @@ Once you deem the code ready, it's time to **merge** it:
   * If it's not, `git pull && git rebase main`
 * Create a [merge request](https://git.skywarder.eu/avn/swd/skyward-boardcore/-/merge_requests/new) to merge the branch back into the main branch
   * Set someone (if in doubt, the current IPTL) as reviewer
-  * Cite the relevent issue(s) number in the MR description, if there's any
+  * Cite the relevant issue(s) number in the MR description, if there's any
   * Mark the MR as `Draft` if it's not quite ready yet (e.g you want someone to review your code but you still have to run some additional tests before merging)
 * If some **issues** are open in the merge request, you will need to **solve** all of them before obtaining the approval from the reviewer.
-* In case you find an issue regarding a whole other topic while developing your feature, it's better if you evelop it separately (another branch & another MR) and mark your MR as draft , so that it doesn't get merged until the issue is fixed
+* In case you find an issue regarding a whole other topic while developing your feature, it's better if you develop it separately (another branch & another MR) and mark your MR as draft , so that it doesn't get merged until the issue is fixed
 * Temporary branches should be as "atomic" as possible. This means that the only connection that they have should be the main branch and **NOT** other temporary branches.
 * Once the code is ready and the reviewer likes it, contact your IPTL to approve the merge request.
 * Finally, you should clean up the git history: 99% of the times, what you want is to squash all commits (i.e. all your commit end up in a single commit).
-  * If this is not the case, you still need to make sure the git history is clean (minimal number of commits), i.e. no commit fixing up the commit before, no `commit #1: start doing this`, `commit #2: continued doing this`, ecc
+  * If this is not the case, you still need to make sure the git history is clean (minimal number of commits), i.e. no commit fixing up the commit before, no `commit #1: start doing this`, `commit #2: continued doing this`, etc.
 
 ## Commits
 
@@ -120,7 +120,7 @@ Some simple rules:
 Sometimes to fix some mistakes in temporary branches or to simply squash some intermediate commits you will need to interactively rebase the branch. To do so, you just need to execute a simple command:
 
 ```
-git rebase -i "hash of the commit you whant to start from"
+git rebase -i "hash of the commit you want to start from"
 ```
 
 After this command, you will be prompted with a terminal editor with all the commits starting from the one you selected.