TIL3. Git Flow

TIL 쓰는 유일한 재미ㅎㅅㅎ 판다 귀여운데 멀리서 찍으면 이름도 같이 나와서 쵸큼 별로...

이게.. 리얼 협업?

국비지원학원에서 깃 쓸 때는 그냥 main 브랜치 하나로만 썼는데 Git Flow는 뭐며...

깃에서 Issues를 써서 커밋하는 건 진짜 완전 처음이다. 애초에 나는 PR(Pull Request)이라는 용어도 여기서 첨 들음.

내가 협업 도구에 너무나도 무지했구나...를 느꼈다.

Git Flow

1) Git

코드 형상 관리 시스템 = Version Control System = VCS

대부분의 VCS가 Git Command를 따라하므로 Git 명령어가 사실상의 표준이라고 이해해도 무방함.

 

• Staging Area

Local Repository 에 반영하기 전 한번 검토하는 영역 + 작업한 내용 중 일부만 커밋하고 싶을 때에도 사용

 

2) 브랜치 종류

• master(main): 현재 서비스 되고 있는 버전과 동일한 브랜치 -> 최종 릴리즈 버전(최신 버전)와 같아야 함.
• hotfix: 배포된 버전에 긴급한 수정이 있을 때 사용하는 브랜치로 완료되면 master 와 develop 브랜치에 병합함.
• release
  - 배포에 사용되는 브랜치
  - 배포 전까지 발생되는 버그 수정도 브랜치에 반영이 되어야 함.
  - 만약 버그가 발생한다면, 브랜치 내용이 수정될 수 있으므로 다시 develop 브랜치에 merge시켜줘야 함.
  - 배포 후에는 master 브랜치에 머지해서 master 가 최종 릴리즈 버전을 유지하게 함.

• develop: merge 브랜치 -> feature 브랜치들의 내용이 합쳐져 release 브랜치의 근간이 됨.
• feature: develop 브랜치에서 분기되며, 새로운 기능을 개발하기 위한 브랜치로 사용됨.

3) Git Command

# 내가 잘 모르겠는 것만 정리한 거임. 순서대로 하면 되는 거 아마 아닐...걸? 잘 모름ㅋㅋㅋㅋㅋ
# 로컬 레파지토리를 원격에 동기화
git push origin 브랜치

# 모든 로컬 브랜치 확인
git branch # -r : 원격 브랜치만, -a : 모든 브랜치 확인

# main 브랜치에서 develop 브랜치 생성 및 체크아웃하며 원격에 반영
git checkout -b develop # 체크아웃 없이 브랜치 생성하려면 git branch 브랜치명
git push origin develop

# develop 브랜치에서 feature 브랜치 생성 및 체크아웃
git checkout -b feature/1_test

# 파일 작성 후 Staging Area에 추가
echo "test" > test.txt
git add A.java # 전체 파일 올릴거면 git add .

# 변경사항을 Local Repository에 커밋 후 동기화
git commit -m "메시지"
git push origin feature/1_test

# 다른 브랜치를 생성하기 위해 develop 브랜치로 이동
git checkout develop # 또는 git switch develop
git pull origin develop

# 이전 브랜치 삭제
git branch -d 브랜치명
# 원격 브랜치 삭제는 git push origin -delete 브랜치명

# 다음날 다시 작업 시작한다고 가정
# Remote Repository 변경사항 확인(병합은 아님) > git log 새로고침 됨.
git fetch

# 현재 브랜치 내용을 로컬에 동기화 (충돌 발생시 해결하면 되는 부분)
git pull origin develop

# develop 브랜치에서 특정 작업 브랜치 merge
git merge 브랜치명

 

4) Pull Request

= PR, 코드 변경 사항을 병합 요청하는 행위

• PR하는 방법

1) GitHub의 Pull Requests 메뉴를 통해 PR 생성 메뉴 접근

2) PR 대상 브랜치 선택 후 PR 생성 요청

   - base : 코드가 합쳐질 target 브랜치

   - compare : 합칠 코드가 존재하는 source 브랜치

3) GitHub PR Template 사용해 PR하기

4) 코멘트 남기기

5) 병합하기

 

Github Desktop을 쓰면 편리하게 쓸 수 있다는 조언을 들었다.

지금 기능 구현보다 이게 더 머리 아프다. 다시 정리해보니 내가 너무 어렵게 생각하는 것 같기도.

어쨌든 PR하기 전에 무조건.. 무조건 검색하고 해봐야겠다.

 

코드 컨벤션

명명규칙을 확실히 정하자? 이 뜻인듯.

 

팀장님이 시범을 보여주셨지만... 미친듯이 졸린 상태라서 잘 기억이 안나서 검색해서 적용했다.

https://blog.naver.com/seek316/223306071687

[IDEA] 인텔리제이(IntelliJ) - 구글 코드 스타일 적용

 

멘토링

SA 피드백으로

1) 지역별 확장성이 고려가 되어야 하기 때문에, 지역별 코드 테이블이 있으면 좋을 것 같다. 관련 링크: code.go.kr

Wait..

➡️ 프론트에서 아래 API를 받아온다고 가정했을 때, Response되는 변수 중 시명, 시군구명, 읍면동명을 받아 DB에 저장하기로 했다.

그래서 p_user(1:1), p_store(1:1), p_delivery_address(1:N) 하는 걸로 ERD + 테이블 명세서 수정함.

 

https://business.juso.go.kr/addrlink/openApi/popupApi.do

팝업API

 

2) 요구사항에서 대면 주문이 가능하다고 명시했기 때문에, 결제 테이블에도 결제 상태(완료, 대기, 취소)가 필요할 것 같다.

➡️ 고대로 p_payment에 status 컬럼 추가했다.

 

이건 내가 따로 질문한 내용인데, 나는 이번에 카테고리, 리뷰, AI 프롬프팅 파트를 담당했다.

Q. 아무래도 배달 플랫폼이다보니 아무래도 주문/결제, 가게/메뉴 파트가 메인 기능인데 그 외 기능을 담당했다면,
     나중에 포트폴리오에서 어떻게 본인어필을 하는 게 좋을까요?

A. 소프트웨어 엔지니어 답게 스레드를 쓴다거나 Redis나 Cache DB를 써서 서버에 가는 부담을 줄이는 등의
     고민을 해서 기능 up하는 트러블슈팅을 하면 좋게 봅니다!

 

라는 답변을 받았다...

이전에 개인 프로젝트를 할 때도 기능은 어렵지 않았지만 실행시간 줄이는 걸 어떻게 구현할지 그걸 어디서부터 찾아야할지가 문제였다.

그래서 이 부분도 여쭤보니 아래 링크 책에서 부하를 줄이는 방법 같은 내용을 다룬다고 추천받았다.

https://jake-seo-dev.tistory.com/553

대규모 서비스를 지탱하는 기술, 9강 IO 부하를 줄이는 방법 요약

 

https://product.kyobobook.co.kr/detail/S000001550638

대규모 서비스를 지탱하는 기술 | 이토 나오야 - 교보문고

 

 

일단 엔티티는 만들어뒀다. 나머지는 안 했다...

난 8시간은 자야하는데 이번주 내내 계속 3~5시간 자니까 컨디션이 너무 안 좋다.

아까 내배캠 정규시간에 두통 + 졸려죽겠음 + Git Flow가 모죠? 이 상태여서 내일...! 빡시게 진도 나가보는 걸로!!

 

TIL3 끝!