How to keep the Django project database and it's contents in sync using GIT

Question

I have setup a git repository and cloned open source code which I am planning on modifying from github to start development. I committed the codebase in our repository. I now have added few users and posts and other "stuff" into database.

I want to commit this change as well so that my teammate can check out and we have same settings and database throughout.

1. Is this possible by using south migrations? ie will database bot contents and schema be in sync as well?
2. I have the project where I am writing the code as well the actual app. Should I commit both of them.
3. What should the github repository look like after doing the "right" thing

Answer 1

Data and database structure

• This is possible using south migrations, data migrations and fixtures.
• The easiest way for development is to just use a SQLite database , which is a binary file that you can commit. The test_project of django-autocomplete-light demonstrates such a possibility: http://django-autocomplete-light.readthedocs.org/en/latest/demo.html
• you must use south anyway !

Apps in the project repo

I think you should keep apps as small and loosely coupled as possible.

If sound, make another repository and python package for the app:

• In some cases it makes sense at the beginning, ie. a "blog" app that you know you will reuse,
• In some cases it makes sense later, ie. you tought your app was really project specific but then you want to reuse it in another project,
• In some cases it never makes sense (ie. the app is only useful to that particular project).

Best practice

As for best practices, there is http://12factor.net , http://lincolnloop.com/django-best-practices/ and pinax projects which are really interresting.

If you're going to reuse and extend external apps, then maybe this article on best practice reusing apps can help.

Answer 2

1. If there is data that every developer needs, these can be provided by initial_fixtures . I have just begun to use south, but I think it is mainly for migrations, (changing your models, without having to delete your data, and resync) not for sharing data. Schema should always be in sync using south, because a developer can pull the south migration, and apply it.