2010-02-03 24 views
10

Tôi có một dự án nguồn đóng được xây dựng trên khung nguồn mở của tôi. Tôi muốn biết làm thế nào tôi nên cấu trúc công việc của tôi. Dưới đây là dự đoán tốt nhất của tôi bằng cách sử dụng git với submodules.Quy trình làm việc Git phù hợp cho hệ điều hành và mã riêng?

  1. tôi tạo một repo khuôn khổ cộng đồng về github với submodules được Repos git riêng biệt.
  2. Tôi mua một tài khoản "vi mô" trên github ($ 7) để tôi có thể có một kho lưu trữ riêng tư.
  3. Tôi tạo một repo riêng và sao chép repo khung công cộng.

Từ đây tôi có thể thay đổi:

  1. đang tin của tôi và đẩy để repo tin của tôi trên github
  2. Mã khuôn khổ cộng đồng và đẩy để repo github riêng tư của tôi và sau đó gửi một kéo yêu cầu từ khung công cộng ..? Hoặc làm thế nào điều này sẽ làm việc?

Làm cách nào để xử lý một repo có chứa mã riêng và mã công cộng và mô-đun con. Ngay bây giờ có vẻ như tôi chỉ phải duy trì hai codebases riêng biệt để đạt được điều này.

Tôi đang tìm câu trả lời tốt nhất có thể giúp ai đó khá mới mẻ để git sắp xếp hợp lý quá trình làm việc trên một codebase là một nửa nguồn mở và một nửa riêng tư. Một điều tốt về nó là mỗi thư mục là riêng tư hoặc công khai, do đó không có lo lắng về việc có các tệp riêng tư và công khai cùng nhau ở đâu đó - nhưng một số thư mục riêng tư có thể ở trong các thư mục công khai!

Một ví dụ khác tôi có thể đưa ra là sử dụng zendframework để xây dựng trang web công ty riêng của bạn trong khi vẫn có thể thực hiện kéo mỗi ngày (và có thể vá đẩy) vào repo zend. Và cũng có thể kéo và đẩy trang web riêng của bạn bên trong zendframework.

Ví dụ, hãy tưởng tượng một cấu trúc thư mục như thế này:

/private_folder 
/public 
     /public_folder 
     /public_folder2 
     /private_folder 

Có lẽ tôi đang yêu cầu hai nhiều để xử lý tất cả trong một gia nhập thư mục repo. Có lẽ không có cách nào dễ dàng để làm điều này và tôi nên tách chúng và làm tất cả các bản vá lỗi công cộng trong một và sau đó chỉ cần kéo vào repo riêng của tôi. Tất nhiên, điều này có nghĩa rằng nếu tôi đang làm việc trên một số mã riêng - Tôi sẽ phải rời khỏi repo đó và mở một công khai và thực hiện thay đổi mã vá, sau đó quay lại chế độ riêng tư, hợp nhất và sau đó tiếp tục làm việc trên mã riêng.

+0

Bạn đề cập đến Zend ở trên. Điều này có nghĩa là dự án của bạn dựa trên PHP? Hay đây chỉ là một ví dụ? (Tôi hỏi vì các ngôn ngữ khác nhau đóng gói mã theo nhiều cách khác nhau và nó có thể ảnh hưởng đến quy trình làm việc của bạn.) –

+0

Có, nó dựa trên PHP - vì vậy không yêu cầu * building *. – Xeoncross

Trả lời

5

Tôi khuyên bạn không nên sử dụng các mô-đun con git, nhưng 2 kho lưu trữ khác nhau không được kết nối trên github.

Bạn có thể xây dựng mối quan hệ giữa chúng bằng cách sử dụng liên kết tượng trưng trên các bản sao được kiểm tra, cơ bản và đơn giản. Các liên kết tượng trưng chỉ phải được tạo một lần cho mỗi địa điểm (sản xuất, phát triển, đồng nghiệp).

Lợi thế là không ai phải nỗ lực thêm để học và duy trì các mô-đun con git, và bạn tránh được rủi ro và sự phức tạp mà nó mang lại.

Nó có thể được thực hiện bằng cách giữ một bản sao làm việc của os và của git repo tin ở đâu đó trên máy tính cục bộ của bạn:

/repos/myproject-os 
/repos/myproject-priv 

Sau đó, bạn có thể tạo tạo cấu trúc thư mục của bạn, nơi dự án sẽ thực sự sống và được làm việc trên một nơi khác trên máy tính này (không phải bên trong/Repos/cây) và tạo symblinks cho các thư mục con bạn sử dụng:

ln -s /repos/myproject-os/dir1 /wrk/myproject/base/dir1 
ln -s /repos/myproject-os/dir2 /wrk/myproject/base/dir2 
ln -s /repos/myproject-priv/dir1 /wrk/myproject/base/dir3 
ln -s /repos/myproject-priv/dir2 /wrk/myproject/base/someother/dir4 
mkdir /wrk/myproject/base/config 
mkdir /wrk/myproject/base/tmp 

