2009-05-17 41 views
8

Tôi tự hỏi nếu có ai có kinh nghiệm làm việc trên các dự án Django trong một nhóm nhỏ (3 trong trường hợp của tôi), sử dụng quản lý kiểm soát nguồn Git.Phát triển các dự án Django bằng Git

Dự án được lưu trữ trên máy chủ phát triển, đó là lý do tại sao tôi gặp sự cố như vậy. Các nhà phát triển không thể xem liệu mã của họ có hoạt động cho đến khi họ thực hiện các thay đổi của họ cho kho lưu trữ cục bộ của họ hay không, sau đó đẩy những thay đổi đó lên máy chủ. Thậm chí sau đó, tuy nhiên, git dường như không được cập nhật các tập tin bên trong thư mục giữ kho lưu trữ trên máy chủ - có lẽ bởi vì nó chỉ lưu trữ các thay đổi để tiết kiệm không gian.

Chúng tôi đang bắt đầu tread trên ngón chân của nhau khi làm việc trên dự án này, vì vậy một số loại điều khiển phiên bản là bắt buộc - nhưng tôi chỉ không thể tìm ra một giải pháp.

Nếu có ai đó khắc phục được sự cố tương tự, tôi rất muốn nghe cách thực hiện.

Trả lời

12

Khi đẩy đến một kho lưu trữ từ xa, kết quả tốt nhất là khi kho lưu trữ từ xa là kho lưu trữ "trống" không có thư mục làm việc. Có vẻ như bạn có một thư mục làm việc trên kho lưu trữ từ xa, sẽ không được Git cập nhật khi thực hiện một thao tác push.

Trong trường hợp của bạn, tôi khuyên các nhà phát triển nên có môi trường thử nghiệm riêng mà họ có thể kiểm tra trước khi phải đẩy mã của họ ở bất kỳ nơi nào khác. Có một vị trí trung tâm nơi mọi người cần thúc đẩy công việc của họ trước khi họ thậm chí có thể thử nó sẽ dẫn đến nhiều đau khổ và đau khổ.

Để triển khai, tôi khuyên bạn nên chuyển sang kho "trung tâm", sau đó có quy trình trong đó máy chủ triển khai kéo mã số mới nhất từ ​​kho trung tâm vào thư mục hoạt động của nó.

+3

+1 Cây git-not-updating-remote-working-tree là một vấn đề phụ. Các nhà phát triển chỉ đơn giản là PHẢI từng có một thiết lập thử nghiệm làm việc tại địa phương (trung thực, với SQLite và máy chủ django dev nó không khó). –

+0

Bạn có thể liên kết đến tài nguyên về cách thiết lập quy trình phát triển mà bạn đề xuất cho người mới sử dụng Django như tôi không? –

3

Khi bạn đẩy tới kho lưu trữ git (được chia sẻ), nó không cập nhật các tệp làm việc của kho lưu trữ đó. Về cơ bản vì các tệp làm việc có thể bị bẩn và trong trường hợp đó, bạn phải hợp nhất --- và cho rằng bạn cần có toàn quyền truy cập shell ở đó, có thể không phải là trường hợp nói chung.

Nếu bạn muốn có "tổng thể" gần đây nhất của repo được chia sẻ được kiểm tra ở đâu đó, bạn có thể sắp xếp cho điều đó bằng cách viết một móc hậu cập nhật. Tôi sẽ đưa ra một ví dụ dưới đây mà tôi sử dụng để kiểm tra thư mục con "ui" và làm cho nó có sẵn cho Apache.

Tuy nhiên, tôi sẽ nói rằng tôi nghĩ rằng quá trình của bạn có thể được cải thiện. Các nhà phát triển thường cần các máy chủ cá nhân mà họ có thể kiểm tra trước khi chuyển sang một điểm được chia sẻ: nếu không, repo được chia sẻ đó có thể sẽ không đáng tin cậy. Hãy xem xét, nếu tôi đẩy một thay đổi cho nó và nó không hoạt động, là sự thay đổi của tôi đã phá vỡ nó hoặc một tác dụng phụ của người khác?

OK, tôi sử dụng như một cái móc sau update:

#!/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: [email protected]" 
} 

die() { 
    echo "post-update: [email protected]" >&2 
    exit 1 
} 

output_dir=.. 
for refname in "[email protected]"; 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 

Như đã đề cập, điều này chỉ kiểm tra ra "ui" thư mục con. Đó là thiết lập bit ": ui" new_tree_id. Chỉ cần lấy ": ui" ra (hoặc thay đổi thành "^ {tree}") để kiểm tra mọi thứ.

Kiểm tra nằm trong thư mục chứa repo git, được kiểm soát bởi output_dir. Kịch bản dự kiến ​​sẽ được chạy bên trong repo git (mà lần lượt dự kiến ​​sẽ được trần): đây không phải là rất sạch sẽ.

Kiểm tra được đưa vào thư mục "tree-XXXX" và liên kết tượng trưng "hiện tại" được trỏ đến điểm gần đây nhất. Điều này làm cho sự thay đổi từ nguyên tử này sang nguyên tử khác, mặc dù khó có thể mất nhiều thời gian đến mức nó quan trọng.Nó cũng có nghĩa là reverts tái sử dụng các tập tin cũ. Và nó cũng có nghĩa là nó nhét không gian đĩa khi bạn tiếp tục đẩy các bản sửa đổi ...

0

Có cùng một vấn đề, cũng làm việc với django.

Đồng ý thử nghiệm tại địa phương trước khi triển khai, như đã đề cập.

Sau đó, bạn có thể đẩy phiên bản cục bộ đến một nhánh mới trên máy chủ. Sau đó, bạn làm một hợp nhất với chi nhánh này và tổng thể. Sau này, bạn sẽ thấy các tập tin cập nhật.

Nếu bạn vô tình bị đẩy vào nhánh chính, bạn có thể đặt lại git --hard. Tuy nhiên, tất cả các thay đổi không được cam kết trong nhánh hiện tại sẽ bị mất. Vì vậy, chăm sóc.

Các vấn đề liên quan