커밋 메시지를 풀 리퀘스트 텍스트로 활용

웹 대화보다 커밋 메시지의 정보 선호

내 git 저장소에 Github , Gitlab , Codeberg 및 sr.ht 을 사용합니다. 내가 하는 대부분의 기여는 Github 또는 Gitlab 리포지토리에 있습니다.

풀/병합 요청을 제출할 때 저는 커밋 메시지를 사용하여 풀/병합 요청 텍스트를 채우는 것을 선호합니다.

선호하는 이유는 무엇입니까? 커밋 메시지가 코드와 함께 계속 이동하기 때문입니다.

이것이 코드와 함께 이동하는 것이 나에게 중요한 이유는 무엇입니까?

나는 코드를 먼저 보는 것을 선호하는 경향이 있습니다. 그런 다음 주석(git annotate 또는 git blame을 통해); 그런 다음 파일 기록을 통해 작업합니다. 코드를 이해하기 위한 최후의 수단으로 원격 저장소의 풀 요청 및 커밋 기록을 살펴볼 수 있습니다.

또한 "원격 서비스를 사용할 수 없으면 어떻게 해야 합니까?"라는 측면에서 생각하는 경향이 있습니다. 모든 원격 서비스가 사라지거나 변경된 후.

인터넷이 끊겼나요? 호스트가 한 서비스에서 다른 서비스로 이동합니까? 누군가 그들의 저장소를 핵무기화합니까?

끌어오기/병합 요청 대화는 코드와 함께 이동하지 않습니다. 해당 기능을 제공하는 서비스에 바인딩됩니다. 그다지 미묘하지 않은 형태의 벤더 종속.

즉, 나는 초기의 장황한 풀 요청 설명보다 장황한 커밋 메시지를 강력히 선호합니다.

대부분의 서비스에서 병합/풀 요청에 하나의 커밋이 있는 경우 해당 서비스는 풀 요청 텍스트를 커밋 메시지로 기본 설정합니다.

하지만 풀 리퀘스트에 대한 커밋이 여러 개인 경우에는 어떻게 해야 합니까? 해당 커밋에서 풀 요청 메시지를 생성하는 간단한 스크립트를 작성했습니다.

핵심은 실제로 구성된 git 명령입니다. 하지만 이 명령 하나는 제 커밋 메시지에서 파생되고 유용한 일관된 풀 요청 설명을 만드는 데 도움이 됩니다.

끌어오기/병합 요청 메시지 작성을 위한 코드

my dotzshrc repository에는 script for building a pull request message이 있습니다.

다음 주문(예: cat ~/git/dotzshrc/bin/build-pull-request-message )은 내가 Org Babel을 사용하여 쉘 명령의 텍스트를 내 게시물에 복사한 것입니다.

cat ~/git/dotzshrc/bin/build-pull-request-message

그리고 여기 스크립트의 본문이 있습니다. 대부분 도움말 텍스트입니다.
build-pull-request-message의 출력은 다음과 같습니다.

## Subject

SHA

Body

제목은 커밋의 첫 줄입니다. 간결하게 유지하십시오. SHA는 커밋의 식별자입니다. 그리고 본문은 커밋 메시지의 나머지 부분입니다.

결론

관련 정보를 가까운 곳에 보관하십시오. 방법에 가까운 인라인 문서. 저장소에 가까운 프로젝트 문서. 변화에 가까운 변화의 "이유".