Git Reset Soft: Hướng Dẫn Hoàn Chỉnh kèm Ví Dụ

Từng Bước: Sử Dụng Git Reset Soft

Làm chủ cách áp dụng soft reset trong thực tế đòi hỏi hiểu cả cơ chế và các quy trình nơi nó mang lại giá trị lớn nhất. Tôi sẽ hướng dẫn bạn qua những kỹ thuật cốt lõi đã trở thành phản xạ tự nhiên trong quá trình phát triển của tôi.

Quy trình từng bước để dùng lệnh git reset --soft.

Thực hiện soft reset về một commit cụ thể

Cú pháp cơ bản của soft reset rất đơn giản: git reset --soft <commit>. Thách thức nằm ở việc xác định đúng commit đích và hiểu kết quả. Đây là quy trình thường dùng của tôi:

git log --oneline -10
git reset --soft m0n1o2p
git statusĐược hỗ trợ bởi

Tôi bắt đầu với git log --oneline -10 để xem lịch sử commit gần đây ở dạng gọn. Khi xác định commit đích, tôi chạy git reset --soft m0n1o2p. Lệnh này di chuyển con trỏ nhánh lùi lại trong khi giữ toàn bộ công việc từ các commit sau đó. Cuối cùng, git status xác nhận mọi thay đổi từ các commit đã reset giờ đang được stage và sẵn sàng commit lại.

Một mẹo tôi học từ người hướng dẫn: luôn dùng git log --oneline trước để có cái nhìn trực quan về lịch sử commit. Tôi cũng hay dùng git log --graph --oneline --all khi làm với nhiều nhánh để hiểu mối quan hệ giữa các dòng phát triển.

Bạn cũng có thể dùng tham chiếu tương đối như HEAD~2 để lùi hai commit từ vị trí hiện tại. Tôi thấy điều này hữu ích cho thao tác nhanh: git reset --soft HEAD~1 có lẽ là lệnh tôi gõ thường xuyên nhất, vì nó chỉ hoàn tác commit cuối cùng trong khi giữ mọi thứ đã stage để làm lại.

Sửa các commit gần đây

Một ứng dụng thực tiễn nhất của soft reset là sửa commit gần đây, dù là cần chỉnh message, thêm thay đổi bỏ sót, hay sắp xếp lại cấu trúc commit. Quy trình này đã cứu tôi khỏi bối rối không biết bao lần.

git log -1
git reset --soft HEAD~1
git add forgotten_file.py
git commit -m "Implement user authentication with proper validation

- Add login/logout endpoints
- Include password validation logic
- Add forgotten error handling module
- Update tests for new authentication flow"Được hỗ trợ bởi

Tôi vừa commit nhưng quên một file quan trọng. Tôi dùng git log -1 để xem commit còn thiếu, rồi git reset --soft HEAD~1. Lệnh này hoàn tác commit trong khi giữ mọi thay đổi ở trạng thái đã stage. Sau khi thêm file bị quên bằng git add forgotten_file.py, tôi tạo commit mới bao gồm đầy đủ với message chuẩn.

Quy trình này đã thành “trí nhớ cơ bắp” với tôi. Tôi dùng mẫu này vài lần mỗi tuần, nhất là khi đang “flow” và commit thường xuyên. Cảm giác dọn dẹp công việc một cách hồi tố rất thỏa mãn — như có nút "undo" cho hệ thống quản lý phiên bản.

Tôi cũng thấy kỹ thuật này cực kỳ hữu ích khi làm việc với quy ước message commit. Nhiều đội dùng định dạng như Conventional Commits, và nếu tôi nhận ra mình chưa theo đúng định dạng, một lần soft reset nhanh cho phép tôi sửa mà không tạo thêm commit.

Tách các commit lớn

