Có thể hoàn tác các thay đổi gây ra bởi lệnh sau không? Nếu vậy thì thế nào?

git reset --hard HEAD~1

Pat Notz là chính xác. Bạn có thể lấy lại cam kết miễn là trong vòng vài ngày. git chỉ thu gom rác sau khoảng một tháng hoặc lâu hơn trừ khi bạn nói rõ ràng để loại bỏ các đốm màu mới hơn.

$ git init
Initialized empty Git repository in .git/

$ echo "testing reset" > file1
$ git add file1
$ git commit -m 'added file1'
Created initial commit 1a75c1d: added file1
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 file1

$ echo "added new file" > file2
$ git add file2
$ git commit -m 'added file2'
Created commit f6e5064: added file2
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 file2

$ git reset --hard HEAD^
HEAD is now at 1a75c1d... added file1

$ cat file2
cat: file2: No such file or directory

$ git reflog
1a75c1d... HEAD@{0}: reset --hard HEAD^: updating HEAD
f6e5064... HEAD@{1}: commit: added file2

$ git reset --hard f6e5064
HEAD is now at f6e5064... added file2

$ cat file2
added new file

Bạn có thể thấy trong ví dụ rằng tệp 2 đã bị xóa do thiết lập lại cứng, nhưng đã được đặt lại đúng vị trí khi tôi đặt lại qua reflog.

Những gì bạn muốn làm là chỉ định sha1 của cam kết bạn muốn khôi phục. Bạn có thể lấy sha1 bằng cách kiểm tra reflog ( git reflog) và sau đó thực hiện

git reset --hard <sha1 of desired commit>

Nhưng đừng chờ đợi quá lâu ... sau một vài tuần, git cuối cùng sẽ thấy cam kết đó là không được ước tính và xóa tất cả các đốm màu.

Câu trả lời được ẩn trong phản hồi chi tiết ở trên, bạn chỉ cần làm:

$> git reset --hard HEAD@{1}

(Xem đầu ra của chương trình giới thiệu git )

Có thể khôi phục nó nếu Git chưa được thu gom rác.

Nhận tổng quan về các cam kết lơ lửng với fsck:

$ git fsck --lost-found
dangling commit b72e67a9bb3f1fc1b64528bcce031af4f0d6fcbf

Khôi phục các cam kết lơ lửng với rebase:

$ git rebase b72e67a9bb3f1fc1b64528bcce031af4f0d6fcbf

Nếu bạn thực sự may mắn, như tôi, bạn có thể quay lại trình chỉnh sửa văn bản của mình và nhấn 'hoàn tác'.

Tôi biết đó không thực sự là một câu trả lời đúng, nhưng nó đã giúp tôi tiết kiệm được nửa ngày làm việc nên hy vọng nó sẽ làm điều tương tự với người khác!

theo như tôi biết, --hardsẽ loại bỏ những thay đổi không được cam kết. Vì những thứ này không được theo dõi bởi git. nhưng bạn có thể hoàn tác discarded commit.

$ git reflog

sẽ liệt kê:

b0d059c HEAD@{0}: reset: moving to HEAD~1
4bac331 HEAD@{1}: commit: added level introduction....
....

nơi 4bac331là discarded commit.

Bây giờ chỉ cần di chuyển đầu đến cam kết đó ::

$ git reset --hard 4bac331

Ví dụ về trường hợp IRL:

$ git fsck --lost-found

