TL; DR;
Để tóm tắt (Như Benubird bình luận ), khi:
git checkout A
git rebase B # rebase A on top of B
local
là B
(rebase lên ),
remote
Là A
Và:
git checkout A
git merge B # merge B into A
local
là A
(hợp nhất thành ),
remote
Là B
Một rebase chuyển ours
(nhánh hiện tại trước khi bắt đầu rebase) và theirs
(nhánh trên đó bạn muốn rebase).
kutschkem chỉ ra rằng, trong bối cảnh GUI mergetool :
- tham chiếu cục bộ các cam kết bị từ chối một phần : "
ours
" (nhánh ngược dòng)
- từ xa đề cập đến các thay đổi đến : "
theirs
" - nhánh hiện tại trước khi rebase.
Xem hình minh họa trong phần cuối của câu trả lời này.
Đảo ngược khi rebase
Sự nhầm lẫn có thể liên quan đến sự đảo ngược ours
và theirs
trong một cuộc nổi loạn .
(trích xuất có liên quan)
git rebase
trang nam :
Lưu ý rằng hợp nhất rebase hoạt động bằng cách phát lại từng cam kết từ nhánh làm việc trên đỉnh của <upstream>
nhánh.
Bởi vì điều này, khi một cuộc xung đột hợp nhất xảy ra:
- phía được báo cáo là '
ours
' là loạt phim nổi loạn cho đến nay, bắt đầu bằng <upstream>
,
- và '
theirs
' là nhánh làm việc. Nói cách khác, các bên được hoán đổi.
Minh họa đảo ngược
Hợp nhất
x--x--x--x--x(*) <- current branch B ('*'=HEAD)
\
\
\--y--y--y <- other branch to merge
, chúng tôi không thay đổi chi nhánh hiện tại 'B', vì vậy những gì chúng tôi có vẫn là những gì chúng tôi đang làm việc (và chúng tôi hợp nhất từ một chi nhánh khác)
x--x--x--x--x---------o(*) MERGE, still on branch B
\ ^ /
\ ours /
\ /
--y--y--y--/
^
their
Trên một cuộc nổi loạn:
Nhưng trên một rebase , chúng tôi chuyển sang bên vì điều đầu tiên một rebase làm là kiểm tra nhánh ngược dòng! (để phát lại các cam kết hiện tại trên đầu trang)
x--x--x--x--x(*) <- current branch B
\
\
\--y--y--y <- upstream branch
git rebase upstream
Đầu tiên A sẽ thay đổi HEAD
B thành nhánh ngược dòng HEAD
(do đó chuyển đổi 'của chúng ta' và 'của họ' so với nhánh làm việc "hiện tại" trước đó.)
x--x--x--x--x <- former "current" branch, new "theirs"
\
\
\--y--y--y(*) <- upstream branch with B reset on it,
new "ours", to replay x's on it
và sau đó rebase sẽ phát lại 'cam kết' của họ trên nhánh B 'mới' của chúng tôi:
x--x..x..x..x <- old "theirs" commits, now "ghosts", available through reflogs
\
\
\--y--y--y--x'--x'--x'(*) <- branch B with HEAD updated ("ours")
^
|
upstream branch
Lưu ý: khái niệm "ngược dòng" là tập hợp dữ liệu tham chiếu (tất cả repo hoặc, như ở đây, một nhánh, có thể là một nhánh cục bộ ) từ đó dữ liệu được đọc hoặc dữ liệu mới được thêm / tạo.
' local
' và ' remote
' so với ' mine
' và ' theirs
'
Pandawood thêm vào trong các ý kiến :
Đối với tôi, câu hỏi vẫn còn, đó là "cục bộ" và ai là "từ xa" (vì thuật ngữ "của chúng tôi" và "của họ" không được sử dụng khi nổi loạn trong git, đề cập đến chúng dường như làm cho một câu trả lời khó hiểu hơn) .
GUI git mergetool
kutschkem thêm, và đúng như vậy:
Khi giải quyết xung đột, git sẽ nói điều gì đó như:
local: modified file and remote: modified file.
Tôi khá chắc chắn rằng câu hỏi nhằm vào định nghĩa của địa phương và từ xa tại thời điểm này. Tại thời điểm đó, dường như với kinh nghiệm của tôi rằng:
- tham chiếu cục bộ các cam kết bị từ chối một phần : "
ours
" (nhánh ngược dòng)
- từ xa đề cập đến các thay đổi đến : "
theirs
" - nhánh hiện tại trước khi rebase.
git mergetool
thực sự đề cập đến 'địa phương' và 'từ xa' :
Merging:
f.txt
Normal merge conflict for 'f.txt':
{local}: modified file
{remote}: modified file
Hit return to start merge resolution tool (kdiff3):
Chẳng hạn, KDiff3 sẽ hiển thị độ phân giải hợp nhất như vậy :
Và meld cũng sẽ hiển thị nó :
Tương tự cho VimDiff , hiển thị :
Gọi Vimdiff như là một mergetool với git mergetool -t gvimdiff. Các phiên bản gần đây của Git gọi Vimdiff với bố cục cửa sổ sau:
+--------------------------------+
| LOCAL | BASE | REMOTE |
+--------------------------------+
| MERGED |
+--------------------------------+
LOCAL
:
Một tệp tạm thời chứa nội dung của tệp trên nhánh hiện tại.
BASE
:
Một tệp tạm thời chứa cơ sở chung cho việc hợp nhất.
REMOTE
:
Một tệp tạm thời chứa nội dung của tệp sẽ được hợp nhất.
MERGED
:
Tập tin chứa các dấu xung đột.
Git đã thực hiện càng nhiều giải quyết xung đột tự động càng tốt và trạng thái của tệp này là sự kết hợp của cả hai LOCAL
và REMOTE
với các dấu xung đột xung quanh bất cứ điều gì mà Git không thể tự giải quyết.
Các mergetool
nên viết là kết quả của các giải pháp cho tập tin này.