git . 커밋 메시지 , 태그 , 브랜치 규칙

 

 

git . 커밋  메시지 , tag , 브랜치  규칙 

 

커밋 메시지 제목 부분 

타입: 요점 형태로 작성.

• 형식: 타입(범위): 제목
• 주요 타입:
  • feat: 새로운 기능 추가
  • fix: 버그 수정 (가장 많이 쓰임)
  • refactor: 코드 리팩토링 (기능 변화 없이 코드 구조만 개선)
  • docs: 문서 수정 (README 등)
  • style: 코드 포맷팅 (세미콜론 누락 등, 로직 변경 없음)
• 예시:
  • feat: 64비트 전용 통신 모듈 추가
  • fix: 1.0.4.5 배포 버전 로그인 크래시 수정
  • refactor: 공통 함수 라이브러리 구조 개선

 

 

태그 

VSCode 에서 태그 기록하는 곳 

- 커밋 한 것 우마우스 클릭하여 뜬 메뉴에서 1 클릭하면 2번 창에 태그기록한다. 

 

VSCode 에서 git 커밋에 태그 기록하기

 

2. 태그 (Semantic Versioning 규격)

태그는 보통 유의적 버전(SemVer) 규칙을 따른다.

• 형식: v[Major].[Minor].[Patch].[Build]
  • Major (1.x.x): 아키텍처가 바뀌거나 호환되지 않는 큰 변화
  • Minor (x.1.x): 하위 호환되는 새로운 기능 추가
  • Patch (x.x.1): 하위 호환되는 버그 수정
• 예시: v1.0.4.5
• 팁: 태그를 달 때 비고란(Annotated Tag)에 해당 버전의 주요 변경 로그(Release Note)를 요약해서 적어두면 나중에 폴더를 열어보지 않아도 무슨 버전인지 바로 알 수 있다. 

1. 태그(Tag) 사용의 '황금률'

태그는 보통 다음 두 가지 경우에만 생성하는 것이 관례.

• 배포(Release): 사용자에게 나가는 최종 결과물 (예: v1.0.4.5, v1.0.5.0)
• 주요 마일스톤: 고객 검수 완료, 대규모 리팩토링 완료 등 '돌아가기엔 너무 멀리 온' 확정 지점

2. 태그와 커밋의 관계 (1:1 대응)

• 원칙: 하나의 배포 버전은 반드시 하나의 특정 커밋을 가리켜야 한다. 
• 이유: "1.0.4.5 버전 소스 좀 줘봐"라고 했을 때, 단 1바이트의 오차도 없는 정확한 시점을 찾기 위함.
• 커밋과의 차이: 커밋은 "과정"이고, 태그는 "결과".

3. 태그 남발 방지를 위한 운영 팁

32비트/64비트 문제와 엮어서 태그를 관리한다면  적용하는 규칙예시. .

• 단일 소스일 때: v1.0.4.5 하나만 찍는다.  (이 커밋에서 32/64비트 둘 다 빌드하겠다는 뜻)
• 부득이하게 소스가 분리되었을 때: v1.0.4.5-x86, v1.0.4.5-x64처럼 아키텍처를 명시하여 찍는다. 
• 태그 삭제: 실수로 잘못 찍은 태그는 삭제가 가능하므로, 폴더를 지우는 것보다 훨씬 깔끔하게 정리가 가능.

4. 태그가 있으면 좋은 '진짜' 이유

만약 지금 1.0.4.4 기반 신규 기능을 한참 만들고 있는데, 갑자기 1.0.4.5 소스를 확인해야 한다면?

• 폴더 관리 방식: 1.0.4.5 폴더를 찾아 들어가서 VS를 또 켭니다.
• Git 태그 방식: 현재 VS에서 git checkout v1.0.4.5 명령(혹은 클릭) 한 번이면 소스가 그 당시로 돌아간다.  확인 후 다시 원래 작업 브랜치로 복귀.

결론적으로, 태그는 "배포 단위"로만 관리. 그 외의 자잘한 수정 기록은  커밋 메시지(Comment 와 Description )가 담당. 

 

 

 

 

브랜치 

VSCode 에서 브랜치 생성방법 

master branch 우마우스 클릭 메뉴 에서  Create Branch.. 클릭  브랜치 이름 적고 엔터치면 브랜치 생성됨. 

 

 

브랜치 명

1. 기본 구조: 타입/내용

브랜치 이름 앞에 슬래시(/)를 사용하여 접두어를 기록하면  Visual Studio나 Git 도구에서 폴더처럼 타입별 계층 구조로 보여주므로 관리 편해짐.

브랜치명 접두어	설명
master	배포가능한 가장 안정적인 소스가 있는 브랜치.  임시 파생 작업 요구될 때 main 에서는 절대 작업하지 않고 브랜치2 만들어서 완성 검증 되면 main 브랜치로 머지하고 브랜지2는 삭제한다.
feature/	기능상의 변경  feature/login-dialog
fix/	버그 수정  예 : fix/memory-leak , fix/issue-104
refactor/	기능 변경없이 코드 구조개선 위주의 작업 예 : refactor/common-library
maintenance/	IDE 변경 등  예 : maintenance/vs2022-migration

 

 

 

2. 버전 정보를 브랜치명에 포함하는 경우

여러 버전을 동시에 관리해야 한다면 브랜치 이름에 버전 번호를 명시하기도 한다. 

• release-1.0.4.5: 1.0.4.5 버전을 출시하기 위해 최종 점검 중인 브랜치
• dev-1.0.5.0: 다음 대기 버전인 1.0.5.0을 목표로 작업 중인 브랜치

3. 작성 시 주의할 규칙 (에러 방지)

Git 브랜치 이름은 파일 경로로도 인식되기 때문에 몇 가지 금지 사항.

1. 공백(Space) 금지: 공백 대신 하이픈(-)이나 언더바(_) 사용. (예: feat/new-task)
2. 한글 사용 금지 : 최신 도구들은 지원하지만, 빌드 환경이나 서버 설정에 따라 소스가 꼬일 수 있다. 영어  안전.
3. 소문자 구분: 윈도우 환경에서는 대소문자를 구분하지 않는 경우가 많아 혼란을 줄 수 있으므로, 소문자로 통일. 

 

표준적인 브랜치 처리 과정

 

1. 출발: main (예 : 1.0.4.5 버전 상태)
2. 가지치기: feat/new-logic 브랜치 생성 후 여기서 변경될 사항들 구현 작업 
3. 완료: 브랜치에서 테스트해보니 완벽.
4. 합치기: main으로 이동해서 feature/new-logic을 Merge.
5. 박제: main에 Tag(v1.0.4.6)를 달기
6. 정리: feature/new-logic 브랜치는 삭제

 

 

 

연관 

 

Git . 깃 포터블 구축 . VSCode 셋팅

 

 

---

첫 등록 : 2026. 04.27

최종 수정 : 

단축 주소 : https://igotit.tistory.com/6576

---