Thử tưởng tượng một ngày đẹp trời, bạn đang code nhiệt tình một feature trên nhánh release riêng của mình, thì một đồng nghiệp khác cũng đang phát triển một feature riêng của họ, và rồi một sự nhầm lẫn xảy ra họ bỗng nhiên merge code vào branch release của bạn mà họ không hề để ý, còn bạn thì không hề hay biết.

Mấy hôm sau cái tính năng của bạn lên Production và do ảnh hưởng từ cái commit của người đồng nghiệp kia nên một tính năng khác đã bị ảnh hưởng nghiệm trọng, và rồi bạn phải giải trình bla blo, xì xà xì xồ với sếp.

Mình nói vui vậy thôi chứ khi cái commit của người đồng nghiệp kia xâm nhập vào branch của bạn mà bạn vẫn để nó lên được Production thì không phải là lỗi của họ nữa rồi, mà là lỗi do bạn review MR không chuẩn rồi.

Vậy thì trong quá trình review MR, bạn phải giải quyết vấn đề này như thế nào cho duyên dáng mà tình đồng nghiệp vẫn thắm thiết bây giờ?

  • Gọi ông đồng nghiệp ra và bảo người ta loại bỏ commit đó ra khỏi branch của mình chỉ vì đơn giản họ làm việc không đúng git-flow?
  • Hay bạn sẽ tự xử lý trong âm thầm, trong ấm ức vì sai lầm của đồng nghiệp?

Dù bạn chọn phương án nào đi nữa, thì trước tiên bạn cũng cần phải biết cách xử lý loại bỏ commit thừa kia trước đã.

Git Reset

Git Log

Xem lịch sử commit ở trên, giả sử cái commit của đồng nghiệp là cái commit mới nhất, có log message commit là file test 4 , ta tiến hành thực hiện lệnh sau:

git reset --hard 65dc2876c0184c82510555a62ddf296b94a6c5ec

Mục tiêu là để quay lại cái commit trước đó của bạn, có log message commit là file test 3

git reset –hard 65dc2876c0184c82510555a62ddf296b94a6c5ec

Lúc này code trên local của bạn đã trở về commit mới nhất của riêng bạn, thực hiện đẩy code lên remote repository bằng command sau:

git push -f origin master

git push -f origin master

Kiểm tra lại bằng lệnh git log thì ta thấy rằng, cái commit của đồng nghiệp đã hoàn toàn biến mất, quá tuyệt vời phải không nào?

Nhưng mà có gì đó chưa hoàn hảo ở đây thì phải? nãy mình giả sử cái commit file test 4 là commit có vấn đề của đồng nghiệp, nhưng giờ hãy giả sử commit có vấn đề là commit file test 3 đi, vậy thì mình có làm được như cách ở trên nữa không đây?

Git Revert

Đơn giản là mình sẽ bốc cái commit file test 3 kia ra khỏi tree và không làm ảnh hưởng đến những commit trước và sau nó.

git log

Thực hiện command sau để revert commit file test 3

git revert -n 65dc2876c0184c82510555a62ddf296b94a6c5ec

Sau đó commit và gửi về remote repository

git revert -n 65dc2876c0184c82510555a62ddf296b94a6c5ec

Lúc này bạn đã thực hiện được việc loại bỏ commit lỗi của đồng nghiệp ra khỏi branch của bạn rồi, mọi vấn đề đã được giải quyết hết sức dễ dàng.

Vậy chốt lại git reset khác git revert như thế nào?

  • git reset loại bỏ hoàn toàn các commit kể từ commit bạn chọn trở về sau, việc này phù hợp với những case đơn giản/có thể là phức tạp, không có nhiều commit quan trọng kể từ commit lựa chọn để reset.
  • git revert phù hợp trong những trường hợp cần loại bỏ những commit ở các vị trí khác nhau.

Ở trên mình có toàn quyền truy cập với branch master, và thích làm gì thì làm, tuy nhiên khi đi làm thực tế ở các công ty, không phải lúc nào account git của bạn cũng có đầy đủ các quyền để mà force push hay thoải mái thao tác trên những branch protected, vậy nên trong quá trình làm việc các bạn hãy nghiền ngẫm, tìm tòi thêm các phương pháp khác nữa và sáng tạo cho bản thân một cách thực hiện tối ưu nhất nhé.

Một số bài viết liên quan: