Tôi đã thấy những bài viết thú vị giải thích sự tinh tế về git reset.

Thật không may, tôi càng đọc về nó, tôi càng không hiểu nó đầy đủ. Tôi đến từ một nền tảng SVN và Git là một mô hình hoàn toàn mới. Tôi dễ dàng đánh đồng, nhưng Git kỹ thuật hơn nhiều.

Tôi nghĩ git resetlà gần gũi hg revert, nhưng dường như có sự khác biệt.

Vì vậy, chính xác những gì git resetlàm? Vui lòng bao gồm các giải thích chi tiết về:

• các tùy chọn --hard, --softvà --merge;
• ký hiệu lạ mà bạn sử dụng HEADnhư HEAD^và HEAD~1;
• trường hợp sử dụng bê tông và dòng chảy công việc;
• hậu quả trên bản sao làm việc, HEADvà mức độ căng thẳng toàn cầu của bạn.

Nói chung, git resetchức năng của nó là lấy nhánh hiện tại và đặt lại nó để chỉ ra một nơi khác, và có thể mang chỉ mục và cây công việc đi cùng. Cụ thể hơn, nếu chi nhánh chính của bạn (hiện đã được kiểm tra) giống như thế này:

- A - B - C (HEAD, master)

và bạn nhận ra rằng bạn muốn chủ chỉ đến B, không phải C, bạn sẽ sử dụng git reset Bđể di chuyển nó đến đó:

- A - B (HEAD, master)      # - C is still here, but there's no branch pointing to it anymore

Digression: Điều này khác với thanh toán. Nếu bạn chạy git checkout B, bạn sẽ nhận được điều này:

- A - B (HEAD) - C (master)

Bạn đã kết thúc trong một trạng thái ĐẦU tách ra. HEAD, cây làm việc, chỉ mục tất cả khớp B, nhưng nhánh chủ bị bỏ lại tại C. Nếu bạn thực hiện một cam kết mới Dtại thời điểm này, bạn sẽ nhận được điều này, đây có thể không phải là điều bạn muốn:

- A - B - C (master)
       \
        D (HEAD)

Hãy nhớ rằng, thiết lập lại không thực hiện các cam kết, nó chỉ cập nhật một nhánh (là con trỏ tới một cam kết) để trỏ đến một cam kết khác. Phần còn lại chỉ là chi tiết về những gì xảy ra với chỉ mục và cây công việc của bạn.

Trường hợp sử dụng

Tôi trình bày nhiều trường hợp sử dụng chính git resettrong phần mô tả của tôi về các tùy chọn khác nhau trong phần tiếp theo. Nó thực sự có thể được sử dụng cho nhiều thứ khác nhau; luồng chung là tất cả chúng liên quan đến việc đặt lại nhánh, chỉ mục và / hoặc cây công việc để trỏ đến / khớp với một cam kết đã cho.

Những điều cần cẩn thận

• --hardcó thể khiến bạn thực sự mất việc. Nó sửa đổi cây làm việc của bạn.

• git reset [options] commitcó thể khiến bạn (sắp xếp) mất các cam kết. Trong ví dụ đồ chơi ở trên, chúng tôi mất cam kết C. Nó vẫn còn trong repo, và bạn có thể tìm thấy nó bằng cách nhìn vào git reflog show HEADhoặc git reflog show master, nhưng nó không thực sự thể truy cập từ bất kỳ chi nhánh nữa.

• Git xóa vĩnh viễn các cam kết như vậy sau 30 ngày, nhưng cho đến lúc đó bạn có thể khôi phục C bằng cách trỏ một nhánh vào nó một lần nữa ( git checkout C; git branch <new branch name>).

Tranh luận

Diễn giải trang man, cách sử dụng phổ biến nhất là ở dạng git reset [<commit>] [paths...], sẽ thiết lập lại các đường dẫn đã cho về trạng thái của chúng từ cam kết đã cho. Nếu các đường dẫn không được cung cấp, toàn bộ cây sẽ được đặt lại và nếu cam kết không được cung cấp, thì nó được coi là CHÍNH (cam kết hiện tại). Đây là một mẫu phổ biến trên các lệnh git (ví dụ: thanh toán, diff, log, mặc dù ngữ nghĩa chính xác khác nhau), vì vậy nó không quá ngạc nhiên.

Ví dụ, git reset other-branch path/to/foođặt lại mọi thứ trong đường dẫn / đến / foo về trạng thái của nó trong nhánh khác, git reset -- .đặt lại thư mục hiện tại về trạng thái của nó trong HEAD và đơn giản git resetđặt lại mọi thứ về trạng thái của nó trong HEAD.

