Git pull dẫn đến các thông báo "Hợp nhất chi nhánh" không liên quan trong nhật ký cam kết

Tôi đang làm việc với một nhà phát triển khác trong một dự án và chúng tôi đang sử dụng Github làm kho lưu trữ từ xa của mình. Tôi đang sử dụng máy Mac sử dụng git 1.7.7.3, anh ấy đang sử dụng Windows bằng git 1.7.6.

Đây là những gì đang xảy ra

1. Một trong số chúng tôi (hãy gọi anh ấy là nhà phát triển A, nhưng không quan trọng là người nào) đẩy một tập hợp các cam kết lên GitHub.
2. Người kia (nhà phát triển B) thực hiện một số cam kết cục bộ.
3. B hiện a git pull.
4. B hiện a git push.
5. Nhìn vào nhật ký lịch sử cam kết, tôi thấy Merge branch 'master' của github.com:foo/bar

Nhật ký cam kết có nhiều thông báo "Hợp nhất chi nhánh" theo thời gian và cũng hiển thị nhà phát triển B là các thay đổi cam kết mà nhà phát triển A đã thực hiện. Cách duy nhất mà chúng tôi đã tìm ra để ngăn chặn vấn đề này là thực hiện git pull --rebaseở bước 3, nhưng tôi không biết việc giảm tác dụng phụ sẽ dẫn đến điều gì. Đây là lần đầu tiên tôi làm việc trên git repo nhiều nhà phát triển, vậy đây có phải là hành vi bình thường không? Bất kỳ suy nghĩ về cách giải quyết vấn đề này?

Cam kết bạn đang thấy là hoàn toàn tốt. A pullchạy hiệu quả git fetchvà sau đó git mergehợp nhất thường xảy ra khi bạn chạy git pull.

Bạn có thể sử dụng phương pháp khôi phục thay vì hợp nhất thay thế, nhưng thông thường bạn nên tránh. Rebasing cho phép bạn giữ lịch sử tuyến tính, nhưng cũng loại bỏ bất kỳ thông tin nào về việc phân nhánh đã xảy ra ban đầu. Nó cũng sẽ khiến lịch sử của nhánh hiện tại được viết lại, tạo lại tất cả các cam kết không có trong nhánh đích (trong trường hợp của bạn là điều khiển từ xa). Vì các cam kết được tạo lại là các cam kết khác nhau , điều này có thể gây ra nhiều nhầm lẫn khi phát triển cùng với những người khác, đặc biệt là khi mọi người đã kiểm tra các phần của các cam kết đó trước khi chúng được viết lại (ví dụ với các nhánh tính năng). Vì vậy, theo nguyên tắc chung, bạn không bao giờ nên viết lại bất kỳ cam kết nào đã được đẩy.

Các cam kết bạn thấy ở đó để kết hợp hai (hoặc nhiều) nhánh. Hoàn toàn ổn nếu có một cam kết mà không làm gì khác sau đó hợp nhất nhiều nhánh. Trên thực tế, nó làm cho nó rất rõ ràng khi bạn có một cam kết hợp nhất kết hợp các nhánh khi xem lịch sử. So với việc phục hồi, hợp nhất cũng cho phép bạn xem hiệu quả lịch sử ban đầu khi nó được phát triển, bao gồm cả các nhánh thực tế đã cùng tồn tại.

Vì vậy, câu chuyện ngắn: Vâng, có các cam kết hợp nhất là hoàn toàn tốt và bạn không nên lo lắng về chúng.

Câu trả lời này đã được sửa đổi, vì sự hiểu biết, sơ đồ và kết luận của tôi không chính xác.

git pullgây ra các cam kết hợp nhất vì git đang hợp nhất. Điều này có thể được thay đổi bằng cách đặt các nhánh của bạn sử dụng rebase thay vì hợp nhất. Sử dụng rebase thay vì hợp nhất trên một pull cung cấp lịch sử tuyến tính hơn cho kho lưu trữ được chia sẻ. Mặt khác, cam kết hợp nhất thể hiện nỗ lực phát triển song song của chi nhánh.

Ví dụ, hai người đang làm việc trên cùng một chi nhánh. Chi nhánh bắt đầu là:

...->C1