Checking object directories: 100% (256/256), done.
Checking objects: 100% (3/3), done.
dangling blob 025cab9725ccc00fbd7202da543f556c146cb119
dangling blob 84e9af799c2f5f08fb50874e5be7fb5cb7aa7c1b
dangling blob 85f4d1a289e094012819d9732f017c7805ee85b4
dangling blob 8f654d1cd425da7389d12c17dd2d88d318496d98
dangling blob 9183b84bbd292dcc238ca546dab896e073432933
dangling blob 1448ee51d0ea16f259371b32a557b60f908d15ee
dangling blob 95372cef6148d980ab1d7539ee6fbb44f5e87e22
dangling blob 9b3bf9fb1ee82c6d6d5ec9149e38fe53d4151fbd
dangling blob 2b21002ca449a9e30dbb87e535fbd4e65bac18f7
dangling blob 2fff2f8e4ea6408ac84a8560477aa00583002e66
dangling blob 333e76340b59a944456b4befd0e007c2e23ab37b
dangling blob b87163c8def315d40721e592f15c2192a33816bb
dangling blob c22aafb90358f6bf22577d1ae077ad89d9eea0a7
dangling blob c6ef78dd64c886e9c9895e2fc4556e69e4fbb133
dangling blob 4a71f9ff8262701171d42559a283c751fea6a201
dangling blob 6b762d368f44ddd441e5b8eae6a7b611335b49a2
dangling blob 724d23914b48443b19eada79c3eb1813c3c67fed
dangling blob 749ffc9a412e7584245af5106e78167b9480a27b
dangling commit f6ce1a403399772d4146d306d5763f3f5715cb5a    <- it's this one

$ git show f6ce1a403399772d4146d306d5763f3f5715cb5a

commit f6ce1a403399772d4146d306d5763f3f5715cb5a
Author: Stian Gudmundsen Høiland <stian@Stians-Mac-mini.local>
Date:   Wed Aug 15 08:41:30 2012 +0200

    *MY COMMIT MESSAGE IS DISPLAYED HERE*

diff --git a/Some.file b/Some.file
new file mode 100644
index 0000000..15baeba
--- /dev/null
+++ b/Some.file
*THE WHOLE COMMIT IS DISPLAYED HERE*

$ git rebase f6ce1a403399772d4146d306d5763f3f5715cb5a

First, rewinding head to replay your work on top of it...
Fast-forwarded master to f6ce1a403399772d4146d306d5763f3f5715cb5a.

Trong hầu hết các trường hợp, có.

Tùy thuộc vào trạng thái kho lưu trữ của bạn khi bạn chạy lệnh, các hiệu ứng git reset --hardcó thể từ tầm thường đến hoàn tác, về cơ bản là không thể.

Dưới đây tôi đã liệt kê một loạt các kịch bản có thể khác nhau và cách bạn có thể phục hồi từ chúng.

Tất cả các thay đổi của tôi đã được cam kết, nhưng bây giờ các cam kết đã biến mất!

Tình huống này thường xảy ra khi bạn chạy git resetvới một đối số, như trong git reset --hard HEAD~. Đừng lo lắng, điều này rất dễ để phục hồi!

Nếu bạn vừa chạy git resetvà chưa làm gì khác kể từ đó, bạn có thể quay lại nơi bạn đang ở với chiếc áo lót này:

git reset --hard @{1}

Điều này đặt lại chi nhánh hiện tại của bạn bất kể trạng thái trước khi nó được sửa đổi lần cuối (trong trường hợp của bạn, sửa đổi gần đây nhất cho chi nhánh sẽ là thiết lập lại cứng mà bạn đang cố gắng hoàn tác).

Tuy nhiên, nếu bạn đã thực hiện các sửa đổi khác cho chi nhánh của mình kể từ khi đặt lại, thì một lớp lót ở trên sẽ không hoạt động. Thay vào đó, bạn nên chạy để xem danh sách tất cả các thay đổi gần đây được thực hiện cho chi nhánh của bạn (bao gồm cả đặt lại). Danh sách đó sẽ trông giống như thế này:git reflog <branchname>

7c169bd master@{0}: reset: moving to HEAD~
3ae5027 master@{1}: commit: Changed file2
7c169bd master@{2}: commit: Some change
5eb37ca master@{3}: commit (initial): Initial commit

Tìm hoạt động trong danh sách này mà bạn muốn "hoàn tác". Trong ví dụ trên, nó sẽ là dòng đầu tiên, dòng có nội dung "thiết lập lại: chuyển sang ĐẦU ~". Sau đó sao chép đại diện của cam kết trước (bên dưới) hoạt động đó. Trong trường hợp của chúng tôi, đó sẽ là master@{1}(hoặc 3ae5027, cả hai đều đại diện cho cùng một cam kết) và chạy git reset --hard <commit>để đặt lại chi nhánh hiện tại của bạn trở lại cam kết đó.

