Làm thế nào để git hợp nhất sau khi cherry-pick hoạt động?

Hãy tưởng tượng rằng chúng ta có một masterchi nhánh.

Sau đó, chúng tôi tạo ra một newbranch

git checkout -b newbranch

và thực hiện hai cam kết mới thành newbranch: commit1 và commit2

Sau đó, chúng tôi chuyển sang làm chủ và thực hiện cherry-pick

git checkout master
git cherry-pick hash_of_commit1

Nhìn vào gitkchúng ta thấy rằng commit1 và phiên bản anh đào của nó có các giá trị băm khác nhau, vì vậy về mặt kỹ thuật, chúng là hai cam kết khác nhau.

Cuối cùng, chúng tôi hợp nhất newbranchthành master:

git merge newbranch

và thấy rằng hai cam kết với các giá trị băm khác nhau đã được hợp nhất mà không gặp vấn đề gì mặc dù chúng ngụ ý rằng các thay đổi tương tự nên được áp dụng hai lần, do đó một trong số chúng sẽ thất bại.

Có phải git thực sự phân tích thông minh nội dung của cam kết trong khi hợp nhất và quyết định rằng những thay đổi không nên được áp dụng hai lần hoặc những cam kết này được đánh dấu nội bộ như được liên kết với nhau?

Câu trả lời ngắn

Đừng lo lắng, Git sẽ xử lý nó.

Câu trả lời dài

Không giống như các ví dụ SVN ¹ , Git không lưu trữ các cam kết trong định dạng tam giác, nhưng là ảnh chụp dựa trên ^2,3 . Mặc dù SVN sẽ cố gắng áp dụng từng cam kết hợp nhất thành một bản vá (và không thành công, vì lý do chính xác mà bạn mô tả), Git thường có thể xử lý tình huống này.

Khi hợp nhất, Git sẽ cố gắng kết hợp các ảnh chụp nhanh của cả hai cam kết thành một ảnh chụp nhanh mới. Nếu một phần mã hoặc tệp giống hệt nhau trong cả hai ảnh chụp nhanh (nghĩa là vì một cam kết đã được chọn), Git sẽ không chạm vào nó.

Nguồn

¹ Skip-Deltas trong Subversion
² Khái niệm cơ bản về Git
³ Mô hình đối tượng Git

Sau khi hợp nhất như vậy, bạn có thể có các cam kết được chọn trong lịch sử hai lần.

Giải pháp để ngăn chặn điều này tôi trích dẫn từ bài viết khuyến nghị cho các nhánh có cam kết (cherry-Pick) sử dụng rebase trước khi hợp nhất:

git merge sau git cherry-pick: tránh các cam kết trùng lặp

Hãy tưởng tượng chúng ta có nhánh chính và nhánh b:

   o---X   <-- master
    \
     b1---b2---b3---b4   <-- b

Bây giờ chúng tôi rất cần các cam kết b1 và b3 trong master, nhưng không phải các cam kết còn lại trong b. Vì vậy, những gì chúng tôi làm là kiểm tra chi nhánh chính và cherry-pick cam kết b1 và b3:

$ git checkout master
$ git cherry-pick "b1's SHA"
$ git cherry-pick "b3's SHA"

Kết quả sẽ là:

   o---X---b1'---b3'   <-- master
    \
     b1---b2---b3---b4   <-- b

Hãy nói rằng chúng tôi thực hiện một cam kết khác về chủ và chúng tôi nhận được:

   o---X---b1'---b3'---Y   <-- master
    \
     b1---b2---b3---b4   <-- b

Nếu bây giờ chúng ta sẽ hợp nhất nhánh b thành master:

$ git merge b

Chúng tôi sẽ nhận được như sau:

   o---X---b1'---b3'---Y--- M  <-- master
     \                     /
      b1----b2----b3----b4   <-- b

Điều đó có nghĩa là những thay đổi được giới thiệu bởi b1 và b3 sẽ xuất hiện hai lần trong lịch sử. Để tránh điều đó, chúng ta có thể rebase thay vì hợp nhất:

$ git rebase master b

Mà sẽ mang lại:

   o---X---b1'---b3'---Y   <-- master
                        \
                         b2'---b4'   <-- b

Cuối cùng:

$ git checkout master
$ git merge b

cho chúng tôi:

   o---X---b1'---b3'---Y---b2'---b4'   <-- master, b

Chỉnh sửa EDIT được cho là bởi nhận xét của David Lemon