notes

git (추가 내용)

2025-04-02수정 2026-09-269 min read

react native

Git 추가 명령어·작업 흐름과 실무에서 자주 쓰는 보충 메모.

Kim mr.

프론트엔드 · 기술 블로그

1. git

git은 스냅샷 스트림 기반의 분산 버전 관리 시스템입니다.

컴퓨터 파일의 변경사항을 추적하고 여러 명의 사용자들 간에 해당 파일들의 작업을 조율할 수 있습니다.

2. 협업 가이드

1. Git Flow

Git Flow는 feature, develop, release, hotfixs, master 5가지의 브랜치 전략을 가지고 있습니다.

기능 개발을 위해 feature 브랜치를 만듭니다.
feature 브랜치는 개발과는 별도로 진행하여 충돌을 막습니다.

기능 개발이 모두 끝나면, develop 브랜치에 머지합니다.
develop 브랜치는 아직 release되지 않은 최신의 소스코드를 유지하게 됩니다.

모든 검증이 끝났다면, develop 브랜치로부터 release 브랜치를 생성합니다.
만약 release 브랜치에서 문제가 발견되었다면, 아래의 절차를 따릅니다.
release 브랜치에서 문제를 해결합니다.
develop 브랜치로 머지합니다.

release 브랜치 코드가 정상 배포되었다면, 최종 코드는 develop과 master 브랜치로 머지합니다.
이 방법으로 master 브랜치는 항상 운영 환경의 코드를 유지합니다.
이 방법으로 develop 브랜치는 개발 환경의 최신 코드를 유지합니다.

master 브랜치에서 문제가 발생하면 hotfix 브랜치로 머지합니다.
hotfix는 실제 운영중인 문제를 빠르게 수정하기 위한 브랜치입니다.

문제가 해결되고 나면 develop 브랜치, 그 다음에 master 브랜치로 머지합니다.

2. GitHub flow

GitHub Flow는 feature, master 2가지의 브랜치 전략을 가지고 있습니다.

Pull Request를 사용하도록 권장되며, 수시로 배포가 발생하므로 CI/CD가 자동화되어 있는 환경에서 유리합니다.

(CI/CD 자동화가 이뤄진) 소규모 팀에서 사용하기 좋은 전략입니다.

3. Kviruslab’s Flow

Kviruslab’s Flow는 main, develop, feature 3가지의 브랜치 전략을 가지고 있습니다.

기능 개발을 위해 feature 브랜치를 만듭니다.
feature 브랜치는 개발과는 별도로 진행하여 충돌을 막습니다.
feature 브랜치는 작은 기능 단위로 쪼개어 최대 10개 미만의 커밋으로 구성되도록 합니다.

기능 개발이 모두 끝나면, develop 브랜치에 머지합니다.
develop 브랜치는 아직 release되지 않은 최신의 소스코드를 유지하게 됩니다.

머지 후에 feature 브랜치는 로컬과 원격에서 삭제합니다.

정해진 주기마다 develop 브랜치로부터 main 브랜치로 머지합니다.
머지는 Pull Request로 진행합니다.
이 단계에서 코드리뷰를 진행합니다.

4. Feature 브랜치

feature 브랜치의 생성, 머지, 삭제에 대한 가이드입니다.

develop 브랜치에서 pull을 받습니다.

# 현재 브랜치 : develop

# 원격 저장소에 있는 프로젝트 내용 가져오기
git pull

feature 브랜치를 생성합니다.
브랜치 이름은 feature/{기능} 형식을 따릅니다.

# 현재 브랜치: develop

# feature 브랜치 생성 후, 해당 브랜치로 이동
git checkout -b feature/chat-filtering

feature 브랜치에서 작업(기능 개발)을 진행합니다.

# 현재 브랜치: feature/chat-filtering

# 커밋할 파일을 선택
git add src/chat/service/chat.service.ts

# 커밋 메세지 작성
git commit -m "FEAT: 대화 내용 필터링 기능 추가"

# 원격 저장소에 작업중인 브랜치 원격 저장소에 push 하기 (upstream 설정)
git push --set-upstream origin feature/chat-filtering

# upstream을 설정한 후에는 다음과 같은 명령어로도 원격저장소에 push가 가능합니다.
# git push feature/chat-filtering

develop 브랜치에 머지합니다.

# 현재 브랜치 : feature/chat-filtering

# develop 브랜치로 이동
git checkout develop

# feature 브랜치를 develop 브랜치로 머지
git merge feature/chat-filtering

merge 과정에서 충돌(Conflict)이 발생할 수 있습니다.
merge 작업 취소는 git merge --abort 명령어를 사용합니다.

develop 브랜치에 성공적으로 병합된 후에는 feature 브랜치를 로컬과 원격에서 삭제합니다.

# 현재 브랜치 : develop

# feature 브랜치를 로컬에서 삭제
git branch -d feature/chat-filtering

# feature 브랜치를 원격에서 삭제
git push origin -d feature/chat-filtering

브랜치에 병합되지 않은 변경 사항 및 푸시되지 않은 커밋이 있는 경우, 위의 방법으로 삭제가 불가능합니다.
(커밋 기록이 실수로 손실되는 것을 Git이 방지합니다.)

2. Commit

커밋은 기능, 타입 단위로 짧게 끊어서 커밋합니다.
한번에 작업한 내용이 많더라도, 커밋은 여러번에 걸쳐 구분하여 커밋합니다.
커밋 타입에 따라 구분하여 커밋합니다.

