TIL 2023-10-24 Github Pull Request 가이드, 팀 협업!!

1. 브랜치 활용하기

수정은 하고 싶은데, 원래 파일(메인 브랜치)은 그대로 두고 싶다.

 

코드의 복사본과 비슷한게 브랜치다.

 

• 브랜치 생성 명령어
  • git branch 브랜치이름
• 브랜치 확인 명령어
  • git branch
  • 터미널에 뜨는 초록색은 내가 보고 있는 브랜치, 하얀색은 내가 만든 브랜치
• 브랜치 이동 명령어
  • git switch 브랜치이름
  • git checkout 브랜치이름
  • 뭘 쓰든 상관 없다.
• 브랜치 한 번에 생성 및 이동
  • git switch -c 브랜치이름
  • git checkout -b 브랜치이름
• 브랜치 합치는 명령어
  • git switch 최종브랜치이름 (main)
  • git merge 합칠브랜치이름

2. Pull Request 활용하기

사실 git merge 잘 안 씀ㅋㅋ 왜냐??

 

Pull Request가 있기 때문!

 

Pull Request를 사용하는 이유는 Mergy전에 코드 리뷰를 통해 Merge 할지 말지 정할 수 있음

 

• 브랜치에 푸쉬
  • git push origin 브랜치명
  • -> 깃허브 들어가면 Compare & Request 뜸 (Merge 하기 전 평가 해달라는 뜻)
• 브랜치에 Merge
  • 깃허브에서 Confirm merge 누르면 Merge

 

1. 브랜치 생성 및 이동

2. 기능 개발 및 코드 저장

3. 코드 업로드 및 Pull request 생성

4. 깃헙에서 머지

5. 내 로컬에도 반영

 

문제점

 

Main 브랜치 === 배포용

 

근데 Main에 합치다가 문제가 생기면?

 

문제점 1) 완벽하게 기능 개발 해야 merge 가능

해결책) develop 브랜치 하나 만들고 (베타) Merge

 

문제점 2) merge시 오류가 날 수 있음

해결책) 로컬에서 먼저 테스트

 

 

초기 세팅

 

1. 팀장: 초기 코드 작성 및 github 업로드
   1. 폴더 생성
   2. 초기 코드 작성
   3. init add commit
   4. 레포지토리 생성
   5. git push
   6. dev 브랜치 생성
      1. git switch -c dev (로컬에서 dev 브랜치 생성)
      2. git push origin dev
      3. dev 브랜치 default 브랜치로 설정
   7. 팀원 추가 (Collaborators)
2. 팀원: 
   1. git clone 주소 .
3. 모든 사람
   1. 기능 브랜치 생성 및 기능 개발 / push
   2. Pull request 생성
   3. 코드 리뷰
      1. 리뷰어 지정, 리뷰 요청
         1. 리뷰어는 files changed 눌러서 리뷰
         2. Start a review 눌러서 리뷰 등록 (댓글)
         3. Finish your review 눌러서 마치기
   4. dev에 합치기 전에 pull로 당겨서 미리 충돌 테스트!!!!
   5. 충돌 테스트 다 끝내고 다시 내가 만든 기능 브랜치에 푸쉬 후 dev랑 merge

 

업로드 불필요한 파일들 제외하기

.gitignore 파일 생성 후 안에 제거 할 파일들 적어주면 된다.

 

gitignore.io

 

여기에서 자기가 쓰는 프로그램 (Windows, Mac, java, spring...)

입력 후 gitignore에 넣어주면 기본적으로 안들어가도 되는 불필요한 파일들을 제외해준다.