Вопрос: Как сделать отдельный .gitignore для деплоя на Heroku?

Лучший ответ: С некоторых пор Heroku поддерживает сабмодули Git, что позволяет разделить непосредственно код приложения и файлы, необходимые исключительно для деплоя на Heroku. Тогда первый репозиторий можно хранить на гитхабе, а второй — хостить внутри Heroku, где к нему не будет ни у кого доступа.
Например, я использовал примерно такую структуру репозитория для деплоя Django-приложения (уверен, нечто подобное можно придумать и для RoR):django-application-heroku   ┊ ← Рабочая копия репозитория для Heroku.
│                           ┊
├── project                 ┊ ← Сабмодуль с кодом, указывающий на GH.
│   ├── django_application  ┊ ← Непосредственно код и данные самого
│   │   ├── locale/         ┊   приложения, которые ничего знать не
│   │   ├── migrations/     ┊   знают о Heroku. Структура файлов и
│   │   ├── templates/      ┊   каталогов, обычная для Django-проекта.
│   │   ├── admin.py        ┊
│   │   ├── apps.py         ┊
│   │   ├── models.py       ┊
│   │   ├── urls.py         ┊
│   │   ├── views.py        ┊
│   │   └── (...)           ┊
│   │                       ┊
│   ├── django_project      ┊
│   │   ├── settings.py     ┊ ← Базовая часть конфигурации, неизменная
│   │   ├── urls.py         ┊   при любом способе деплоя.
│   │   ├── wsgi.py         ┊
│   │   └── (...)           ┊
│   │                       ┊
│   ├── manage.py           ┊ ← Раннер и конфиг с закреплёнными версиями,
│   └── requirements.txt    ┊   используемые на машинах разработчиков.
│        	            ┊
├── bin                     ┊
│   └── post_compile        ┊ ← Вспомогательный скрипт, который сам
│        	            ┊   запускает миграции БД при успешном деплое
│                           ┊   на Heroku.
│        	            ┊
├── manage.py               ┊ ← Такой же раннер, что и в рабочем репозитории,
│        	            ┊   но использует heroku-settings.py в качестве
│        	            ┊   конфигурации приложения вместо settings.py.
├── requirements.txt        ┊ ← Закреплённые версии специально для Heroku.
│        	            ┊   Тот же набор, что и в рабочем репозитории,
│        	            ┊   плюс дополнительно пакеты gunicorn,
│        	            ┊   dj-database-url и WhiteNoise.
├── heroku_settings.py      ┊ ← Конфигурация приложения специально
│        	            ┊   для Heroku. Например, приводит DATABASE_URL
│        	            ┊   к формату, понятному Django.
├── heroku_wsgi.py          ┊ ← То же, что и wsgi.py, но с конфигом Heroku.
├── Procfile                ┊ ← Запускает gunicorn с нужными параметрами.
└── runtime.txt             ┊ ← Используемый рантайм.
Конечно, данный подход не лишён недостатков (наиболее серьёзный из которых — приходится поддерживать набор практически одинаковых файлов manage.py, requirements.txt, wgsi.py), однако он позволяет:избавиться от мешанины разрозненных файлов в корне репозитория(какая религия помещала разработчикам Heroku искать эти файлы в отдельном подкаталоге, а не корне проекта?);эффективно разграничить разработку и деплой.

Худший ответ: Воспользоваться переменными окружения https://devcenter.heroku.com/articles/config-varscd myapp
$ heroku config:set S3_KEY=8N029N81 S3_SECRET=9s83109d3+583493190
Adding config vars and restarting myapp... done, v14
S3_KEY:   8N029N81
S3_SECRET: 9s83109d3+583493190