Làm cách nào để tìm băm nhánh trong Git?

Với tên nhánh cục bộ / từ xa, làm cách nào tôi có thể lấy băm của cam kết mà nhánh này trỏ tới?

Lệnh git rev-parselà bạn của bạn, ví dụ:

$ git rev-parse development
17f2303133734f4b9a9aacfe52209e04ec11aff4

... hoặc cho chi nhánh theo dõi từ xa:

$ git rev-parse origin/master
da1ec1472c108f52d4256049fe1f674af69e785d

Lệnh này nhìn chung rất hữu ích, vì nó có thể phân tích cú pháp bất kỳ cách nào để chỉ định tên nhánh git, chẳng hạn như:

git rev-parse master~3
git rev-parse HEAD@{2.days.ago}

... Vân vân.

Các băm được lưu trữ dưới .git/refs/, ví dụ:.git/refs/heads/master

Nhưng sử dụng git rev-parsetheo chương trình theo đề xuất của Mark Longair vì nó an toàn hơn.

Đừng quên rằng kể từ Git 2.19 (Quý 2 năm 2018), Git chuẩn bị chuyển đổi từ hàm băm SHA1 sang SHA2: xem " Tại sao Git không sử dụng SHA hiện đại hơn? "

Với Git 2.25 (Q1 2020), git rev-parsephát triển và phản ánh hàm băm mới có thể có.

Xem cam kết fa26d5e , cam kết cf02be8 , cam kết 38ee26b , cam kết 37ab8eb , cam kết 0370b35 , cam kết 0253e12 , cam kết 45e2ef2 , cam kết 79b0edc , cam kết 840624f , cam kết 32a6707 , cam kết 440bf91 , cam kết 0b408ca , cam kết 2eabd38 (28 tháng 10 2019), và cam kết 1bcef51 , cam kết ecde49b (05 Oct 2019) bởi brian m. carlson ( bk2204) .
^{(Hợp nhất bởi Junio ​​C Hamano - gitster- trong cam kết 28014c1, Ngày 10 tháng 11 năm 2019)}

rev-parse: thêm một --show-object-formattùy chọn

^{Người ký tên: brian m. carlson}

Thêm một tùy chọn để in định dạng đối tượng được sử dụng để nhập, xuất hoặc lưu trữ.
Điều này cho phép các tập lệnh shell phát hiện ra thuật toán băm đang được sử dụng.

Vì kế hoạch chuyển đổi cho phép nhiều thuật toán đầu vào, tài liệu mà chúng tôi có thể cung cấp nhiều kết quả cho đầu vào và định dạng kết quả có thể có.
Mặc dù hiện tại chúng tôi không hỗ trợ điều này, nhưng việc ghi chép nó sớm có nghĩa là các tác giả kịch bản có thể kiểm chứng lại kịch bản của họ trong tương lai khi chúng tôi thực hiện.

Các git rev-parsetài liệu hiện nay bao gồm:

--show-object-format[=(storage|input|output)]:

Hiển thị định dạng đối tượng (thuật toán băm) được sử dụng cho kho lưu trữ bên trong .gitthư mục, đầu vào hoặc đầu ra. Đối với đầu vào, nhiều thuật toán có thể được in, được phân tách bằng dấu cách. Nếu không được chỉ định, mặc định là "bộ nhớ".

Với Git 2.29 (Q4 2020), bạn có thể đảm bảo định dạng bạn phải sử dụng để đọc cam kết băm của một nhánh (hoặc bất kỳ đối tượng nào khác).

Xem cam kết e023ff0 , cam kết 4feb562 , cam kết 8a06d56 , cam kết c49fe07 , cam kết 02a32db , cam kết ceaa4b3 , cam kết eff45da , cam kết b5b46d7 , cam kết c5aecfc , cam kết e74b606 , cam kết 439d3a1 , cam kết 6c2adf8 , cam kết de5737c , cam kết e0a646e , cam kết 6ff6a67 , cam kết 831279d , cam kết b6e5005 , cam kết 287bb3a , cam kết 22f1824 , cam kết db00af9 ,cam kết 7187eb1 , cam kết 98de0b2 , cam kết a5587b8 , cam kết 66b6d43 , cam kết 2197f87 , cam kết c0b65ea , cam kết d62607d , cam kết d482c23 , cam kết 866be6e , cam kết 4bacb6d , cam kết 252a4ee , cam kết 368f3cb , cam kết abe3db1 , cam kết 08fbc5d , cam kết 11b6961 , cam kết 9e3bd8a , cam kết d827bce , cam on 094a685 (29 Jul 2020) by brian m. carlson ( bk2204) .
Xemcam kết 800e6a7 (29 tháng 7 năm 2020) bởi Johannes Schindelin ( dscho) .
^{(Được hợp nhất bởi Junio ​​C Hamano - gitster- trong cam kết e0ad957 , ngày 11 tháng 8 năm 2020)}

