개발·검수개발·협업 · 약 7분

APP DEVELOPMENT TERM

브랜치·커밋

작업 분리와 변경 기록 단위

브랜치는 새 기능이나 수정 작업을 기준 코드와 분리해 진행하는 작업선이고, 커밋은 특정 시점의 관련 변경을 설명과 함께 저장한 이력 단위입니다.

Git 브랜치Git 커밋BranchCommit기능 브랜치

30초 이해

브랜치는 작업 중인 변화를 안전하게 나누고 커밋은 왜 바뀌었는지 다시 찾을 수 있게 기록합니다

운영 중인 코드에서 여러 기능을 한꺼번에 수정하면 미완성 작업이 섞이거나 다른 사람의 변경과 충돌하기 쉽습니다. 브랜치를 만들면 기준 코드에서 작업선을 나눠 새 기능과 긴급 수정을 독립적으로 진행한 뒤 검토를 거쳐 다시 합칠 수 있습니다.

커밋은 단순 저장 버튼이 아닙니다. 로그인 오류 수정처럼 하나의 의미를 가진 변경을 파일 내용, 작성자, 시점과 설명으로 묶어 남깁니다. 너무 많은 일을 한 커밋에 섞지 않아야 검토하고 문제 변경만 되돌리기 쉽습니다.

한 장으로 이해

기준 코드에서 작업을 나누고 검토 가능한 이력으로 합치는 과정

기준 브랜치에서 작업 브랜치를 만들고 의미 있는 커밋을 쌓은 뒤 검토를 거쳐 다시 통합합니다.

  1. 01

    기준 선택

    현재 검수·운영 기준이 되는 브랜치에서 작업을 시작합니다.

  2. 02

    브랜치 분리

    기능·오류 수정 목적별로 독립된 작업선을 만듭니다.

  3. 03

    커밋 기록

    관련 변경을 작은 단위로 묶고 이유가 보이는 설명을 남깁니다.

  4. 04

    검토 후 통합

    테스트와 리뷰를 통과한 변경만 기준 브랜치에 합칩니다.

브랜치 이름, 커밋 설명과 연결된 업무 번호가 분명하면 개발자가 바뀌어도 어떤 목적의 변경인지 빠르게 이해할 수 있습니다.

언제 사용하는 개념인가요?

01

새 기능을 만들 때

운영 기준 코드와 분리된 공간에서 기능을 완성하고 검수 준비를 합니다.

02

긴급 오류를 수정할 때

진행 중인 다른 기능을 섞지 않고 필요한 수정만 빠르게 검토·반영합니다.

03

변경 이력을 조사할 때

커밋 설명과 실제 파일 차이를 보고 기능이 언제 왜 바뀌었는지 확인합니다.

왜 중요한가요?

  • 미완성 작업의 운영 반영을 줄입니다

    기준 브랜치와 작업 브랜치를 나눠 완료·검수된 변경만 선택해 합칠 수 있습니다.

  • 작은 단위로 검토하고 되돌립니다

    관련 변경이 커밋별로 정리되면 문제의 원인과 영향 범위를 비교하기 쉽습니다.

  • 개발 의사결정을 이력으로 남깁니다

    무엇을 고쳤는지만 아니라 왜 바꿨는지 설명과 업무 맥락을 후임자가 확인할 수 있습니다.

실제 상황 예시

예약 앱의 알림 기능과 결제 오류를 동시에 고친다면

서로 다른 목적을 별도 브랜치와 커밋으로 나눠 독립적으로 검수합니다.

알림 기능 작업선

  • 알림 설정 기능 브랜치 생성
  • 권한 안내 화면 커밋
  • 알림 예약 로직 커밋
  • 알림 시나리오 검수 후 통합

결제 긴급 수정선

  • 운영 기준에서 수정 브랜치 생성
  • 중복 결제 조건 수정 커밋
  • 결제 회귀 테스트 실행
  • 긴급 검토 후 우선 배포

작업을 분리하면 결제 수정만 먼저 운영에 반영하고 아직 검수 중인 알림 기능은 그대로 유지할 수 있습니다.

자주 하는 오해

브랜치는 프로젝트 전체를 매번 복사하는 폴더다

사용자에게는 별도 작업선처럼 보이지만 Git이 공통 이력과 차이를 효율적으로 관리합니다. 목적과 통합 기준이 더 중요합니다.

커밋을 많이 하면 무조건 좋은 관리다

개수보다 하나의 의미 있는 변경과 이해 가능한 설명이 중요합니다. 무관한 수정을 한 커밋에 섞지 않아야 합니다.

기준 브랜치에 바로 올려도 나중에 고치면 된다

검토되지 않은 변경이 빌드·배포와 연결될 수 있습니다. 작은 팀도 최소한 작업 분리와 확인 절차가 필요합니다.

우리 서비스에 적용할 때 확인하세요

  1. 1운영·검수 기준 브랜치가 명확한가요?
  2. 2기능과 긴급 수정을 목적별 브랜치로 나누나요?
  3. 3커밋 설명만 보고 변경 이유를 이해할 수 있나요?
  4. 4관련 없는 수정이 한 커밋에 섞이지 않았나요?
  5. 5합치기 전에 자동 검사와 사람의 검토를 거치나요?

공식 참고

서비스 기준은 공식 문서에서 다시 확인하세요

다음 자료

이해한 내용을 바로 적용해보세요

브랜치와 커밋을 보관하는 Git·GitHub, 합치기 전 검토 절차인 Pull Request와 공개 결과를 식별하는 버전을 함께 확인하세요.

작업 목적이 브랜치와 커밋 기록에서 바로 보이게 만드세요

기준 브랜치, 이름 규칙, 커밋 크기와 합치기 조건을 간단히 합의하면 작은 팀도 안전하게 변경을 관리할 수 있습니다.