D.S

item4.github.io

Git 커밋 메시지 작성법(How to Write a Git Commit Message) - item4 Dev Story

Git 커밋 메시지 작성법(How to Write a Git Commit Message) - item4 Dev Story About Résumé Feed item4 Dev Story Git 커밋 메시지 작성법 How to Write a Git Commit Message Posted on 2016-11-01 06:15 Permalink: https://item4.github.io/2016-11-01/How-to-Write-a-Git-Commit-Message/ Keywords: Git commit commit message 커밋 커밋 메시지 Share: Twitter Facebook Google+ Tumblr Reddit 프로젝트가 지루하게 늘어지면, 커밋 메시지는 점점 더 무의미해진다. 들어가며 | 일곱 가지 규칙 | 팁들 | 원문 들어가며: 좋은 커밋 메시지는 왜 중요한가? Git 저장소 중 아무거나 골라 살펴보면, 커밋 메시지가 뒤죽박죽인 것을 발견할 수 있을 것이다. 예를 들어 내가 초창기에 Spring에 커밋한 gem 을 보라. $ git log --oneline -5 --author cbeams --before "Fri Mar 26 2009" e5f4b49 Re-adding ConfigurationPostProcessorTests after its brief removal in r814. @Ignore-ing the testCglibClassesAreLoadedJustInTimeForEnhancement() method as it turns out this was one of the culprits in the recent build breakage. The classloader hacking causes subtle downstream effects, breaking unrelated tests. The test method is still useful, but should only be run on a manual basis to ensure CGLIB is not prematurely classloaded, and should not be run as part of the automated build. 2db0f12 fixed two build-breaking issues: + reverted ClassMetadataReadingVisitor to revision 794 + eliminated ConfigurationPostProcessorTests until further investigation determines why it causes downstream tests to fail (such as the seemingly unrelated ClassPathXmlApplicationContextTests) 147709f Tweaks to package-info.java files 22b25e0 Consolidated Util and MutableAnnotationUtils classes into existing AsmUtils 7f96f57 polishing 맙소사. 이것과 같은 저장소에 있는 최근 커밋들을 비교해 보자. $ git log --oneline -5 --author pwebb --before "Sat Aug 30 2014" 5ba3db6 Fix failing CompositePropertySourceTests 84564a0 Rework @PropertySource early parsing logic e142fd1 Add tests for ImportSelector meta-data 887815f Update docbook dependency and generate epub ac8326d Polish mockito usage 어떤 커밋 메시지가 더 읽기 좋은가? 앞은 길이와 형식이 제각각이지만, 뒤는 간결하고 일관성이 있다. 앞은 그냥 두면 나타나는 것이지만, 뒤는 손을 대지 않는 이상 우연히 만들어지지 않는다. 많은 저장소의 로그가 앞 예제와 비슷하지만, 예외도 존재한다. 리눅스 커널 과 Git 은 훌륭한 예제이다. 스프링 부트 나 Tim Pope 가 운영하는 다른 저장소도 살펴보라. 이 저장소 기여자들은 동료 개발자(뿐만 아니라 실제로 미래의 자기 자신)와 변경사항에 대한 맥락을 공유할 수 있는 최고의 수단은 잘 다듬어진 커밋 메시지라는 것을 잘 알고 있다. diff로 어떤 것이 변경되었는지 확인할 수 있지만, 오직 커밋 메시지를 통해서만 그 이유를 알 수 있을 것이다. Peter Hutter가 이 점을 잘 설명해 놓았다 . 코드 조각의 앞뒤 맥락을 다시 살펴야 하는 것은 가치 없는 일이다. 이를 완벽하게 피할 수는 없기에, 코드 맥락을 다시 살피는 일을 줄이기 위해서 최대한 노력해야 한다. 커밋 메시지는 정확히 그런 일을 할 수 있고, 이로 인해 커밋 메시지 하나로 어떤 개발자가 좋은 협력자인지 아닌지 알 수 있다. 만약 당신이 Git 커밋 메시지를 훌륭하게 쓰기 위해 깊은 고민을 하지 않았다면, git log와 이에 연관된 도구를 사용하는데에도 그리 많은 시간을 쏟지 않았을 것이다. 다음과 같이 악의 고리가 시작된다. 커밋 이력이 체계와 일관성이 없으므로, 누구도 이를 사용하거나 관리하기 위해 많은 시간을 들이지 않는다. 그러면 사용하거나 관리하지 않기 때문에 여전히 체계와 일관성이 없는 채로 남겨진다. 하지만 잘 관리된 로그는 아름답고 유용하다. git blame이나 revert, rebase, log, shortlog 뿐만 아니라 다른 하위 명령어들도 활력을 얻게 된다. 다른 사람이 작성한 커밋과 풀 리퀘스트를 리뷰하는 것은 가치 있는 활동이 되고, 어느새 독립적으로 완료할 수 있게 된다. 몇 달 전이나 몇 년 전에 어떤 일이 일어난 이유에 대해 알 수 있음은 물론, 효과적으로 이해할 수 있게 된다. 한 프로젝트가 오랫동안 성공할 수 있을지의 여부는 (다른 것 중에서) 유지보수성에 달려 있다. 그리고 유지보수를 하는 사람에게 프로젝트 로그보다 더 강력한 도구는 별로 없다. 따라서 이를 정확히 다루는 법을 배우는 데 시간을 쏟을 만한 가치가 있다. 처음에는 혼란스럽겠지만 이내 습관이 될 것이고, 점차 관련된 모든 사람의 자신감과 생산성의 원천이 될 것이다. 이 글에서 나는 그저 건강한 커밋 이력을 유지하기 위한 가장 기본적인 요소만을 이야기하고 있다. 바로 개별 커밋 메시지를 어떻게 쓸 것인가이다. 여기서 언급하지 않은 커밋 스쿼싱(commit squashing: 여러 커밋을 하나로 모으는 것) 같은 다른 중요한 실천요소들도 많다. 그것은 아마도 다음 글에서 다루게 될 것이다. 대부분 프로그램 언어들은 기여자에 대한 명명법, 포매팅 등의 관용적인 스타일에 대해 규칙이 잘 세워져 있다. 물론 컨벤션 종류가 다양하지만, 모두가 각자 스타일을 따라 개발해서 혼돈을 겪는 것보다는 한 가지 스타일 골라 그것만 사용하는 것이 훨씬 좋다는 것에 대다수의 개발자가 동의한다. 팀 차원 커밋 로그에 대한 접근법도 별반 다를 것이 없다. 유용한 정정 이력을 만들기 위해, 우선 팀은 적어도 다음 세 가지를 정의하는 커밋 메시지 컨벤션에 동의해야 한다. 스타일: 마크업 문법, 여백 감싸기, 문법, 대문자 사용, 구두점. 이것들을 문서화시켜 추측을 제거하고, 가능한 한 간단하게 만들어야 한다. 그 결과 눈에 띄게 일관성을 갖게 되어 읽기 즐겁고, 실제로 규칙적으로 읽히는 로그가 될 것이다. 내용: 커밋 메시지의 본문에는 어떤 종류에 대한 내용이 들어가야 할까? 어떤 것은 들어가지 않아야 할까? 메타데이터(Metadata): 이슈 트래킹 아이디, 풀 리퀘스트 번호 등등은 어떻게 참조할 수 있어야 하나? 다행히도 관용적인 Git 커밋 메시지에 대해 잘 만들어진 컨벤션이 있다. 사실 컨벤션에서 상당 부분은 Git 명령어 기능처럼 보인다. 다시 발명해야 할 것은 없다. 그저 아래의 7가지 규칙 을 따르고, 자신 있게 프로처럼 커밋하면 된다. 훌륭한 Git 커밋 메시지의 일곱 가지 규칙 기억해두자. 이 내용은 이미 이전에 다 했던 이야기다 . 제목과 본문을 빈 행으로 분리한다 제목 행을 50자로 제한한다 제목 행 첫 글자는 대문자로 쓴다 제목 행 끝에 마침표를 넣지 않는다 제목 행에 명령문을 사용한다 본문을 72자 단위로 개행한다 어떻게 보다는 무엇과 왜를 설명한다 다음은 위 규칙을 따르는 커밋 예시다. Summarize changes in around 50 characters or less 50자 또는 그 이하로 변경 사항을 요약 More detailed explanatory text, if necessary. Wrap it to about 72 characters or so. In some contexts, the first line is treated as the subject of the commit and the rest of the text as the body. The blank line separating the summary from the body is critical (unless you omit the body entirely); various tools like `log`, `shortlog` and `rebase` can get confused if you run the two together. 필요하다면 더 자세한 설명을 서술한다. 한 행은 72자 정도에서 변경한다. 맥락에 따라서 첫 행이 커밋의 제목처럼, 나머지 내용이 본문처럼 다뤄지는 경우도 있다. 첫 행의 요약과 본문 사이에 빈 행을 넣는 것은 중요하다. (물론 본문을 입력하지 않는 경우라면 무관하다) 이 규칙을 지키지 않은 경우에는 `log` 또는 `shortlog`, `rebase`와 같은 도구를 사용할 때 혼란스러울 수 있다. Explain the problem that this commit is solving. Focus on why you are making this change as opposed to how (the code explains that). Are there side effects or other unintuitive consequences of this change