Các tùy chọn chỉ mục và cây công việc chính

Có bốn tùy chọn chính để kiểm soát những gì xảy ra với cây công việc và chỉ mục của bạn trong quá trình thiết lập lại.

Hãy nhớ rằng, chỉ mục là "khu vực tổ chức" của git - đó là nơi mọi thứ diễn ra khi bạn nói git addđể chuẩn bị cam kết.

• --hardlàm cho mọi thứ khớp với cam kết bạn đã đặt lại. Đây là cách dễ hiểu nhất, có lẽ. Tất cả các thay đổi cục bộ của bạn bị tắc nghẽn. Một mục đích sử dụng chính là thổi bay công việc của bạn nhưng không chuyển đổi các cam kết: git reset --hardcó nghĩa git reset --hard HEADlà không thay đổi chi nhánh mà loại bỏ tất cả các thay đổi cục bộ. Cái khác chỉ đơn giản là di chuyển một nhánh từ nơi này sang nơi khác và giữ cho chỉ mục / cây công việc được đồng bộ hóa. Đây là một trong những thực sự có thể làm cho bạn mất việc, bởi vì nó sửa đổi cây công việc của bạn. Hãy rất chắc chắn rằng bạn muốn vứt bỏ công việc địa phương trước khi bạn chạy bất kỳ reset --hard.

• --mixedlà mặc định, git resetcó nghĩa là git reset --mixed. Nó đặt lại chỉ mục, nhưng không phải là cây làm việc. Điều này có nghĩa là tất cả các tệp của bạn đều còn nguyên vẹn, nhưng bất kỳ sự khác biệt nào giữa cam kết ban đầu và cam kết bạn đặt lại sẽ hiển thị dưới dạng sửa đổi cục bộ (hoặc các tệp không bị theo dõi) với trạng thái git. Sử dụng điều này khi bạn nhận ra bạn đã thực hiện một số cam kết xấu, nhưng bạn muốn giữ tất cả công việc bạn đã thực hiện để bạn có thể khắc phục và đề xuất. Để cam kết, bạn sẽ phải thêm lại tệp vào chỉ mục ( git add ...).

• --softkhông chạm vào chỉ mục hoặc cây làm việc. Tất cả các tệp của bạn vẫn còn nguyên vẹn như với --mixed, nhưng tất cả các thay đổi hiển thị như changes to be committedvới trạng thái git (nghĩa là đã được kiểm tra để chuẩn bị cho việc cam kết). Sử dụng điều này khi bạn nhận ra mình đã thực hiện một số cam kết xấu, nhưng tất cả đều tốt - tất cả những gì bạn cần làm là đề xuất nó theo cách khác. Chỉ mục không bị ảnh hưởng, vì vậy bạn có thể cam kết ngay lập tức nếu bạn muốn - cam kết kết quả sẽ có tất cả nội dung giống như bạn đã ở trước khi bạn đặt lại.

• --mergeđã được thêm vào gần đây và nhằm giúp bạn hủy bỏ việc hợp nhất không thành công. Điều này là cần thiết bởi vì git mergethực sự sẽ cho phép bạn thử hợp nhất với một cây công việc bẩn (một với các sửa đổi cục bộ) miễn là các sửa đổi đó nằm trong các tệp không bị ảnh hưởng bởi hợp nhất. git reset --mergeĐặt lại chỉ mục (như --mixed- tất cả các thay đổi hiển thị dưới dạng sửa đổi cục bộ) và đặt lại các tệp bị ảnh hưởng bởi việc hợp nhất, nhưng chỉ để lại các thay đổi khác. Điều này hy vọng sẽ khôi phục lại mọi thứ như trước khi hợp nhất xấu. Bạn sẽ thường sử dụng nó dưới dạng git reset --merge(có nghĩa git reset --merge HEAD) bởi vì bạn chỉ muốn đặt lại hợp nhất, không thực sự di chuyển chi nhánh. ( HEADchưa được cập nhật, vì việc hợp nhất thất bại)

  Để cụ thể hơn, giả sử bạn đã sửa đổi các tệp A và B và bạn cố gắng hợp nhất trong một nhánh đã sửa đổi các tệp C và D. Việc hợp nhất không thành công vì một số lý do và bạn quyết định hủy bỏ nó. Bạn sử dụng git reset --merge. Nó đưa C và D trở lại cách họ tham gia HEAD, nhưng để lại các sửa đổi của bạn cho A và B, vì chúng không phải là một phần của sự hợp nhất đã cố gắng.