Tôi dàn dựng những thay đổi của mình với git add, nhưng không bao giờ cam kết. Bây giờ những thay đổi của tôi đã biến mất!

Đây là một chút khó khăn hơn để phục hồi từ. git không có bản sao của các tệp bạn đã thêm, nhưng vì các bản sao này không bao giờ được gắn với bất kỳ cam kết cụ thể nào, bạn không thể khôi phục tất cả các thay đổi cùng một lúc. Thay vào đó, bạn phải định vị các tệp riêng lẻ trong cơ sở dữ liệu của git và khôi phục chúng theo cách thủ công. Bạn có thể làm điều này bằng cách sử dụnggit fsck .

Để biết chi tiết về điều này, hãy xem Hoàn tác thiết lập lại git - với các tệp không được cam kết trong khu vực tổ chức .

Tôi đã thay đổi các tập tin trong thư mục làm việc của mình mà tôi chưa bao giờ dàn dựng git add và không bao giờ cam kết. Bây giờ những thay đổi của tôi đã biến mất!

À ồ. Tôi ghét phải nói với bạn điều này, nhưng có lẽ bạn không gặp may. git không lưu trữ các thay đổi mà bạn không thêm hoặc cam kết với nó, và theo tài liệu chogit reset :

--cứng

Đặt lại chỉ mục và cây làm việc. Mọi thay đổi đối với các tệp được theo dõi trong cây làm việc <commit>đều bị loại bỏ.

Có thể bạn có thể khôi phục các thay đổi của mình bằng một số tiện ích khôi phục đĩa hoặc dịch vụ khôi phục dữ liệu chuyên nghiệp, nhưng tại thời điểm này có lẽ nhiều rắc rối hơn giá trị của nó.

Nếu bạn chưa thu thập rác, kho lưu trữ của bạn (ví dụ: sử dụng git repack -dhoặcgit gc , nhưng lưu ý rằng việc thu gom rác cũng có thể tự động xảy ra), thì cam kết của bạn vẫn ở đó - nó không còn có thể truy cập được thông qua ĐẦU.

Bạn có thể thử tìm cam kết của mình bằng cách xem qua đầu ra của git fsck --lost-found .

Các phiên bản mới hơn của Git có một thứ gọi là "reflog", đây là nhật ký của tất cả các thay đổi được thực hiện cho các ref (trái ngược với các thay đổi được thực hiện cho nội dung kho lưu trữ). Vì vậy, ví dụ, mỗi khi bạn chuyển CHÍNH của mình (tức là mỗi lần bạn thực hiện git checkoutchuyển đổi các nhánh) sẽ được ghi lại. Và, tất nhiên, bạn git resetcũng thao túng ĐẦU, vì vậy nó cũng được ghi lại. Bạn có thể truy cập các trạng thái cũ của refs của mình theo cách tương tự mà bạn có thể truy cập các trạng thái cũ hơn của kho lưu trữ của mình, bằng cách sử dụng một @dấu hiệu thay vì ~, nhưgit reset HEAD@{1} .

Phải mất một thời gian tôi mới hiểu được sự khác biệt giữa HEAD @ {1} và HEAD ~ 1, vì vậy đây là một lời giải thích nhỏ:

git init
git commit --allow-empty -mOne
git commit --allow-empty -mTwo
git checkout -b anotherbranch
git commit --allow-empty -mThree
git checkout master # This changes the HEAD, but not the repository contents
git show HEAD~1 # => One
git show HEAD@{1} # => Three
git reflog

Vì vậy, HEAD~1có nghĩa là "đi đến cam kết trước khi cam kết mà ĐẦU hiện đang chỉ", trong khi đó HEAD@{1}có nghĩa là "đi đến cam kết mà CHÍNH chỉ vào trước khi nó chỉ vào nơi mà nó hiện đang chỉ".

Điều đó sẽ dễ dàng cho phép bạn tìm thấy cam kết bị mất của mình và phục hồi nó.

Trước khi trả lời cho phép thêm một số nền tảng, giải thích đây là gì HEAD.

First of all what is HEAD?

