형상관리 개선 기록: viewdevelop 브랜치를 만든 이유 (스프링 부트 기준)

[ 개선하게 된 배경 ]

Spring Boot 팀 프로젝트를 진행하면서

작업한 코드는 그날그날 커밋해서

원격에 올리는 운영을 하고 있었다.

 

문제는 기능 개발이 진행 중인 컨트롤러가

develop에 계속 반영되면서 미완성 코드들끼리

충돌하거나 컴파일/빈 등록 단계에서 오류가 나서

부트 실행 자체가 막히는 날이 생겼다는 점이다.

 

부트가 실행되지 않으면 뷰(JSP/CSS/JS) 수정이

아무리 잘 되어도 화면에서 테스트할 방법이 없다.

 

결국 프론트 작업이 '백엔드 미완성 코드의 영향'을

직접적으로 받아버리는 상황이 반복됐다.

 

이 문제를 해결하기 위해

'V를 정상적으로 테스트 가능한 상태'를

항상 유지하는 전용 브랜치가 필요했고,

그래서 'viewdevelop'을 추가했다.

---

문제가 터지는 구조

기존 운영은 대략 이런 흐름이었다.

• develop: 팀 통합 브랜치
• feature/이름: 개인 작업 브랜치
• 각자 feature에서 작업 후 PR로 develop에 합침

이 방식 자체는 정석인데

 팀이 하루 작업분을 모두 커밋해서 올리는

방식을 택하면 아래 문제가 쉽게 발생한다.

1. 컨트롤러/서비스가 아직
   미완성인데도 develop에 올라감
2. 미완성 컨트롤러끼리 컴파일/DI/매핑
   충돌이 나서 부트 실행이 실패함
3. 프론트는 뷰 확인이 급한데,
   실행이 안 돼서 테스트가 멈춤

핵심은 '프론트 테스트 가능 상태'가
develop의 안정성과 묶여버렸다는 점이다.

---

해결 전략: 실행 가능한 V 통합 브랜치 분리

viewdevelop의 목적은 단순하다.

• viewdevelop
  V(뷰) 테스트가 가능한 상태를 유지하는 브랜치
• develop
  전체 통합 브랜치(Controller/Service 포함,
  중간 미완성 코드가 섞일 수 있음)

즉, 프론트 작업은 viewdevelop을 기준으로 진행한다.
백엔드 기능 개발은 develop을 기준으로 진행한다.

이렇게 하면 develop이 잠깐 깨지더라도

프론트는 viewdevelop에서 계속 작업/테스트가 가능하다.

 

여기서 중요한 전제는 이것이다.

• viewdevelop은 '뷰/정적 리소스만'
  들어가는 브랜치로 운영한다.
• 컨트롤러/서비스 변경이 섞이면
  viewdevelop의 목적이 무너진다.

---

형상관리 규칙 변경 사항

기존 'main/develop/feature' 구조는 유지하되,

프론트 작업자가 사용할 통합 브랜치로

viewdevelop을 추가했다.

• main: 최종 배포 브랜치
• develop: 전체 통합 브랜치
  (백엔드 포함, 일시적으로 깨질 수 있음)
• viewdevelop: 뷰 통합 브랜치
  (항상 부트 실행 가능 상태 유지)
• feature/이름: 개인 작업 브랜치(고정)

그리고 프론트 작업 흐름은 develop 대신

viewdevelop을 기준으로 돌아가게 된다.

---

'V용 브랜치 운영 루틴' 최종본

[ V용 브랜치 운영 루틴 (viewdevelop) * 기본 원칙 ] viewdevelop: V(뷰) 통합 브랜치 (부트 실행 가능한 상태 유지용) develop: 전체 통합 브랜치(Controller/Service 포함, 중간 미완성 코드 섞일 수 있음) main: 최종 배포 브랜치 feature/이름-기능: 개인 작업 브랜치

1. 매일 작업 시작 루틴

▶ viewdevelop 최신화

git checkout viewdevelop

git pull origin viewdevelop

▶ 내 feature로 이동

git checkout feature/seunghwan

▶ 내 feature에 viewdevelop 반영

