2011-10-28 35 views
6

Tôi thực sự thất vọng về việc sử dụng tính năng submodule của git. Hoặc tôi vẫn không làm đúng hoặc nó không hoạt động như tôi mong đợi điều này. Sau tình hình dự án được đưa ra:Git submodule mess: cách sử dụng git submodules với các nhà phát triển không quen thuộc với git?

Project 
    | .git 
    | projsrc 
    | source (submodule) 
    | proj.sln 

Trong kịch bản này nguồn được trỏ đến một kho chứa dữ liệu nguồn phổ biến trên tất cả các dự án của chúng tôi. Có rất nhiều sự phát triển xảy ra dưới nguồn cũng như dưới projsrc. Thật không may Dự án trỏ đến một số cam kết của mô-đun con nguồn và không phải cho HEAD thực tế của nó. Đây là hành vi git thông thường, theo như tôi biết.

Tôi đã phát hiện ra rằng

git submodule update 

chỉ có được phiên bản của submodule được cam kết cùng với các dự án chính. Tuy nhiên, tôi thực sự muốn luôn luôn được cập nhật với sự phát triển submodules, nhưng không có bất kỳ đầu mối thực sự làm thế nào để làm điều này đúng. Do đó câu hỏi của tôi là:

Có thể gắn Dự án đến HEAD của submodule, reagardless thực tế nếu điều này sẽ phá vỡ biên soạn các dự án hay không. Tôi không muốn luôn đi vào submodule thư mục và làm git pull tại đó. Vì tôi nghĩ rằng tôi có thể mất các thay đổi của tôi được thực hiện trong thư mục con, bởi vì điều này là đơn giản gắn liền với một cam kết và không thực sự để bất kỳ chi nhánh hay như vậy.

Hãy xem xét những hạn chế sau:

  • phát triển trong nhóm của chúng tôi không phải là quen thuộc với tất cả VCS xung quanh. Chúng tôi được sử dụng để sử dụng kho svn thực sự lớn trước đây, mà không có bất kỳ tính năng repo bên ngoài nào cả.
  • Chúng tôi đang làm việc trên Windows
  • Một giải pháp click'n'forget sẽ là tốt nhất, vì hầu hết các thành viên dự án khá sợ hãi bằng cách sử dụng một giao diện dòng lệnh :)
+1

Xem thêm http://stackoverflow.com/questions/1979167/git-submodule-update/1979194#1979194 và http://stackoverflow.com/questions/3131912/ Tại sao-là-git-submodules-không tương thích-với-svn-externals/3132221 # 3132221 – VonC

+0

"Tôi có thể mất các thay đổi của tôi thực hiện trong thư mục submodule, bởi vì điều này là đơn giản gắn liền với một cam kết và không thực sự đến bất kỳ chi nhánh nào "Nó không đúng! Luôn luôn có một chi nhánh.Bạn không bao giờ mất các thay đổi của mình cho đến khi bạn cam kết khi bạn ở trạng thái đầu bị tách rời. – Vanuan

Trả lời

7

Lý do tại sao một điểm submodule cho một phiên bản cụ thể là quan trọng. Nếu bạn trỏ đến HEAD, bản dựng sẽ là không thể sản xuất được. I E. nếu bạn kiểm tra ngày hôm qua là một phiên bản của dự án, bạn sẽ không bao giờ biết được phiên bản chính xác của nguồn @ HEAD là ngày hôm qua.

Đó là lý do tại sao nó luôn lưu trữ sha sửa đổi cụ thể.

Để kéo tất cả các môđun con bạn có thể sử dụng Easy way pull latest of all submodules

+0

Tôi hoàn toàn đồng ý rằng họ sẽ phá vỡ, tuy nhiên tôi ổn với tình huống đó. Tôi chỉ cảm thấy phiền lòng khi giải thích mọi nhà phát triển không quen thuộc hợp tác trên ** Project ** của tôi rằng submodule ** source ** không hoạt động như mong đợi. Họ luôn cam kết/thúc đẩy nguồn trên bất kỳ thay đổi nào ở đó. Và quan trọng hơn, nếu họ chỉ làm _git submodule update_ trong Project, chúng mất tất cả các thay đổi của chúng được tạo ra cho _source_, vì chúng bị ghi đè bởi bản sửa đổi cụ thể đó. – cgart

+0

'cập nhật submodule' không xóa bất kỳ thay đổi, như tôi biết, nó chỉ kiểm tra sửa đổi được giới thiệu. Các thay đổi được thực hiện vẫn còn trong repo, và bạn có thể kiểm tra chúng, sau đó cập nhật ** Project ** để tham khảo bản sửa đổi và cam kết tham chiếu sửa đổi mô-đun con đến dự án chính. – kan