HEADchỉ đơn giản là một tham chiếu đến cam kết hiện tại (mới nhất) trên nhánh hiện tại.
Chỉ có thể có một duy nhất HEADtại bất kỳ thời điểm nào. (không bao gồm git worktree)

Nội dung của HEADđược lưu trữ bên trong .git/HEADvà nó chứa 40 byte SHA-1 của cam kết hiện tại.

detached HEAD

Nếu bạn không tham gia vào cam kết mới nhất - có nghĩa HEADlà chỉ đến một cam kết trước đó trong lịch sử được gọi là cam kết detached HEAD.

Trên dòng lệnh, nó sẽ trông như thế này- SHA-1 thay vì tên chi nhánh vì HEADnó không trỏ đến đầu của nhánh hiện tại

Một vài lựa chọn về cách phục hồi từ một ĐẦU tách ra:

git checkout

git checkout <commit_id>
git checkout -b <new branch> <commit_id>
git checkout HEAD~X // x is the number of commits t go back

Điều này sẽ kiểm tra chi nhánh mới chỉ vào cam kết mong muốn.
Lệnh này sẽ kiểm tra một cam kết nhất định.
Tại thời điểm này, bạn có thể tạo một nhánh và bắt đầu làm việc từ thời điểm này.

# Checkout a given commit. 
# Doing so will result in a `detached HEAD` which mean that the `HEAD`
# is not pointing to the latest so you will need to checkout branch
# in order to be able to update the code.
git checkout <commit-id>

# create a new branch forked to the given commit
git checkout -b <branch name>

git reflog

Bạn luôn có thể sử dụng refloglà tốt.
git reflogsẽ hiển thị bất kỳ thay đổi nào đã cập nhật HEADvà kiểm tra mục nhập reflog mong muốn sẽ đặt HEADlại cho cam kết này.

Mỗi khi sửa đổi ĐẦU sẽ có một mục mới trong reflog

git reflog
git checkout HEAD@{...}

Điều này sẽ đưa bạn trở lại cam kết mong muốn của bạn

git reset HEAD --hard <commit_id>

"Di chuyển" đầu của bạn trở lại cam kết mong muốn.

# This will destroy any local modifications.
# Don't do it if you have uncommitted work you want to keep.
git reset --hard 0d1d7fc32

# Alternatively, if there's work to keep:
git stash
git reset --hard 0d1d7fc32
git stash pop
# This saves the modifications, then reapplies that patch after resetting.
# You could get merge conflicts, if you've modified things which were
# changed since the commit you reset to.

• Lưu ý: ( Kể từ Git 2.7 ),
  bạn cũng có thể sử dụng git rebase --no-autostash.

git revert <sha-1>

"Hoàn tác" phạm vi cam kết hoặc cam kết đã cho.
Lệnh đặt lại sẽ "hoàn tác" mọi thay đổi được thực hiện trong cam kết đã cho.
Một cam kết mới với bản vá hoàn tác sẽ được cam kết trong khi cam kết ban đầu cũng sẽ vẫn còn trong lịch sử.

# add new commit with the undo of the original one.
# the <sha-1> can be any commit(s) or commit range
git revert <sha-1>

Lược đồ này minh họa lệnh nào làm gì.
Như bạn có thể thấy có reset && checkoutsửa đổi HEAD.

git reflog

• Tìm sha cam kết của bạn trong danh sách sau đó sao chép và dán nó vào lệnh này:

git cherry-pick <the sha>

Tôi biết đây là một chủ đề cũ ... nhưng vì nhiều người đang tìm cách hoàn tác công cụ trong Git, tôi vẫn nghĩ rằng có thể nên tiếp tục đưa ra lời khuyên ở đây.

Khi bạn thực hiện "git add" hoặc di chuyển bất cứ thứ gì từ trên cùng bên trái sang dưới cùng bên trái trong git gui, nội dung của tệp được lưu trữ trong một blob và nội dung tệp có thể phục hồi từ blob đó.

Vì vậy, có thể khôi phục một tập tin ngay cả khi nó không được cam kết nhưng nó đã được thêm vào.

git init  
echo hello >> test.txt  
git add test.txt  

