[IMP] odoo_sh: improve spelling

Yenthe666 · beledouxdenis · commit 20d242ef7917 · 2018-03-29T10:49:27.000+02:00
diff --git a/odoo_sh/getting_started/branches.rst b/odoo_sh/getting_started/branches.rst
@@ -74,14 +74,14 @@ After that, they can be garbage collected automatically.
 If you make configuration changes or view changes in these branches, make sure to document them or write them directly
 in the modules of the branch, using XML data files overriding the default configuration or views.
 
-The unit tests are not performed as, in Odoo, they currently relies on the demo data, which are not loaded in the
+The unit tests are not performed as, in Odoo, they currently rely on the demo data, which is not loaded in the
 production database. In the future, if Odoo supports to run the unit tests without the demo data,
 Odoo.sh will then consider running the tests on staging databases.
 
 
 Development
 -----------
-Development branches creates new databases using the demo data and running the unit tests.
+Development branches create new databases using the demo data and to run the unit tests.
 The modules installed and tested by default are the ones included in your branches.
 You can change this list of modules to install in your projects settings.
 
@@ -121,7 +121,7 @@ It just means you skip the validation of your changes with the production data t
 You can merge your development branches into each other, and your staging branches into each other.
 
 Of course, you can also use :code:`git merge` directly to merge your branches.
-Odoo.sh will be notified new revisions have been pushed in your branches.
+Odoo.sh will be notified when new revisions have been pushed in your branches.
 
 Merging a staging branch in the production branch only merges the source code: Any configuration changes you made in the
 staging databases are not passed to the production database.
@@ -132,7 +132,7 @@ If you test configuration changes in staging branches, and want them to be appli
   overriding the default configuration or views in your branches,
   and then increase the version of your module in its manifest (*__manifest__.py*) to trigger the update of the module
   when you merge your staging branch in your production branch.
-  This is the best practice for a better scalability of your developments as you will use the Git versionning features
+  This is the best practice for a better scalability of your developments as you will use the Git versioning features
   for all your configuration changes, and therefore have a traceability for your changes.
 * pass them manually from your staging to your production database, by copy/pasting them.
 