Commit lớn vi phạm nguyên tắc thay đổi nguyên tử và khiến review khó khăn. Soft reset mang lại giải pháp thanh nhã để chia nhỏ commit quá khổ thành các phần logic, dễ review. Đây là một trong những kỹ thuật cải thiện nhiều nhất phản hồi review code của tôi qua thời gian.

git log --oneline -3
git reset --soft HEAD~1
git status
git reset
git add models/user.py
git commit -m "Add user model with validation rules"
git add controllers/user_controller.py
git commit -m "Implement user CRUD operations"
git add tests/test_user_model.py tests/test_user_controller.py
git commit -m "Add comprehensive user model and controller tests"
git add templates/user/ static/css/user.css
git commit -m "Add user interface templates and styling"Được hỗ trợ bởi

Tôi bắt đầu với git log --oneline -3 để tìm commit quá lớn, rồi dùng git reset --soft HEAD~1. Lệnh này hoàn tác commit nhưng giữ thay đổi ở trạng thái đã stage. Chạy git reset (không có cờ) để bỏ stage mọi thứ, cho tôi một slate sạch. Giờ tôi có thể tạo các commit tập trung: đầu tiên là model, rồi controller, sau đó test, và cuối cùng là thành phần UI. Cách này biến một commit khổng lồ thành các phần logic, dễ review.

Cách làm này đã thay đổi cách reviewer phản hồi pull request của tôi. Thay vì nhận xét kiểu "Commit này quá lớn để review hiệu quả", giờ họ đưa ra phản hồi cụ thể, có thể hành động cho từng phần logic.

Một điều tôi học được là hãy nghĩ về câu chuyện commit kể. Mỗi commit nên thể hiện một ý trọn vẹn và tự nó có ý nghĩa. Nếu tôi không thể giải thích commit trong một câu rõ ràng, có lẽ nó quá lớn và cần tách nhỏ.

Nén lịch sử (squash)

Khi bạn có nhiều commit nhỏ trong quá trình phát triển — sửa lỗi chính tả, phản hồi review, hay tiến triển từng bước —gộp chúng (squash) thành một commit trau chuốt sẽ tạo lịch sử sạch hơn. Kỹ thuật này trở nên thiết yếu trong quy trình của tôi, đặc biệt khi làm tính năng kéo dài vài ngày.

git log --oneline -6
git reset --soft HEAD~5
git status
git commit -m "Implement comprehensive user registration system

- Add user registration endpoint with validation
- Include password strength requirements
- Add comprehensive test coverage
- Update documentation with usage examples"Được hỗ trợ bởi

Tôi dùng git log --oneline -6 để xem lịch sử lộn xộn, rồi git reset --soft HEAD~5. Lệnh này kết hợp năm commit nhỏ trong khi tự động stage toàn bộ công việc. Chạy git status cho thấy mọi thứ đã sẵn sàng để commit lại. Tôi tạo một commit trau chuốt với message chuyên nghiệp mô tả đầy đủ tính năng thay vì hành trình gỡ lỗi.

Tôi đặc biệt thích dùng kỹ thuật này trước khi merge các nhánh tính năng. Nó cho phép tôi có commit chi tiết trong quá trình phát triển (giúp gỡ lỗi và theo dõi tiến độ) đồng thời trình bày một lịch sử sạch, chuyên nghiệp lên nhánh chính.

Một quy trình tôi phát triển là dùng tiền tố đặt tên commit WIP. Tôi sẽ dùng tiền tố như "WIP:" hoặc "temp:" cho các commit biết chắc sẽ squash sau. Điều này giúp dễ nhận ra commit "kể chuyện" so với commit "điểm kiểm tra".

Đẩy thay đổi sau khi soft reset

Sau khi viết lại lịch sử cục bộ bằng soft reset, việc push lên remote cần cân nhắc kỹ. Vì bạn đã thay đổi cấu trúc commit, Git sẽ từ chối thao tác push thông thường. Đây là lúc hiểu force-push an toàn trở nên quan trọng.

