Игорь Шевченко

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

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

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

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

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 уже будет сразу возвращать изображение.

Я вижу только такой вариант:
1. Для всех тестов пользователь должен авторизоваться на вашем сайте через Фейсбук. Раз тут висит тег Django, то порекомендую для этого библиотеку allauth.
2. Для каждого конкретного теста с сервера идут запросы к API Фейсбука за данными, которые нужны для этого теста. Опять же могу посоветовать использовать facebook-sdk.
3. Когда данные получены, они обрабатываются уже с учетом логики этого теста. Логика получается разной для каждого теста, поэтому будет логично выделить каждый тест в отдельный класс.

Еще хочу предупредить о том, что у Фейсбука довольно много ограничений по работе с API. Например, уже с двумя тестами из примера возникнут проблемы:

• Фейсбук не отдает по API полный список друзей пользователя. Вообще никак. Максимум, что можно получить, это список друзей, которые тоже авторизовались на вашем сайте.
  
• Возраст пользователя получить можно, но это либо будет диапазон (13–17, 18–21 или 21+), либо вам придется запрашивать разрешение user_birthday. Чтобы вы могли получать это разрешение, придется пройти ревью Фейсбука (отправить им на проверку текст на английском, описывающий, зачем вам разрешение, и скринкаст, демонстрирующий это).
  

У Вконтакте таких ограничений меньше, можете попробовать с его API.

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

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

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

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