Sự khác biệt giữa git pull và git pull --rebase

Thỉnh thoảng tôi bắt đầu sử dụng git và không hiểu hết những điều phức tạp. Câu hỏi cơ bản của tôi ở đây là tìm ra sự khác biệt giữa a git pullvà git pull --rebase, vì việc thêm --rebasetùy chọn dường như không làm điều gì đó rất khác: chỉ cần thực hiện một thao tác kéo.

Xin hãy giúp tôi hiểu sự khác biệt.

git pull= git fetch+ git mergechống theo dõi chi nhánh thượng nguồn

git pull --rebase= git fetch+ git rebasechống theo dõi chi nhánh thượng nguồn

Nếu bạn muốn biết làm thế nào git mergevà git rebasekhác nhau, đọc này .

Đôi khi chúng ta có một dòng ngược dòng / khởi động lại một nhánh mà chúng ta phụ thuộc vào. Đây có thể là một vấn đề lớn - gây ra xung đột lộn xộn cho chúng ta nếu chúng ta xuôi dòng.

Điều kỳ diệu là git pull --rebase

Một git pull bình thường là, nói một cách lỏng lẻo, một cái gì đó như thế này (chúng ta sẽ sử dụng một nguồn gốc được gọi là từ xa và một nhánh được gọi là foo trong tất cả các ví dụ này):

# assume current checked out branch is "foo"
git fetch origin
git merge origin/foo

Thoạt nhìn, bạn có thể nghĩ rằng một git pull --rebase thực hiện điều này:

git fetch origin
git rebase origin/foo

Nhưng điều đó sẽ không giúp ích gì nếu cuộc nổi loạn ngược dòng liên quan đến bất kỳ sự "đè bẹp" nào (có nghĩa là các bản vá lỗi của các xác nhận đã thay đổi, không chỉ là thứ tự của chúng).

Điều đó có nghĩa là git pull --rebase phải làm nhiều hơn thế một chút. Đây là một lời giải thích về những gì nó làm và làm thế nào.

Giả sử điểm xuất phát của bạn là thế này:

a---b---c---d---e  (origin/foo) (also your local "foo")

Thời gian trôi qua, và bạn đã thực hiện một số cam kết trên "foo" của riêng bạn:

a---b---c---d---e---p---q---r (foo)

Trong khi đó, trong một cơn thịnh nộ chống lại xã hội, người duy trì thượng nguồn không chỉ chống lại "foo" của mình, anh ta thậm chí còn sử dụng một hoặc hai quả bí. Chuỗi cam kết của anh ấy bây giờ trông như thế này:

a---b+c---d+e---f  (origin/foo)

Một git kéo vào thời điểm này sẽ dẫn đến hỗn loạn. Ngay cả một git lấy; git rebase origin / foo sẽ không cắt nó, bởi vì cam kết "b" và "c" ở một bên và cam kết "b + c" ở bên kia, sẽ xung đột. (Và tương tự với d, e và d + e).

Có gì git pull --rebasekhông, trong trường hợp này, đó là:

git fetch origin
git rebase --onto origin/foo e foo

Điều này mang lại cho bạn:

 a---b+c---d+e---f---p'---q'---r' (foo)

Bạn vẫn có thể có xung đột, nhưng chúng sẽ là xung đột thực sự (giữa p / q / r và a / b + c / d + e / f) và không xung đột do b / c xung đột với b + c, v.v.

Câu trả lời được lấy từ (và sửa đổi một chút):
http://gitolite.com/git-pull--rebase

Giả sử bạn có hai cam kết trong chi nhánh địa phương:

      D---E master
     /
A---B---C---F origin/master

Sau khi "git pull", sẽ là:

      D--------E  
     /          \
A---B---C---F----G   master, origin/master

Sau "git pull --rebase", sẽ không có điểm hợp nhất G. Lưu ý rằng D và E trở thành các cam kết khác nhau:

A---B---C---F---D'---E'   master, origin/master

Trong trường hợp đơn giản nhất không có va chạm

• với rebase: khởi động lại các cam kết cục bộ của bạn ontop của HEAD từ xa và không tạo ra một cam kết hợp nhất / hợp nhất
• không có / bình thường: hợp nhất và tạo ra một cam kết hợp nhất

Xem thêm:

man git-pull

Chính xác hơn, git pull chạy git fetch với các tham số đã cho và gọi git merge để hợp nhất các đầu nhánh được lấy vào nhánh hiện tại. Với --rebase, nó chạy git rebase thay vì git merge.

Xem thêm:
Khi nào tôi nên sử dụng git pull --rebase?
http://git-scm.com/book/en/Git-Branching-Rebasing

Đối với điều này là quan trọng để hiểu sự khác biệt giữa Hợp nhất và Rebase.

Sự nổi loạn là cách các thay đổi sẽ chuyển từ đầu phân cấp xuống dưới và hợp nhất là cách chúng chảy ngược lên trên.

Để biết chi tiết tham khảo - http://www.derekgourlay.com/archives/428