git push origin feature-branch
git push --force-with-lease origin feature-branchĐược hỗ trợ bởi

Sau khi viết lại lịch sử, git push origin feature-branch thông thường sẽ thất bại với lỗi "non-fast-forward". Tôi dùng git push --force-with-lease origin feature-branch thay thế. Lệnh này force-push an toàn, đảm bảo không ai khác đã cập nhật nhánh kể từ lần fetch cuối của tôi.

Tùy chọn --force-with-lease đã cứu đội của tôi khỏi vài thảm họa. Nó đảm bảo không ai khác đã push commit lên nhánh kể từ lần fetch cuối của bạn. Điều này ngăn vô tình ghi đè công việc của cộng tác viên — sai lầm có thể gây tổn hại nghiêm trọng đến quan hệ nhóm và sự ổn định dự án.

Tôi biết đến --force-with-lease theo cách khó khăn sau khi vô tình ghi đè công việc của đồng đội bằng một lần force push thường. Cuộc trò chuyện sau đó thật... khó xử. Từ đó, tôi mặc định dùng --force-with-lease cho mọi thao tác force push, và tôi khuyên bất kỳ ai làm việc trên repository dùng chung cũng nên như vậy.

Ứng Dụng Thực Tiễn và Ví Dụ

Các quy trình Git trong thế giới thực nảy sinh những tình huống mà soft reset trở nên không thể thiếu. Tôi sẽ chia sẻ vài ví dụ từ trải nghiệm của mình để minh họa cách xử lý các tình huống phổ biến bạn sẽ gặp trong môi trường chuyên nghiệp

Biến commit lộn xộn thành gọn gàng với git reset --soft.

Hoàn tác commit cuối nhưng giữ thay đổi

Đây là trường hợp dùng soft reset thường xuyên nhất trong ngày của tôi — khi bạn commit quá sớm hoặc với message chưa đạt. Tôi làm điều này ít nhất một lần mỗi ngày.

git log -1
git reset --soft HEAD~1
git status
git commit -m "Fix authentication middleware edge case handling

- Resolve null pointer exception when user session expires
- Add proper error handling for malformed JWT tokens  
- Include additional test coverage for session timeout scenarios
- Update error messages to be more user-friendly"Được hỗ trợ bởi

Khi thấy một message xấu hổ như "fix stuff" sau khi chạy git log -1, tôi dùng git reset --soft HEAD~1. Lệnh này hoàn tác commit trong khi giữ các thay đổi ở trạng thái đã stage. Rồi git status xác nhận mọi thứ sẵn sàng, và tôi có thể commit lại với message chuyên nghiệp, thực sự giải thích những gì tôi sửa.

Quy trình này cứu tôi khỏi việc để những message kiểu "asdf", "temp", hay "fix" nằm vĩnh viễn trong lịch sử dự án. Message commit chuyên nghiệp rất quan trọng; chúng là tài liệu cho developer tương lai (kể cả chính bạn) đang cố hiểu vì sao thay đổi được thực hiện.

Tôi đặt ra quy tắc cho bản thân: nếu tôi không thể viết một message giải thích rõ "lý do" đằng sau thay đổi, có lẽ commit chưa sẵn sàng. Soft reset cho tôi tự do commit sớm và thường xuyên trong phát triển mà vẫn giữ chuẩn mực chuyên nghiệp ở lịch sử cuối cùng.

Hoàn tác nhiều commit

Đôi khi bạn cần quay lại vài commit để sắp xếp lại chuỗi thay đổi liên quan hoặc tích hợp phản hồi ảnh hưởng đến nhiều commit. Tình huống này xuất hiện thường xuyên trong các vòng review code.

git log --oneline -8
git reset --soft HEAD~4
git status
git commit -m "Refactor user authentication system based on security review

This consolidates the previous authentication improvements into a single
cohesive implementation that addresses all security concerns raised
during code review."Được hỗ trợ bởi

