기존 커밋으로 git 로그 향상

Git은 대부분의 컴퓨터에 설치된 매우 강력한 도구입니다. 개발자로서 우리는 매일 그것을 사용합니다. 그러나 불행히도 언뜻보기에이 도구는 개발자 친화적이지 않습니다. 이것이 많은 사람들이 GUI(그래픽 사용자 인터페이스)를 사용하여 명령줄 인터페이스(CLI)를 우회하는 이유입니다.
언어 자체를 모르는 상태에서 프레임워크를 사용하는 것과 같습니다. 처음에는 괜찮을 수 있지만 조만간 문제가 생길 것입니다.

예를 들어 보겠습니다.

$ git log --oneline ./src/components/button/

daccff1f test should pass
3fff19f6 test should pass
5b998d9a add disabled property for button
06faab4d fix lint
186cce90 refactor button
4b99d91a fix spinner component
5b998d9a fix css
263288a5 test should pass
c3fb85af Create Button component


이 로그에는 아무 문제가 없을 수 있습니다. 이 로그에서 발견한 문제를 보여드리겠습니다.
  • 컴포넌트의 이력을 이해하기 어렵습니다. 이미 수정된 오류를 반복할 수 있습니다.
  • 로그를 오염시키고 기록을 읽기 어렵게 만드는 불필요한 커밋이 있습니다. 또한 git blame와 같은 기능은 관련이 없습니다.
  • 몇 번의 커밋으로 기능이 추가된 것 같습니다. 이 작업을 되돌리려면 어떤 커밋을 포함해야 합니까?
  • 4b99d9a 다른 구성 요소에 대해 말하십시오. 원치 않는 변화입니까? 다시 말하지만 되돌려야 하는 경우 어떻게 해야 합니까?
  • ...
  • git commitctrl + s 를 혼동해서는 안 된다고 생각합니다. Agit log는 마치 동화를 읽는 듯한 느낌이어야 한다. 로그를 읽으면 전체 파일 기록을 ~10초 안에 이해할 수 있어야 합니다.

    다음과 같은 것이 있다면 어떨까요?

    $ git log --oneline ./src/components/button/
    
    06faab4d revert: feat: add disabled property
    186cce90 feat: add disabled property
    5b998d9a test: add scenario for readonly property
    263288a5 fix: fix css when hover
    c3fb85af feat: add button component
    


    훨씬 깨끗하지 않습니까?
    그것은 Conventional Commits라고 불리는 것입니다.

    기존 커밋



    기존 커밋은 Angular team 에서 만든 Git 커밋 규칙입니다. 기본적으로 모든 pull 요청은 하나의 커밋과 표준화된 커밋 메시지로 끝나야 합니다.

    메시지는 다음 정규식을 따라야 합니다.

    /^(revert: )?(feat|fix|docs|style|refactor|perf|test|chore)(\(.+\))?: .{1,50}/
    


    커밋 유형:

  • feat: 새로운 기능을 추가합니다(Semantic VersioningMINOR와 동일).

  • 수정: 버그를 수정합니다( Semantic VersioningPATCH와 동일).

  • docs: 문서 변경 사항.

  • style: 코드 스타일 변경(세미콜론, 들여쓰기...).

  • refactor: 공개 API를 변경하지 않고 코드를 리팩터링합니다.

  • perf: 코드 성능을 업데이트합니다.

  • 테스트: 기존 기능에 테스트를 추가합니다.

  • chore: 사용자에게 영향을 주지 않고 무언가를 업데이트합니다(예: package.json에서 종속성을 범프).

  • 이 규칙을 사용하는 프로젝트: Angular , Vue.js , Gatsby (almost) , Lerna (almost) , jest (almost) .

    이익



    프로젝트/코드 이해도
    커밋은 더 설명적이며 프로젝트의 이력을 더 쉽게 이해할 수 있습니다. 또한 기여도가 쉬워졌습니다.
    예를 들어, 저는 Angular의 http 패키지에 기여한 적이 없습니다. 그러나 reading the repo's git log 이 패키지의 역사를 더 잘 이해하는 데 도움이 됩니다.

    사용성
    커밋 당 하나의 작업이 있으면 변경 사항을 되돌리기가 더 쉬워졌습니다. git 충돌이있는 경우에도 마찬가지입니다 ...

    Git 기술 마스터
    모든 Git 저장소 관리자에 "스쿼시 및 병합"옵션이 있는 것은 아니므로 이 작업을 직접 수행해야 하는 경우가 있습니다. 따라서 커밋을 "스쿼시"하는 방법, 커밋을 "수정"하는 방법, 특정 커밋을 제거하는 방법을 배웁니다...
    후드 아래에서 무슨 일이 일어나고 있는지 아는 것이 항상 중요합니다!

    또한보십시오


  • conventionalcommits.org
  • Vue.js commit convention

  • github.com/conventional-changelog/conventional-changelog - git 메시지를 기반으로 변경 로그를 생성하는 좋은 도구입니다.

  • github.com/conventional-changelog/commitlint - 자식 커밋 린터. 허스키와 함께 사용하세요.

  • maxpou.fr에 원래 게시되었습니다.

    좋은 웹페이지 즐겨찾기