Tôi có nên git hợp nhất phát triển thành chính và sau đó quay lại sau khi gắn thẻ không?

Question

Câu hỏi đặt ra là - cách đạt được phiên bản chính xác (được hiển thị với git describe) trên develop sau khi tôi hợp nhất nó thành master và được gắn thẻ master.

Tôi sử dụng phân nhánh git chung - master để sản xuất. Giả sử git describe hiển thị 1.5 trên master và sau khi hợp nhất với develop, master hiển thị 1.5-234-g1e894af.
Vì vậy, tôi tạo thẻ được chú thích mới với git tag -a 1.6 và do đó git describe master hiện hiển thị 1.6.

NHƯNG: git describe develop vẫn hiển thị 1.5-something, điều kỳ lạ đối với tôi - nó có cùng cam kết như trong master - tại sao git cho rằng nó vẫn thuộc về phiên bản 1.5?

Không có gì tốt hơn đi vào bộ não của tôi vì vậy tôi chỉ hợp nhất vào phát triển, và sau đó phát triển cho thấy phiên bản 1.6-2-... được chấp nhận nhưng tạo thêm 1 cam kết hợp nhất vô dụng và cảnh báo tôi về "hợp nhất được đệ quy" không có ý nghĩa để làm, nhưng làm thế nào để đạt được phiên bản chính xác sau đó?

Answer 1

Xét git describe là về "việc tìm kiếm các từ khóa gần đây nhất mà có thể truy cập từ một cam kết", có vẻ như ok mà một git describe trên develop lấy lại cho master tại một cam kết mà thẻ mới 1.6 của bạn vẫn chưa được thiết lập.

m(1.5)--m--m--m(1.6, master) 
\   /
    d-------d--d (develop)   => git describe develop will return 1.5-xxx 

Sau khi sáp nhập tổng thể để phát triển

m(1.5)--m--m--m(1.6, master) 
\   /\ 
    d-------d--d---d (develop)  => git describe develop will return 1.6-xxx 

Nếu người đóng góp khác không làm việc trên develop, bạn có thể xem xét rebasingdevelop chi nhánh trên đầu trang của master, để nhận lại thẻ dự kiến ​​của bạn. (git rebase)

m(1.5)--m--m--m(1.6, master) 
       \    
       d--d--d (develop) => git describe develop will return 1.6-xxx 

Answer 2

Có vẻ như đã xảy ra sự cố với việc sử dụng git của bạn. Nếu bạn đang sáp nhập develop-master, nhưng không bao giờ master-develop, sau đó master là miễn phí để phân ra - bất kỳ thay đổi nào trên master sẽ không bao giờ nhận được vào develop chi nhánh. Vì vậy, tuyên bố của bạn rằng họ có cùng một cam kết là sai. Sử dụng biểu đồ của VonC,

m(1.5)--m1--m2--m(1.6, master) 
\   /
    d-------d----d (develop) 

Các cam kết mà tôi đã gắn nhãn "m1" và "m2" sẽ không bao giờ bị "phát triển". Nếu không có cam kết như vậy - bạn không làm việc trên master - thế thì khi bạn hợp nhất phát triển thành master, nó phải là sự hợp nhất nhanh về phía trước; họ sẽ có cùng cam kết sau đó và mọi thứ sẽ hoạt động như bạn đã mô tả.

Giải pháp phụ thuộc vào quy trình làm việc bạn đang cố gắng đạt được, tất nhiên.

• Cá nhân, tôi sẽ vào thời điểm này hoặc xóa và tạo lại chi nhánh develop bắt đầu từ bậc thầy, hoặc nhanh chóng chuyển tiếp nó đến 1.6, để khi bạn tiếp tục làm việc trên develop bạn có cấu trúc này:

  m(1.5)--m1--m2---m(1.6, master) 
  \   /\ 
      d-------d----d d--d (develop) 
  

  Sau đó, git describe sẽ xem xét nó dựa trên 1,6 như thực tế.

• Nếu ý định của bạn là develop là chi nhánh phát triển liên tục và master là chi nhánh "phát hành" không thường xuyên, thì bạn nên tránh tạo bất kỳ cam kết nào như m1 và m2; giống như bạn làm, git describe là cho bạn biết chính xác điều gì đó khác biệt.

Tôi không phải là chuyên gia về sử dụng git trong các nhóm, vì vậy hãy tận dụng tất cả điều này với một hạt muối.