Khi phản hồi review ảnh hưởng đến nhiều commit, tôi dùng git log --oneline -8 để xác định commit cần cấu trúc lại, rồi git reset --soft HEAD~4. Lệnh này hoàn tác chúng trong khi giữ thay đổi đã stage. Sau khi chạy git status để xác nhận, tôi tạo một commit duy nhất giải quyết toàn bộ phản hồi trong một hiện thực mạch lạc.

Tôi nhớ một buổi review đặc biệt khó khi đội bảo mật phát hiện vấn đề trải dài ba commit khác nhau trong tính năng xác thực. Thay vì tạo thêm commit "fix", tôi dùng kỹ thuật này để tích hợp phản hồi và trình bày hiện thực đã sửa như một commit sạch, đơn nhất. Reviewer đánh giá cao việc không phải lần theo các bản sửa rải rác.

Cách tiếp cận này đặc biệt giá trị khi bạn đã thử nghiệm nhiều hiện thực và muốn trình bày giải pháp cuối cùng mà không phơi bày toàn bộ commit thử-sai dẫn đến đó.

Reset một file đơn trong index

Dù không riêng cho soft reset, hiểu thao tác reset ở cấp file sẽ bổ trợ cho quy trình soft reset và đem lại quyền kiểm soát chi tiết khu vực staging.

git add user_model.py user_controller.py debug_helper.py
git status
git reset debug_helper.py
git statusĐược hỗ trợ bởi

Sau khi stage nhiều file bằng git add user_model.py user_controller.py debug_helper.py, tôi nhận ra file debug không nên đưa vào. Tôi dùng git reset debug_helper.py. Lệnh này chỉ bỏ stage file đó, để các file khác vẫn được stage. Chạy git status xác nhận thao tác bỏ stage chọn lọc đã hoạt động hoàn hảo.

Mức kiểm soát chi tiết này trở nên thiết yếu trong quy trình của tôi. Tôi thường thấy mình đã stage nhiều file hơn dự định, và khả năng bỏ stage chọn lọc mà không ảnh hưởng lịch sử commit cho phép tôi tạo các commit chính xác.

Tôi cũng thấy điều này hữu ích khi làm việc với file sinh tự động hoặc khi IDE vô tình thêm file tôi không định commit. Nó sạch sẽ hơn nhiều so với bỏ stage tất cả rồi stage lại chọn lọc.

Giữ thay đổi trong working tree trong khi loại bỏ commit trước đó

Tình huống này xảy ra khi bạn muốn loại bỏ commit khỏi lịch sử nhưng giữ nguyên thay đổi mã để có thể tích hợp lại. Tôi dùng kỹ thuật này khi nhận ra cấu trúc commit của mình không kể đúng câu chuyện.

git log --oneline -4
git reset --soft HEAD~3
git reset
git add backend/
git commit -m "Implement backend API changes for user profile feature"
git add frontend/
git commit -m "Update frontend components for user profile display"Được hỗ trợ bởi

Khi tôi có các commit trộn frontend/backend cần tổ chức lại, tôi dùng git log --oneline -4 để xem lịch sử lộn xộn, rồi git reset --soft HEAD~3. Lệnh này xóa commit khỏi lịch sử trong khi giữ thay đổi đã stage. Chạy git reset (không cờ) để bỏ stage mọi thứ, cho phép tôi sắp xếp lại bằng cách thêm file backend trước, rồi frontend thành các commit logic riêng.

Quy trình này đặc biệt hữu ích khi làm tính năng full-stack, nơi ban đầu tôi commit chung frontend và backend, nhưng sau nhận ra nên tách commit để review dễ và có thể rollback từng phần.

Tách một commit thành nhiều commit nhỏ hơn

Chia nhỏ commit cải thiện chất lượng review và giúp việc gỡ lỗi sau này chính xác hơn. Kỹ thuật này đã cải thiện đáng kể phản hồi tôi nhận được trên pull request.

