Bắt đầu một tin nhắn cam kết git với một dấu băm (#)


283

Git coi các dòng bắt đầu bằng #các dòng nhận xét khi cam kết. Điều này rất khó chịu khi làm việc với hệ thống theo dõi vé và cố gắng viết số vé ở đầu dòng, ví dụ:

#123 salt hashed passwords

git sẽ chỉ xóa dòng khỏi thông điệp cam kết. Có cách nào để thoát khỏi hàm băm không? tôi đã thử \!, nhưng không có gì hoạt động. khoảng trắng trước đây #được bảo tồn, vì vậy chúng cũng không phải là giải pháp hiệu quả cho vấn đề.


8
@AlexBudovski vì có giá trị ngắn gọn.
Xavi

8
Kể từ git 1.8.2 (tháng 2 năm 2013), git config core.commentcharcho phép định cấu hình ký tự nhận xét đó. Xem câu trả lời của tôi dưới đây
VonC

3
Vì Git v2.0.0 (2014.05.21) git commit --cleanup=scissorssẽ linh hoạt hơn. Xem chi tiết trong câu trả lời của tôi
Sungam

4
Tôi phải nói rằng, tôi rất ngạc nhiên khi người GitHub không nghĩ về vấn đề này khi họ quyết định đánh dấu các số phát hành bằng băm!
Michael Scheper

1
@Michael Công bằng mà nói, quy ước này đã được sử dụng bởi Mantis, Trac, Redmine và có lẽ những người khác. Tôi cho rằng GitHub chỉ quyết định đi theo nó thay vì phát minh lại bánh xe. Xem stackoverflow.com/questions
40495 / từ

Câu trả lời:


235

Hành vi này là một phần của hành vi git commit'dọn dẹp' mặc định. Nếu bạn muốn giữ các dòng bắt đầu với #bạn có thể sử dụng chế độ dọn dẹp thay thế.

Ví dụ

git commit --cleanup=whitespace

Nếu bạn làm điều này, bạn phải cẩn thận để xóa tất cả các #dòng mà bạn không muốn xuất hiện trong cam kết.


Câu hỏi tiếp theo là: Tôi có thể chỉnh sửa nhận xét thông báo cam kết mà git giới thiệu bắt đầu theo mặc định bằng # ở đâu?
Alex

2
@Alex: Nó được điều khiển bởi commit.templatebiến cấu hình git.
CB Bailey

23
Điều này hoạt động rất tốt để sửa đổi các cam kết hiện có. Ví dụ:git commit --amend --cleanup=whitespace
James Andres

@CharlesBailey: Tôi đã hy vọng thoát khỏi văn bản được xác định trước bằng git commit -t / dev / null nhưng nó vẫn cho thấy điều đó
Alex

Vì bạn có thể có một thông báo cam kết về "# 123 Thông điệp cam kết" cũng như các nhận xét trong các ứng dụng khách như GitHub cho Mac và SourceTree Tôi đoán là những khách hàng này đang làm gì?
Phil Ostler

134

Lưu ý rằng, kể từ git1.8.2 (tháng 2 năm 2013) , bạn có thể sử dụng một ký tự khác với ' #' cho dòng nhận xét trong thông báo cam kết.

Điều đó cho phép bạn sử dụng ' #' để tham khảo số lỗi của bạn.

Các dòng "gợi ý" khác nhau mà Git đưa ra khi nó yêu cầu người dùng chỉnh sửa tin nhắn trong trình chỉnh sửa được nhận xét bằng ' #' theo mặc định.

Biến core.commentCharcấu hình có thể được sử dụng để tùy chỉnh ' #' này thành một ký tự khác.


Về lý thuyết, bạn có thể đặt một core.commentChartừ (nhiều ký tự), nhưng git 2.0.x / 2.1 sẽ chặt chẽ hơn (quý 3 năm 2014).

Xem cam kết 50b54fd của Nguyễn Thái Ngọc Duy ( pclouds) :

cấu hình: nghiêm ngặt trên core.commentChar

Chúng tôi không hỗ trợ các chuỗi nhận xét (ít nhất là chưa). Và mã hóa ký tự nhiều byte cũng có thể bị hiểu sai.

Bài kiểm tra với hai dấu phẩy được cập nhật vì nó vi phạm điều này. Nó được thêm vào với bản vá giới thiệu core.commentChartrong eff80a9 (Cho phép tùy chỉnh "bình luận char" - 2013-01-16). Tôi không rõ tại sao hành vi đó lại muốn.


git 2.0.x / 2.1 (quý 3 năm 2014) sẽ thêm lựa chọn tự động cho core.commentChar:
Xem cam kết 84c9dc2

Khi core.commentCharlà " auto", char bình luận bắt đầu bằng ' #' như mặc định nhưng nếu nó đã có trong thông báo đã chuẩn bị, hãy tìm một char khác trong một tập hợp nhỏ. Điều này sẽ dừng bất ngờ vì git dải một số dòng bất ngờ.

Lưu ý rằng git không đủ thông minh để nhận ra ' #' là char bình luận trong các mẫu tùy chỉnh và chuyển đổi nó nếu char bình luận cuối cùng khác.
Nó nghĩ các dòng '#' trong các mẫu tùy chỉnh như là một phần của thông điệp cam kết. Vì vậy, không sử dụng điều này với các mẫu tùy chỉnh.

Danh sách các nhân vật ứng cử viên cho "tự động" là:

# ; @ ! $ % ^ & | :

Điều đó có nghĩa là một lệnh like git commit -m '#1 fixed issue'sẽ tự động chuyển bình luậnChar thành ' ;', vì ' #' đã được sử dụng trong thông báo cam kết.


1
Để sửa lỗi cú pháp HL sau này, hãy xem câu hỏi liên quan này: stackoverflow.com/questions/16164624/iêu
Alois Mahdal

@Guten Đúng, tôi đã điều chỉnh lại câu trả lời để phản ánh điều đó.
VonC

1
@newbyca với phiên bản git nào bạn thấy không được hỗ trợ trong quá trình rebase tương tác?
VonC

2
Vì vậy, để thiết lập điều này bạn có thể làm, ví dụ:$ git config --global core.commentchar ';'
davetapley

6
Tôi thích câu trả lời này. Oneliner cho giải pháp được đề xuất mới:git config --global core.commentChar auto
vào

81

Câu trả lời ở đây là tốt và chi tiết, nhưng đối với một git noob như tôi tùy chỉnh các tùy chọn cấu hình git không quá rõ ràng. Dưới đây là một ví dụ để thay đổi từ #thành ;cho các ký tự nhận xét:

git config core.commentChar ";"

Đó là tất cả những gì bạn cần làm.


3
Cái này cũng thay đổi văn bản nhận xét mặc định mà git thêm vào thông điệp cam kết khi người ta sử dụng git commitđể mở trình soạn thảo được cấu hình để chỉnh sửa thông báo cam kết!
Michael Trouw

1
Đối với các bản sửa lỗi một lần, hãy sử dụng cách này: git -c core.commentChar="|" commit --amend(thay thế| bằng bất cứ điều gì bạn muốn).
Dropogans

62

Bạn có thể sử dụng tùy chọn dòng lệnh -m:

git commit -m "#123 fixed"

35
Nhưng đây là một thông điệp cam kết khủng khiếp. đảm bảo bao gồm lỗi là gì và cách khắc phục
Người tốt

3
các thông báo cam kết vẫn ổn miễn là có một số lỗi
Trident D'Gao

6
Không, nếu hệ thống theo dõi lỗi đột nhiên bị hỏng và bạn không có bản sao lưu! :)
caveman_dick 8/10/2015

