학습 키워드
- 브랜치
- 충돌
- 트러블슈터
브랜치
Dev, Stage, Prod Branch 구성
Git에서 Dev, Stage, Prod Branch 구성을 사용하는 이유는 개발, 테스트, 배포 단계를 명확히 구분하여 안정성과 협업 효율성을 높이기 위함입니다.
Dev Branch
- 역할
- 새로운 기능 개발(feature)과 버그 수정(bugfix)을 포함한 모든 작업의 기반 브랜치입니다.
- 개발자들이 가장 활발히 작업하는 브랜치로, 실험적 코드와 아직 완전하지 않은 변경 사항도 포함될 수 있습니다.
- 특징
- 이 브랜치의 상태는 안정적이지 않을 수 있으며, 테스트가 완벽히 이루어지지 않은 상태의 코드가 포함됩니다.
병합흐름
- 개발 완료 후, stage 브랜치로 병합합니다.
Stage Branch
- 역할
- 배포 전의 테스트 환경을 제공하며, 통합 테스트(Integration Test)와 품질 보증(QA)이 이루어지는 단계입니다.
- 실질적으로 배포 준비가 완료된 코드를 포함합니다.
- 특징
- dev 브랜치에서 충분히 검증된 코드를 이 브랜치로 병합하여 테스트합니다.
- 테스트 환경에서는 실제 운영 환경(Prod)과 유사한 설정을 사용하여 예상치 못한 문제를 미리 발견합니다.
병합흐름
- dev → state로 병합 후 테스트 진행합니다.
- 테스트 통과 후, prod 브랜치로 병합합니다.
Prod Branch
- 역할
- 실제 사용자가 접근하는 프로덕션 환경의 코드를 포함하는 브랜치입니다.
- 이 브랜치의 코드는 반드시 안정적이고, 배포 가능한 상태여야 합니다.
- 특징
- 사용자가 직접 사용하는 서버스의 모든 변경 사항은 이 브랜치에 반영됩니다.
- 긴급 수정이 필요한 경우, hotfix 브랜치를 사용하여 prod 브랜치에서 작업 후 바로 병합할 수도 있습니다.
- 버전 태그(tag)를 통해 배포 이력을 관리하는 경우가 많습니다.
병합흐름
- state → prod로 병합하여 배포합니다.
Risky
staging 브랜치에 검증되지 않은 코드를 바로 prod(프로덕션) 환경에 반영할 경우 발생할 수 있는 위험성을 나타냅니다.
- 설명
- 코드가 충분히 테스트 되지 않았거나, 새로운 기능 또는 변경 사항에 대해 예상치 못한 버그가 있을 수 있습니다.
- 프로덕션 환경은 사용자에게 직접 영향을 미치므로ㅡ staging에서 바로 병합하는 경우 신중히 검토되어야 합니다.
- 이 과정이 부주의하거나 빠르게 이루어진다면 시스템 장애 또는 사용자 경험 문제로 이어질 수 있습니다.
- 대안
- 철저한 QA(품질 보증) 테스트를 거치고, 변경 사항을 세분화하여 점진적으로 배포하는 것이 좋습니다.
Slow
- 변경 사항의 양이 많아질수록 테스트와 배포에 필요한 시간이 증가합니다.
- Fat Release는 배포 과정의 복잡성을 높이며, 문제가 발생할 경우 복구 시간이 길어집니다.
Fat Release
-
의미
- staging에서 prod로 병합될 때 한 번에 많은 양의 코드(새로운 기능, 수정 사항...등)가 반영되는 대규모 릴리스를 의미합니다.
-
설명
- 여러 기능과 변경 사항을 한 번에 배포하다 보면 배포 과정이 느려지고(slow), 문제가 발생했을 때 오느 부분에서 문제가 생겼는지 파악하기 어렵습니다.
- Fat Release는 배포 속도를 저하 시킬 뿐만 아니라 문제 해결 및 롤백 과정도 복잡하게 만듭니다.
- 한 번에 반영된 코드가 많기 때문에 QA팀이 모든 변경 사항을 충분히 테스트하기 어려운 경우가 많습니다.
-
대안
- 작은 릴리스(Small Release) 전략을 채택하여 변경 사항을 작게 나누고, 각 변경 사항을 점진적으로 배포하면 위험을 줄일 수 있습니다.
feature branch
- 역할
- 새로운 기능 개발을 위한 브랜치입니다.
- 보통 develop 브랜치에서 분기하여 작업을 시작하고, 개발이 완료되면 다시 develop 브랜치로 병합됩니다.
- 작명 규칙
feature/login-page,feature/api-integration...등 기능 이름을 포함합니다.
- 사용 시점
- 특정 기능이나 개선 사항을 독립적으로 작업할 때 사용합니다.
- 코드 리뷰와 기본 테스트를 거친 후 develop 브랜치에 병합합니다.
release branch
- 역할
- 배포 전 최종 테스트 및 QA(품질 보증)을 위한 브랜치입니다.
- develop 브랜치에서 분기하며, 모든 버그가 수정되고 테스트를 통과하면 master 브랜치에 병합됩니다.
- 테스트 중 발견된 버스는 release 브랜치에서 바로 수정한 후 병합합니다.
- 사용 시점
- 새로운 릴리스를 준비할 때 사용합니다.
- 안정화 작업 완료 후 master 및 develop에 병합합니다.
hotfix branch
- 역할
- 프로덕션에서 발생한 긴급 버그를 수정하기 위한 브랜치입니다.
- master 브랜치에서 바로 분기하며, 수정이 완료되면 다시 master와 develop 브랜치로 병합됩니다.
- 사용 시점
- 프로덕션에서 긴급한 수정이 필요할 때 사용합니다.
- 치명적인 결함, 서비스 중단 이슈...등
- 작명 규칙
hotfix/critical-bug,hotfis/payment-error...등
Version
x.x.x 형태의 버전 표기는 Semantic Versioning(SemVer)이라는 규칙을 따르는 경우가 많습니다. 이 방식은 주 버전(Major), 부 버전(Minor), 패치(Patch)로 구성됩니다.
- Major
- 기존 버전과 호환되지 않는 변경(Breaking Changes)이 발생했을 때 증가합니다.
- Minor
- 새로운 기능 추가가 있지만, 기존 기능과 호환성이 유지될 때 증가합니다.
- Patch
- 버그 수정과 같은 작은 변경이 있을 때 증가합니다.
충돌
Rebase
한 브랜치의 변경 이력을 다른 브랜치 위로 다시 쌓아서 합치는 명령입니다. 쉽게 말해, 이미 작업한 내용을 최신 상태의 브랜치에 깔끔하게 재정렬한다고 보면 됩니다.
commit --amend
과거에 커밋한 메시지에 오타가 있거나, 빼먹은 파일이 있을 때 이 방법을 사용합니다. amend 의 사용을 권장하는 이유는 git reset 등으로 과거의 잘못된 커밋을 지우는 것보다 기존 커밋에 문제가 있을 경우, 수정해서 amend와 관련한 메시지 내용을 추가해줌으로써 커밋 이력 관리에 용이하기 때문입니다.
트러블슈팅
error: cannot rebase: You have unstaged changes. error: Please commit or stash them.
이 메시지는 커밋(commit)하거나 임시 저장(stash)하지 않은 변경사항이 있는 상태에서는 리베이스(rebase)를 수행할 수 없다'는 의미입니다. Git은 현재 작업 중인 변경 사항을 안전하게 보존하기 위해 이 작업을 차단합니다.
이에 대한 해결 방법은
- 변경 사항 커밋
git add .git comiit -m "save"
- 변경 사항 임시 저장
git stash- 이후
git rebase를 실행한 후,git stash pop명령어로 임시 저장했던 변경 사항을 다시 적용할 수 있습니다.
please commit your changes or stash them before you merge. aborting merge with strategy ort failed.
이 메시지는 로컬에 커밋하지 않은 변경사항이 있어 원격 저장소를 병합할 수 없을 때 발생합니다.
해결 방법은 위와 동일 합니다.
Please commit your changes or stash them before you merge.
이 메시지는 로컬 변경사항 때문에 git pull이 실패했을 때 발생하는 에러입니다.
이 또한 해결 방법이 동일합니다.
