Develop Reference

No changes in the Admin or the Api although Migrations are done successfully

I have pushed a Django project to a droplet and migrated my app. Migrations were done successfully. Then, I created a user and all the models appeared in the Admin. Later, I added a property to one of my models locally, then pushed the changes and pulled them on the server. Finally, I made migrations again, but this time the added property, although the changes were migrated successfully, did not appear in the admin or the API. I restarted the server many times, but that did not help.
That's what I got when I ran the following two commands.
python manage.py makemigrations
Migrations for 'courses':
courses/migrations/0002_exam_course_name.py
Add field course_name to exam
command:
python manage.py migrate
Operations to perform:
Apply all migrations: admin, auth, contenttypes, courses, sessions
Running migrations:
Applying courses.0002_exam_course_name... OK

As explained here, I should run:
sudo systemctl restart gunicorn
Every time I make changes to my Django App.

Why should we use three migration commands to migrate our database succesfully?

I was working on models in django and after creating classes for models and when migrating them I was supposed to use three commands for completing migration of models. The commands are :python manage.py migrate,python manage.py makemigrations <app_name>,python manage.py migrate
So my question is that why should we use three commands like this ?

From the django docs,
migrate: which is responsible for applying and unapplying migrations.
makemigrations: which is responsible for creating new
migrations based on the changes you have made to your models.
If you make changes to your model use python manage.py makemigrations followed by python manage.py migrate.
Incase of initial migration just after you create an app you dont need to python manage.py makemigrations but just python manage.py migrate works.

Django migrating app without migrations

I've created a new Django project consisting of a single app. I thought Django would only migrate an app only if its migrations exist.
The first time I run python manage.py migrate, Django would create tables for my app as well(I've created models.py for my app)
I haven't run python manage.py makemigrations app or python manage.py makemigrations till this time.
I would get the following output on running python manage.py migrate:
Synchronizing apps without migrations:
Creating tables...
Creating table app_model
This is not what I want, because the next time I actually make migrations for the app and run migrate, Django would complain that the tables already exist.

You can create the migrations, and fake the first migration:
python manage.py makemigrations <app_name>
python manage.py migrate --fake-initial
This will skip any initial migration for which the tables have already been created.
Django (pre 1.9) will synchronize any apps that don't have migrations, see the docs on migrate:
The behavior of this command changes depending on the arguments provided:
No arguments: All migrated apps have all of their migrations run, and all unmigrated apps are synchronized with the database,

If you want to save migrations for app, wich you already migrate. You can change one field in model, then makemigrations this_app -> migrate and return has been again with makemigrations and migrate. But I dont understand why you want this.

Undo or reset the faked migrations in django

In my project which is based on django-1.8.2 I was facing some problems with migrations so i ran command
python manage.py migrate --fake
But it faked all the migrations which this command is meant for. But now python manage.py migrate command is not doing or applying any migration. I want to undo the faked migrations so that I can apply the migrations to database. I want to apply the existing migrations to the database.

For each app, you can fake the migrations back to where they were before you faked them.
python manage.py migrate --fake myapp 00XX_last_migration
where 00XX_last_migration is the last migration that you actually ran for your app myapp.
Or, if you haven't actually run any migrations for that app yet:
python manage.py migrate --fake myapp zero

From the docs:
be warned that using --fake runs the risk of putting the migration state table into a state where manual recovery will be needed to make migrations run correctly.
So I suggest you to simply remove faked migrations from django_migrations table.

What should I use instead of syncdb in Django 1.9?

Take a look at this:
$ pypy ./manage.py syncdb
/usr/lib64/pypy-2.4.0/site-packages/django/core/management/commands/syncdb.py:24: RemovedInDjango19Warning: The syncdb command will be removed in Django 1.9
warnings.warn("The syncdb command will be removed in Django 1.9", RemovedInDjango19Warning)
(cut)
I ran a quick google search, but could not find the answer - what should I be using instead of syncdb?

syncdb is deprecated because of the migration system, introduced with django 1.7.
Now you can track your changes using makemigrations. This transforms your model changes into python code to make them deployable to another databases. When you have further modifications you need applied to the database, you can use data migrations.
After you created the migrations you have to apply them: migrate.
So instead of using syncdb you should use makemigrations and then migrate.
Workflow on development after you changed something in your models:
./manage.py makemigrations
./manage.py migrate
And on your production system:
./manage.py migrate
Bonus: you do not need to run migrate for each change. If you have multiple changes not applied yet django will run them in the correct order for you.

You should definitely use migration system. Which lets you track changes in your models.py, and create migrations for the database. The migration system uses the commands makemigrations to create migrations and migrate to migrate the database.
If for whatever reason you need to create a database the same way syncdb did it there is command flag that causes migrate to work the same way. You should only do this if you REALLY need it and you know what you are doing. For example to create an empty database on for a continuous integration system of your choice.
python manage.py migrate auth
# performs migrations for auth and contenttypes contrib apps
python manage.py migrate --run-syncdb
# creates the rest of the database
Tested on Django 1.9.1.

You should use the makemigrations and migrate commands that were introduced in django 1.7
https://docs.djangoproject.com/en/1.7/topics/migrations/

syncdb has some problem with db migration. so, after django 1.7 makemigrations and migrate have been introduced.
Now in django 1.9 syncdb has been deprecated.
try
1. python manage.py makemigrations which detects changes in db and creates one .py file as inside migrations folder
2. python manage.py migrate will apply the migrations to the database