git kéo từ chủ vào nhánh phát triển


496

Tôi có một nhánh gọi là dmgr2 (phát triển) và tôi muốn lấy từ nhánh chính (trang trực tiếp) và kết hợp tất cả các thay đổi vào nhánh phát triển của mình. Có cách nào tốt hơn để làm điều này? đây là những gì tôi đã lên kế hoạch thực hiện, sau khi cam kết thay đổi:

git checkout dmgr2
git pull origin master

điều này sẽ kéo các thay đổi trực tiếp vào nhánh phát triển của tôi, hoặc tôi có sai điều này không?


1
đầu tiên cam kết tất cả các thay đổi của bạn trong nhánh dmgr2. và sau đó trỏ đến chủ 1.git thanh toán tổng thể và sau đó nhận được mới nhất thay đổi 2.git kéo 3.git merge dmgr2 4.git đẩy -u bậc thầy gốc Và sau đó quay trở lại của bạn dmgr2 5.git thanh toán dmgr2
mat_vee

tôi đã cam kết tất cả các thay đổi của tôi đối với chi nhánh dmgr2, xin lỗi đã quên thêm điều đó
Matthew Colley

1
Nếu tôi thực hiện bước 4, bạn có muốn thay đổi sự phát triển của mình thành chủ không? tôi không muốn làm điều đó
Matthew Colley

Vì vậy, những gì bạn đang nói là bạn muốn mang những thay đổi từ nhánh chính của bạn, vào nhánh dev của bạn?
JcKelley

9
Chuyển sang devchi nhánh với a git checkout dev. Sau đó git pull --rebase origin master. Nếu bạn may mắn, sẽ không có xung đột và nhà phát triển sẽ có những thay đổi mới nhất từ ​​chủ.
jww

Câu trả lời:


724

Các bước bạn liệt kê sẽ hoạt động, nhưng có một cách dài hơn cung cấp cho bạn nhiều tùy chọn hơn:

git checkout dmgr2      # gets you "on branch dmgr2"
git fetch origin        # gets you up to date with origin
git merge origin/master

Các fetchlệnh có thể được thực hiện bất cứ lúc nào trước merge, ví dụ, bạn có thể trao đổi thứ tự của các lấy và thanh toán, bởi vì fetchchỉ đi giao cho tên từ xa ( origin) và nói với nó: "gimme tất cả mọi thứ bạn có mà tôi không ", Tức là tất cả các cam kết trên tất cả các chi nhánh. Chúng được sao chép vào kho lưu trữ của bạn, nhưng được đặt tên origin/branchcho bất kỳ nhánh nào có tên branchtrên điều khiển từ xa.

Tại thời điểm này, bạn có thể sử dụng bất kỳ người xem nào ( git log, gitkv.v.) để xem "những gì họ có" mà bạn không có và ngược lại. Đôi khi điều này chỉ hữu ích cho Cảm giác mờ ấm áp ("ah, vâng, thực tế đó là những gì tôi muốn") và đôi khi nó rất hữu ích để thay đổi chiến lược hoàn toàn ("whoa, tôi chưa muốn RẤT NHIỀU thứ đó").

Cuối cùng, mergelệnh lấy cam kết đã cho, mà bạn có thể đặt tên là origin/master, và làm bất cứ điều gì cần thiết để đưa vào cam kết đó và tổ tiên của nó, cho bất kỳ nhánh nào bạn đang ở khi bạn chạy merge. Bạn có thể chèn --no-ffhoặc --ff-onlyđể ngăn chuyển tiếp nhanh hoặc chỉ hợp nhất nếu kết quả là chuyển tiếp nhanh, nếu bạn muốn.

Khi bạn sử dụng trình tự:

git checkout dmgr2
git pull origin master

các pullchỉ thị lệnh git để chạy git fetch, và sau đó tương đương với đạo đức của git merge origin/master. Vì vậy, điều này gần giống như thực hiện hai bước bằng tay, nhưng có một số khác biệt tinh tế có lẽ không quá liên quan đến bạn. (Đặc biệt là fetchbước chạy bởi pullmang trên chỉ origin/master , và nó không cập nhật các ref trong repo của bạn: 1 bất kỳ cam kết mới gió lên gọi đến chỉ bởi sự đặc biệt FETCH_HEAD. Tài liệu tham khảo)

Nếu bạn sử dụng nhiều thứ rõ ràng hơn git fetch origin(sau đó tùy chọn nhìn xung quanh) và sau đó git merge origin/mastertrình tự, bạn cũng có thể mang đến địa phương của riêng bạn mastervới điều khiển từ xa, chỉ với một lần fetchchạy trên mạng:

git fetch origin
git checkout master
git merge --ff-only origin/master
git checkout dmgr2
git merge --no-ff origin/master

ví dụ.


