develop 브랜치에서 작업을 하고 있었는데, 정책상 develop에 직접 작업하면 안 된다.
작업한 내용을 새로운 feature 브랜치로 옮긴 후 원격 저장소에 Push 하고 Pull Request(PR)를 통해 develop에 병합해야 한다.
이번 글에서는 실제 진행했던 과정을 기준으로 전체 흐름을 정리합니다.
작업 시나리오
현재 상황입니다.
현재 develop 브랜치에서 개발 작업 진행 중
↓
정책상 feature 브랜치로 분리 필요
↓
새로운 feature 브랜치 생성
↓
기존 작업 내용 유지
↓
commit
↓
origin 서버로 push
↓
Pull Request 생성
↓
develop 브랜치로 Merge
Git Flow 관점에서는 아래 구조입니다.
develop
↓ (분기)
feature/pms-simple
↓
origin 서버 Push
↓
Pull Request 생성
↓
develop Merge
1. develop 브랜치에서 feature 브랜치 생성
기존 작업은 develop 브랜치에서 이미 진행하고 있었습니다.
새로운 feature 브랜치를 생성합니다.
git checkout -b feature/pms-simple
결과
Switched to a new branch 'feature/pms-simple'
Git 내부적으로 브랜치가 생성되면서 현재 작업 상태도 그대로 유지됩니다.
구조
Before
develop
└── 작업중 파일 존재
After
develop
feature/pms-simple ← 현재 위치
└── 작업 파일 그대로 유지
2. 이미 생성된 브랜치를 다시 만들면 오류 발생
실수로 다시 생성하려고 하면 다음 오류가 발생합니다.
git switch -c feature/pms-simple
결과
fatal: a branch named 'feature/pms-simple' already exists
이 의미는 이미 로컬 브랜치가 존재한다는 뜻입니다.
현재 브랜치 확인
git status
결과
On branch feature/pms-simple
이미 feature 브랜치로 이동한 상태입니다.
3. 변경된 파일 상태 확인
현재 작업 내역 확인
git status
결과
Changes to be committed:
new file:
modified:
실제 변경 파일
GetProjectSimpleList.cs
ProjectSimpleListSpResultDto.cs
IProjectListSpRepository.cs
ProjectListSpRepository.cs
ProjectController.cs
Simple.cshtml
project-simple.js
Git 상태 개념
Working Directory
↓
Staging Area
↓
Commit Repository
현재는 Staging 상태였습니다.
4. 변경 파일 Stage 등록
모든 변경 파일을 Stage에 등록합니다.
git add .
의미
현재 폴더 기준 모든 변경 파일을 Commit 대상으로 등록
구조
Modified Files
↓
git add .
↓
Staged Files
5. Commit 생성
Commit 생성
git commit -m "PMS SIMPLE 프로젝트 구현"
결과
[feature/pms-simple c3136b570] PMS SIMPLE 프로젝트 구현
변경 내역
7 files changed
3757 insertions
1 deletion
생성된 Commit
Commit ID
c3136b570
Git 구조
feature/pms-simple
Commit
└── c3136b570
6. 원격 저장소(origin)로 Push
원격 서버로 feature 브랜치를 업로드합니다.
git push -u origin feature/pms-simple
결과
[new branch] feature/pms-simple -> feature/pms-simple
설명
-u
옵션은 upstream 설정입니다.
즉 이후에는 단순히
git push
만 입력해도 됩니다.
현재 구조
Local
feature/pms-simple
Remote(origin)
origin/develop
origin/feature/pms-simple
아직 Merge 되지 않은 상태입니다.
7. 원격 저장소에서 Pull Request 생성
Push는 단순 업로드입니다.
Merge가 아닙니다.
현재 상태
origin
develop
feature/pms-simple
이제 Azure DevOps 또는 GitHub 에서 Pull Request 생성합니다.
구조
Source Branch
feature/pms-simple
Target Branch
develop
PR 생성 화면 예시
feature/pms-simple
↓
Pull Request
↓
develop
입력 예시
Title
PMS SIMPLE 프로젝트 구현
Description
- PMS SIMPLE 프로젝트 구현
- 신규 View 추가
- API 처리 로직 추가
- Repository 수정
8. develop 브랜치로 이동
PR 생성 후 로컬 작업 정리를 진행합니다.
브랜치 변경
git checkout develop
결과
Switched to branch 'develop'
현재 상태
Your branch is behind 'origin/develop' by 23 commits
의미
원격 develop 이 내 로컬 develop 보다 23개 commit 앞서 있다
동기화 필요합니다.
9. 로컬 feature 브랜치 삭제
작업 완료 후 로컬 브랜치 삭제
git branch -d feature/pms-simple
결과
Deleted branch feature/pms-simple
현재 구조
Local
develop
10. 원격 feature 브랜치 삭제
PR Merge 후 더 이상 필요 없으면 삭제합니다.
git push origin --delete feature/pms-simple
결과
[deleted] feature/pms-simple
구조
Remote(origin)
develop
feature 브랜치 제거 완료
전체 흐름 정리
1. develop 에서 작업 시작
develop
└── 코드 수정
2. feature 브랜치 생성
git checkout -b feature/pms-simple
3. 파일 Stage 등록
git add .
4. Commit 생성
git commit -m "PMS SIMPLE 프로젝트 구현"
5. 원격 Push
git push -u origin feature/pms-simple
6. Azure DevOps PR 생성
feature/pms-simple
↓
Pull Request
↓
develop
7. develop 이동
git checkout develop
8. 로컬 feature 삭제
git branch -d feature/pms-simple
9. 원격 feature 삭제
git push origin --delete feature/pms-simple
실무에서 주의할 점
1) Push 했다고 Merge 되는 것이 아니다
많이 헷갈립니다.
git push
≠
Merge
Push
내 브랜치를 서버에 업로드
PR
Merge 요청
Merge
실제 develop 반영
2) develop 직접 작업은 피하는 것이 좋다
권장 구조
main
develop
feature/login
feature/project
feature/payment
즉
기능 단위 = feature 브랜치
3) Merge 후 develop 최신 상태 동기화
반드시 수행합니다.
git pull origin develop
최신 코드 반영
최종 Git 명령어 모음
git checkout -b feature/pms-simple
git status
git add .
git commit -m "PMS SIMPLE 프로젝트 구현"
git push -u origin feature/pms-simple
(원격지 PR 생성)
git checkout develop
git pull origin develop
git branch -d feature/pms-simple
git push origin --delete feature/pms-simple
마무리
실무에서는 종종
develop 에서 작업했는데 feature 브랜치 정책을 따라야 하는 상황
이 발생합니다.
핵심은 간단합니다.
현재 작업 내용은 그대로 유지된다.
develop
↓
git checkout -b feature/xxx
↓
commit
↓
push
↓
PR
↓
merge
Git 을 사용할 때 가장 중요한 것은
Push 와 Merge 는 완전히 다른 개념이라는 점입니다.
이 부분만 이해하면 실무 브랜치 전략 대부분을 이해할 수 있습니다.