Người đầu tiên hoàn thành công việc của họ và đẩy đến nhánh:

...->C1->C2

Người thứ hai hoàn thành công việc của họ và muốn thúc đẩy, nhưng không thể vì họ cần cập nhật. Kho lưu trữ cục bộ cho người thứ hai trông giống như sau:

...->C1->C3

Nếu kéo được đặt để hợp nhất, kho lưu trữ ngôi thứ hai sẽ trông như thế nào.

...->C1->C3->M1
      \      /
       ->C2->

Trong đó M1 là một cam kết hợp nhất. Lịch sử nhánh mới này sẽ được đẩy lên repo. Nếu thay vào đó, pull được đặt để rebase repo cục bộ sẽ trông giống như sau:

...->C1->C2->C3

Không có cam kết hợp nhất. Lịch sử đã được thực hiện tuyến tính hơn.

Cả hai lựa chọn đều phản ánh lịch sử của chi nhánh. git cho phép bạn chọn lịch sử nào bạn thích.

Thực sự có những nơi mà rebase có thể gây ra sự cố với các nhánh từ xa. Đây không phải là một trong những trường hợp đó. Chúng tôi thích sử dụng rebase vì nó đơn giản hóa lịch sử nhánh vốn đã phức tạp cũng như hiển thị phiên bản lịch sử liên quan đến kho lưu trữ được chia sẻ.

Bạn có thể đặt branch.autosetuprebase = luôn để git tự động thiết lập các nhánh từ xa của bạn dưới dạng rebase thay vì master.

git config --global branch.autosetuprebase always

Cài đặt này khiến git tự động tạo cài đặt cấu hình cho từng nhánh từ xa:

branch.<branchname>.rebase=true

Bạn có thể tự thiết lập điều này cho các chi nhánh từ xa đã được thiết lập.

git config branch.<branchname>.rebase true

Tôi muốn cảm ơn @LaurensHolst đã đặt câu hỏi và theo đuổi những phát biểu trước đây của tôi. Tôi chắc chắn đã tìm hiểu thêm về cách git hoạt động với các cam kết kéo và hợp nhất.

Để biết thêm thông tin về các cam kết hợp nhất, bạn có thể đọc Đóng góp cho một dự án trong ProGit-Book . Phần Nhóm nhỏ Riêng tư hiển thị các cam kết hợp nhất.

Bạn có thể làm:

git pull --rebase

Tuy nhiên, điều này sẽ luôn đặt các thay đổi của bạn lên hàng đầu của các cộng tác viên. Nhưng bạn sẽ không nhận được bất kỳ thông báo hợp nhất gây ô nhiễm nào.

Thực sự có một câu trả lời đơn giản hơn nhiều cho điều này. Chỉ cần nhà phát triển B kéo TRƯỚC KHI thực hiện cam kết của mình. Điều này sẽ ngăn các cam kết hợp nhất đó, vì chúng được gây ra bởi lịch sử bạn đã tạo trên repo cục bộ của mình từ cam kết cục bộ của bạn đang cố gắng hợp nhất với lịch sử của các cam kết trên repo từ xa. Nếu bạn nhận được thông báo cho biết điều gì đó dọc theo dòng 'thay đổi sẽ bị ghi đè' khi thực hiện kéo, điều đó có nghĩa là cả hai bạn đã chạm vào cùng một tệp, vì vậy hãy làm như sau:

git stash
git pull
git stash pop

thì bạn có thể giải quyết mọi xung đột hợp nhất nếu có.

Thực hiện kéo git sẽ chèn các thông báo "Hợp nhất chi nhánh", đó chỉ là những gì nó làm. Bằng cách kéo git, bạn đã hợp nhất nhánh từ xa vào nhánh cục bộ của mình.

Khi bạn thực hiện kéo git và có xung đột, nhật ký git sẽ hiển thị các bản cập nhật cho các tệp bị xung đột do người dùng đã giải quyết xung đột. Tôi cho rằng điều này là do người khắc phục xung đột cam kết lại tệp.

Theo như tôi biết đó chỉ là cách git hoạt động, và không có cách nào xung quanh nó.

Rebasing sẽ xóa lịch sử git, vì vậy bạn sẽ không thể biết thời điểm hợp nhất xảy ra.