Tại sao git không thể thiết lập lại cứng / mềm theo đường dẫn?

$ git reset -- <file_path> có thể thiết lập lại theo đường dẫn.

Tuy nhiên, $ git reset (--hard|--soft) <file_path>sẽ báo cáo một lỗi như dưới đây:

Cannot do hard|soft reset with paths.

Bởi vì không có điểm nào (các lệnh khác đã cung cấp chức năng đó rồi) và nó làm giảm khả năng thực hiện sai một cách tình cờ.

Một "thiết lập lại cứng" cho một đường dẫn chỉ được thực hiện với git checkout HEAD -- <path>(kiểm tra phiên bản hiện có của tệp).

Thiết lập lại mềm cho đường dẫn không có ý nghĩa.

Một thiết lập lại hỗn hợp cho một đường dẫn là những gì git reset -- <path>làm.

Bạn có thể hoàn thành những gì bạn đang cố gắng sử dụng git checkout HEAD <path>.

Điều đó nói rằng, thông báo lỗi được cung cấp không có ý nghĩa với tôi (vì nó git resethoạt động tốt trên các thư mục con) và tôi thấy không có lý do tại sao git reset --hardkhông nên làm chính xác những gì bạn yêu cầu.

Câu hỏi làm thế nào đã được trả lời , tôi sẽ giải thích phần tại sao .

Vì vậy, git reset làm gì? Tùy thuộc vào các tham số được chỉ định, nó có thể làm hai việc khác nhau:

• Nếu bạn chỉ định một đường dẫn, nó sẽ thay thế các tệp phù hợp trong chỉ mục bằng các tệp từ một cam kết (theo mặc định). Hành động này hoàn toàn không ảnh hưởng đến cây làm việc và thường được sử dụng như đối diện với git add.

• Nếu bạn không chỉ định một đường dẫn, nó sẽ di chuyển đầu nhánh hiện tại đến một xác nhận đã xác định và cùng với đó , tùy ý đặt lại chỉ mục và cây làm việc về trạng thái của cam kết đó. Đây thêm hành vi được điều khiển bởi các tham số chế độ:
  --soft : không chạm vào chỉ mục và cây làm việc.
  --mixed (mặc định): đặt lại chỉ mục nhưng không phải cây làm việc.
  --hard : đặt lại chỉ mục và cây làm việc.
  Ngoài ra còn có các tùy chọn khác, xem tài liệu cho danh sách đầy đủ và một số trường hợp sử dụng.

  Khi bạn không chỉ định một cam kết, nó sẽ mặc định là CHÍNH, vì vậy git reset --softsẽ không làm gì cả, vì đó là lệnh để di chuyển đầu đến CHÍNH (về trạng thái hiện tại). git reset --hardmặt khác, có ý nghĩa do tác dụng phụ của nó, nó nói di chuyển đầu đến CHÍNH và đặt lại chỉ mục và cây làm việc thành CHÍNH.

  Tôi nghĩ bây giờ nên rõ ràng tại sao hoạt động này không dành cho các tệp cụ thể - bản chất của nó là di chuyển đầu chi nhánh ở vị trí đầu tiên, đặt lại cây làm việc và chỉ mục là chức năng phụ.

Hãy chắc chắn rằng bạn đặt dấu gạch chéo giữa gốc hoặc ngược dòng (nguồn) và nhánh thực tế:

git reset --hard origin/branch

hoặc là

git reset --hard upstream/branch`

Có một lý do rất quan trọng đằng sau đó: các nguyên tắc checkoutvàreset .

Theo thuật ngữ Git, thanh toán có nghĩa là "đưa vào cây làm việc hiện tại". Và với việc git checkoutchúng ta có thể lấp đầy cây làm việc với dữ liệu từ bất kỳ khu vực nào , là từ một cam kết trong kho lưu trữ hoặc các tệp riêng lẻ từ một cam kết hoặc khu vực tổ chức (đó là mặc định).

Đổi lại, git reset không có vai trò này. Như tên cho thấy, nó sẽ thiết lập lại ref hiện tại nhưng luôn có kho lưu trữ dưới dạng nguồn, độc lập với "Reach" (--soft, --mixed hoặc --hard).

Tóm tắt lại

• kiểm tra : Từ bất cứ đâu (index / repo commit) -> cây làm việc
• đặt lại : Cam kết Repo -> Ghi đè ĐẦU (và tùy chọn chỉ mục và cây làm việc)

Do đó, điều có thể hơi khó hiểu là sự tồn tại của git reset COMMIT -- files"ghi đè ĐẦU" chỉ với một số tệp không có ý nghĩa!

Trong trường hợp không có lời giải thích chính thức, tôi chỉ có thể suy đoán rằng các nhà phát triển git thấy rằng đó resetvẫn là tên tốt nhất của lệnh để loại bỏ các thay đổi được thực hiện cho khu vực tổ chức và, với nguồn dữ liệu duy nhất là kho lưu trữ, sau đó " hãy mở rộng chức năng "thay vì tạo một lệnh mới.

Vì vậy, bằng cách nào đó git reset -- <files>đã có một chút đặc biệt: nó sẽ không ghi đè lên ĐẦU. IMHO tất cả các biến thể như vậy sẽ là ngoại lệ. Ngay cả khi chúng ta có thể hình dung một --hardphiên bản, những người khác (ví dụ --soft) sẽ không có ý nghĩa.

Giải trình

Các git resetnhãn hiệu danh sách 3 cách gọi:

• 2 là file-khôn ngoan: Chúng không ảnh hưởng đến cây làm việc , nhưng chỉ hoạt động trên các tệp trong chỉ mục được chỉ định bởi <paths>:

  • git reset [-q] [<tree-ish>] [--] <paths>..
  • git reset (--patch | -p) [<tree-ish>] [--] [<paths>...]

• 1 là cam kết khôn ngoan: Hoạt động trên tất cả các tệp trong tham chiếu <commit>và có thể ảnh hưởng đến cây làm việc:

  • git reset [<mode>] [<commit>]

Không có chế độ gọi chỉ hoạt động trên các tệp được chỉ định và ảnh hưởng đến cây làm việc.

Giải pháp thay thế

Nếu bạn muốn cả hai:

• Đặt lại phiên bản chỉ mục / bộ đệm của tệp (s)
• Kiểm tra (các) tệp (nghĩa là làm cho cây làm việc khớp với chỉ mục và phiên bản cam kết)

Bạn có thể sử dụng bí danh này trong tệp cấu hình git của mình:

[alias]
  reco   = !"cd \"${GIT_PREFIX:-.}\" && git reset \"$@\" && git checkout \"$@\" && git status --short #"  # Avoid: "fatal: Cannot do hard reset with paths."

Sau đó, bạn có thể thực hiện một trong:

$ git reco <paths>

$ git reco <branch/commit> <paths>

$ git reco -- <paths>

(Mnenonic cho reco: reset && check out)

git reset --soft HEAD ~ 1 tên tệp hoàn tác cam kết nhưng các thay đổi vẫn ở trạng thái cục bộ. tên tệp có thể - cho tất cả các tệp được cam kết