Đôi khi git đề nghị git rm --cachedđể unstst một tập tin, đôi khi git reset HEAD file. Khi nào nên sử dụng?

BIÊN TẬP:

D:\code\gt2>git init
Initialized empty Git repository in D:/code/gt2/.git/
D:\code\gt2>touch a

D:\code\gt2>git status
# On branch master
#
# Initial commit
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       a
nothing added to commit but untracked files present (use "git add" to track)

D:\code\gt2>git add a

D:\code\gt2>git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
#
#       new file:   a
#
D:\code\gt2>git commit -m a
[master (root-commit) c271e05] a
 0 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 a

D:\code\gt2>touch b

D:\code\gt2>git status
# On branch master
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       b
nothing added to commit but untracked files present (use "git add" to track)

D:\code\gt2>git add b

D:\code\gt2>git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       new file:   b
#

git rm --cached <filePath> không bỏ qua một tập tin, nó thực sự sẽ loại bỏ (các) tập tin khỏi repo (giả sử nó đã được cam kết trước đó) nhưng để lại tập tin trong cây làm việc của bạn (để lại cho bạn một tập tin không bị theo dõi).

git reset -- <filePath>sẽ bỏ qua mọi thay đổi theo giai đoạn cho (các) tệp đã cho.

Điều đó nói rằng, nếu bạn đã sử dụng git rm --cachedtrên một tập tin mới được dàn dựng, về cơ bản nó sẽ trông giống như bạn vừa chưa thực hiện nó vì nó chưa bao giờ được cam kết trước đó.

Cập nhật git 2.24
Trong phiên bản git mới hơn này, bạn có thể sử dụng git restore --stagedthay vì git reset. Xem tài liệu git .

git rm --cachedđược sử dụng để xóa một tập tin khỏi chỉ mục. Trong trường hợp tệp đã có trong repo, git rm --cachedsẽ xóa tệp khỏi chỉ mục, để nó trong thư mục làm việc và một cam kết cũng sẽ xóa nó khỏi repo. Về cơ bản, sau khi cam kết, bạn sẽ đảo ngược tệp và giữ một bản sao cục bộ.

git reset HEAD file(mà theo mặc định là sử dụng --mixedcờ) thì khác ở chỗ trong trường hợp tệp đã có trong repo, nó thay thế phiên bản chỉ mục của tệp bằng một từ repo (HEAD), thực sự bỏ qua các sửa đổi đối với nó.

Trong trường hợp tệp không được đảo ngược, nó sẽ hủy bỏ toàn bộ tệp vì tệp không có trong ĐẦU. Trong khía cạnh này git reset HEAD filevà git rm --cachedgiống nhau, nhưng chúng không giống nhau (như được giải thích trong trường hợp các tệp đã có trong repo)

Đối với câu hỏi Why are there 2 ways to unstage a file in git?- không bao giờ thực sự chỉ có một cách để làm bất cứ điều gì trong git. đó là vẻ đẹp của nó :)

Rất đơn giản:

• git rm --cached <file> làm cho git dừng theo dõi tập tin hoàn toàn (để nó trong hệ thống tập tin, không giống như git rm*)
• git reset HEAD <file> bỏ qua bất kỳ sửa đổi nào được thực hiện đối với tệp kể từ lần xác nhận cuối cùng (nhưng không hoàn nguyên chúng trong hệ thống tệp, trái với những gì tên lệnh có thể đề xuất **). Các tập tin vẫn còn dưới sự kiểm soát sửa đổi.

Nếu trước đó tệp không nằm trong kiểm soát sửa đổi (nghĩa là bạn không tạo ra tệp mà bạn mới chỉnh sửa git addlần đầu tiên), thì hai lệnh có cùng tác dụng, do đó xuất hiện hai cách này là "hai cách thực hiện một việc gì đó ".

