diff --git a/docs/howto/upgrade-version.txt b/docs/howto/upgrade-version.txt
index 34cb3e65d6..82666d677b 100644
--- a/docs/howto/upgrade-version.txt
+++ b/docs/howto/upgrade-version.txt
@@ -54,7 +54,7 @@ The most convenient way is to use pip_ with the ``--upgrade`` or ``-U`` flag:
 
 .. code-block:: bash
 
-   pip install -U Django
+   $ pip install -U Django
 
 pip_ also automatically uninstalls the previous version of Django.
 
diff --git a/docs/internals/contributing/writing-code/unit-tests.txt b/docs/internals/contributing/writing-code/unit-tests.txt
index 3690264875..d6a031b3ae 100644
--- a/docs/internals/contributing/writing-code/unit-tests.txt
+++ b/docs/internals/contributing/writing-code/unit-tests.txt
@@ -30,15 +30,17 @@ sample settings module that uses the SQLite database. To run the tests:
 
 .. code-block:: bash
 
-    git clone git@github.com:django/django.git django-repo
-    cd django-repo/tests
-    PYTHONPATH=..:$PYTHONPATH ./runtests.py
+   $ git clone git@github.com:django/django.git django-repo
+   $ cd django-repo/tests
+   $ PYTHONPATH=..:$PYTHONPATH ./runtests.py
 
 .. versionchanged:: 1.7
 
-Older versions of Django required specifying a settings file::
+Older versions of Django required specifying a settings file:
 
-    PYTHONPATH=..:$PYTHONPATH python ./runtests.py --settings=test_sqlite
+.. code-block:: bash
+
+   $ PYTHONPATH=..:$PYTHONPATH python ./runtests.py --settings=test_sqlite
 
 ``runtests.py`` now uses ``test_sqlite`` by default if settings aren't provided
 through either ``--settings`` or :envvar:`DJANGO_SETTINGS_MODULE`.
@@ -111,7 +113,7 @@ internationalization, type:
 
 .. code-block:: bash
 
-    ./runtests.py --settings=path.to.settings generic_relations i18n
+   $ ./runtests.py --settings=path.to.settings generic_relations i18n
 
 How do you find out the names of individual tests? Look in ``tests/`` — each
 directory name there is the name of a test. Contrib app names are also valid
@@ -123,13 +125,13 @@ of the ``i18n`` module, type:
 
 .. code-block:: bash
 
-    ./runtests.py --settings=path.to.settings i18n.tests.TranslationTests
+   $ ./runtests.py --settings=path.to.settings i18n.tests.TranslationTests
 
 Going beyond that, you can specify an individual test method like this:
 
 .. code-block:: bash
 
-    ./runtests.py --settings=path.to.settings i18n.tests.TranslationTests.test_lazy_objects
+   $ ./runtests.py --settings=path.to.settings i18n.tests.TranslationTests.test_lazy_objects
 
 Running the Selenium tests
 ~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -141,7 +143,7 @@ the tests with the ``--selenium`` option:
 
 .. code-block:: bash
 
-    ./runtests.py --settings=test_sqlite --selenium admin_inlines
+   $ ./runtests.py --settings=test_sqlite --selenium admin_inlines
 
 
 .. _running-unit-tests-dependencies:
@@ -165,9 +167,11 @@ dependencies:
 
 You can find these dependencies in `pip requirements files`_ inside the
 ``tests/requirements`` directory of the Django source tree and install them
-like so::
+like so:
 
-    pip install -r tests/requirements/py2.txt  # Python 3: py3.txt
+.. code-block:: bash
+
+   $ pip install -r tests/requirements/py2.txt  # Python 3: py3.txt
 
 You can also install the database adapter(s) of your choice using
 ``oracle.txt``, ``mysql.txt``, or ``postgres.txt``.
@@ -200,13 +204,17 @@ Contributors are encouraged to run coverage on the test suite to identify areas
 that need additional tests. The coverage tool installation and use is described
 in :ref:`testing code coverage<topics-testing-code-coverage>`.
 
