Sự khác biệt giữa các lệnh "git pull" khi kéo từ gốc?


82

Sự khác biệt giữa các lệnh này là gì ?:

# 1
git pull
# 2
git pull origin
# 3
git pull origin master
# 4
git pull origin/master
# 5
git pull origin HEAD:master

Vâng, ngay cả sau khi đọc trang người đàn ông, Nó không phải trong mọi trường hợp rõ ràng điều gì xảy ra chính xác. Ví dụ: Ý nghĩa của việc git pullkhông có cấu hình ngược dòng là gì? (Trang người đàn ông chỉ cho biết mặc định là phần ngược dòng được định cấu hình.)
michas

Tóm lại: 1. sẽ thất bại nếu không có cấu hình cho nhánh hiện tại và nếu không sẽ giống như 2. với tên từ xa. 2. sẽ sử dụng cấu hình tìm nạp mặc định cho điều khiển từ xa đã cho (và hợp nhất điều khiển đầu tiên), ngược lại trong 3. bạn chỉ định những gì cần tìm nạp và hợp nhất. 4. không hợp lệ, imho. 5. (nếu nó hoạt động), sẽ đặt HEAD từ xa vào refs / remotes / origin / master và hợp nhất nó.
andi5

2
Bỏ phiếu để mở lại câu hỏi này vì rất tiếc, đó là một trong những kết quả tìm kiếm site:stackoverflow.com git Difference "git pull" "git pull origin master".

Câu trả lời:


81

git pulllà một lệnh tiện lợi, đang làm những việc khác nhau cùng một lúc. Về cơ bản, nó chỉ là sự kết hợp của git fetch, kết nối với kho lưu trữ từ xa và tìm nạp các cam kết mới và git merge(hoặc git rebase) kết hợp các cam kết mới vào chi nhánh cục bộ của bạn. Bởi vì hai lệnh khác nhau liên quan đến ý nghĩa của git pullkhông phải lúc nào cũng rõ ràng.

Bạn có thể cấu hình ngược dòng cho một nhánh cục bộ. Sau một bản sao mới, bạn sẽ có một nhánh cục bộ "chủ", một "nguồn gốc" từ xa và nhánh chính của bạn có "nguồn gốc / chủ" là ngược dòng. Tôi giả sử thiết lập này bên dưới. (Bạn có thể xem cấu hình ngược dòng của mình bằng git branch -vvhoặc bằng cách xem .git / config.)

Bây giờ cho câu hỏi của bạn:

  1. git pull= git fetch origin+ git merge origin/master(hoặc bất cứ điều gì ngược dòng của bạn)
  2. git pull origin= git pull(miễn là nguồn gốc là từ xa ngược dòng của bạn)
  3. git pull origin master= git fetch origin master+git merge FETCH_HEAD
  4. git pull origin/master : không hợp lệ trừ khi bạn có điều khiển từ xa có tên "origin / master"
  5. git pull origin HEAD:master: Cố gắng đặt lại trực tiếp trang cái cục bộ của bạn thành bất kỳ HEAD nào trỏ đến tại điểm gốc. (Đừng làm điều này.)

2
Tại sao thực hiện git pull origin HEAD:mastermột ý tưởng tồi?
Ryan Edwards

2
Phía bên phải được cho là một nhánh xa. Xem cảnh báo trong trang người đàn ông. Hãy chắc chắn rằng bạn biết những gì bạn đang làm nếu bạn sử dụng này.
michas

nếu tôi đã được ở someother chi nhánh sẽ git pullkéo mà chi nhánh hoặc thạc sĩ
aWebDeveloper

1
@aWebDeveloper: Đối với sự hoàn chỉnh: git pull origin HEAD:mastervề cơ bản (theo nghĩa đen cho đến khi tập lệnh được viết lại bằng C trong Git 2.6) chuyển HEAD:mastermột phần cho git fetch, để thực hiện những gì git fetchcho bước đó; sau đó hợp nhất hoặc giảm giá bằng cách sử dụng băm cam kết mà git fetchbước đã có. Refspec là nguồn: đích , do đó HEADđược cung cấp cho Git khác để dịch. Vì vậy, nó phụ thuộc vào Git khác - nhưng thường Git khác HEADlà một tên cho nó master. Nếu bạn không phải của riêng mình master, thì merge-hoặc-rebase sử dụng lần tìm nạp cập nhật master( đích ) của bạn (trừ khi fetchlỗi).

1
Một điều khác cần cẩn thận: không bao giờ làm git pull origin br1 br2. Nó trông giống như thế này git checkout br1; git pull origin; git checkout br2; git pull origin- nhưng nó không! Thay vào đó, trên thực tế, nó thực hiện : git fetch origin && git merge origin/br1 origin/br2, kết hợp cả hai kết quả tìm nạp vào nhánh hiện tại của bạn , thứ mà Git gọi là hợp nhất bạch tuộc . Đây không bao giờ là điều mà bất cứ ai muốn. Có lẽ git pullnên từ chối lệnh hoàn toàn (bất cứ ai thực sự không muốn nó có thể chạy lấy đầu tiên, sau đó hợp nhất).

18

pullVề cơ bản, A là một fetch(đưa một số cam kết và các đối tượng được liên kết từ một kho lưu trữ từ xa vào của bạn) và sau đó là một hoạt động "áp dụng" chúng vào bản sao làm việc của bạn. Giai đoạn thứ hai, theo mặc định, được thực hiện bằng cách sử dụng a mergenhưng bạn có thể đặt pull.rebasebiến thành truevà sau đó nó sẽ rebase thay thế.