docs: thêm tài liệu cho extensions.objectFormat

^{Ký tên bởi: brian m. carlson Người
đánh giá: Eric Sunshine}

Ghi lại extensions.objectFormatcài đặt cấu hình.
Cảnh báo người dùng không được tự sửa đổi.

git configbây giờ bao gồm trong trang người đàn ông của nó :

extensions.objectFormat

Chỉ định thuật toán băm để sử dụng.

Các giá trị được chấp nhận là sha1và> sha256.
Nếu không được chỉ định, sha1được giả định.
Đó là một lỗi khi chỉ định khóa này trừ khi core.repositoryFormatVersionlà 1.

Lưu ý rằng cài đặt này chỉ nên được đặt bởi git inithoặc git clone.
Cố gắng thay đổi nó sau khi khởi tạo sẽ không hoạt động và sẽ tạo ra các vấn đề khó chẩn đoán.

Nói rõ hơn, với Git 2.29 (Q4 2020), việc bổ sung hỗ trợ SHA-256 gần đây được đánh dấu là thử nghiệm trong tài liệu.

Xem cam kết ff233d8 (16 tháng 8 năm 2020) bởi Martin Ågren ( none) .
^{(Hợp nhất bởi Junio ​​C Hamano - gitster- in cam kết d1ff741 , ngày 24 tháng 8 năm 2020)}

Documentation: đánh dấu --object-format=sha256là thử nghiệm

^{Ký tên: Martin Ågren}