_{* Hãy ghi nhớ cảnh báo @DrewT đề cập đến câu trả lời của anh ấy, liên quan đến git rm --cachedmột tập tin đã được cam kết trước đó vào kho lưu trữ. Trong bối cảnh của câu hỏi này, về một tệp vừa được thêm và chưa được cam kết, không có gì phải lo lắng.}

_{** Tôi đã rất sợ trong một thời gian dài lúng túng khi sử dụng lệnh git reset vì tên của nó - và ngày nay tôi vẫn thường tìm kiếm cú pháp để đảm bảo rằng tôi không làm hỏng. ( cập nhật : Cuối cùng tôi đã dành thời gian để tóm tắt việc sử dụng git resettrong một trang tldr , vì vậy bây giờ tôi có một mô hình tinh thần tốt hơn về cách thức hoạt động của nó và tham khảo nhanh khi tôi quên một số chi tiết.)}

Chủ đề này hơi cũ, nhưng tôi vẫn muốn thêm một chút trình diễn vì nó vẫn không phải là một vấn đề trực quan:

me$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   new file:   to-be-added
#   modified:   to-be-modified
#   deleted:    to-be-removed
#

me$ git reset -q HEAD to-be-added

    # ok

me$ git reset -q HEAD to-be-modified

    # ok

me$ git reset -q HEAD to-be-removed

    # ok

# or alternatively:

me$ git reset -q HEAD to-be-added to-be-removed to-be-modified

    # ok

me$ git status
# On branch master
# Changes not staged for commit:
#   (use "git add/rm <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   to-be-modified
#   deleted:    to-be-removed
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#   to-be-added
no changes added to commit (use "git add" and/or "git commit -a")

git reset HEAD(không có -q) đưa ra cảnh báo về tệp đã sửa đổi và mã thoát của nó là 1 sẽ được coi là lỗi trong tập lệnh.

Chỉnh sửa: git checkout HEAD to-be-modified to-be-removedcũng hoạt động để không tạo ảnh, nhưng loại bỏ hoàn toàn thay đổi khỏi không gian làm việc

Cập nhật git 2.23.0: Thỉnh thoảng, các lệnh thay đổi. Bây giờ, git statusnói:

  (use "git restore --staged <file>..." to unstage)

... hoạt động cho cả ba loại thay đổi

nếu bạn vô tình dàn dựng các tệp mà bạn không muốn cam kết và muốn chắc chắn rằng bạn giữ các thay đổi, bạn cũng có thể sử dụng:

git stash
git stash pop

điều này thực hiện thiết lập lại thành CHÍNH và áp dụng lại các thay đổi của bạn, cho phép bạn tạo lại các tệp riêng lẻ cho cam kết. điều này cũng hữu ích nếu bạn quên tạo một nhánh tính năng cho các yêu cầu kéo ( git stash ; git checkout -b <feature> ; git stash pop).

Hai lệnh này có một số khác biệt tinh tế nếu tệp đang đề cập đã có trong repo và dưới sự kiểm soát phiên bản (đã cam kết trước đó, v.v.):

• git reset HEAD <file> bỏ tập tin trong cam kết hiện tại.
• git rm --cached <file>cũng sẽ bỏ tập tin cho các cam kết trong tương lai. Nó không được tạo ra cho đến khi nó được thêm lại với git add <file>.

Và có một sự khác biệt quan trọng hơn:

• Sau khi chạy git rm --cached <file>và đẩy chi nhánh của bạn đến điều khiển từ xa, bất kỳ ai kéo chi nhánh của bạn từ xa sẽ nhận được tệp HOẠT ĐỘNG bị xóa khỏi thư mục của họ, mặc dù trong bộ làm việc cục bộ của bạn, tệp sẽ không bị khóa (tức là không bị xóa khỏi thư mục).