Có hai câu hỏi bật lên với pulllệnh. Đầu tiên là, chính xác những gì được tìm nạp? Và thứ hai là, nó áp dụng những thay đổi này vào bản sao làm việc của tôi như thế nào? Hãy bắt đầu với cái đầu tiên. Dạng đầy đủ của lệnh là

git pull [options] [repository] [<refspec>...]

optionscác cờ kiểm soát hành vi (ví dụ --rebase để làm cho pullhoạt động như một fetch+ rebasengay cả khi pull.rebasefalse).

repository là tên (hoặc URL) của điều khiển từ xa để tìm nạp.

refspecs là một cách ngắn gọn để chỉ định những tham chiếu nào trên điều khiển từ xa bạn muốn tìm nạp và bạn muốn đặt chúng ở đâu trong bản sao làm việc hiện tại của mình.

Trước tiên, hãy lấy mẫu rõ ràng nhất.

 git pull origin branch1:branch2

Về cơ bản, điều này nói rằng, hãy kéo các thay đổi trong tham chiếu branch1trên điều khiển từ xa được gọi originvà sau đó hợp nhất (hoặc rebase) chúng vào nhánh cục bộ branch2. Ví dụ: nếu git pull origin master:devtôi sẽ nhận được một nhánh cục bộ được gọi là nhánh devnày sẽ trỏ đến cùng một cam kết như master. Chi tiết về cách chỉ định refspec có tại đây . Bạn có thể sử dụng a *để chỉ ra nhiều refspec. Ví dụ, git pull origin refs/heads/*:refs/heads/*sẽ kéo tất cả các nhánh (được lưu trữ dưới heads) vào kho lưu trữ cục bộ và hợp nhất chúng thành các nhánh cục bộ có cùng tên.

Bây giờ, chúng ta hãy loại bỏ từng đối số một để thảo luận về cách hoạt động của mặc định. Đầu tiên, chúng ta có thể xóa đích khỏi refspec của mình và chỉ cần nói git pull origin branch1. Điều này đầu tiên sẽ fetchchuyển nhánh từ xa branch1vào kho lưu trữ cục bộ của bạn. Nó sẽ có sẵn dưới dạng một tham chiếu tạm thời được gọi là FETCH_HEAD. Sau đó, nó sẽ chạy git merge FETCH_HEADsẽ hợp nhất nhánh này vào nhánh đang hoạt động hiện tại của bạn (tức là HEAD). Điều này thường được thực hiện khi bạn đang ở trong một chi nhánh cục bộ và muốn tìm nạp các thay đổi từ điều khiển từ xa vào chi nhánh đó.

Bây giờ, hãy bỏ branch1hoàn toàn và chỉ nói git pull origin. Bây giờ, git biết nơi tìm nạp từ ( origin) nhưng không biết tìm nạp cái gì. Nó có một số mặc định cho điều này. Kịch bản nhất là khi tệp cấu hình của bạn có một branch.<name>.mergetùy chọn (đây là một mục được gọi mergebên trong một phần như [branch "master"]). Nếu vậy, nó sẽ sử dụng refspec ở đó cho hoạt động.

Nếu chúng ta bỏ originhoàn toàn và chỉ nói đơn giản git pull, nó sẽ kiểm tra cấu hình để xem có cấu hình branch.<name>.remotenào chỉ định điều khiển từ xa nào không. Điều đó cùng với những điều ở trên cho bạn biết những gì cần kéo.

Điểm # 4 và # 5 của bạn không phải là trường hợp sử dụng bình thường. Điều đầu tiên có ý nghĩa nếu bạn có một điều khiển từ xa được gọi là origin/masterđiều khó xảy ra. origin/masterthường một tham chiếu địa phương theo dõi các masterchi nhánh trên điều khiển từ xa origin. Thứ hai sẽ cố gắng tìm nạp các thay đổi trên HEADđiều khiển từ xa (nhánh mặc định thường là master) và sau đó hợp nhất chúng vào cục bộ của bạn master. Mặc dù đây có thể là điều bạn muốn làm thường xuyên, nhưng lệnh này khá độc đáo và không phải là thứ tôi đã thấy được sử dụng thường xuyên.

Tôi đã bỏ qua một vài chi tiết nhưng những điều này sẽ đủ để giúp bạn an toàn và thoải mái trong công việc hàng ngày. Để biết tất cả các chi tiết đẫm máu, bạn có thể xem trang hướng dẫn sử dụng git pull.


"Ví dụ: nếu tôi nói git pull origin master: dev, tôi sẽ nhận được một nhánh cục bộ có tên là dev sẽ trỏ đến cùng một cam kết với master." Vì vậy, bạn sẽ tải xuống một nhánh mới có tên là dev và nó sẽ trỏ đến master?
user33276346

Không, bạn sẽ lấy chi nhánh mastertừ điều khiển từ xa nhưng nó sẽ được gọi là devcục bộ.
Noufal Ibrahim

git pull origin refs/heads/*:refs/heads/*không hiệu quả với tôi, và tôi đã nhận được no matches found: refs/heads/*:refs/heads/*. Tôi cũng đã thử git pull origin refs/remotes/origin/*:refs/heads/*, nhưng điều đó cũng không hiệu quả. Tôi không nghĩ rằng việc kéo tất cả các nhánh trên điều khiển từ xa trong một lệnh là có thể thực hiện được và việc hợp nhất / khôi phục tiếp theo của tất cả các nhánh này thành các nhánh cục bộ tiếp theo của chúng cũng không.
Ben Butterworth
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.