Bạn muốn biết thêm?

Tôi nghĩ rằng man git resetnó thực sự khá tốt cho việc này - có lẽ bạn cần một chút cảm giác về cách thức hoạt động của git để chúng thực sự chìm trong mặc dù. Đặc biệt, nếu bạn dành thời gian để đọc chúng một cách cẩn thận, những bảng chi tiết trạng thái của các tệp trong chỉ mục và cây công việc cho tất cả các tùy chọn và trường hợp khác nhau là rất rất hữu ích. (Nhưng vâng, chúng rất dày đặc - chúng đang truyền tải rất nhiều thông tin trên dưới dạng rất súc tích.)

Ký hiệu lạ

"Ký hiệu lạ" ( HEAD^và HEAD~1) bạn đề cập chỉ đơn giản là một cách viết tắt để chỉ định các cam kết, mà không phải sử dụng tên băm như thế nào 3ebe3f6. Nó được ghi lại đầy đủ trong phần "chỉ định sửa đổi" của trang man cho git-rev-parse, với rất nhiều ví dụ và cú pháp liên quan. Dấu mũ và dấu ngã thực sự có nghĩa là những thứ khác nhau :

• HEAD~là viết tắt của HEAD~1và có nghĩa là cha mẹ đầu tiên của cam kết. HEAD~2có nghĩa là cha mẹ đầu tiên của cam kết. Hãy nghĩ về HEAD~n"n cam kết trước ĐẦU" hoặc "tổ tiên thế hệ thứ n của ĐẦU".
• HEAD^(hoặc HEAD^1) cũng có nghĩa là cha mẹ đầu tiên của cam kết. HEAD^2có nghĩa là cha mẹ thứ hai của cam kết . Hãy nhớ rằng, một cam kết hợp nhất bình thường có hai cha mẹ - cha mẹ đầu tiên là cam kết hợp nhất và cha mẹ thứ hai là cam kết được hợp nhất. Nói chung, sáp nhập thực sự có thể có nhiều cha mẹ tùy ý (sáp nhập bạch tuộc).
• Các toán tử ^và ~toán tử có thể được xâu chuỗi lại với nhau, như trong HEAD~3^2, cha mẹ thứ hai của tổ tiên thế hệ thứ ba của HEAD, HEAD^^2cha mẹ thứ hai của cha mẹ đầu tiên của HEAD, hoặc thậm chí HEAD^^^, tương đương với HEAD~3.

Hãy nhớ rằng trong gitbạn có:

• các HEADcon trỏ , mà nói với bạn những gì cam kết bạn đang làm việc trên
• các cây làm việc , đại diện cho nhà nước của các tập tin trên hệ thống của bạn
• các khu vực dàn (còn gọi là chỉ số ), trong đó "giai đoạn" thay đổi để họ sau này có thể được cam kết cùng nhau

Vui lòng bao gồm các giải thích chi tiết về:

--hard, --softVà --merge;

Theo thứ tự ngày càng nguy hiểm:

• --softdi chuyển HEADnhưng không chạm vào khu vực tổ chức hoặc cây làm việc.
• --mixeddi chuyển HEADvà cập nhật khu vực tổ chức, nhưng không phải là cây làm việc.
• --mergedi chuyển HEAD, đặt lại khu vực tổ chức và cố gắng di chuyển tất cả các thay đổi trong cây làm việc của bạn sang cây làm việc mới.
• --harddi chuyển HEAD và điều chỉnh khu vực tổ chức của bạn và cây làm việc mới HEAD, vứt bỏ mọi thứ.

trường hợp sử dụng cụ thể và quy trình làm việc;

• Sử dụng --softkhi bạn muốn chuyển sang một cam kết khác và vá mọi thứ mà không "mất vị trí". Thật hiếm khi bạn cần thứ này.

-

# git reset --soft example
touch foo                            // Add a file, make some changes.
git add foo                          // 
git commit -m "bad commit message"   // Commit... D'oh, that was a mistake!
git reset --soft HEAD^               // Go back one commit and fix things.
git commit -m "good commit"          // There, now it's right.

-

• Sử dụng --mixed(là mặc định) khi bạn muốn xem mọi thứ trông như thế nào ở một cam kết khác, nhưng bạn không muốn mất bất kỳ thay đổi nào bạn đã có.

