2011-09-04 27 views
88

OK. Nếu tôi đang ở trên chi nhánh (giả sử working) và tôi muốn hợp nhất các thay đổi từ một chi nhánh khác (giả sử master), thì tôi chạy lệnh git-merge master khi đang ở trên chi nhánh working và các thay đổi sẽ được hợp nhất mà không phải rebasing lại lịch sử ở tất cả. Nếu tôi chạy git-rebase master, thì các thay đổi trong master được đặt lại để được đặt ở trên cùng của chi nhánh working của tôi. Nhưng nếu tôi muốn hợp nhất các thay đổi từ master nhưng rebase các thay đổi của tôi trong working để được trên đầu trang? Làm thế nào để làm điều đó? Nó có thể được thực hiện?Làm cách nào để bạn thay đổi các thay đổi của chi nhánh hiện tại trên các thay đổi đang được hợp nhất?

Tôi có thể chạy git-rebase working trên chi nhánh master để đặt các thay đổi của mình lên trên chi nhánh master, nhưng tôi muốn làm điều đó trong chi nhánh working và tôi không biết làm cách nào. Gần nhất mà tôi có thể nghĩ đến là tạo một chi nhánh mới từ master và sau đó rebase working 's thay đổi trên đó, nhưng sau đó tôi muốn có một chi nhánh mới thay vì thay đổi chi nhánh working.

Trả lời

173

Bạn đã có những gì rebase thực hiện ngược. git rebase master thực hiện những gì bạn đang yêu cầu - thực hiện các thay đổi trên nhánh hiện tại (kể từ phân kỳ chính) và phát lại chúng trên đầu trang master, sau đó đặt đầu của nhánh hiện tại làm người đứng đầu lịch sử mới đó. Nó không phát lại các thay đổi từ master trên đầu nhánh hiện tại.

+0

LOL. Ouch. Cảm ơn vì đã sửa tôi. Chỉ khi tôi nghĩ rằng tôi đã nhận được hang của tất cả ... –

+2

@ Jonathan nó mát mẻ. Đây là một chút của một chủ đề khó khăn. Nhân tiện, 'git rebase working' sẽ di chuyển các thay đổi' master' (sau thời điểm 'working' phân nhánh) nằm trên nhánh' working' - nhưng đó không phải là điều rất hợp lý để làm với ' master' :) – hobbs

41

Một cách khác để nhìn vào nó là xem xét git rebase master như:

rebase nhánh hiện trên đầu trang củamaster

Ở đây, 'master' là thượng nguồn chi nhánh, và điều đó giải thích tại sao, trong quá trình rebase, ours and theirs are reversed.

+0

Điều đó cũng giải thích tại sao LOCAL và REMOTE bị đảo ngược. Cảm ơn. – AVIDeveloper

+0

@AVIDeveloper trên LOCAL và REMOTE, bạn cũng có thể đọc http://stackoverflow.com/a/3052118/6309 – VonC

+4

@@ VonC: Cảm ơn. Đúng, sau khi dành một buổi chiều lẩm bẩm với bản thân mình "REMOTE là chi nhánh của tôi .. ĐỊA PHƯƠNG không phải của tôi", tất cả đều chìm vào.Thành thật mà nói, tôi sẽ thích nhìn thấy tên chi nhánh (hoặc viết tắt là SHA) thay vì REMOTE/LOCAL/ours/theirs/mine. Suy nghĩ của tôi cũng giống nhau về sự trái/phải của 'git difftool'. Kinda tắt chủ đề, nhưng đối với 'difftool' tôi dính vào git-meld và tận hưởng những cái tên như 'working-dir', 'stash @ {0}', cứ như vậy. – AVIDeveloper

3

Tôi vừa thực hiện những khoảnh khắc này trước theo cách sau:

  1. sao lưu công việc hiện tại của bạn cơ bản dở dang git checkout -b work-in-progress
  2. lấy mới nhất thay đổi git fetch origin/master
  3. loại bỏ bất kỳ thay đổi địa phương git reset --hard origin/master
  4. phát lại mới nhất thay đổi từ chủ git rebase origin/master
  5. phát lại tác phẩm của bạn đang tiến hành git rebase origin/work-in-progress
  6. đồng bộ hóa công việc của bạn đang tiến hành với bản gốc mới nhất git rebase origin/master
+0

Đã làm việc để tôi cập nhật chi nhánh làm việc hiện tại với mã mới nhất. – Dragunov

+0

Hướng dẫn này phản trực giác. Một nhánh mới đang hoạt động sau đó được thiết lập lại? Làm thế nào về một cái gì đó như: 1. đặt công việc không được cam kết của bạn trong một stash: 'git stash' 2. tìm thay đổi mới nhất:' git fetch' 3. rebase từ chi nhánh phía trước; trong trường hợp này, chủ: 'git rebase origin/master' 4. quay lại làm việc về những gì bạn đang làm:' git stash pop' EDIT, không thể thêm ngắt dòng trong phần bình luận. lol – NathanQ

+0

Có lẽ nó phản trực giác với bạn, nhưng bạn có thực sự đọc câu hỏi thực tế ở trên không? –

Các vấn đề liên quan