멋사에서 진행한 개인 프로젝트 1, 2 강사님 해설
- 프로젝트의 요구사항에 대한 예외상황을 어떻게 핸들링 할건지 생각하였다면 발전 가능성이 있는 생각 이라고 하셨다.
- 멋사 마지막 주 차에 본인이 한 개인 프로젝트 Fork가 가능하다고 하셔서 프로젝트 링크는 작성하지 못합니다...
swagger
- 기존에
spring - doc방식으로swagger를 사용하면서 컨트롤러 단에swagger관련 어노테이션이 많이 붙게되어 가독성을 떨어 뜨리는 문제점이 있었습니다.
팀원들과의 회의 끝에 git flow 전략을 세우기로 정하였습니다.
여기서 git flow 란 ?
혼자 하는 토이 프로젝트 같은경우나 규모가 작은 프로젝트에 대해서는 브랜치를 생성하지않고
main그대로 작성해서 배포 해도 상관 없을 것입니다.
하지만 기업에 입사를 하고 프로젝트의 규모가 커짐으로 이슈 발생시 코드를 롤백 해야되고,
conflict 를 해결 해야하고, ⬅ 필자도 경험 현재 팀프로젝트를 하며 경험해 보았지만, 상당히 골치 아픈 일 인것 같다.
(현재까지 main에 merge 된 코드와 다르면 충돌이 나는 경우....)
그래서 git flow 가 뭔데 ?
위와 같은 과정들을 최소화하고 형상관리를 효율적으로 하기 위해 생겨난 전략 이라고 합니다.
대표적인 브랜치 명칭으로 아래와 같이 5가지가 존재합니다.
-
main(master) : 제품으로 출시될 수 있게 관리하는 주요 브랜치 -
develop: 다음 출시 버전을 개발하는 브랜치 -
feature: 개발 중인 기능을 개발하는 브랜치로,develop브랜치에서 파생됩니다. -
release: 이번 출시 버전을 준비하는 브랜치 -
hotfix: 출시 버전에서 발생한 심각한 버그나 긴급한 문제를 해결하기 위한 브랜치입니다.
총 이렇게 5가지가 존재하며 각 회사마다 규칙이 다를수 있습니다.
🙂 현재
기존의 팀프로젝트를 진행하면서 해왔떤 방법으로는
main브랜치 에서 각각의 개인 브랜치를 만들어
PR을 올린후main브랜치에merge를 하였는데 방법을 바꿔main브랜치에서는 테스트 관련 로직을 빼기로 하였습니다. (API 테스트 등등)
🧐 변경 점
swagger - test라는 브랜치를 만들어swagger관련 어노테이션과API테스트 로직을 해당 브랜치에 모으는 것 입니다.
