使用Git开发Django项目

我想知道是否有人有在一个小团队中（在我的例子中是3个）使用Git源代码管理处理Django项目的经验

该项目托管在开发服务器上，这就是为什么我会遇到这样的问题。在将更改提交到本地存储库，然后将这些更改推送到服务器之前，开发人员无法查看其代码是否有效。然而，即使这样，git似乎也没有更新服务器上存储库所在目录中的文件——可能是因为它只存储更改以节省空间

在这个项目中，我们开始互相攻击，所以需要某种版本控制——但我就是想不出一个解决方案

---

如果有人已经解决了类似的问题，我想听听如何解决。

当推送到远程存储库时，最好的结果是远程存储库是一个没有工作目录的“裸”存储库。听起来您在远程存储库上有一个工作目录，在推送时Git不会更新该目录

对于您的情况，我建议开发人员拥有自己的测试环境，在将代码推送到其他地方之前，可以在本地对其进行测试。有一个中心位置，每个人都需要在尝试之前推动他们的工作，这将导致很多痛苦和痛苦

对于部署，我建议推送到一个中央“裸”存储库，然后让部署服务器将最新代码从中央存储库拉入其工作目录。

当推送到（共享）git存储库时，它不会更新该存储库的工作文件。基本上是因为工作文件可能是脏的，在这种情况下，您必须合并——为此，您需要在那里拥有完整的shell访问权限，一般情况下可能不是这样

如果您想在某个地方签出共享回购协议的最新“主”文件，您可以通过编写更新后挂钩来进行安排。下面我将给出一个示例，我使用它检查“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”子目录。这是设置新树id的“：ui”位。只需将“：ui”取出（或更改为“^{tree}”）即可查看所有内容

签出在包含git repo的目录中，由output_dir控制。该脚本预计将在git repo内部运行（而git repo又是裸的）：这不是很干净

---

签出被放在“tree XXXX”目录中，并管理一个“current”符号链接以指向最近的。这使得从一个原子到另一个原子的变化成为可能，尽管这不太可能需要太长的时间。它还意味着恢复和重用旧文件。这也意味着它会在你不断推动修订时占用磁盘空间…

也有同样的问题，也与django一起工作

如前所述，同意在部署前进行本地测试

然后可以将本地版本推送到服务器上的新分支。然后，将此分支与主分支合并。在此之后，您将看到更新的文件

---

如果您不小心推到了主分支，那么您可以执行git重置——很难。但是，当前工作分支中未提交的所有更改都将丢失。所以要小心。

+1 git不更新远程工作树是一个次要问题。开发人员只需每个人都有一个本地工作测试设置（老实说，使用SQLite和django开发服务器并不难）。您是否可以链接到有关如何为像我这样的django新手设置开发工作流的参考资料？