Bằng cách đó bạn có cấu trúc kho luôn sạch sẽ và có thể kết hợp và sắp xếp các thư mục từ cả hai reposit ories theo cách bạn muốn họ, và bạn cũng có một không gian cho các cấu hình cục bộ hoặc các tập tin tạm thời mà không đi vào kho.

Bạn sẽ thực hiện các cam kết git và mọi thứ từ/repos/tree và dự án của bạn sẽ chạy và bạn sẽ chỉnh sửa các tệp từ/wrk/tree. Xin lưu ý rằng đoạn mã .git mà dữ liệu git sẽ là không phải là có dạng/wrk/tree, bởi vì bạn chỉ liên kết đến các thư mục con (hoặc có thể là các tệp đơn từ thư mục gốc).

Part2: Bạn nói rằng bạn muốn đảm bảo rằng bạn không vô tình đẩy mã riêng tư vào kho công cộng. Bạn có thể thiết lập một kho git bổ sung giữa kho OS làm việc của bạn và kho github, giả sử bạn đặt nó vào/Repos/gatekeeper, sau đó cây của bạn trông như thế này:

/repos/gatekeeper/myproject-os 
/repos/myproject-os 
/repos/myproject-priv 

Mỗi khi bạn đẩy từ/Repos/myproject-os nó đến/repos/gatekeeper/myproject-os. Nhưng từ/repos/myproject-priv bạn đẩy trực tiếp đến repo github riêng của bạn.

Bằng cách đó bạn có cùng quy trình làm việc trong cả hai/repos/myproject-os và/repos/myproject-priv và bạn không cần lo lắng quá nhiều. Theo thời gian khi bạn muốn đẩy các thay đổi của bạn vào codebase hệ điều hành thực, bạn vào/repos/gatekeeper/myproject-os và đẩy từ đó đến github.

Bạn có thể thực hiện đánh giá mã bổ sung trước đó và xem xét các khác biệt để bạn chắc chắn rằng chỉ những gì bạn thực sự muốn công khai.

Nếu bạn muốn bảo mật bổ sung/repos/gatekeeper/myproject-os cũng có thể nằm trên một máy khác hoặc thậm chí vị trí khác.

+0

Ý tưởng hay. Tôi đoán rằng đối với rất nhiều thư mục (tôi có hàng trăm), bạn có thể tạo một kịch bản lệnh shell để tạo tất cả các thư mục cho bạn trên mỗi máy lấy một biến 'repo_path' đơn giản. – Xeoncross

+0

Tôi sẽ trao cho bạn tiền thưởng vì những gì bạn đang nói sẽ làm việc - nhưng tôi không nghĩ rằng tôi sẽ thực sự làm điều này. Phần lớn khó thiết lập cho nhiều người trong một nhóm và với nhiều dự án như thế này. – Xeoncross

+0

Câu trả lời thú vị. Tôi đang trên Linux bản thân mình, nhưng hầu hết các nhà phát triển trong công ty của tôi là trên Windows, vì vậy họ không có sự sang trọng của ln -s. Có ai đã thử điều này trên Windows? –

1

Bạn có thể có chi nhánh 'công khai' và 'riêng tư' trong kho lưu trữ cục bộ của mình. Khi bạn đẩy, mỗi nhánh sẽ được đẩy đến một kho lưu trữ từ xa riêng biệt (tra cứu cú pháp 'git push'). Sau đó, bạn có thể tự do hợp nhất từ ​​công khai thành riêng tư.

Tôi chắc chắn có cách bạn có thể hợp nhất các thay đổi đã chọn từ riêng tư thành công khai, mặc dù tôi phải tìm kiếm nó.

+0

Với quy trình làm việc này, bạn không thể có thư mục làm việc với các tệp công khai và riêng tư. Khi bạn đã kiểm tra các chi nhánh công cộng, bạn chỉ thấy các tập tin công cộng; kiểm tra các chi nhánh tư nhân và bạn chỉ có các tập tin cá nhân. –

+0

@AmedeeVanGasse: Điều đó không đúng. Chi nhánh tư nhân có cả tệp công khai và riêng tư. Chi nhánh công cộng chỉ có các tệp công khai. Đó là những gì "hợp nhất". –

+0

Điều đó không rõ ràng từ lời giải thích! –

-1

Làm cho công khai repo một mô-đun con trong mô hình riêng. Khi đẩy, hãy nhớ rằng bạn phải đẩy cả hai. Cũng nên nhớ kiểm tra trong submodule chính nó trong repo tư nhân, do đó, nó theo dõi những sửa đổi của submodule nó đang sử dụng.

1

git submodules cho phép bạn xác định cấu hình (xem this question), đó là tham chiếu đến một cam kết của một thành phần khác (trong một repo khác).

Bạn có thể phát triển cả hai mã (của bạn và các mô-đun con) trong cùng một repo, nhưng khi bạn đang nói về nhiều thư mục riêng trong mã công khai, hãy gọi subtree merge strategy.
Nó sẽ cho phép bạn xem xét các thư mục của bạn (các thư mục riêng và công khai) là một cây làm việc tự nhiên.

