How to properly organize development (python git testing virtualenv)?

Question

Python

How right? :
1) First write tests (all cases), commit, push. Then write code, commit, push. Test, change the main code, commit, push. ?
or 2) First write the main code, commit, push. Then, one by one, add tests and test and change the main code after adding a new test. Commit, push after every test addition and every code change. ?
And as I understand it, the master branch should be empty until the package is completely finished, or initially it may contain some code that is not working and partially working, for example, individual modules of the package?
How often to commit and push? If the module is small, more tests than code, is there a difference? Is it worth committing the whole module at once if it is not large?
Does the git only store requirements.txt ?, and update it every time a new dependency is added to the code, or do we do it in one fell swoop at the end of package (module) development?
And classes with unit tests should be stored in the same module as the code or separately and then imported there and run via if __name__ ....?

Answer 1

Read gitflow and TDD with Python and questions will disappear by themselves.
Yes. Otherwise, how will your teammates know that you have updated Junga from 1.6 to 1.10? Will you write to each of them in the chat?
No difference.

Answer 2

tdd flow
Python has https://docs.python.org/3/library/unittest.html - no need to invent bicycles
Before writing a unit test and code, you must have written a functional (acceptance) test for a functional block. That's when this test is green (and all other tests as well), you can merge your commits into the master

$cat requirements.txt
-r requirements/production.txt
psycopg
....

$ cat requirements/dev.txt
-r requirements/base.txt
ipython
....

$ cat requirements/base.txt
Django
....

git flow

spoiler