Разработка проектов Django с использованием Git - PullRequest
8 голосов
/ 18 мая 2009

Мне интересно, есть ли у кого-то опыт работы над проектами Django в небольшой команде (в моем случае 3), использующей систему управления исходным кодом Git.

Проект размещен на сервере разработки, поэтому у меня возникла такая проблема. Разработчики не могут увидеть, работает ли их код, пока они не передадут свои изменения в свой локальный репозиторий, а затем отправят эти изменения на сервер. Однако даже в этом случае git, похоже, не обновляет файлы внутри каталога, в котором находится хранилище на сервере - возможно, потому, что он сохраняет только изменения для экономии места.

Мы начинаем наступать друг другу на ноги, работая над этим проектом, поэтому требуется какой-то контроль версий - но я просто не могу найти решение.

Если кто-нибудь преодолеет подобную проблему, я бы хотел услышать, как это можно сделать.

Ответы [ 3 ]

12 голосов
/ 18 мая 2009

При отправке в удаленный репозиторий лучшие результаты достигаются, когда удаленный репозиторий представляет собой «пустой» репозиторий без рабочего каталога. Похоже, у вас есть рабочий каталог в удаленном хранилище, который не будет обновляться Git при выполнении push.

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

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

3 голосов
/ 18 мая 2009

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

Если вы хотите, чтобы где-нибудь был извлечен последний «мастер» общего репо, вы можете договориться об этом, написав хук после обновления. Ниже я приведу пример, который я использую, чтобы проверить подкаталог «ui» и сделать его доступным для Apache.

Однако я скажу, что я думаю, что ваш процесс может быть улучшен. Разработчикам, как правило, нужны персональные серверы, на которых они могли бы протестировать, прежде чем отправлять их в общую точку: в противном случае это общее хранилище, вероятно, будет ужасно ненадежным. Подумайте, если я настаиваю на том, чтобы оно изменилось, и оно не сработало, это мое изменение, которое сломало его, или побочный эффект кого-то другого?

ОК, я использую это как ловушку после обновления:

#!/bin/sh
# Should be run from a Git repository, with a set of refs to update from on the command line.
# This is the post-update hook convention.

info() {
    echo "post-update: $@"
}

die() {
    echo "post-update: $@" >&2
    exit 1
}

output_dir=..
for refname in "$@"; do
    case $refname in
        refs/heads/master)
            new_tree_id=$(git rev-parse $refname:ui)
            new_dir="$output_dir/tree-$new_tree_id"
            if [ ! -d "$new_dir" ]; then
                info "Checking out UI"
                mkdir "$new_dir"
                git archive --format=tar $new_tree_id | ( cd $new_dir && tar xf - )
            fi
            prev_link_target=$(readlink $output_dir/current)
            if [ -n "$prev_link_target" -a "$prev_link_target" = "tree-$new_tree_id" ]; then
                info "UI unchanged"
            else
                rm -f $output_dir/current
                ln -snf "tree-$new_tree_id" "$output_dir/current"
                info "UI updated"
                title=$(git show --quiet --pretty="format:%s" "$refname" | \
                    sed -e 's/[^A-Za-z][^A-Za-z]*/_/g')
                date=$(git show --quiet --pretty="format:%ci" "$refname" | \
                    sed -e 's/\([0-9]*\)-\([0-9]*\)-\([0-9]*\) \([0-9]*\):\([0-9]*\):\([0-9]*\) +0000/\1\2\3T\4\5\6Z/')
                ln -s "tree-$new_tree_id" "$output_dir/${date}__${title}"
            fi
            ;;
    esac
done

Как уже упоминалось, это просто проверяет подкаталог "ui". Это бит ": ui", устанавливающий new_tree_id. Просто извлеките «: ui» (или измените на «^ {tree}»), чтобы проверить все.

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

Оформления оформляются в каталоги «tree-XXXX», и «текущая» символическая ссылка может указывать на самую последнюю. Это делает переход от одного к другому атомарным, хотя вряд ли это займет так много времени, что это имеет значение. Это также означает, что можно повторно использовать старые файлы. И это также означает, что он жует дисковое пространство, когда вы продолжаете выдвигать ревизии ...

0 голосов
/ 18 мая 2009

Была такая же проблема, также работа с django.

Согласитесь на локальное тестирование до развертывания, как уже упоминалось.

Затем вы можете отправить локальную версию в новую ветку на сервере. Затем вы делаете слияние с этой веткой и мастером. После этого вы увидите обновленные файлы.

Если вы случайно нажали на ветку master, вы можете выполнить git reset --hard. Однако все изменения, не зафиксированные в текущей рабочей ветке, будут потеряны. Так что береги себя.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...