git show --name-only HEAD
git reset --soft HEAD~1
git reset
git add models/user_profile.py
git commit -m "Add user profile model with validation"
git add api/user_profile_endpoints.py  
git commit -m "Implement user profile API endpoints"
git add tests/test_user_profile.py
git commit -m "Add comprehensive user profile tests"
git add frontend/components/UserProfile.js
git add frontend/styles/user-profile.css
git commit -m "Add user profile frontend components and styling"Được hỗ trợ bởi

Tôi dùng git show --name-only HEAD để xem các file thay đổi trong commit lớn, rồi git reset --soft HEAD~1. Lệnh này hoàn tác commit trong khi giữ thay đổi đã stage. Chạy git reset (không cờ) để bỏ stage mọi thứ. Giờ tôi tạo commit tập trung: model trước, rồi API endpoints, sau đó test, rồi frontend. Cách này biến một commit quá tải thành các phần logic, dễ review.

Sự chuyển đổi này thật đáng kể. Thay vì reviewer phải hiểu một commit khổng lồ chạm vào nhiều mối quan tâm, họ có thể review từng phần logic riêng. Điều này dẫn đến phản hồi tốt hơn, review nhanh hơn và ít lỗi lọt vào production.

Tôi nhận thấy khi tôi chịu khó tách commit đúng cách, reviewer có xu hướng bắt được các vấn đề tinh vi hơn vì họ tập trung vào một mối quan tâm tại một thời điểm, thay vì bị “ngợp” bởi một bộ thay đổi lớn.

Thực Hành Tốt Nhất Khi Dùng Git Reset Soft

Quy trình Git chuyên nghiệp đòi hỏi kỷ luật để tránh mất dữ liệu và duy trì năng suất nhóm. Những nguyên tắc sau là bài học rút ra từ nhiều năm quản lý dự án phức tạp và, thú thật, từ vài sai lầm đắt giá.

Giao thức an toàn

Trước khi thực hiện bất kỳ thao tác reset nào, tôi luôn thiết lập “lưới an toàn” cho phép khôi phục khi mắc lỗi. Thói quen này hình thành sau một sự cố khá đau hồi đầu sự nghiệp khiến tôi mất vài giờ làm việc.

git branch backup-before-reset-$(date +%Y%m%d-%H%M%S)
git reset --soft HEAD~3
git reset --hard backup-before-reset-20250905-182003Được hỗ trợ bởi

Tôi luôn tạo nhánh backup trước khi thao tác rủi ro bằng git branch backup-before-reset-$(date +%Y%m%d-%H%M%S). Lệnh này tạo “lưới an toàn” có đóng dấu thời gian. Nếu có trục trặc sau khi reset, tôi có thể khôi phục bằng git reset --hard backup-before-reset-20250905-182003.

git status
git log --oneline -10
git diff --stagedĐược hỗ trợ bởi

Sau các thao tác reset, tôi xác minh mọi thứ bằng git status để kiểm tra staging, git log --oneline -10 để xem lịch sử commit, và git diff --staged. Lệnh cuối cho thấy chính xác điều gì sẽ nằm trong commit tiếp theo.

Quy tắc quan trọng nhất tôi tuân theo: không thực hiện reset trên các commit đã chia sẻ với người khác trừ khi có sự phối hợp rõ ràng với nhóm. Quy tắc này đã ngăn vô số xung đột và duy trì niềm tin trong đội.

Một kỹ thuật tôi dùng là đặt tên nhánh mô tả trạng thái đang làm dở. Ví dụ, feature/user-auth-wip báo hiệu rõ với đồng đội rằng lịch sử của nhánh này có thể thay đổi.

Giới hạn và cạm bẫy

