사내 프로젝트에서 Git을 사용하긴 하지만 브랜치를 나누지 않고 로컬에서만 작업하는 상황이었다.
운영 반영은 .sh 파일을 통한 수동 복사 방식으로 이뤄져, Git을 제대로 활용하지 못하고 있었던 것이다.
이에 허락을 구하고 develop 브랜치를 분리하여 개발 작업을 진행하고, 이를 master 브랜치와 병합해 운영에 반영하는 구조를 도입해 보기로 했다.
이번 포스팅에서는 그 과정을 절차별로 정리하고, 사용한 Git 명령어를 함께 기록해보려 한다.
1. 클론 후 브랜치 분기 및 초기 설정
1.1 Git 저장소 clone
git clone http://your-repo.git
cd your-repo
git checkout -b develop
1.2 .gitignore 작성 및 추적 해제
echo -e ".classpath\n.settings/\ntarget/" > .gitignore
git rm --cached .classpath
git rm --cached -r .settings/ target/
git add .gitignore
git commit -m "chore: .gitignore 설정 및 자동 생성 파일 추적 해제"
git push -u origin develop2. Eclipse에서 develop 브랜치 기준 Import
- Git Perspective에서 origin/develop 브랜치 우클릭 → Checkout as Local Branch
- File > Import > Maven > Existing Maven Projects
- 프로젝트 루트 선택 후 pom.xml 인식되면 Finish
- Maven > Update Project로 의존성 확인 및 빌드
3. develop에서 작업 후 master로 머지하기
3.1 develop 브랜치에서 작업 및 커밋
git checkout develop
# 작업 후
git add .
git commit -m "feat: 기능 개발"
git push origin develop
3.2 master 브랜치로 이동 후 병합
git checkout master
git pull # 최신 동기화
git merge develop
git push origin master- 이때 origin/develop은 따로 push 하지 않으면 그대로 유지된다.
4. 브랜치 삭제 여부
- 머지를 해도 브랜치는 자동으로 사라지지 않는다.
- 병합 후 불필요하면 수동으로 삭제해야 한다.
로컬 브랜치 삭제
git branch -d develop # 안전 삭제 (병합된 경우만)
git branch -D develop # 강제 삭제 (주의)
원격 브랜치 삭제
git push origin --delete develop5. 기타
Tips
- Remote Tracking 브랜치(origin/*)는 읽기 전용 → 직접 병합 X
- 브랜치 병합은 반드시 로컬 브랜치 간에 수행해야 한다.
- develop 브랜치가 필요 없는 경우 원격에서도 삭제가 가능하다.
브랜치 전략 추천
| 브랜치 | 용도 | 설명 |
| master | 운영 | 운영 서버에 배포되는 안정 버전 |
| develop | 개발 통합 | 기능개발이 merge 되는 브랜치 |
| feature/* | 기능 단위 | 작은 기능 단위 작업 브랜치 |
| hotfix/* | 긴급 패치 | 운영 긴급 수정용 브랜치 |
마무리
이런 브랜치 전략을 꾸준히 유지하면 팀원 간의 협업은 더욱 명확해지고, 운영 반영 시 발생할 수 있는 실수도 효과적으로 줄일 수 있다.
이처럼 Git을 적극적으로 활용함으로써 코드 관리와 협업 효율이 높아질 것으로 기대하며, 추후에는 운영 반영 방식 또한 CI/CD 파이프라인을 도입하여 자동화하는 방향으로 개선을 추진해 볼 계획이다.