• Sử dụng --mergekhi bạn muốn chuyển đến một vị trí mới nhưng kết hợp những thay đổi bạn đã có vào cây làm việc đó.

• Sử dụng --hardđể xóa sạch mọi thứ và bắt đầu một bảng mới tại cam kết mới.

Bài đăng Reset Demystified trong blog Pro Git đưa ra lời giải thích rất không có trí tuệ về git resetvà git checkout.

Sau tất cả các cuộc thảo luận hữu ích ở đầu bài đăng đó, tác giả giảm các quy tắc xuống ba bước đơn giản sau:

Đó là cơ bản nó. Các resetlệnh ghi đè ba cây theo một thứ tự cụ thể, dừng lại khi bạn nói với nó.

1. Di chuyển bất cứ điểm nào nhánh CHÍNH tới (dừng nếu --soft)
2. THEN, làm cho Index trông như thế (dừng ở đây trừ khi --hard)
3. THEN, làm cho Thư mục làm việc trông như thế

Ngoài ra còn có --mergevà --keepcác tùy chọn, nhưng tôi muốn giữ mọi thứ đơn giản hơn bây giờ - đó sẽ là cho một bài viết khác.

Khi bạn cam kết một cái gì đó để git, trước tiên bạn phải giai đoạn (thêm vào chỉ mục) những thay đổi của bạn. Điều này có nghĩa là bạn phải git thêm tất cả các tệp bạn muốn có trong cam kết này trước khi git coi chúng là một phần của cam kết. Trước tiên chúng ta hãy xem hình ảnh của một repo git:

vì vậy, nó đơn giản bây giờ Chúng tôi phải làm việc trong thư mục làm việc, tạo tập tin, thư mục và tất cả. Những thay đổi này là những thay đổi chưa được theo dõi. Để làm cho chúng được theo dõi, chúng ta cần thêm chúng vào chỉ mục git bằng cách sử dụng lệnh git add . Một khi chúng được thêm vào chỉ số git. Bây giờ chúng ta có thể cam kết những thay đổi này, nếu chúng ta muốn đẩy nó vào kho git.

Nhưng đột nhiên chúng tôi biết rằng trong khi cam kết rằng chúng tôi có thêm một tệp mà chúng tôi đã thêm vào chỉ mục không bắt buộc phải lưu trữ trong kho git. Điều đó có nghĩa là chúng tôi không muốn tập tin đó trong chỉ mục. Bây giờ câu hỏi là làm thế nào để loại bỏ tập tin đó khỏi chỉ mục git, Vì chúng tôi đã sử dụng git add để đưa chúng vào chỉ mục, nên sử dụng git rm là hợp lý ? Sai lầm! git rm sẽ chỉ cần xóa tệp và thêm xóa vào chỉ mục. Vậy phải làm gì bây giờ:

Sử dụng:-

thiết lập lại git

Nó Xóa chỉ mục của bạn, để thư mục làm việc của bạn không bị ảnh hưởng. (chỉ đơn giản là không dàn dựng mọi thứ).

Nó có thể được sử dụng với số lượng tùy chọn với nó. Có ba tùy chọn chính để sử dụng với git reset: --hard, --soft và --mixed . Những điều này ảnh hưởng đến những gì được thiết lập lại ngoài con trỏ CHÍNH khi bạn đặt lại.

Đầu tiên, - đặt lại tất cả mọi thứ. Thư mục hiện tại của bạn sẽ chính xác như nó sẽ làm nếu bạn đã theo dõi chi nhánh đó suốt. Thư mục làm việc và chỉ mục được thay đổi thành cam kết đó. Đây là phiên bản mà tôi sử dụng thường xuyên nhất. git reset - rất giống với svn Revert .

Tiếp theo, hoàn toàn ngược lại, Wapsoft , không thiết lập lại cây làm việc cũng như chỉ mục. Nó chỉ di chuyển con trỏ CHÍNH. Điều này khiến cho trạng thái hiện tại của bạn có bất kỳ thay đổi nào khác với cam kết mà bạn đang chuyển sang vị trí trong thư mục của mình và đã tổ chức trực tuyến. Nếu bạn thực hiện một cam kết cục bộ nhưng chưa đẩy cam kết đến máy chủ git, bạn có thể đặt lại về cam kết trước đó và khuyến nghị với một thông báo cam kết tốt.

