Làm thế nào để tôi không hoàn nguyên lại một cam kết Git được hoàn nguyên?

Đưa ra một thay đổi đã được cam kết sử dụng commit, và sau đó được hoàn nguyên bằng cách sử dụng revert, cách tốt nhất để hoàn tác lại đó là gì?

Lý tưởng nhất, điều này nên được thực hiện với một cam kết mới, để không viết lại lịch sử.

Nếu bạn chưa thúc đẩy sự thay đổi đó, git reset --hard HEAD^

Nếu không, hoàn nguyên hoàn nguyên là hoàn toàn tốt.

Một cách khác là git checkout HEAD^^ -- .và sau đó git add -A && git commit.

git cherry-pick <original commit sha>
Sẽ tạo một bản sao của cam kết ban đầu, về cơ bản áp dụng lại cam kết

Hoàn nguyên hoàn nguyên sẽ làm điều tương tự, với một thông điệp cam kết lộn xộn hơn:
git revert <commit sha of the revert>

Một trong những cách này sẽ cho phép bạn git pushmà không ghi đè lên lịch sử, bởi vì nó tạo ra một cam kết mới sau khi hoàn nguyên.
Khi nhập sha xác nhận, thông thường bạn chỉ cần 5 hoặc 6 ký tự đầu tiên:
git cherry-pick 6bfabc

Một cam kết hoàn nguyên cũng giống như bất kỳ cam kết nào khác trong git. Có nghĩa là, bạn có thể hoàn nguyên nó, như trong:

git revert 648d7d808bc1bca6dbf72d93bf3da7c65a9bd746

Điều đó rõ ràng chỉ có ý nghĩa một khi các thay đổi được đẩy, và đặc biệt là khi bạn không thể buộc đẩy vào nhánh đích (đó là một ý tưởng tốt cho nhánh chính của bạn ). Nếu thay đổi chưa được đẩy, chỉ cần thực hiện chọn cherry, hoàn nguyên hoặc đơn giản là xóa cam kết hoàn nguyên theo các bài đăng khác.

Trong nhóm của chúng tôi, chúng tôi có một quy tắc sử dụng hoàn nguyên trên các cam kết Revert đã được cam kết trong nhánh chính, chủ yếu là để giữ cho lịch sử sạch sẽ, để bạn có thể thấy cam kết nào hoàn nguyên những gì:

      7963f4b2a9d   Revert "Revert "OD-9033 parallel reporting configuration"
      "This reverts commit a0e5e86d3b66cf206ae98a9c989f649eeba7965f.
                    ...
     a0e5e86d3b6    Revert "OD-9055 paralel reporting configuration"
     This reverts commit 648d7d808bc1bca6dbf72d93bf3da7c65a9bd746.
                ...
     Merge pull request parallel_reporting_dbs to master* commit 
    '648d7d808bc1bca6dbf72d93bf3da7c65a9bd746'

Bằng cách này, bạn có thể theo dõi lịch sử và tìm ra toàn bộ câu chuyện, và ngay cả những người không có kiến ​​thức về di sản cũng có thể tự mình giải quyết. Trong khi đó, nếu bạn chọn thứ anh đào hoặc rebase , thông tin có giá trị này sẽ bị mất (trừ khi bạn đưa nó vào bình luận).

Rõ ràng, nếu một cam kết được hoàn nguyên và hoàn nguyên lại nhiều lần, điều đó trở nên khá lộn xộn.

Hoàn nguyên hoàn nguyên sẽ thực hiện các mẹo

Ví dụ,

Nếu abcdeflà cam kết của bạn và ghijkllà cam kết bạn có khi hoàn nguyên cam kết abcdef, thì hãy chạy:

git revert ghijkl

Điều này sẽ hoàn nguyên hoàn nguyên

Nó có vẻ ngu ngốc đối với tôi. Nhưng tôi đã ở trong tình huống tương tự và tôi đã hoàn nguyên các cam kết được hoàn nguyên. Tôi đã hoàn nguyên số vì vậy tôi phải hoàn nguyên cho mỗi 'cam kết hoàn nguyên'.

Bây giờ lịch sử cam kết của tôi trông hơi kỳ lạ một chút.

Đây là một dự án thú cưng nên không sao. Nhưng đối với dự án thực tế, tôi sẽ ưu tiên thực hiện cam kết cuối cùng trước khi hoàn nguyên khôi phục tất cả mã được hoàn nguyên cùng nhau trong một cam kết và nhận xét hợp lý hơn.

Đây là cách tôi đã làm:
Nếu chi nhánh my_branchnameđược bao gồm trong một hợp nhất đã được hoàn nguyên. Và tôi muốn hủy bỏ my_branchname:

Trước tiên tôi làm một git checkout -b my_new_branchnametừ my_branchname.
Sau đó, tôi làm một git reset --soft $COMMIT_HASHnơi $COMMIT_HASHlà cam kết hash của cam kết ngay trước khi cam kết đầu tiên của my_branchname(xem git log)
sau đó tôi thực hiện một cam kết mới git commit -m "Add back reverted changes"
sau đó tôi đẩy mạnh các chi nhánh mới git push origin new_branchname
sau đó tôi đã thực hiện một yêu cầu kéo cho chi nhánh mới.

Hoặc bạn có thể git checkout -b <new-branch>và git cherry-pick <commit>trước đó để và git rebasebỏ revertcam kết. gửi yêu cầu kéo như trước đây.

Nếu bạn không thích ý tưởng "hoàn nguyên hoàn nguyên" (đặc biệt là khi điều đó có nghĩa là mất thông tin lịch sử cho nhiều lần xác nhận), bạn luôn có thể hướng đến tài liệu git về "Hoàn nguyên hợp nhất bị lỗi" .

Cho tình huống bắt đầu sau đây

 P---o---o---M---x---x---W---x
  \         /
   A---B---C----------------D---E   <-- fixed-up topic branch

(W là hoàn nguyên ban đầu của bạn về hợp nhất M; D và E là các bản sửa lỗi cho nhánh / cam kết tính năng bị hỏng ban đầu của bạn)

Bây giờ bạn có thể chỉ cần phát lại cam kết từ A đến E, để không ai trong số họ "thuộc về" hợp nhất hoàn nguyên:

$ git checkout E
$ git rebase --no-ff P

Bản sao mới của chi nhánh của bạn bây giờ có thể được hợp nhất masterlại:

   A'---B'---C'------------D'---E'  <-- recreated topic branch
  /
 P---o---o---M---x---x---W---x
  \         /
   A---B---C----------------D---E

Để lấy lại những thay đổi chưa được dàn dựng và dàn dựng được hoàn nguyên sau một cam kết:

git reset HEAD@{1}

Để khôi phục tất cả các thao tác xóa chưa được chỉnh sửa:

git ls-files -d | xargs git checkout --