38

Nếu bạn đang thực hiện một cuộc nổi loạn tương tác, thì khi bạn lưu thông điệp cam kết của mình mà không có gì trong đó (vì #ngay từ đầu đã đưa ra nhận xét và do đó nó bị bỏ qua) git sẽ cho bạn biết phải làm gì:

Aborting commit due to empty commit message.
Could not amend commit after successfully picking 5e9159d9ce3a5c3c87a4fb7932fda4e53c7891db... 123 salt hashed passwords
This is most likely due to an empty commit message, or the pre-commit hook
failed. If the pre-commit hook failed, you may need to resolve the issue before
you are able to reword the commit.
You can amend the commit now, with

        git commit --amend

Once you are satisfied with your changes, run

        git rebase --continue

Vì vậy, chỉ cần sửa đổi thông báo:

git commit --amend -m "#123 salt hashed passwords"

và tiếp tục cuộc nổi loạn:

git rebase --continue

Điều này đúng với người đã thực hiện cam kết, nhưng muốn thay đổi tin nhắn
Hoàng Trinh

Nó cũng áp dụng cho các cam kết mới nếu bạn nhập tin nhắn bằng trình chỉnh sửa của mình và nó có hàm băm ngay từ đầu.
Owain Williams

29

git commit --cleanup=scissorsnên được sử dụng. Nó được thêm vào Git v2.0.0 vào ngày 2014.05.21

từ git commit --help

--cleanup=<mode>
  scissors
    Same as whitespace, except that everything from (and including) the line
    "# ------------------------ >8 ------------------------" is truncated if the message
    is to be edited. "#" can be customized with core.commentChar.

Tôi không hiểu làm thế nào tốt hơn việc sử dụng commit.cleanup = whitespacevà xóa # …bình luận bằng tay, như @CharlesBailey đã đề xuất. scissors-mode chỉ cần dọn dẹp thêm cú pháp kéo được sử dụng bởi git format-patch/ mailinfo/ am; không sử dụng …-- >8 --…cú pháp khi thêm bình luận để cam kết thông điệp .
Slipp D. Thompson

1. Tôi nghĩ rằng nó tốt hơn bởi vì tôi không cần phải "xóa # ...bình luận một cách khó khăn. 2. Tôi không chắc lắm về phần thứ hai của bình luận của bạn, scissorschế độ chắc chắn là trong git commit --help. Bạn gitđang sử dụng phiên bản nào? @ SlippD.Thndry
Sungam

Huh? whitespacechế độ cung cấp tước 1. dòng trống hàng đầu và dấu, 2. khoảng trắng theo sau, 3. thu gọn các dòng trống liên tiếp. scissorscung cấp tước bỏ 1. dòng trống hàng đầu và dấu, 2. khoảng trắng theo sau, 3. thu gọn các dòng trống liên tiếp, 4. mọi thứ từ (và bao gồm) dòng # -…- >8 -…-. Tuy nhiên, các đường kéo ( # -…- >8 -…-) chỉ được chèn khi sử dụng git-format-patch/ mailinfo/ am. Vì vậy đối với một bình thường git-commit/ merge/ rebase/ cherry-pickcông việc, scissorstước chế độ cung cấp số không lợi ích hơn whitespacechế độ. v2.11.0
Slipp D. Thompson

@ SlippD.Thndry Phiên bản git nào bạn đang sử dụng? Tôi đang sử dụng 2.8.3 và git commit --cleanup=scissors DOES đặt trước # ------------------------ >8 ------------------------dòng trước git statusthông tin. Giống như bên dưới: `# ------------------------> 8 ------------------- ----- # Đừng chạm vào dòng trên. # Mọi thứ bên dưới sẽ bị xóa. # Trên nhánh chính # # Cam kết ban đầu # # Thay đổi được cam kết: # tệp mới: .gitignore `
Sungam

1
Tôi tin rằng tôi đã đi đến tận cùng của điều này. Git thực sự đã chèn # ------------------------ >8 ------------------------trước trạng thái txt Cảnh Có vẻ như bạn có thể bị Vượt _ khi sử dụng scissors; Tuy nhiên, nó chèn dòng kéo sau khi các # Conflicts: …văn bản. Tôi đã commit.status = falsethiết lập .gitconfig, vì vậy tôi không thấy bất kỳ văn bản trạng thái nào, chỉ có văn bản xung đột. Tôi đứng sửa; thay đổi để upvote.
Slipp D. Thompson

3

Sử dụng một tiền tố khác nhau cho số vé. Hoặc thêm một từ vào số vé, như "Lỗi # 42". Hoặc thêm một ký tự khoảng trắng vào dòng; nếu bạn muốn xóa khoảng trắng đó, bạn có thể thêm hook-hook cho điều đó.

Cá nhân tôi thà không thực hiện thao tác cam kết thông điệp cam kết này bởi một cái móc bởi vì nó có thể rất khó chịu khi nó kích hoạt khi bạn không muốn nó. Giải pháp đơn giản nhất có lẽ là suy nghĩ lại vấn đề.


1
từ ngữ khác nhau chỉ là một cách giải quyết cho vấn đề. nếu hướng dẫn dự án tuyên bố rằng một thông điệp cam kết phải bắt đầu bằng id vé, thì nó sẽ không hoạt động. và một cái móc sau cam kết là rất xấu xí. Tôi nghĩ rằng tôi nên báo cáo "lỗi" này cho các nhà phát triển git
knittl

Đừng bận tâm, điều đó là sai. Đừng yêu cầu các nhà phát triển git làm việc theo hướng dẫn của bạn. Bạn sẽ không yêu cầu Dennis Ritchie thay đổi ngôn ngữ C để nó hỗ trợ bạn quy ước tên biến bắt đầu bằng ký tự băm, phải không? Áp dụng tương tự ở đây. Nếu thông điệp cam kết cho phép nhận xét thì điều này sẽ thêm hỗ trợ cho những điều thú vị, như mở trình soạn thảo cam kết với khác biệt được thêm và nhận xét để bạn không cần phải nhớ các thay đổi chính xác của mình. Có gì sai với việc giữ gìn nhân vật không gian hàng đầu?
wilmustell

1
hỗ trợ các nhân vật thoát trong thông điệp cam kết của git sẽ không phải là vấn đề lớn như vậy
knittl

5
Đó là một yêu cầu tính năng hoàn toàn hợp lý. Đặc biệt là về thực tế là Trac, AFAICT, không liên kết cam kết với phiếu lỗi nếu thông báo cam kết không bắt đầu bằng số phiếu, bắt đầu bằng hàm băm. Vì vậy, nó không chỉ là tiêu chuẩn của ai đó, mà còn là một cú pháp bắt buộc của công cụ. Hãy để các nhà phát triển Git quyết định xem nó có đáng hay không. (Và vâng, Trac cũng có thể khắc phục vấn đề. Không có gì sai khi yêu cầu Git làm những gì có thể.)
Luke Maurer

Đặc biệt là sự thật rằng Trac, AFAICT, không liên kết cam kết với phiếu lỗi nếu thông báo cam kết không bắt đầu bằng số phiếu, bắt đầu bằng hàm băm. - theo kinh nghiệm hạn chế của tôi với Trac, một cái gì đó như #xxxxảy ra ở bất cứ đâu trong thông điệp cam kết sẽ liên kết đến vấn đề. Nó không phải là lúc bắt đầu cam kết. Có lẽ đây là một cái gì đó đã thay đổi trong năm năm qua?
Guildenstern

1

Tất cả các cam kết của tôi bắt đầu với #issueNumbervì vậy tôi đặt bản tóm tắt này cho vim .git/hooks/commit-msg:

NAME=$(git branch | grep '*' | sed 's/* //') 
echo "$NAME"' '$(cat "$1") > "$1"

Vì vậy, giả sử chúng tôi có chi nhánh #15và chúng tôi thực hiện thông điệp cam kết add new awesome feature. Với cách tiếp cận này, thông điệp cam kết cuối cùng sẽ được #15 add new awesome feature.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.