Bây giờ blob được tạo nhưng nó được tham chiếu bởi chỉ mục nên nó sẽ không được liệt kê với git fsck cho đến khi chúng tôi đặt lại. Vì vậy, chúng tôi đặt lại ...

git reset --hard  
git fsck  

bạn sẽ nhận được một blob lủng lẳng ce013625030ba8dba906f756967f9e9ca394464a

git show ce01362  

sẽ cung cấp cho bạn nội dung tập tin "xin chào" trở lại

Để tìm các cam kết không được ước tính, tôi đã tìm thấy một mẹo ở đâu đó gợi ý điều này.

gitk --all $(git log -g --pretty=format:%h)  

Tôi có nó như một công cụ trong git gui và nó rất tiện dụng.

Nếu bạn đang sử dụng IDE JetBrains (mọi thứ dựa trên IntelliJ), bạn có thể khôi phục ngay cả những thay đổi không được cam kết của mình thông qua tính năng "Lịch sử địa phương" của họ.

Nhấp chuột phải vào thư mục cấp cao nhất trong cây tệp của bạn, tìm "Lịch sử cục bộ" trong menu ngữ cảnh và chọn "Hiển thị lịch sử". Điều này sẽ mở ra một chế độ xem có thể tìm thấy các chỉnh sửa gần đây của bạn và khi bạn đã tìm thấy bản sửa đổi mà bạn muốn quay lại, nhấp chuột phải vào nó và nhấp vào "Hoàn nguyên".

Tôi vừa mới thiết lập lại một dự án sai. Điều đã cứu cuộc đời tôi là lịch sử địa phương của Eclipse. IntelliJ Idea được cho là cũng có một, và vì vậy, biên tập viên của bạn cũng vậy, rất đáng để kiểm tra:

1. Chủ đề trợ giúp của Eclipse về Lịch sử địa phương
2. http://wiki.eclipse.org/FAQ_Where_is_the_workspace_local_history_stored%3F

Tạo một tập lệnh nhỏ để làm cho việc tìm kiếm cam kết đang tìm kiếm dễ dàng hơn một chút:

git fsck --lost-found | grep commit | cut -d ' ' -f 3 | xargs -i git show \{\} | egrep '^commit |Date:'

Vâng, nó có thể được làm đẹp hơn đáng kể với awk hoặc một cái gì đó tương tự, nhưng nó đơn giản và tôi chỉ cần nó. Có thể cứu người khác 30 giây.

Vấn đề của tôi gần như tương tự. Tôi có các tệp không được cam kết trước khi tôi nhậpgit reset --hard .

Rất may. Tôi quản lý để bỏ qua tất cả các tài nguyên. Sau khi tôi nhận thấy rằng tôi chỉ có thể hoàn tác ( ctrl-z). Tôi chỉ muốn thêm điều này vào tất cả các câu trả lời ở trên.

Ghi chú. Nó không thể ctrl-zmở tập tin.

• Làm cách nào tôi có thể hoàn tác thiết lập lại git - đầu trang ~ 1?
• Hoàn tác thiết lập lại git - với các tệp không được cam kết trong khu vực tổ chức
• Khôi phục tập tin đã thêm sau khi thực hiện thiết lập lại git - đầu trang ^
• Bài viết trung bình: Cách thực hiện: Khôi phục từ thiết lập lại Git Hard (Hoặc, đây là lý do tại sao chúng ta có lẽ không nên nhưng hoàn toàn có thể có những điều tốt đẹp)

Điều này đã cứu cuộc đời tôi: https://medium.com/@CarrieGuss/how-to-recover-from-a-git-hard-reset-b830b5e3f60c

Về cơ bản bạn cần chạy:

for blob in $(git fsck --lost-found | awk ‘$2 == “blob” { print $3 }’); do git cat-file -p $blob > $blob.txt; done

Sau đó, thủ công vượt qua nỗi đau để sắp xếp lại các tệp của bạn theo đúng cấu trúc.

Takeaway: Không bao giờ sử dụng git reset --hardnếu bạn không hoàn toàn hiểu 100% cách thức hoạt động của nó, tốt nhất không sử dụng nó.