-To run coverage on the Django test suite using the standard test settings::
+To run coverage on the Django test suite using the standard test settings:
 
-    coverage run ./runtests.py --settings=test_sqlite
+.. code-block:: bash
 
-After running coverage, generate the html report by running::
+   $ coverage run ./runtests.py --settings=test_sqlite
 
-    coverage html
+After running coverage, generate the html report by running:
+
+.. code-block:: bash
+
+   $ coverage html
 
 When running coverage for the Django tests, the included ``.coveragerc``
 settings file  defines ``coverage_html`` as the output directory for the report
@@ -225,6 +233,8 @@ multiple modules by using a ``tests`` directory in the normal Python way.
 If you have URLs that need to be mapped, put them in ``tests/urls.py``.
 
 To run tests for just one contrib app (e.g. ``auth``), use the same
-method as above::
+method as above:
 
-    ./runtests.py --settings=settings django.contrib.auth
+.. code-block:: bash
+
+   $ ./runtests.py --settings=settings django.contrib.auth
diff --git a/docs/intro/tutorial01.txt b/docs/intro/tutorial01.txt
index d8e62a70ed..e8b6fc10e0 100644
--- a/docs/intro/tutorial01.txt
+++ b/docs/intro/tutorial01.txt
@@ -17,7 +17,7 @@ tell Django is installed and which version by running the following command:
 
 .. code-block:: bash
 
-    python -c "import django; print(django.get_version())"
+    $ python -c "import django; print(django.get_version())"
 
 If Django is installed, you should see the version of your installation. If it
 isn't, you'll get an error telling "No module named django".
@@ -55,7 +55,7 @@ code, then run the following command:
 
 .. code-block:: bash
 
-   django-admin.py startproject mysite
+   $ django-admin.py startproject mysite
 
 This will create a ``mysite`` directory in your current directory. If it didn't
 work, see :ref:`troubleshooting-django-admin-py`.
@@ -131,8 +131,13 @@ The development server
 ----------------------
 
 Let's verify this worked. Change into the outer :file:`mysite` directory, if
-you haven't already, and run the command ``python manage.py runserver``. You'll
-see the following output on the command line:
+you haven't already, and run the command:
+
+.. code-block:: bash
+
+   $ python manage.py runserver
+
+You'll see the following output on the command line:
 
 .. parsed-literal::
 
@@ -568,9 +573,11 @@ make new ones - it specialises in upgrading your database live, without
 losing data. We'll cover them in more depth in a later part of the tutorial,
 but for now, remember the three-step guide to making model changes:
 
-* Change your models (in models.py)
-* Run ``python manage.py makemigrations`` to create migrations for those changes
-* Run ``python manage.py migrate`` to apply those changes to the database.
+* Change your models (in ``models.py``).
+* Run :djadmin:`python manage.py makemigrations <makemigrations>` to create
+  migrations for those changes
+* Run :djadmin:`python manage.py migrate <migrate>` to apply those changes to
+  the database.
 
 The reason there's separate commands to make and apply migrations is because
 you'll commit migrations to your version control system and ship them with
diff --git a/docs/intro/tutorial02.txt b/docs/intro/tutorial02.txt
index b703200428..11c0bece6b 100644
--- a/docs/intro/tutorial02.txt
+++ b/docs/intro/tutorial02.txt
@@ -469,7 +469,7 @@ template directory in the source code of Django itself
 
     .. code-block:: bash
 
-        python -c "
+        $ python -c "
         import sys
         sys.path = sys.path[1:]
         import django
diff --git a/docs/ref/django-admin.txt b/docs/ref/django-admin.txt
index cac7a5bc22..9a458152c9 100644
--- a/docs/ref/django-admin.txt
+++ b/docs/ref/django-admin.txt
@@ -38,8 +38,8 @@ Usage
 
 .. code-block:: bash
 
-    django-admin.py <command> [options]
-    manage.py <command> [options]
+    $ django-admin.py <command> [options]
+    $ manage.py <command> [options]
 
 ``command`` should be one of the commands listed in this document.
 ``options``, which is optional, should be zero or more of the options available