자식 커밋 메시지가 수정 된 파일을 언급해야합니까?

50

git commit 메시지의 첫 번째 줄에는 변경 사항이 여러 파일에 걸쳐 있지 않은 경우 수정 된 파일을 언급하는 습관이 있습니다.

Add [somefunc] to [somefile]

이것이 좋은 일입니까, 아니면 불필요합니까?

git

— 매티
소스

84

버전 관리 도구는 수정 된 파일과 추가 된 방법을 사용자가 볼 수 있도록 강력합니다. 이는 일반적으로 이미 존재하는 것을 명백히 복제하는 로그 메시지가 로그를 오염시키고 있음을 의미합니다.

somefunc요구 사항을 충족시키는 방법을 추가했습니다 . 예 :

기능을 추가하려면
버그를 제거하거나
소스 코드를 리팩터링합니다.

이는 로그 메시지가 영향을받는 기능 / 버그 또는 리팩토링의 목적을 설명해야한다는 것을 의미합니다.

— 아르 세니 무르 첸코
소스

5

또한 그 이유에 대해서도 이야기해야합니다 . 다른 옵션을 고려한 이유는 무엇입니까?

— Jay Bazuzi

2

나는 코드를 주석 처리하는 것과 같은 방식으로 커밋에 대해 언급합니다. 개인적으로 파일 / 모듈 수준 (git으로)으로 분류하지만 커밋이 저렴하고 책처럼 역사를 읽을 수 있기 때문에 만 가능합니다. YMMV.

— Evan Plaice

1

어떤 이유로 사람이 같은 버그와 관련이없는 많은 파일을 한 번에 커밋하는 경우 여름 전에 파일 이름과 버그 ID를 나열하는 것이 좋습니다. file.cpp : addgetMethod ()를 알 필요는 없지만 버그 ID # 10 file.cpp : 괜찮은 여름입니다. 그들이 여러 버그 보고서에 걸쳐있는 많은 파일을 커밋하면 실제로는 마음에 들지 않기 때문에 이야기 할 것입니다. 나는 오히려 여러 번 커밋을하고 싶습니다. 그들이 해결하고있는 각 이슈마다 하나씩.

— William

@ 윌리엄 : 또한 하나의 버그 수정에 문제가있는 경우 최소한의 번거 로움으로 되돌릴 수 있습니다. 한 번의 커밋에 10 개의 버그 수정을 결합하면 심각한 문제가 될 수 있습니다.

— David Thornley

59

커밋 내용 을 검사하는 방법은 많이 있습니다 . 주석은 커밋 의 목적 을 설명해야합니다 .

— 댄 레이
소스

30

티켓 / 문제 번호 를 추가하는 것을 잊지 마십시오 .

티켓 번호 또는 문제 번호 가있는 기능 또는 문제 추적 시스템이있는 경우 해당 ID 번호를 커밋에 넣어야합니다. 작업중인 기능이나 문제에 대해 더 알고 싶은 사람에게 도움이됩니다.

마지막 프로젝트에는 주석의 처음 7 자리가 명확한 퀘스트 (우리의 이슈 / 기능 추적 시스템)에서 유효한 이슈 번호가되도록 개발 된 매크로가있었습니다.

— java_mouse
소스

그렇다면 리팩토링 변경을 어떻게 커밋합니까?

— Jules

@Jules 리팩토링은 아직 끝나지 않은 티켓 #을 가지고 있습니다

— Caleth

@Jules의 한 가지 방법론은 리팩토링이 "잡은"종류의 이슈로 추적되므로 이슈 번호도 있다는 것입니다.

— Scott McIntyre

@ScottMcIntyre 이것이 사실 일지 모르지만, 그것이 좋은 생각이라고 확신하지는 않습니다. 리팩토링은 기회 적으로 또는 리팩토링 할 코드에 의존하는 코드를 개발하는 프로세스의 일부로 수행하는 것이 가장 좋습니다. 파울러으로 그것을두고 , "계획 리팩토링은 [...] 팀이 다른 워크 플로우를 사용하여 충분한 리팩토링을 수행하지 않은 있다는 신호". 론 제프리스 (Ron Jeffries) : 리팩토링-백 로그에는 없다! .

— Jules

3

예를 들어 여러 파일을 변경 해야하는 결함에 대한 수정 사항을 커밋 할 때 해당 유형의 작업을 수행합니다. 이를 통해 변경 세트의 개별 파일을 보지 않고 실제로 변경된 내용을보다 쉽게 알 수 있습니다.

단일 파일 변경 세트에는 필요하지 않습니다.

첫 번째 줄은 항상 결함이나 사용자 스토리에 대한 링크와 같이 변경 집합에 대한 높은 수준의 설명입니다.

— 마이크 파트 리지
소스

3

커밋 메시지의 서술에 관련된 정보라면 포함하십시오. 정보의 유일한 비트가 파일 이름 자체 인 경우에는 아닙니다.

"build_foo ()를 사용하려는 대부분의 프로그램은 이미 foobase.c를 포함하고 있기 때문에 build_foo () 함수를 fooutil.c에서 foobase.c로 이동했습니다."

": bar 매개 변수를 사용하도록 fooutil.c의 build_foo ()를 업데이트했습니다."

— 앤디 레스터
소스

1

여기에 다른 관점을 추가하고 싶습니다.

내 대답은 예 또는 아니요입니다. 그러나 일반적으로 예라고 대답합니다.

버전 제어는 실제로 어떤 파일이 업데이트되고 있는지 알 수있을만큼 강력합니다. 그러나 우리가 할 때

$ git log

커밋 메시지 만 볼 수 있습니다. 대부분의 사람들이하는 일.

로그 자체를 살펴봄으로써. 추가 컨텍스트를 추가합니다. 예를 들면 다음과 같습니다.

readme.md: Fix typo detected by language tool

보다 낫다

Fix typo detected by language tool

그러나 변경 사항이 여러 파일을 생성하는 경우 최소한 편집중인 구성 요소를 언급하십시오.

API: Fix reset password not sent email to user

그것을 읽으면, 수정 된 오류가 API 구성 요소에 있으며 코드베이스의 API 디렉토리에있을 것입니다.

그러나 우리는 할 수 있었다

$ git show COMMIT_ID --name-only

그러나 파일을 얻기 위해 더 많은 단계를 추가합니다.

— 야나 아군 시스 완토
소스

0

이것이 단일 파일 체크인에 유용하다는 것을 알 수있는 유일한 시간은 파일의 많은 곳에서 사용되는 기능을 변경하여 diff가 어수선 해지는 경우입니다. 그럼에도 불구하고 변경 추적기 #와 변경에 대한 일반 텍스트 설명을 먼저 넣었습니다.

— 댄 닐리
소스

-1

나는 여기서 진짜 질문은 당신의 커밋이 얼마나 제한적이라고 생각합니까? 한 번의 커밋으로 관련없는 다양한 변경 사항을 함께 커밋하기를 기다리는 경우 어떤 파일이 어떤 목적으로 변경되었는지 지정해야 할 수도 있습니다.

그러나 더 좁은 커밋을 더 자주 만들면 단일 커밋이 수정 된 파일을 설명하고 메시지의 목적을 간단히 설명 할 수 있습니다.

더 많은 커밋, 더 자주. 그렇게하면 메시지가 너무 장황하게되는 것을 피할 수 있습니다.

— 라피
소스

-2

해서는 안됩니다

관심있는 사람은 누구나 역사의 변화를 볼 수 있습니다

많은 파일이 자동으로 생성 될 수 있으므로 더 큰 시스템에서는 실행되지 않습니다

— 코드 아트
소스