Sau eff45daab8 (" repository: kích hoạt hỗ trợ SHA-256 theo mặc định", 2020-07-29, Git v2.29.0 - hợp nhất được liệt kê trong lô # 6 ), các bản dựng vani của Git cho phép người dùng chạy, ví dụ:

git init --object-format=sha256  

và hack đi.
Đây có thể là một cách tốt để có được kinh nghiệm với thế giới SHA-256, ví dụ: để tìm lỗi

GIT_TEST_DEFAULT_HASH=sha256 make test  

không phát hiện.

Nhưng nó thực sự là một thế giới riêng biệt: Các repo SHA-256 như vậy sẽ hoàn toàn tách biệt với tập hợp các repo SHA-1 (hiện nay là khá lớn).
Tương tác xuyên biên giới về nguyên tắc là có thể thực hiện được, ví dụ: thông qua " diff+ apply" (hoặc " format-patch+ am"), nhưng ngay cả điều đó cũng có những hạn chế của nó: Áp dụng khác biệt SHA-256 trong repo SHA-1 hoạt động trong trường hợp đơn giản, nhưng nếu bạn cần phải dùng đến -3, bạn không may mắn.

Tương tự, " push+ pull" sẽ hoạt động, nhưng bạn thực sự sẽ hoạt động chủ yếu được bù đắp từ phần còn lại của thế giới. Điều đó có thể ổn vào thời điểm bạn khởi tạo kho lưu trữ của mình và có thể ổn trong vài tháng sau đó, nhưng có thể sẽ đến một ngày bạn bắt đầu hối hận khi sử dụng [git init --object-format = sha256 ](https://github.com/git/git/blob/ff233d8dda12657a90d378f2b403bc6c85838c59/Documentation/git-init.txt#L52)<sup>([man](https://git-scm.com/docs/git-init#Documentation/git-init.txt---object-formatltformatgt))</sup>và có tự đào mình xuống một cái hố khá sâu.

Hiện có các chủ đề đang được triển khai để ghi lại các định dạng và giao thức dữ liệu của chúng tôi liên quan đến SHA-256 và trong một số trường hợp (midx và biểu đồ cam kết), chúng tôi đang xem xét điều chỉnh cách định dạng tệp cho biết định dạng đối tượng nào sẽ sử dụng.

Bất cứ nơi nào --object-formatđược đề cập trong tài liệu của chúng tôi, hãy làm rõ rằng việc sử dụng nó với "sha256" là thử nghiệm.
Nếu sau này chúng tôi cần giải thích lý do tại sao chúng tôi không thể xử lý dữ liệu mà chúng tôi đã tạo vào năm 2020, chúng tôi luôn có thể chỉ ra đoạn này mà chúng tôi đang thêm ở đây.

Bằng cách "bao gồm ::" - thêm một chút lỗi nhỏ, chúng ta sẽ có thể nhất quán trong toàn bộ tài liệu và cuối cùng có thể giảm dần mức độ nghiêm trọng của văn bản này.
Một ngày nào đó, chúng ta thậm chí có thể sử dụng nó để bắt đầu loại bỏ dần dần --object-format=sha1, nhưng chúng ta đừng vượt lên chính mình ...

Cũng có extensions.objectFormat, nhưng nó chỉ được đề cập ba lần. Hai lần chúng tôi thêm tuyên bố từ chối trách nhiệm mới này và ở vị trí thứ ba, chúng tôi đã có cảnh báo "không chỉnh sửa". Từ đó, những độc giả quan tâm cuối cùng sẽ tìm thấy cái mới này mà chúng tôi đang thêm ở đây.

Bởi vì GIT_DEFAULT_HASHcung cấp một điểm vào khác cho chức năng này, hãy ghi lại bản chất thử nghiệm của nó.

gitbây giờ bao gồm trong trang người đàn ông của nó :

được sử dụng thay thế. Giá trị mặc định là "sha1". BIẾN SỐ NÀY LÀ THỰC NGHIỆM! Xem --object-formattrong git init.

object-format-disclaimerbây giờ bao gồm trong trang người đàn ông của nó :

LỰA CHỌN NÀY LÀ THỰC NGHIỆM!
Hỗ trợ SHA-256 là thử nghiệm và vẫn đang trong giai đoạn đầu.

Một kho lưu trữ SHA-256 nói chung sẽ không thể> chia sẻ công việc với các kho lưu trữ SHA-1 "thông thường".
Nên giả định rằng, ví dụ, các định dạng tệp nội bộ Git liên quan đến kho lưu trữ SHA-256 có thể thay đổi theo những cách không tương thích ngược.
Chỉ sử dụng --object-format=sha256cho mục đích thử nghiệm.

Git 2.29 tương tự (Q4 2020) đảm bảo rằng " git clone" ^{( man )} sẽ hoạt động khi một bản sao từ kho lưu trữ SHA-1, trong khi đã GIT_DEFAULT_HASHđược thiết lập để sử dụng SHA-256.
Trước 2.29, điều đó dẫn đến một kho lưu trữ không thể sử dụng được mà một nửa tuyên bố là kho lưu trữ SHA-256 với các đối tượng SHA-1 và các tham chiếu.
Điều này đã được sửa chữa.

Xem cam kết 47ac970 (20/09/2020) bởi brian m. carlson ( bk2204) .
^{(Được hợp nhất bởi Junio ​​C Hamano - gitster- trong cam kết b28919c , ngày 29 tháng 9 năm 2020)}

builtin/clone: tránh thất bại với GIT_DEFAULT_HASH

^{Người trình bày: Matheus Tavares
Người ký tên: brian m. carlson}

Nếu người dùng đang sao chép kho lưu trữ SHA-1 với GIT_DEFAULT_HASHđặt thành " sha256", thì chúng tôi có thể kết thúc với một kho lưu trữ có phiên bản định dạng kho lưu trữ là 0 nhưng extensions.objectformatkhóa được đặt thành " sha256".
Điều này vừa sai (người dùng có kho lưu trữ SHA-1) vừa không đúng chức năng (vì không thể sử dụng tiện ích mở rộng trong kho lưu trữ v0).

Điều này xảy ra bởi vì trong một bản sao, ban đầu chúng tôi thiết lập kho lưu trữ, sau đó thay đổi thuật toán của nó dựa trên những gì phía từ xa cho chúng tôi biết nó đang sử dụng.
Ban đầu, chúng tôi đã thiết lập kho lưu trữ là SHA-256 trong trường hợp này, sau đó đặt lại phiên bản kho lưu trữ mà không xóa phần mở rộng.

Chúng tôi luôn có thể đặt tiện ích mở rộng trong trường hợp này, nhưng điều đó có nghĩa là kho SHA-1 của chúng tôi không tương thích với các phiên bản Git cũ hơn, mặc dù không có lý do gì khiến chúng không nên như vậy.
Và chúng tôi cũng không muốn khởi tạo kho lưu trữ dưới dạng SHA-1 ban đầu, vì điều đó có nghĩa là nếu chúng tôi nhân bản một kho lưu trữ trống, chúng tôi sẽ không đáp ứng được GIT_DEFAULT_HASHbiến và sẽ kết thúc với một kho lưu trữ SHA-1, không kho lưu trữ SHA-256.

Cả hai điều đó đều không hấp dẫn, vì vậy hãy cho biết mã khởi tạo kho lưu trữ nếu chúng tôi đang thực hiện khởi động lại như thế này và nếu có, hãy xóa tiện ích mở rộng nếu chúng tôi đang sử dụng SHA-1.
Điều này đảm bảo chúng tôi tạo ra một kho lưu trữ hợp lệ và chức năng và không phá vỡ bất kỳ trường hợp sử dụng nào khác của chúng tôi.