Soft reset xử lý khéo các file được theo dõi, nhưng có vài điểm tinh tế dễ làm developer vướng. Hiểu các giới hạn này giúp tôi tránh bối rối và hành vi bất ngờ.

git reset --soft HEAD~2
git status
git add .Được hỗ trợ bởi

Khi tôi dùng git reset --soft HEAD~2, chạy git status cho thấy mọi thứ đã sẵn sàng. Lệnh này hoàn tác hai commit trong khi giữ thay đổi đã stage. Sau đó tôi có thể dùng git add . để stage bất kỳ chỉnh sửa bổ sung nào trước khi commit lại tất cả.

Viết lại lịch sử qua reset có thể gây nhầm lẫn cho cộng tác viên và làm gián đoạn quy trình chung. Tôi học cách thiết lập quy ước nhóm về thời điểm và cách dùng reset trên các nhánh chia sẻ. Ở đội hiện tại, chúng tôi có quy tắc: không viết lại lịch sử trên nhánh chính hoặc bất kỳ nhánh nào đã có người khác dựa vào.

Một lỗi tôi thấy ở một số developer là dùng soft reset trên các commit đã được merge vào nhánh khác. Điều này tạo lịch sử phân kỳ khó hòa giải và có thể khiến cùng một thay đổi xuất hiện nhiều lần trong lịch sử dự án.

Tôi cũng cẩn trọng khi reset các commit chứa kết quả giải quyết xung đột merge. Thông tin giải quyết xung đột sẽ mất trong reset, và nếu bạn cần merge lại, bạn sẽ phải giải quyết xung đột lần nữa.

Cộng tác và cân nhắc với nhánh remote

Truyền thông về thay đổi lịch sử giúp ngăn xung đột trong đội và duy trì ổn định dự án. Tôi đã phát triển một giao thức trao đổi thông tin phục vụ tốt cho các đội của mình trong nhiều năm.

git checkout -b feature/user-auth-history-cleanup
git reset --soft HEAD~4
git commit -m "Implement user authentication system"
git push origin feature/user-auth-history-cleanupĐược hỗ trợ bởi

Tôi làm việc trên các nhánh tính năng đặt tên rõ như git checkout -b feature/user-auth-history-cleanup. Lệnh này tạo một nhánh báo hiệu có thay đổi lịch sử. Sau khi thực hiện thao tác reset như git reset --soft HEAD~4, tôi push phiên bản đã dọn và tạo pull request với lịch sử được tổ chức.

git push --force-with-lease origin feature-branchĐược hỗ trợ bởi

Khi cần force-push, tôi dùng git push --force-with-lease. Lệnh này push an toàn, đảm bảo không ai khác đã cập nhật nhánh.

Tôi cũng duy trì thói quen ghi lại mọi thay đổi lịch sử lớn trong mô tả pull request. Ví dụ: "Lưu ý: Lịch sử nhánh này đã được dọn bằng git reset --soft để gộp 5 commit tăng dần thành 2 commit logic để review dễ hơn."

Giao tiếp là chìa khóa. Tôi luôn thông báo với các thành viên trước khi viết lại lịch sử trên bất kỳ nhánh nào họ có thể theo dõi, và tôi cung cấp rõ ràng hash commit trước/sau để họ hiểu điều gì đã đổi.

Khắc Phục Sự Cố và Khôi Phục

Ngay cả developer dày dạn cũng gặp tình huống thao tác reset không như kế hoạch. Hiểu kỹ thuật khôi phục giúp thêm tự tin khi dùng tính năng Git nâng cao và mang lại sự yên tâm khi làm việc với lịch sử phức tạp.

Sơ đồ quy trình cho thấy git reflog khôi phục commit bị mất sau hard reset.

Cách khôi phục commit sau khi dùng git reset --hard

Dù phần này tập trung vào khôi phục sau hard reset, hiểu nguyên tắc sẽ hữu ích cho mọi thao tác reset. Reflog của Git lưu lịch sử nơi HEAD đã trỏ tới, cho phép khôi phục các commit tưởng như đã mất.