Cuối cùng, --mixed đặt lại chỉ mục, nhưng không phải là cây làm việc. Vì vậy, tất cả các thay đổi vẫn còn đó, nhưng là những người không có bản quyền và không cần phải git add'ed hoặc git commit -a . đôi khi chúng tôi sử dụng điều này nếu chúng tôi cam kết nhiều hơn so với git commit -a, chúng tôi có thể sao lưu cam kết với git reset - trộn lẫn, thêm những điều chúng tôi muốn cam kết và chỉ cam kết những điều đó.

Sự khác biệt giữa git Revert và git reset : -

Nói một cách đơn giản, git reset là một lệnh để "sửa lỗi không được sửa chữa" và git hoàn nguyên là một lệnh để "sửa lỗi được cam kết" .

Điều đó có nghĩa là nếu chúng tôi đã thực hiện một số lỗi trong một số thay đổi và cam kết và đẩy tương tự để git repo, thì git Revert là giải pháp. Và nếu trong trường hợp chúng tôi đã xác định lỗi tương tự trước khi đẩy / cam kết, chúng tôi có thể sử dụng git reset để khắc phục sự cố.

Tôi hy vọng nó sẽ giúp bạn thoát khỏi sự nhầm lẫn của bạn.

TL; DR

git resetĐặt lại Giai đoạn đến cam kết cuối cùng. Sử dụng --hardđể cũng đặt lại các tệp trong thư mục Làm việc của bạn đến lần xác nhận cuối cùng.

PHIÊN BẢN DÀI HẠN

Nhưng đó rõ ràng là đơn giản do đó nhiều câu trả lời khá dài dòng. Nó có ý nghĩa hơn đối với tôi để đọc lên git resettrong bối cảnh thay đổi hoàn tác. Ví dụ: xem cái này:

Nếu git Revert là một cách an toàn của người Viking để hoàn tác các thay đổi, bạn có thể nghĩ git reset là phương pháp nguy hiểm. Khi bạn hoàn tác với git reset (và các xác nhận không còn được tham chiếu bởi bất kỳ ref hoặc reflog nào), không có cách nào để lấy lại bản sao gốc, đó là một bản hoàn tác vĩnh viễn. Phải cẩn thận khi sử dụng công cụ này, vì đây là một trong những lệnh Git duy nhất có khả năng làm mất công việc của bạn.

Từ https://www.atlassian.com/git/tutorials/undceed-changes/git-reset

và điều này

Ở cấp độ cam kết, đặt lại là một cách để di chuyển đầu nhánh sang một cam kết khác. Điều này có thể được sử dụng để loại bỏ các cam kết từ chi nhánh hiện tại.

Từ https://www.atlassian.com/git/tutorials/resetting-checking-out-and-reverting/commit-level-operations

Xin lưu ý, đây là một giải thích đơn giản nhằm mục đích là bước đầu tiên để tìm hiểu chức năng phức tạp này.

Có thể hữu ích cho những người học trực quan muốn hình dung trạng thái dự án của họ trông như thế nào sau mỗi lệnh này:

Đối với những người sử dụng Terminal có bật màu (git config --global color.ui auto):

git reset --soft A và bạn sẽ thấy nội dung của B và C có màu xanh lá cây (được dàn dựng và sẵn sàng cam kết)

git reset --mixed A(hoặc git reset A) và bạn sẽ thấy nội dung của B và C có màu đỏ (không được dàn dựng và sẵn sàng để được dàn dựng (màu xanh lá cây) và sau đó được cam kết)

git reset --hard A và bạn sẽ không còn thấy những thay đổi của B và C ở bất cứ đâu (sẽ như thể chúng chưa từng tồn tại)

Hoặc cho những người sử dụng chương trình GUI như 'Tháp' hoặc 'SourceTree'

git reset --soft A và bạn sẽ thấy nội dung của B và C trong khu vực 'tập tin dàn dựng' sẵn sàng cam kết

git reset --mixed A(hoặc git reset A) và bạn sẽ thấy nội dung của B và C trong khu vực 'tệp không được sắp xếp' sẵn sàng để được chuyển sang dàn dựng và sau đó cam kết

git reset --hard A và bạn sẽ không còn thấy những thay đổi của B và C ở bất cứ đâu (sẽ như thể chúng chưa từng tồn tại)

Thanh toán chỉ đầu vào một cam kết cụ thể.

Đặt lại điểm một chi nhánh tại một cam kết cụ thể. (Một nhánh là một con trỏ tới một cam kết.)

Ngẫu nhiên, nếu đầu của bạn không chỉ ra một cam kết cũng được chỉ ra bởi một nhánh thì bạn có một cái đầu tách ra. _{(hóa ra là sai. Xem bình luận ...)}