Post

VSC 디버깅 및 깃 커밋 메시지 관습

Posted
By Sangjin_Yoon
14 min read

디버깅 전략

점진적 프로그램 개발, 역추적, 원격 디버깅, 로깅, 클라우드 디버깅이 있습니다. 이 중 점진적 프로그램 개발과 역추적을 알아보려 합니다.

역추적Backtracking

소규모 프로그램에서 주로 사용됩니다. 오류 발생 시점부터 역방향으로 작업하며 코드의 발생 지점을 찾습니다. 코드 라인 수가 증가하고 구조가 복잡해질 수록 어려워집니다.

점진적 개발Incremental program development

코드의 작은 부분을 자주 테스트할 수 있도록, 관리하기 좋은 섹션으로 나누어 개발합니다. 이를 통해 개발자는 그들이 찾은 버그를 localize할 수 있습니다. 이는 한 번에 하나의 버그만을 고칠 수 있게 합니다.

[출처: AWS - What is Debugging]

VSC 디버깅 툴

vsc는 자체적으로 NodeJS 디버깅이 지원되어 JS, TS 등이 가능합니다. 다른 디버거는 확장을 추가로 설치해야 합니다. 디버깅 설정 세부 사항을 구성하고 저장하기 위해서는 작업 영역 최상단에 .vscode 폴더, launch.json 파일이 필요합니다.

alt text

디버깅 명령어/동작은 아래 4가지가 있습니다. 위 그림의 버튼이 순서대로 아래 동작에 대응됩니다. (마지막 맨 오른쪽 2개 restart, stop 제외)

  • continue/pause: 프로그램 및 스크립트 실행을 다시 시작하기/현재 라인부터 한줄씩 디버그를 시작하고 코드를 검사하기

  • step over: 다음 함수 및 메소드를 하나의 명령어로서 실행합니다. (함수 호출 코드를 발견해도 해당 함수의 선언 내부로 들어가지 않는다는 뜻입니다)

  • step into: 다음 함수 및 메소드의 선언 내부로 들어가서 한줄씩 실행합니다.

  • step out: 함수 및 메소드 안에 있을 때, 남아있는 라인들을 한번에 모두 실행하고 이전의 실행 맥락(해당 함수 호출)로 돌아옵니다.

Commit Message Convention

개발을 진행하며 단위마다 커밋할 필요가 생겨 보기 좋고, 실용적이게 작성하고 싶었습니다.

차용할 만한 커밋 메시지 규칙을 조사해 정리하였습니다.

Karma Style

웹 서버 생성 도구 Karma에서 Git을 사용하는 규칙이라고 합니다. Karma에서는 자동으로 changelog를 생성하고, git history를 간단히 탐색하기 위해 이러한 convention을 사용한다고 합니다.

커밋 메시지 형식

아래와 같은 형식을 가집니다. type, scope 등에는 어떤 것이 들어가는지 예시와 설명으로 확인해 봅시다. () 표시는 필수가 아님을 뜻합니다.

1
2
3
4
5
6

<type>(<scope>): <subject>

(<body>)

(<footer>)

예시

1
2
3
4
5
6

fix(middleware): ensure Range headers adhere more closely to RFC 2616

Add one new dependency, use `range-parser` (Express dependency) to compute
range. It is more well-tested in the wild.

Fixes

type 종류

어떤 종류의 커밋인지 알립니다.

  • feat = 주로 사용자에게 새로운 기능이 추가되는 경우
  • fix = 사용자가 사용하는 부분에서 발생한 버그를 수정한 경우
  • docs = 문서에 변경 사항이 있는 경우
  • style = 세미콜론 추가 등 형식적인 부분을 다루는 경우 (코드의 변화가 생산적인 것이 아닌 경우)
  • refactor = production code를 수정하는 경우 (네이밍 수정, 파일 구조 변경 등 결과의 변경 없이 코드의 구조를 재조정함)
  • test = 테스트 코드를 수정하거나, 추가하는 경우 (코드의 변화가 생산적인 것이 아닌 경우)
  • chore = 별로 중요하지 않은 일을 수정하는 경우 (코드의 변화가 생산적인 것이 아닌 경우) (chore: 따분한 일 이라는 뜻이라네요..ㅎ)

<적용 범위

  • init, runner, watcher, config, web-server, proxy, etc. Karma 도구 내에서 주로 사용되며, 필수가 아닙니다.

subject 내용

  • 수행한 작업에 대한 간단한 요약 및 알기 쉬운 설명을 작성해야 합니다.
  • 영미권 문화에서는 명령형 어조를 사용한다고 하네요.
  • 국내에서는 명사형태로 작성해도 될 것 같습니다.

아래 2개 항목은 간단한 커밋의 경우 생략해도 된다고 합니다.

body 본문

본문 역시 현재 시제 명령형 어조를 사용한다고 합니다. 간단한 와 달리 이전 커밋과 비교하며 왜 변경하게 되었는지 이유를 포함할 것을 권장합니다.

footer 꼬리말

특정한 git issue를 해결하려는 커밋인 경우 footer에 issue 번호를 기입합니다. footer에 참조된 issue는 close됩니다.