git reflog
git reset --hard def5678
git branch recovery-branch def5678
git checkout recovery-branchĐược hỗ trợ bởi

Reflog của Git theo dõi lịch sử HEAD, cho phép khôi phục commit. Tôi chạy git reflog để xem lịch sử, xác định commit muốn khôi phục, rồi hoặc dùng git reset --hard def5678 để khôi phục trực tiếp, hoặc dùng cách an toàn hơn là git branch recovery-branch def5678 rồi git checkout recovery-branch để kiểm tra trước khi áp dụng.

Reflog đã cứu tôi không biết bao lần. Tôi nhớ có lần căng thẳng khi lỡ dùng git reset --hard thay vì git reset --soft và tưởng mất cả một ngày làm. Reflog cho tôi thấy chính xác công việc đã đi đâu, và chỉ trong vài phút tôi khôi phục được hết.

Reflog cung cấp lưới an toàn đáng kể, nhưng cần biết lưới đó tồn tại bao lâu. Git giữ hai mốc hết hạn khác nhau cho các bản ghi này:

• Bản ghi cho commit không còn truy cập được — như bị loại sau git reset --hard — được giữ 30 ngày theo mặc định.

• Bản ghi cho commit còn truy cập được (vẫn thuộc một nhánh) được giữ 90 ngày theo mặc định.

Trong tình huống khôi phục như vậy, bạn có khoảng một tháng để lấy lại công việc. Tuy nhiên, điều này chỉ áp dụng cho commit từng thuộc lịch sử cục bộ của bạn. Nếu bạn chưa từng commit cục bộ, ngay cả reflog cũng không thể giúp.

Một kỹ thuật tôi dùng khi sắp thao tác rủi ro là tạo commit tạm trước, dù công việc chưa sẵn sàng. Tôi có thể reset sau, nhưng có nó trong reflog sẽ tăng thêm lớp an toàn.

Hoàn tác một commit trên remote

Khi commit đã được push lên remote, quy trình khôi phục trở nên phức tạp hơn và cần phối hợp nhóm. Tình huống này đòi hỏi cân nhắc kỹ tác động tới thành viên khác.

git reset --soft HEAD~1
git commit -m "Corrected implementation with proper error handling"
git push --force-with-lease origin main
git revert abc1234
git push origin mainĐược hỗ trợ bởi

Với commit chưa bị người khác pull, tôi dùng git reset --soft HEAD~1. Lệnh này hoàn tác commit trong khi giữ thay đổi đã stage. Sau đó tôi tạo commit đã sửa và push với --force-with-lease. Với commit đã được phân phối rộng rãi, git revert abc1234 rồi push bình thường an toàn hơn vì không làm gián đoạn công việc của người khác.

Tôi học được tầm quan trọng của phân biệt này trong một dự án khi tôi force-push viết lại lịch sử lên nhánh chia sẻ mà ba developer khác đã dựa vào. Các xung đột merge và rối rắm sau đó mất nửa ngày để giải quyết, dạy tôi thận trọng hơn nhiều với việc viết lại lịch sử chung.

Force-push lên nhánh chia sẻ nên là biện pháp cuối cùng và cần truyền thông rõ ràng trong đội. Trong hầu hết trường hợp, git revert là lựa chọn an toàn hơn vì tạo commit mới để hoàn tác thay vì viết lại lịch sử.

Kết Luận

Làm chủ git reset --soft giúp bạn quản lý commit chính xác mà vẫn giữ nguyên công việc. Nó lý tưởng để dọn dẹp commit, cải thiện message, hoặc chuẩn bị lịch sử trau chuốt cho cộng tác, tất cả mà không mất tiến độ quý giá.

Để nâng cao kỹ năng, hãy khám phá Version Control with Git hoặc khóa GitHub Concepts.