Chap.01 : Project Day 3 - Scrum

Ch.1 AI 활용 비즈니스 프로젝트

어제 한일, 오늘 할일,  내일 할일

장애물 개선

 

장소 : ZEP

 

참여자 : 서동우(튜터), 정민수, 염금성, 노현지

이지언(자격증 시험)

 

스크럼 진행

1.  깃허브 브랜치 설정, 브랜치 Rule 적용

2. 개발 작업 진행 - 개인

 

어제 작업

---

튜터님과 피드백 결과 확인 및 스크럼

API / Table 명세서 확정, ERD/인프라 설계 확정

공통사항 작성

Code / Git Conbention 작성 완료

깃허브 Organization , Team 생성

 

오늘 작업

---

01 문제 - 깃 프로텍션 설정

• 깃허브 브랜치 디폴트 설정 main -> develop
  

01 결론

•  기본적으로 main으로 진행해 다른 CI/CD에서 적용해야 할 수 있기 떄문에 다시 main으로 결정

• Main 브랜치
  • main, develop 브랜치
  • rules은 Restrict deletions, Require a pull request before merging, Block force pushes 결정
• 보조 브랜치
  • 각자 자유롭게 rules 적용
    

 

 

02 문제 -Merge하는 방법은 필수 학습

https://hudi.blog/git-merge-squash-rebase/

Git의 다양한 브랜치 병합 방법 (Merge, Squash & Merge, Rebase & Merge)

Merge 방법은 여러 가지가 있다.

이 중에서 우리한테 맞는 Merge방법을 선택해야 한다.

Merge (일반 병합)

• 가장 일반적으로 사용되는 병합 방식
• 기존 커밋 이력을 유지하면서 병합
• Fast-Forward Merge와 Recursive Merge 두 가지 방식이 있음

2. Fast-Forward Merge (빠른 병합)

• 병합 대상 브랜치(main)가 최신 상태이며, 중간에 새로운 커밋이 없을 때 가능
• 새로운 커밋 없이 브랜치 포인터만 이동

git checkout main
git merge my-branch

3. Recursive Merge (병합 커밋 생성)

• 병합 대상 브랜치(main)에 새로운 커밋이 있을 경우 사용됨
• 공통 부모를 기준으로 Merge Commit이 생성됨

git checkout main
git merge my-branch

• Fast-Forward Merge가 가능하지만 강제로 Merge Commit을 남기려면 --no-ff 옵션 사용

git merge --no-ff my-branch

 

Squash & Merge

• 여러개의 커밋을 하나의 커밋으로 합치는 것을 의미한다.
• Squash Merge는 병합할 브랜치의 모든 커밋을 하나의 커밋으로 Squash한 새로운 커밋을 Base브랜치에 추가하는 방식으로 병합하는 것을 의미한다.
• Squash를 하게 되면 모든 커밋 이력이 하나의 커밋으로 합쳐지며 사라진다는 점을 주의해야 한다.

$ git checkout main
$ git merge --squash my-branch
$ git commit -m "squash & merge"

Rebase & Merge

Rebase를 알아보기 전에 Base에 대해 알아보자.

my-branch가 main브랜치의 A커밋으로 분기되었다는 가정하에, my-branch는 이때 A커밋이 된다.

그렇다면 Rebase란

Base를 다시 설정한다는 의미이다. my-branch가  분기된 main브랜치의 최신 커밋이 된다.

 

Rebase를 하면 커밋들의 Base가 변경되므로 Commit Hash 또한 변경 될 수 있다. 이로 인해 Force Push를 해야할 경우도 있으니 주의하자.

$ git checkout my-branch
$ git rebase main
$ git checkout main
$ git merge my-branch

 

결론 02 - 어떤 방식을 언제 사용해야 하는가?

Branch	적합한 방식	이유
feature → develop	Squash & Merge	기능 단위 커밋 유지, feature 브랜치는 삭제되므로 Merge Commit 불필요(자유)
develop → main	Rebase & Merge	커밋 이력을 유지하면서 Merge Commit을 남기지 않음

 

Squash & Merge - 깃허브나 인텔리제이에서 설정

 

03 문제 - Branch 전략은 다양하다.

https://techblog.woowahan.com/2553/

우린 Git-flow를 사용하고 있어요 | 우아한형제들 기술블로그

 

• 기능별 브랜치 관리 필요성이 있는걸 인지한 상태였기에 튜터님의 조언을 듣고 Git flow 전략이 필요하다는걸 알게 된다.
• 대부분 실무에서 Git-flow 브랜치 전략을 이렇게 가져간다.

 

• Main 브랜치
  • main : 출시 가능한 안정적인 브랜치.
  • develop : 다음 출시 버전을 개발하는 브랜치.
• 보조 브랜치
  • feature : 새로운 기능 개발 브랜치.
  • release : 출시 준비 브랜치.
  • hotfix : 긴급 버그 수정 브랜치.

 

03 결론

현재 프로젝트 상황에서 필요한 브랜치 전략

• main(default - 배포), develop, feat/(기능 개발 브런치), test/(테스트 브랜치)
• 단, 주의할 점은 JIRA를 쓰지 않기 때문에 브랜치 수 증가하기 때문에 각 기능의 API 브랜치를 정리

feat/user -> develop (V) 각자 브랜치

브런치 전략 참고 키워드 - git flow 전략, github flow 전략

 

04 문제 - 공통 모듈 구현

build.gradle - 라이브러리 추가

 

패키지 생성

• common
  • config(JpaAuditingConfig,QuertDslConfig,Security)
  • exception (Custom, Handler)
  • dto
  • client
• domain

enum타입 자체는 상속이 불가능하다. 각자 도메인에서 예를 들어 UserException을 만들어서 써라.

 

• DTO를 따로 둔 이유
  
  • DTO는 클라이언트와 서버 간에 데이터를 전달하는 역할을 하며, 이를 명확하게 구분하면 유지보수와 확장성이 좋아진다.
• common, product, order 패키지에 DTO가 각각 있는 이유
  • common 패키지: 여러 모듈에서 공통적으로 사용하는 DTO를 모아둔 것입니다. 예를 들어, 날짜 정보, 사용자 정보 등 여러 곳에서 필요할 수 있는 DTO가 포함된다.
  • product, order 패키지: 각 도메인(product, order)에서만 사용되는 DTO를 정의하여, 해당 모듈에서만 필요한 데이터를 주고받도록 분리한 것이다.
  • 이렇게 하면 모듈 간 책임 분리가 명확해지고, 필요 없는 데이터를 공유하지 않으면서도 필요한 곳에서 DTO를 활용할 수 있다.

 

 

dto를 왜 따로 뒀는지 common, product, order에 각자 dto가 들어 있는 이유가 질문

목적에 맞게 컨트랙트하기 위해서다. 세분화 한거다.

(외부)클라이언트끼리 받을 모듈을 common패키지에 빼둔 이유이고, (내부)다른 order나 product에 있는 dto가 서로 활용하기 위해서이다.

ACL (Order) 참고

 

05 문제 - 진행할 경우, 안쉬고 진행한다는 점!

05 결론 - 휴식이 필요하다면 언제든지 말하고 10분씩 휴식 갖기...

 

 

내일  작업 (주말 및 월요일)

각자 기능 개발 진행 및 보고