New Git page

source/coding/git.rst

@@ -32,7 +32,7 @@ The goal will be to work on your computer and save your changes to **your** fork
 
 By default all repositories have a main version of the code (a branch called *master* or *main*). When you are exploring new pieces of code, fixing bugs or tinkering in general you should always create a branch first (with a meaningful name) to avoid messing up your main branch with your tests :bash:`git checkout -b my_branch`. Your main branch in **your** fork should always stay the same as the main branch in the **upstream**. A good practice is to never use :bash:`git add` or :bash:`git commit` in your main branch: only :bash:`git pull upstream master` (or main).
 
-If your modifications are useful, and you want to keep it safe, you should commit and push them. If your modifications of one branch of your own fork to be added to the real scilpy repository (upstream)could be useful to everyone and you want to share them with the rest of the world [2]_, you should consider doing a *pull request*. Only when everything is clean and tested, in the Github web interface, you can start an official pull request that will be reviewed by other members of the lab.
+If your modifications are useful, and you want to keep it safe, you should commit and push them. If your modifications of one branch of your own fork to be added to the real scilpy repository (upstream) could be useful to everyone and you want to share them with the rest of the world [2]_, you should consider doing a *pull request*. Only when everything is clean and tested, in the Github web interface, you can start an official pull request that will be reviewed by other members of the lab.
 
 When that branch is accepted and merged to the master branch of the upstream, then if you update **your** own master branch of **your** fork (:bash:`git pull upstream master`), you will see the changes. You will then be able to delete safely your branch in your fork (:bash:`git branch -d my_test_branch`).