ForeignKey — это отношение много-к-одному. Вы можете создать много изображений, поместив им в поле post одну и ту же новость.

Поэтому post.image — это не само изображение, а менеджер, который возвращает все изображения для этой новости. Иными словами, post.image вернет то же самое, что и Images.objects.filter(post=post). Поправить это можно несколькими способами.

Если вы хотите, чтобы всё просто заработало без значительных изменений:

<img src="{{ new.image.first().url }}">

Если у новости действительно может быть много изображений

{% for image in new.image.all %}
     <img src="{{ image.image.url }}">
{% endfor %}

Если у новости может быть только одно изображение:

class Images(models.Model):
    post = models.OneToOneField(News, default=None, related_name="image")
    image = models.ImageField(upload_to=settings.MEDIA_ROOT,
                              verbose_name="Image")

OneToOneField — это отношение один-к-одному. В этом случае post.image уже будет сразу возвращать изображение.

class Foo:
    def __init__(self, a, b):
        self.a = a
        self.b = b
        
    def __str__(self):
        return '\n'.join('%s : %s' % item for item in vars(self).items())

Используется так:

>>> print Foo(123, 'ololo')
a : 123
b : ololo

В remote надо написать любое имя (обычно пишут origin). В URL — адрес репозитория, Например:

https://<username>@github.com/<username>/<project>.git

Для битбакета формат ссылки такой же, только там bitbucket.org вместо github.com. Обычно эти URL можно найти на сайте на странице репозитория.

Мы тоже искали решение подобной проблемы и пришли к тому, что меньше всего боли нам доставляет вот такой модифицированный gitflow:

• Код на продакшн заливается из ветки master.
  
• Код на тестовый сервер заливается из ветки develop.
  
• Все задачи делаются в отдельных feature-бранчах. Важно, что feature-бранчи ответвляются от master.
  
• Разработчик, завершив работу над задачей, мёржит ветку этой задачи в develop.
  
• Вмёрженные в develop задачи заливаются на тестовый сервер, где их сможет проверить тестировщик.
  
• Когда приходит время релиза, feature-бранчи для всех задач, которые должны быть включены в него и успешно протестированы, мёржатся в master.
  
• develop никогда не мёржат в master, потому что там может быть непроверенный код с багами.
  

Вот здесь мы описали этот подход более развернуто и пояснили некоторые тонкие моменты (например, что делать, если несколько задач логически связаны между собой).

Этот workflow подойдет не всем, многое зависит от сложившихся в команде процессов. Но в ситуации, которая описана в вопросе, он должен помочь (возможно, с небольшими изменениями).