git merge viewdevelop

2. 작업 중 루틴 (V 작업자)

▶ 기능 단위로 자주 커밋하고 push

커밋 범위: JSP / HTML / CSS / JS / 이미지 / static 리소스 중심

git add -A

git commit -m "view: ..."

git push origin feature/seunghwan

3. viewdevelop로 합치기(PR) 루틴 (V 작업자)

▶ PR 올리기 직전, 마지막 동기화(필수)

git checkout viewdevelop

git pull origin viewdevelop

git checkout feature/seunghwan

git merge viewdevelop

git push origin feature/seunghwan

▶ 그 다음 GitHub에서 PR 생성

base: viewdevelop

compare: feature/seunghwan

▶ 리뷰 후 merge

이때 컨트롤러/서비스 파일 변경이 PR에 섞이면 merge 금지

(뷰 커밋 분리 or 불필요 변경 되돌리고 다시 PR)

4. viewdevelop의 변경을 develop로 반영하는 루틴 (중요)

목표: viewdevelop 전체를 merge하는 게 아니라, develop에 “뷰만” 안전하게 반영한다.

방식: viewdevelop을 develop에 PR로 올린다. (단, viewdevelop은 뷰/정적만 포함)

▶ viewdevelop 최신화

git checkout viewdevelop

git pull origin viewdevelop

▶ GitHub에서 PR 생성

base: develop

compare: viewdevelop

▶ merge 전 체크(필수)

Files changed에 src/main/java/... 변경이 있으면 merge 금지

뷰/정적 경로만 있으면 merge

5. PR 머지 후 팀 공통 루틴 (V 작업자)

▶ 누가 viewdevelop에 PR을 머지했든, 다음 작업 전 viewdevelop pull

git checkout viewdevelop

git pull origin viewdevelop

6. 충돌을 줄이는 V 팀 규칙

▶ 같은 JSP/같은 CSS 파일 크게 건드릴 예정이면 작업 시작 전에 공유

▶ viewdevelop PR도 작게/자주(오래 끌면 충돌 급상승)

▶ PR 올리기 전 feature에 viewdevelop merge는 필수

▶ viewdevelop에는 컨트롤러/서비스 파일 변경 금지(섞이면 PR reject)

---

운영 중 추가로 정리한 이슈: 업로드 폴더 추적 제거

프로젝트를 진행하다 보면

런타임 중 생성되는 업로드 파일(이미지 등)이

리포지토리에 섞이는 문제가 자주 생긴다.

 

이건 팀 작업에서 충돌과 오염의 주요 원인이다.

그래서 아래 규칙을 강제했다.

• upload 폴더는 커밋 대상이 아니다.
• 이미 추적되고 있었다면 추적을 끊는다.

.gitignore에 포함

• /uploads/
• /src/main/webapp/upload/

그리고 이미 추적되던 파일은

'추적 해제 커밋'으로 정리한 뒤,

viewdevelop과 develop에 모두 반영했다.

 

이 과정을 거치면 이후에는 upload 폴더가

PR에 섞일 확률이 크게 줄어든다.

---

결과

viewdevelop 도입 이후 기대 효과는 명확하다.

• develop이 일시적으로 깨져도
  프론트 테스트는 계속 가능
• 프론트 작업자는 실행 가능한 구버전 컨트롤러
  기반으로 화면을 안정적으로 확인
• viewdevelop을 develop에 반영할 때도
  경로 체크로 사고 방지
• 업로드 폴더 같은 런타임 파일 오염도 구조적으로 차단

---

[ 마무리 체크리스트 ]

• 프론트 작업 시작은
  develop이 아니라 viewdevelop에서 pull
• viewdevelop PR에는
  src/main/java 변경이 들어가면 무조건 reject
• viewdevelop → develop PR은
  Files changed 경로 체크 후 머지
• upload 폴더는 .gitignore로 차단
  + 이미 추적된 파일은 추적 해제 커밋으로 정리

이렇게 운영하면 '부트 실행 가능 상태'가

프론트 작업의 기본 전제가 되고,

백엔드 개발 진행 상황에 프론트가 끌려가지 않게 된다