📝 Added git forking flow for development

README.md

@@ -108,10 +108,42 @@ However, when developing, the easiest way is to use the provided Jupyter Lab con
 2. Set up locally
 3. Test your changes with `pytest`
 4. Submit a PR. The PR should contain the following:
-- new/changed functionality
-- tests for the changes
-- changes added to `CHANGELOG.md`
-- any other relevant resources updated (esp. `viadot/docs`)
+    - new/changed functionality
+    - tests for the changes
+    - changes added to `CHANGELOG.md`
+    - any other relevant resources updated (esp. `viadot/docs`)
+
+The general flow of working for this repository in case of forking:
+1. Pull before making any changes
+2. Create a new branch with 
+```
+git checkout -b <name>
+```
+3. Make some work on repository
+4. Stage changes with 
+```
+git add <files>
+```
+5. Commit the changes with 
+```
+git commit -m <message>
+``` 
+__Note__: See out Style Guidelines for more information about commit messages and PR names
+
+6. Fetch and pull the changes that could happen while working with 
+```
+git fetch <remote> <branch>
+git checkout <remote>/<branch>
+```
+7. Push your changes on repostory using 
+```
+git push origin <name>
+```
+8. Use merge to finish your push to repository 
+```
+git checkout <where_merging_to>
+git merge <branch_to_merge>
+```
 
 Please follow the standards and best practices used within the library (eg. when adding tasks, see how other tasks are constructed, etc.). For any questions, please reach out to us here on GitHub.