Angular Convention

두번째로, Angular 프레임워크의 Angular에서 사용하는 convention을 알아보겠습니다. 하나만 알아보면 재미 없으니!

형식

형식은 카르마와 동일합니다. 대부분 같은 형식을 차용하는 게 좋을 것 같네요.

type 종류

  • revert: 이전 커밋으로 되돌리는 경우. body에 This reverts commit \<hash>와 같이 작성.
  • build: 빌드 시스템 또는 외부 종속성에 영향을 미치는 변경 사항 (예시 scope: gulp, broccoli, npm)
  • ci: CI configuration 파일 및 스크립트 변경 (예시 scope: Travis, Circle, BrowserStack, SauceLabs)
  • docs: 문서 변경
  • feat: 새로운 기능
  • fix: 버그 수정
  • perf: 기능 개선 코드
  • refactor: 버그 수정과 기능 개선이 아닌 코드
  • style: 코드에 의미 변화가 없는 수정(공백, 포맷팅, 세미콜론, 등)
  • test: 테스트 추가 혹은 수정

scope 적용 범위

  • animations, common, compiler, compiler-cli, core, elements, forms, http, router, …

몇가지 예외를 제외하곤 영향을 받은 npm 패키지의 이름을 담아야 한다고 하네요. 마찬가지로 Angular에 기여할 것이 아니시라면 넘어가도 될 것 같습니다.

Subject 내용

강하게 작성되어 있어 몰랐던 저에게는 재미있네요. 그대로 가져왔습니다.

  • 명령문, 현재 시제 사용 (“change” 가능, “changed”나 “changes”는 불가)
  • 첫번째 글자 대문자로 쓰지 말기
  • 마지막에 온점. 찍지 말기

Body 본문

Karma 스타일에서 이야기와 같습니다. 또한, subject와 같이 현재시제 명령문이어야 합니다.

Footer 꼬리말

해당 커밋이 close하는 깃헙 이슈에 대한 참조 혹은 Breaking Changes를 담아야 합니다. Breaking Changes의 경우 Footer는 BREAKING CHANGE: 와 같이 시작해야 합니다.

이렇게 기업마다 상황마다 다양한 커밋 방법이 있으니, 상황에 맞게 사용하면 좋을 것 같습니다.

논외로, 커밋 단위 역시 어렵게 느껴질 때가 많습니다. 이것 역시 정답은 없지만, 대체로 기능 단위 혹은, 함수 단위로 커밋하는 경우가 많다고 하네요. 협업 중이라면 구성원들과 충분히 논의할 필요가 있겠습니다.

참고자료: 커밋로그 작성법 깃헙 블로그 angular 깃헙 커밋 메시지 가이드라인

GitHub Pull Request 보내기

  1. fork
    • 타켓 프로젝트 저장소에서 fork로 자신의 계정에 새로운 저장소를 만듭니다.

  2. clone, remote

    • 위에서 생성된 본인 계정 저장소에서 clone or download 버튼을 누릅니다.
    • clone with https를 선택해 주소를 복사합니다.
    • 터미널에서 로컬 저장소로 클론합니다.
    1

    git clone {복사한 주소} {생성될 폴더 이름}
    • 이후, 로컬 저장소에 2개 원격 저장소를 추가합니다.
      • fork 해서 생긴 내 계정 깃헙 repository
      • 원본 프로젝트 계정 깃헙 repository
    1
2

    # 내 계정 저장소는 clone할 때 origin이라는 별명으로 저절로 추가됩니다.
git remote add {원본 저장소 별명} {원본 계정 저장소 clone with https 주소}
  3. branch 생성
    1

    git checkout -b develop

    로컬 컴퓨터에서 코드를 추가할 때는 branch를 만들어 main(혹은 master)에서 독립적으로 구현합니다.

  4. 수정 작업 저장후 add, commit, push 내 계정 원격 저장소(origin)에 push해 줍니다. 브랜치명을 꼭 명시해야 합니다.
    1

    git push origin develop
  5. pull request 생성 push 이후 내 계정에 fork된 깃헙 레포지토리 페이지를 확인하면 Compare & pull request 버튼을 확인할 수 있습니다. 해당 버튼을 클릭해 적절한 메시지를 작성하고 PR을 생성합니다.
  6. 코드 리뷰, Merge PR을 받은 원본 저장소 관리자가 코드 변경시힝을 확인하고 Merge 여부를 결정합니다.

  7. 동기화 및 branch 삭제 원본 저장소에 Merge가 완료되면 로컬 코드와 원본 저장소의 코드를 동기화 합니다. 이후, 작업하던 로컬의 branch를 삭제한다.

    1
2
3
4

    # 코드 동기화
git pull {원본 저장소 별명}
# 브랜치 삭제 delete
git branch -d {브랜치 별명}

    나중에 추가로 작업할 일이 있다면 pull을 이용해 원본 저장소와 동기화 후 위 과정을 반복합니다.

Git
TIL Debugging Git Github
This post is licensed under CC BY 4.0 by the author.