# 커밋할 변경사항 선택하기
git add src/chat/service/chat.service.ts

# 커밋 메세지 남기기
git commit -m "FEAT: 대화 내용 필터링 기능 추가"

커밋 후에는 원격 저장소에 push합니다.
이를 통해 다른 멤버가 자신이 작업하고 있는 파일, 내용을 알 수 있게 됩니다.

# 원격 저장소에 작업중인 브랜치 원격 저장소에 push 하기 (upstream 설정)
git push --set-upstream origin feature/chat-filtering

# upstream을 설정한 후에는 다음과 같은 명령어로도 원격저장소에 push가 가능합니다.
git push feature/chat-filtering

3. Commit message

커밋 메세지는 규칙을 정하고 일관성 있게 작성해야 합니다.
올바른 커밋을 남기는 것은 중요합니다.
좋은 커밋 메세지는 동료 개발자 또는 미래의 자신에게 변경사항을 전달하는 데 도움을 줍니다.
깃 자체에서 무엇이 변경되었는지 알려주지만, 변경의 이유는 커밋 메세지로만 알려줄 수 있습니다.
간결하고 읽기 쉬운 메세지는 읽는이가 많은 정보를 빠르게 획득하도록 돕습니다.

Commit Message Structure
기본적으로 커밋 메세지는 다음과 같이 제목 / 본문 / 꼬리말로 구성됩니다.

type: subject  # 제목

body  # 본문(선택사항)

footer  # 꼬리말(선택사항)

1-1. 제목

제목은 50자를 넘기지 않도록 하며, 가능한 간결하게 작성합니다.
제목에는 마침표를 사용하지 않습니다.
제목은 동사로 시작하며, 명령어로 작성합니다.
이렇게 작성하면, Git 자체가 사용하는 메세지와 통일될 수 있습니다.
예를 들어, Git에서 merge를 하는 경우 아래와 같은 메세지가 로그에 작성됩니다.

# Git에서 merge를 하는 경우 생성되는 메세지 로그
Merge branch 'test'

1-2. 본문

본문을 통해 무엇을, 왜 등을 설명합니다.
생략해도 좋지만, 코드 변경의 이유를 명확히 작성할수록 코드를 읽는 이가 이해하기 쉬워집니다.

1-3. 꼬리말

등록된 이슈 ID를 트래킹할 때 주로 사용합니다.
선택사항이기 때문에 모든 커밋에 꼬리말을 작성할 필요는 없습니다.

Commit Type
커밋 타입은 다음 7가지를 사용합니다.
FEAT FIX
DOCS REFACTOR STYLE
REMOVE RESOURCE

FEAT : 새로운 기능 추가

FEAT: 대화 내용 필터링 기능 추가

FIX : 버그 수정, 기능 수정

FIX: 채팅 데이터가 최신화되지 않는 문제 해결

DOCS : 문서 수정

DOCS: README.md 수정

REFACTOR : 코드 리팩토링
리팩토링(Refactoring)이란, 결과의 변경 없이 코드의 구조를 재조정함을 의미합니다.
결과의 변경이 있는 경우, FIX를 사용해야 합니다.

REFACTOR: 카테고리 분류 로직 개선

STYLE : 코드 스타일 변경 (코드 자체 변경이 없는 경우)

STYLE: 세미콜론 추가

REMOVE : 파일 또는 코드, 리소스 제거

REMOVE: cat.controller.ts 삭제

RESOURCE : 이미지 리소스, prefab 등의 코드와 상관없는 리소스 추가

RESOURCE: 이미지 리소스 추가

Example Commit Message

FEAT: 대화 내용 필터링 기능 추가 (#123)

대화 내용에 연락처, 비속어가 있는 경우 필터링을 하는 기능 추가

해결: #123
참고: #456, #789

4. Pull Request

Kviruslab’s Flow에서는 정해진 주기마다 develop 브랜치로부터 main 브랜치로 머지합니다.

이 때, Pull Request를 통한 코드리뷰가 진행됩니다.

GitHub에서 Pull Request를 하는 방법은 다음과 같습니다.

Repository에 들어간 후, Pull requests를 클릭합니다.

New pull request를 클릭합니다.

base: main , compare: develop 을 선택한 후, Create pull request를 클릭합니다.

Pull request 메세지를 적고, Reviewers와 Assignees를 지정합니다.
Reviewers에는 리뷰를 해 줄 사람을 지정합니다.
Assignees에는 현재 PR 작업의 담당자를 지정합니다.

Create pull request를 클릭하면 아래와 같은 화면이 나옵니다.

Pull Request에 리뷰를 남기는 방법은 다음과 같습니다.

Repository에 들어간 후, Pull requests를 클릭합니다. 그리고 해당 PR을 클릭합니다.

Files changed를 클릭합니다.

의견을 적고 싶은 지점에서 + 를 클릭한 후, 글을 작성합니다.
글을 작성한 후, Start a review를 클릭합니다.

리뷰 작성이 끝난 후에는 Finish your review를 클릭합니다.
리뷰에 대한 총평 등을 작성한 후, Comment / Approve / Request changes 중 선택합니다.
Submit review 를 클릭합니다.

Merge pull request를 클릭하면, develop 브랜치가 main 브랜치로 병합됩니다.

develop 브랜치는 계속 사용하므로, 브랜치 삭제는 하지 않습니다.