1 Phần thứ hai này đã được thay đổi. Tôi nói "cố định" đã sửa lỗi 1.8.4, hiện đang cập nhật các tham chiếu "nhánh từ xa" một cách cơ hội. (Đó là, như các ghi chú phát hành nói, một quyết định thiết kế có chủ ý bỏ qua bản cập nhật, nhưng hóa ra nhiều người thích git đó cập nhật nó hơn. Nếu bạn muốn SHA-1 chi nhánh từ xa cũ, nó mặc định được lưu trong và do đó có thể phục hồi từ, reflog. Điều này cũng cho phép một tính năng git 1.9 / 2.0 mới để tìm kiếm các cuộc nổi loạn ngược dòng.)


28
Tôi chỉ yêu cầu một người bạn, bạn sẽ làm thế nào để hoàn tác khối mã đầu tiên bạn có ở đây (thanh toán / tìm nạp / hợp nhất)?
Bradshaw giàu

10
@RichBradshaw: git checkoutthường không phá hủy và thông thường không có lý do nào để hoàn tác a git fetch, vì vậy có vẻ như bạn đang hỏi làm thế nào để sao lưu một cam kết hợp nhất. Câu trả lời tương tự như đối với các cam kết khác: git resethoặc git revert. Đối với những thay đổi chưa được công bốgit reset thường là phương pháp tốt nhất; cho những thay đổi mà người khác đã có, git revertcó thể tốt hơn, nhưng hãy xem lời khuyên của Linus Torvald về việc hoàn nguyên hợp nhất: kernel.org/pub/software/scm/git/docs/howto/iêu
torek

2
@ WEDoTDD: Tôi không hiểu câu hỏi. Có một số lệnh để xem biểu đồ cam kết ( gitk, git log --graphcó hoặc không --oneline, v.v.) và bạn có thể git showhoặc git show -mmột cam kết hợp nhất hoặc sử dụng git diff. Trong tất cả các trường hợp này, bạn chỉ định chương trình khi bạn nhập lệnh trên dòng lệnh.

1
@torek: đã thử cách của bạn: chi nhánh git checkout và sau đó git pull master master, nhưng nó đã kéo tất cả các thay đổi chính thành một thay đổi duy nhất nên được thực hiện lại cục bộ, thay vì kéo chúng bằng lịch sử và thông báo cam kết của chúng, vì vậy sau khi cập nhật cục bộ làm chủ và chuyển sang nhánh, "git rebase master" thực hiện công việc với tất cả các xung đột để giải quyết, sau đó tôi thêm vào "git pull --rebase" và xử lý lại tất cả các xung đột, và sau đó git đẩy nhánh gốc để căn chỉnh tất cả. Tôi đoán nên có cách tốt hơn cho nó - tôi có đúng không?
dùng10556443

1
@torek: Tôi đồng ý kết quả tôi nhận được là một quá trình mệt mỏi buộc tôi phải xử lý việc lặp lại rebase & merge & ... mỗi khi tôi muốn nhận được cập nhật từ chủ ... Nhưng, cách tôi đề xuất, tôi thừa nhận là nhiều dễ dàng hơn, có tất cả các thay đổi theo một thay đổi không được cam kết duy nhất tại chi nhánh địa phương mà không giữ trật tự / lịch sử cam kết chính. Tôi sẽ rất vui khi biết về đề xuất tốt hơn về cách sử dụng "tìm nạp" và theo dõi chủ mà không cần sử dụng "kéo", v.v.
user10556443

14

Tình huống : Làm việc trong chi nhánh địa phương của tôi, nhưng tôi thích cập nhật thông tin trong ngành phát triển có tên dev.

Giải pháp : Thông thường, tôi thích làm:

git fetch
git rebase origin/dev

15
Với tuyên bố từ chối thông thường, việc rebase chỉ nên được thực hiện nếu nhánh cục bộ chỉ là cục bộ, nghĩa là chưa được đẩy đi bất cứ đâu khi nó viết lại lịch sử.
Locus

8

Điều này làm việc cho tôi. Để nhận mã mới nhất từ ​​chủ đến chi nhánh của tôi

git rebase origin/master


Đừng quên git fetch originđầu tiên.
lenooh

3

Kịch bản :

Tôi có cập nhật tổng thể và cập nhật chi nhánh, tôi muốn chi nhánh của mình theo dõi chủ nhân với việc nổi loạn, để giữ cho tất cả lịch sử được theo dõi đúng cách, hãy gọi cho chi nhánh của tôi Mybranch

Giải pháp :

git checkout master    
git pull --rebase    
git checkout Mybranch    
git rebase master
git push -f origin Mybranch
  • cần giải quyết tất cả các xung đột với git mergetool &, git rebase --continue, git rebase --skip, git add -u, theo tình huống và gợi ý git, cho đến khi tất cả được giải quyết

(chỉnh sửa đến giai đoạn cuối, với sự giúp đỡ của Tzachi Cohen, sử dụng lực lượng "-f" git để "cập nhật lịch sử" tại máy chủ)

bây giờ chi nhánh nên được liên kết với chủ và được khởi động lại, cũng được cập nhật từ xa, vì vậy tại nhật ký git không có "phía sau" hoặc "phía trước", chỉ cần xóa tất cả các tệp * xung đột cục bộ để giữ thư mục "sạch"

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.