Объединение двух репозиториев git вместе с веб-сервером Django, один разработчик

Question

Я начал свой проект Django локально и прекрасно использовал git.

Я опередил себя и скопировал код на сервер, который мгновенно стал не синхронизирован с моей локальной версией. Я не сделал ветку или что-нибудь еще.

Вопрос, состоящий из двух частей: какая структура лучше для меня работать локально, push / pull на тестовый сервер и затем обновлять работающий сервер, когда тест завершен, и как мне настроить его там, где я нахожусь? *

На ранних этапах разработки у меня не было ветвей, но я бы вместо этого следовал стандартной практике ветвления и слияния.

Я использую NetBeans 6.8 локально для кодирования, а также у меня есть GitX. Так что любые советы по интеграции также были бы полезны, но я чувствую себя комфортно, используя любые командные строки.

Спасибо!

Джеймс

Answer 1

Во-первых, вы должны иметь возможность взаимодействовать между репозиториями git, установленными на вашем локальном компьютере, тестовым сервером и живым сервером.Git очень гибок в этом отношении, поэтому есть несколько вариантов:

1. Получить тестовый и работающий сервер из локального репозитория.
2. От разработки до тестирования и вживуюсерверы в подходящее время.
3. От разработки до производства и запуск тестового сервера с производства.
4. В четвертом месте вы будете хранить свое git-репо и переходить от разработки к этому хранилищу.и проведите тестирование и прямую трансляцию оттуда.

В любом случае, как только вы достигнете стадии, когда захотите попробовать что-то на тестовом сервере, создайте тег.На тестовом сервере извлеките этот тег (git checkout <tagname>) и проведите тестирование.(И когда вы убедитесь, что он работает так, как вы хотите, вы также можете использовать этот тег на производстве. Но я думаю, это довольно очевидно. :))

Промежуточный шаг между созданием тега и его проверкойвыход полностью зависит от вашей настройки.Используя четвертый вариант, который я только что упомянул, вам сначала нужно нажать на свой тег и загрузить его на тестовом компьютере.Таким образом, весь процесс будет выглядеть примерно так:

<development>$ git tag v1.0
<development>$ git push
<development>$ git push --tags

<testing>$ git fetch --tags
<testing>$ git checkout v1.0

<live>$ git fetch --tags
<live>$ git checkout v1.0

При желании вы можете (ab) использовать git decribe, чтобы проверить, какой тег у вас уже получен.

Относительноветвление и слияние: мне нравится создавать ветки для каждой функции, над которой я работаю.Как только я завершу эту функцию, я объединю ее с мастером.Поэтому, если мне нужно выпустить до того, как функция будет готова, я могу просто оставить эту функцию (и каждую выпущенную) фиксацию вне релиза.

Но это только один из способов сделать это.Вы можете настроить рабочий процесс в соответствии с вашей ситуацией.Особенно в отношении использования веток.Более сложная настройка описана Винсентом Дриссеном в его статье Успешная модель ветвления Git .

Отказ от ответственности: я использую git почти исключительно с одним авторитетным репо на сервере (четвертый вариант).Я лично не пробовал другие настройки, которые я предложил ...

Обновление, чтобы ответить на комментарий iJames:

Чтобы сделать dev push to и проверить pull изновый / другой репозиторий по умолчанию с этого момента, смотрите принятый ответ на этот вопрос :

$ git branch --set-upstream master origin/master

Что касается терминологии:

• Pushэто относительно просто: он помещает ваши локальные коммиты в другой репозиторий.См., Например, Руководство пользователя Git .
• Выборка выполняет противоположное действие: она "обновит все ветви удаленного отслеживания до последней версии, найденной в хранилище".(Цитата из Git Руководство пользователя .)
• Команда pull не только извлекает изменения, но и объединяет их в текущую ветку.(См. пример в официальном учебнике по Git.)