Và để quản lý tốt hơn việc đẩy và kéo các bộ phận của kho lưu trữ toàn cầu của bạn vào một tài khoản riêng tư, tôi sẽ giới thiệu git subtree script tool.

1

Để tóm tắt, tôi khuyên bạn nên công việc này:

  1. giữ nó đơn giản; có một bản sao làm việc cho mỗi kho (không sử dụng các môđun con git)
  2. sử dụng các công cụ của ngôn ngữ của bạn để gói lên khuôn khổ của bạn
  3. kịch bản cài đặt hoặc dụng cụ ánh sáng để làm bối cảnh chuyển đổi nhanh hay tự động

tôi đã sử dụng git submodules trong quá khứ. Tôi không nghĩ chúng phù hợp với trường hợp sử dụng của bạn. Nhược điểm lớn mà nhảy ra ngoài với tôi là:

  • Giúp bạn ăn thức ăn cho chó khi bạn xây dựng (hoặc trích xuất) một khuôn khổ. Bạn có mong đợi người dùng khung của bạn cũng thiết lập các mô-đun con git khi họ sử dụng khung của bạn không? Tôi đoán là không.
  • Có một số rủi ro vô tình xuất bản mã nguồn riêng của bạn vào khung nguồn mở của bạn.
  • Các mô-đun con Git đã cải thiện khá nhiều trong năm qua, nhưng chúng vẫn tương đối ít được hiểu rõ hơn. Ngay cả gitters có thẩm quyền có thể đấu tranh với submodules.

Dưới đây là một câu hỏi phụ mà tôi sẽ thừa nhận không rõ ràng: "Luồng công việc nào giúp dễ dàng hơn để thoát qua lại giữa khung PMNM và dự án riêng tư?"

  • Có một sự quyến rũ nhất định khi sử dụng mô-đun con và có cả hai dự án trong một cây. Điều này sẽ tăng tốc độ bạn có lẽ trong chỉnh sửa văn bản của bạn, nhưng có lẽ sẽ làm chậm bạn xuống (hoặc gây ra nhiều sai lầm hơn bình thường) khi nói đến cam kết và đẩy.

  • Có sự quyến rũ nhất định khi tách riêng các dự án. Công tắc ngữ cảnh (từ một cửa sổ soạn thảo văn bản này sang cửa sổ soạn thảo văn bản khác) có thể giúp nhắc nhở bạn rằng dự án PMNM là dành cho tiêu dùng công cộng. Ví dụ, nó có thể giúp kỷ luật bạn không phá vỡ khả năng tương thích ngược và giữ một thay đổi tốt. Cam kết và đẩy sẽ dễ dàng tương đối so với thay thế mô-đun.

Một trong những bạn đã quyết định bản sao làm việc của mình, bạn sẽ muốn tìm ra quy trình làm việc hàng ngày. Nó sẽ phụ thuộc vào ngôn ngữ của bạn tất nhiên. (Trong Ruby, ví dụ, bạn có thể đóng gói khung OSS của bạn như một viên ngọc, xây dựng nó, sau đó có mã riêng của bạn phụ thuộc vào nó.) Bất cứ điều gì bạn chọn, thiết lập một số script (hoặc các trình soạn thảo có lẽ) để giúp bạn xây dựng các thư viện của bạn (hoặc gói) một cách nhanh chóng, thậm chí có thể tự động khi các tệp thay đổi, để bạn có thể thoát ra giữa khung công tác và dự án của bạn một cách dễ dàng.

+0

Gần đây tôi đã đọc rất nhiều trong cuốn sách progit.com và tôi nghĩ rằng bạn đúng - tốt nhất nên giữ mọi thứ riêng biệt nếu vì lý do đơn giản là tôi có thể vô tình đẩy mã riêng vào repo công cộng. Lý do khác là tôi sẽ phải áp dụng phương pháp này anyway cho các dự án bổ sung mà phụ thuộc vào khuôn khổ vì tôi sẽ không tiếp tục bổ sung thêm nhiều trang web vào một repo kết hợp. – Xeoncross

0

Có hai cách tiếp cận ở đây:

  1. Bạn có thể sử dụng chi nhánh của repo git cùng. Trong repo riêng của bạn tạo ra một chi nhánh với một tham chiếu đến repo công cộng của bạn và xử lý cả hai như thế.

  2. Nếu các thành phần sử dụng trong dự án riêng tư của bạn là tiểu dự án công cộng của bạn, thì bạn nên sử dụng các mô-đun con. Việc xử lý submodule là trong một loại giai đoạn đầu trên git tại phiên bản 1.6.6, nhưng có thể hữu ích như bạn đang sử dụng subproject.

Điều gì dường như với tôi bạn không thể mất nếu dự án nào phù hợp với từng dự án, vì vậy nếu bạn có dự án rõ ràng, thì bất kể bạn chọn nó sẽ hoạt động !!!!!! Bên cạnh đó, git thật dễ dàng.

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