협업방법

• 이슈관리
• 제목에 어떤 이슈인지
• 내용에 이슈 상세

• 브랜치
• 이슈 번호로 파기

git fetch origin && git switch -c 브랜치명 origin/develop

• PR
• 제목에 이슈번호 + 어떤 내용 구현했는지
• 내용에 내용 구현 상세 + 캡쳐사진
• 예시) #12 로그인 페이지 구현

• merge
• 로테이션 정해서 담당자한테 리뷰 및 머지 요청

• 커밋
• https://overcome-the-limits.tistory.com/entry/협업-협업을-위한-기본적인-git-커밋컨벤션-설정하기
• 한글로
• 형식 예시) Feat : 로그인 기능 구현
• 커밋 태그 이름

• 초기세팅
• cra
• typescript
• @emotion
• craco
• ESlint + prettier
• recoil [참고자료]
 

가정

• remote name이 origin이라는 가정

• 작업한 branch name이 feature라는 가정

1. (작업 시작 전) 브랜치를 새로 만들기

• 원격 저장소의 최신 상태를 로컬에 반영 후, 브랜치를 새로 생성한다

git fetch origin && git switch -c 브랜치명 origin/develop

2. (작업중) 열심히 작업을 진행한다.

3. (작업 완료) add, commit 을 한다.

git add .
git commit -m "커밋 메세지"

4. (작업 완료) push 전에 원격 상태를 로컬에 반영하기

• 현재 브랜치의 작업이 길어졌을 경우, 그동안 origin/develop이 업데이트 되었을 수도 있다. 이때 브랜치를 푸시하기 전에 이력이 꼬이지 않도록 최신 상태를 로컬에 반영한다. (이 과정은 필수는 아니지만, 추후 충돌의 복잡도를 줄이기 위해서는 최신화를 시켜주는 것이 좋다고 생각됨!)

• 이 명령어를 수행하는 위치는 [feature] 브랜치

• fetch는 어차피 다 가져오는 것이라 상관없지만, rebase는 브랜치 위치가 중요

git fetch origin && git rebase origin/develop

#rebase과정에서 충돌이 나면, 로컬에서 충돌 수정
#충돌 수정이 끝나면,
git add .
git rebase --continue

#만약에 원격에 충돌이 난 브랜치가 있다면 삭제하고 다시 push 하자
#(pr을 만들기전에만 사용, pr을 보낸 이후에 이렇게 하면 pr이 닫힘)
git push origin :브랜치이름

#(pr을 만들고나서는 이렇게)
git push origin +브랜치이름

#rebase과정에서 계속 문제가 발생하면 rebase 이전으로 돌아가자
git rebase --abort

#feature 브랜치에서 원격 develop을 pull해오고 충돌 수정

5. (작업 완료) 원격 feature 브랜치로 push

git push origin feature

6. (작업 완료) 원격에서 develop으로 pr 보내고, 팀원들 승인 후 merge

7. (merge 이후) 머지 완료된 브랜치 정리하기

• 원격 feature 브랜치 삭제

• 이 때, 로컬 feature 브랜치도 삭제해주는 것이 좋다

git branch -d feature

만약에, rebase에서 conflict가 난다면?

(옵션) 원격과 로컬 브랜치의 상태를 맞춰주기

• 상태를 맞춰두지 않으면 나중에 깃이 꼬이거나 문제가 발생했을 때 해결에 어려움을 겪을 수 있다

• rebase를 쓰는 이유는 pull을 하면서 발생하는 merge commit을 만들지 않기 위함

# 특정 브랜치만 당겨오기
# 로컬에서 당겨올 브랜치로 이동 후,
git pull --rebase origin 브랜치명

Tip

# -- origin에 올라간 브랜치 삭제하기
git push origin :브랜치이름

# 원격 origin에 있는 브랜치 상태와 로컬 브랜치 상태를 맞춰주기
git remote prune origin

• 역할분담