'Git đổ lỗi' làm gì?

Tôi đã thấy rất nhiều câu hỏi về phương pháp sử dụng git blame, nhưng tôi không thực sự hiểu chúng.

Tôi thấy một Blamenút trên đầu tệp trên giao diện GitHub. Khi nhấp vào nó, nó hiển thị một số khác với tên người dùng trên thanh bên trái. Điều đó chỉ ra điều gì?

Tại sao git blamethực sự được sử dụng, ngoài GitHub?

Từ git-đổ lỗi :

Chú thích từng dòng trong tệp đã cho với thông tin từ bản sửa đổi cuối cùng đã sửa đổi dòng. Tùy chọn, bắt đầu chú thích từ sửa đổi nhất định.

Khi được chỉ định một hoặc nhiều lần, -L giới hạn chú thích cho các dòng được yêu cầu.

Thí dụ:

johndoe@server.com:~# git blame .htaccess
...
^e1fb2d7 (John Doe 2015-07-03 06:30:25 -0300  4) allow from all
^72fgsdl (Arthur King 2015-07-03 06:34:12 -0300  5)
^e1fb2d7 (John Doe 2015-07-03 06:30:25 -0300  6) <IfModule mod_rewrite.c>
^72fgsdl (Arthur King 2015-07-03 06:34:12 -0300  7)     RewriteEngine On
...

Xin lưu ý rằng git blamekhông hiển thị lịch sử sửa đổi trên mỗi dòng theo nghĩa thời gian. Nó chỉ cho thấy ai là người cuối cùng đã thay đổi một dòng trong tài liệu cho đến lần cam kết cuối cùng HEAD.

Điều đó có nghĩa là để xem toàn bộ lịch sử / nhật ký của một dòng tài liệu, bạn sẽ cần phải chạy một git blame path/to/filecho mỗi cam kết trong của bạn git log.

Lệnh giải thích chính nó khá tốt. Đó là tìm ra đồng nghiệp nào đã viết dòng cụ thể hoặc phá hỏng dự án, vì vậy bạn có thể đổ lỗi cho họ :)

Từ GitHub :

Lệnh đổ lỗi là một tính năng Git, được thiết kế để giúp bạn xác định ai đã thay đổi tệp.

Mặc dù tên nghe có vẻ tiêu cực, nhưng git đổ lỗi thực sự khá vô hại; chức năng chính của nó là chỉ ra ai đã thay đổi dòng nào trong một tệp và tại sao. Nó có thể là một công cụ hữu ích để xác định các thay đổi trong mã của bạn.

Về cơ bản, git-blameđược sử dụng để hiển thị bản sửa đổi và tác giả đã sửa đổi lần cuối mỗi dòng của một tệp. Nó giống như kiểm tra lịch sử phát triển của một tập tin.

Các git blamelệnh được sử dụng để biết ai / mà cam kết chịu trách nhiệm về thay đổi mới nhất thực hiện cho một tập tin. Tác giả / cam kết của từng dòng cũng có thể được nhìn thấy.

git blame filename (cam kết chịu trách nhiệm cho các thay đổi cho tất cả các dòng trong mã)

git blame filename -L 0,10 (cam kết chịu trách nhiệm cho các thay đổi từ dòng "0" sang dòng "10")

Có nhiều lựa chọn khác để đổ lỗi, nhưng nhìn chung chúng có thể giúp ích.

Các git blamelệnh annotates dòng với thông tin từ phiên bản đó sửa đổi lần cuối dòng, và ... với Git 2.22 (Q2 2019), sẽ làm như vậy nhanh hơn , vì một sửa chữa thực hiện xung quanh " git blame", đặc biệt là trong một lịch sử tuyến tính (đó là định mức chúng ta nên tối ưu hóa cho).

Xem cam kết f892014 (02 tháng 4 năm 2019) của David Kastrup ( fedelibre) . ^{(Được hợp nhất bởi Junio ​​C Hamano - gitster- trong cam kết 4d8c4da , ngày 25 tháng 4 năm 2019)}

blame.c: không bỏ các đốm gốc như háo hức

Khi một blob cha mẹ đã có hàng đợi xếp hàng để đổ lỗi, việc bỏ blob ở cuối một bước đổ lỗi sẽ khiến nó được tải lại ngay lập tức, tăng gấp đôi lượng I / O và giải nén khi xử lý lịch sử tuyến tính.

Giữ các đốm màu cha mẹ như vậy trong bộ nhớ có vẻ như là một tối ưu hóa hợp lý sẽ gây thêm áp lực bộ nhớ chủ yếu khi xử lý các phép hợp nhất từ ​​các nhánh cũ.

Các git blamelệnh được sử dụng để kiểm tra các nội dung của một dòng tập tin bằng cách dòng và nhìn thấy khi mỗi dòng được sửa đổi lần cuối và ai là tác giả của những sửa đổi đã.

Nếu có một lỗi trong mã, hãy sử dụng nó để xác định ai đã xử lý nó, sau đó bạn có thể đổ lỗi cho anh ta. Git đổ lỗi là nhận lỗi (d).

Nếu bạn cần biết lịch sử của một mã dòng, hãy sử dụng git log -S"code here", đơn giản hơn git đổ lỗi.

đăng nhập git vs git đổ lỗi