Sự khác biệt cuối cùng này rất quan trọng đối với các dự án bao gồm tệp cấu hình trong đó mỗi nhà phát triển trong nhóm có một cấu hình khác nhau (nghĩa là cài đặt url, ip hoặc cổng cơ sở khác nhau) vì vậy nếu bạn đang sử dụng git rm --cached <file> bất kỳ ai kéo chi nhánh của mình sẽ phải tự thủ công lại. tạo cấu hình hoặc bạn có thể gửi chúng cho bạn và họ có thể chỉnh sửa lại về cài đặt ip của họ (v.v.), vì việc xóa chỉ ảnh hưởng đến mọi người kéo chi nhánh của bạn từ xa.

Giả sử bạn stagecó toàn bộ thư mục thông qua git add <folder>, nhưng bạn muốn loại trừ một tệp khỏi danh sách theo giai đoạn (tức là danh sách tạo khi chạy git status) và giữ các sửa đổi trong tệp bị loại trừ (bạn đang làm việc trên một cái gì đó và nó chưa sẵn sàng để cam kết, nhưng bạn không muốn mất việc ...). Bạn chỉ có thể sử dụng:

git reset <file>

Khi bạn chạy git status, bạn sẽ thấy bất kỳ tệp nào bạn resetđang có unstagedvà phần còn lại của các tệp bạn addedvẫn còn trong stageddanh sách.

1.

D:\code\gt2>git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
#
#       new file:   a

(sử dụng "git rm --cached ..." để bỏ qua)

• git là một hệ thống con trỏ

• bạn chưa có một cam kết nào để thay đổi con trỏ của bạn thành

• cách duy nhất để 'lấy các tệp ra khỏi nhóm được chỉ ra' là xóa các tệp bạn đã nói với git để theo dõi các thay đổi

2.

D:\code\gt2>git commit -m a
[master (root-commit) c271e05] a
0 files changed, 0 insertions(+), 0 deletions(-) create mode 100644 a

cam kết -ma

• bạn đã cam kết, " đã lưu "

3.

D:\code\gt2>git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       new file:   b
#

(sử dụng "git reset HEAD ..." để bỏ ngỏ)

• bạn đã thực hiện một cam kết trong mã của bạn tại thời điểm này
• bây giờ bạn có thể đặt lại con trỏ của mình về cam kết ' trở lại lần lưu cuối cùng '

Tôi ngạc nhiên khi không ai nhắc đến glog reflog ( http://git-scm.com/docs/git-reflog ):

# git reflog
<find the place before your staged anything>
# git reset HEAD@{1}

Reflog là một lịch sử git không chỉ theo dõi các thay đổi đối với repo mà còn theo dõi các hành động của người dùng (Ví dụ: kéo, thanh toán đến các chi nhánh khác, v.v.) và cho phép hoàn tác các hành động đó. Vì vậy, thay vì bỏ qua các tập tin được dàn dựng sai, nơi bạn có thể trở lại điểm mà bạn không tạo ra các tập tin.

Điều này tương tự git reset HEAD <file>nhưng trong một số trường hợp nhất định có thể chi tiết hơn.

Xin lỗi - không thực sự trả lời câu hỏi của bạn, nhưng chỉ đưa ra một cách khác để bỏ qua các tệp mà tôi sử dụng khá thường xuyên (tôi cho một câu trả lời giống như của Ryan Stewart và waldyrious rất nhiều.);) Tôi hy vọng nó có ích.

Chỉ dùng:

git reset HEAD <filename>

Điều này sẽ loại bỏ tệp và giữ các thay đổi bạn đã làm với nó, do đó, bạn có thể thay đổi các nhánh nếu bạn muốn và git addcác tệp đó sang nhánh khác thay thế. Tất cả các thay đổi được lưu giữ.

Đối với tôi, dường như git rm --cached <file>loại bỏ tệp khỏi chỉ mục mà không xóa tệp khỏi thư mục nơi đơn giản git rm <file>sẽ thực hiện cả hai, giống như một hệ điều hành rm <file>sẽ xóa tệp khỏi thư mục mà không xóa phiên bản.

Chỉ dành cho phiên bản 2.23 trở lên,

Thay vì những gợi ý này, bạn có thể sử dụng git restore --staged <file>để unstage(các) tệp.