+0

Bằng chứng thư git, hãy xóa các thay đổi của bạn nếu bạn chưa cam kết và đẩy chúng (cũng như chưa đẩy các thay đổi trong phụ huynh). Kể từ khi nguồn/là một mô-đun con với các HEAD riêng biệt (các hành vi mặc định) các bản cập nhật submodule git sẽ luôn luôn mang nguồn/thư mục trong trạng thái được chỉ bởi kho lưu trữ gốc. Đây là, trong mắt tôi, hành vi rất xấu của git, vì nó thậm chí không thông báo cho tôi rằng các thay đổi cục bộ của tôi bị ghi đè (git 1.7.7) – cgart

2

Tôi không giỏi Git và submodule. Nhưng tôi nghĩ rằng một số quy tắc đơn giản sẽ rất hữu ích.

  1. Cam kết và đẩy từ thư mục con.
  2. Quay lại thư mục gốc của dự án của bạn, kiểm tra trạng thái nếu bạn cần cam kết và đẩy lại.

khi Kéo. có thể thử sử dụng tập lệnh để nhóm "cập nhật kéo/mô-đun con" cùng nhau. Và chỉ làm điều đó ở gốc của dự án của bạn.

2

Hãy xem xét điều này:

  1. nguồn được trỏ đến HEAD (như bạn mong muốn).
  2. bạn thực hiện thay đổi đối với nguồn bên trong Dự án (bạn cam kết nhưng không đẩy chúng)
  3. bây giờ bạn có hai HEAD: một trong nguồn dự án, một nguồn khác trong nguồn chung của bạn.

Bạn muốn có mặt nào trong Dự án khi cập nhật mô-đun con?

Vấn đề (và tính năng chính) của git trong trường hợp của bạn là bạn xem xét cam kết và đẩy hoạt động nguyên tử. Nó không phải là. Git được phân cấp. Không có HEAD phổ biến. Bạn có thể có nhiều kho với các HEAD khác nhau.

Hãy xem xét điều này:

  1. bạn có 3 nhà phát triển (A, B và C) với một dự án git.
  2. tất cả đều kéo HEAD của dự án.
  3. mỗi nhà phát triển đã thực hiện thay đổi đối với dự án
  4. giờ mỗi người trong số họ có 3 HEADS: HEAD HEAD, HEAD B và HEAD C.

HEAD nào bạn cho là HEAD "đúng"?

Vì vậy, để trả lời câu hỏi của bạn: Nếu bạn muốn môđun con nguồn chung luôn được đồng bộ hóa với kho lưu trữ trung tâm, git không phải là lựa chọn của bạn. Và có lẽ không có VCS nào giúp bạn với điều đó.

Bạn nên xử lý git submodule như một thư viện thirdparty cần được cập nhật bằng tay với hai bước sau:

  1. Kéo submodule của bạn ("tải về thư viện thirdparty")
  2. Cam kết dự án của bạn với submodule cập nhật (" đặt phiên bản mới của thư viện thirdparty để dự án của bạn ")

Nếu bạn muốn thay đổi submodule bạn nên làm như vậy theo thứ tự ngược:

  1. Commit submodule của bạn ("thực hiện thay đổi vào thư viện thirdparty")
  2. Đẩy submodule của bạn ("gửi các thay đổi của bạn vào thư viện duy trì thirdparty")
  3. Cam kết dự án của bạn với submodule cập nhật ("đặt mới phiên bản thư viện của bên thứ ba vào dự án của bạn ")
+0

Cảm ơn Vanuan. Vâng, tôi biết tôi có ý tưởng về git. Bạn có thể đúng, nó có thể không phải là lựa chọn đúng đắn. Vấn đề là, nó đã cho tôi rất dài thời gian để hiểu những gì git là thực sự làm so với svn trước đây được sử dụng. Tôi đã thực sự sợ về việc giải thích điều này cho các nhà phát triển đồng nghiệp của mình ... Tuy nhiên, tôi nghĩ rằng tôi đã tìm thấy luồng công việc của mình bằng cách sử dụng git. – cgart

+0

Đừng ngại giải thích. Git cũng đơn giản như phiên bản phân tán có thể được. Một điều mà các đồng phát triển của bạn phải hiểu là mỗi bản sao của git repo là "svn-server" cục bộ. Sự cần thiết của đồng bộ hóa giữa "máy chủ" là lý do tại sao một số điều không thể với git. – Vanuan

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