Git Flow 다른사람과 협업하기

이번에 프로젝트를 들어가기에 앞서, Git Flow로 정리해보려고 한다. 🧐

1. 원래의 Repository(repo)를 fork하기

☝️이때, 포크(fork)는 원격 저장소를 자신의 계정으로 복제하는 방법을 의미한다.

• Why? 내가 소유하지 않은 원격 저장소(원래의 repo)에 직접 푸시할 수 없지만, 나의 계정으로 포크(복제)한 원격 저장소에는 푸시할 수 있다.

그러면 소유하지 않은 원격 저장소(=원래의 repo)에는 어떻게 푸시할까?
➡️ 포크한 자신의 원격 저장소에서 Pull Request를 보내고 원래의 Repo에서 Merge를 하면 자신의 코드가 push된다.
(해당 내용은 Pull Request에서 더 자세히 다룬다!!)

직접 fork를 해보자!

1️⃣ 자신이 포크하고 싶은 Repository에 들어가서 오른쪽 상단에 있는 fork를 누르면 아래의 사진처럼 + Create a new fork를 볼 수 있는데, 이 버튼을 누르면 된다.

2️⃣ 그러면 아래와 같이 fork와 관련된 세부사항을 누를 수 있는 창이 나오는다.

• 자신이 원하는 Repository name과 Description을 입력할 수 있다.
  

3️⃣ 최종적으로 자신의 계정에 fork한 Repository를 볼 수 있다.

2. fork한 저장소를 내 PC로 clone하기

☝️ 이때, 클론(clone)은 원격 저장소를 복제하는 것이다.

• 깃허브상에 존재하는 원격 저장소를 나의 컴퓨터(로컬)로 복사하여 가져오는 방법이다.

1️⃣ 나의 PC 터미널에 다음의 명령어를 입력한다.

$ git clone [fork한 repo의 url]

2️⃣ 해당 명령어를 입력하고 나면, 아래와 같이 자신의 PC에서 fork한 저장소와 동일한 파일들을 확인할 수 있다.

3. clone한 저장소에서 remote 추가하기

☝️ git remote : 원격 저장소를 관리할 수 있는 명령어이다.

• Why? 원격 저장소를 관리할 수 있는 명령어를 입력해 놓으면, 원하는 원격 저장소의 url을 입력하지 않고 원하는 이름으로 쉽게 push하고 pull을 할 수 있다.

1️⃣ 원격 저장소와 연결하기 : git remote add [name][url] 옵션

$ git remote add origin [원격 저장소 url]

• origin이라는 이름으로 원격 저장소 주소를 등록한다.
  origin 이름을 사용하면, 방금 전에 만든 저장소에 접속할 수 있다.
  (git push origin 처럼 쉽게 push하거나 pull할 때 사용할 수 있다.)

2️⃣ 현재 연결되어 있는 원격 repository 목록을 확인할 수 있다.

• 이때, 해당 폴더(프로젝트)에게만 git remote 명령어를 사용했으므로 다른 폴더(프로젝트)에서는 관련 내용은 적용되지 않는다.
  (다른 프로젝트에도 git remote 명령어로 적용해줘야 한다.)

$ git remote -v

📚 참고 자료 : https://www.zerocho.com/category/Git/post/581042fdcae2d100152ceae6

4. 원형 Repository에서 변경된 내용 가져오기(Pull)

• Why? 원래의 Repository에 여러 사람들이 코드 작업을 하고 나서 변경사항이 발생할 수 있다. 따라서 코드 작업을 하기 전에는 pull을 하여 나의 local에 변동 사항을 반영해준다.

1️⃣ git pull [원형 Repository 이름][나의 local branch]

• 이때, 위에서 수행한 clone한 저장소에서 remote 추가하기를 참고하여 원형 Repository을 upstream 이름으로 저장해놓는다.

ex) git pull upstream develop

5. 기능 작업 전 이슈 생성 및 feature 브런치 생성하기

☝️ 기능 구현하기 전에는 반드시 이슈 발급하고, feature 브런치 생성할 때는 해당 이슈번호 연결해서 만든다.
(이때, 브런치를 만드는 방법은 다양하므로 해당 방법은 참고만 하면 된다!!)

Why? 협업을 할 때에 맡은 작업을 이슈로 작성해놓아서, 다른 사람들이 볼때 해당 작업의 진행 상황과 완료 여부 등을 확인할 수 있다.
+) Branch를 생성할 때에도 이슈번호를 작성해 놓으면, 더 자세하게 해당 Branch의 역할을 구분할 수 있다.

1️⃣ GitHub에 발생할 이슈들을 분류할 수 있는 label들을 만들어 놓는다.

• 아래의 예시에 경우에는 핫픽스 , 개선 작업, 수정 등 총 8가지의 label로 만들어 놓았다.
  

2️⃣ 이슈를 발급한다.

• 아래와 같이 Issues 카테코리를 들어가보면 New issue를 누르고 새로운 issue를 만들 수 있다,
  
• 아래의 사진에서 오른쪽 부분에 Labels로 만들어 놓은 label들을 적용할 수 있다.
• 그리고 원하는 이슈와 글을 작성하여 issue를 생성하면 이슈의 제목 옆에 #1과 같이 이슈 번호가 자동으로 생성된다.
  

5-2. 원래의 Repo에 브런치 생성하기

브랜치 종류

• main : 배포용 브랜치
• develop : 기능을 합하는 브랜치
• feature : 각자 기능을 개발하는 브랜치
  • feature-#이슈번호
  • ex) feature-#6
• hotfix : 출시 버전에서 발생한 버그를 수정 하는 브랜치

ex ) 브런치 이름 : feature/기능이름-#6

5-3. Git 협업 규칙

git-repo 관련

브런치는 4개로 나뉘었으니, 일단 근본적으로 develop에 개발한 것들을 합친다고 생각한다.
각자 develop에서 fork하여 개인 repo를 구성한다.

6. 기능을 완성할 때까지 commit과 push 반복하기

1) clone한 repository(local)에 commit한다.
2) local에서 origin으로 push한다.

• 작업 다 끝내고 커밋 다 했으면 터미널에 git push origin develop을 입력한다.
• push 전에 버그 확인한다.

6-1. IntelliJ에서 작업하기

• 코드를 작성한다.
  

6-2. Commit을 작성하기

커밋 규칙

• 어떤 내용의 커밋을 했는 지 → feat, fix
  Git | git 커밋 컨벤션 설정하기
  

• 내용 → 어떤 식으로 해결했는 지..

fix : 제목

설명

7. Pull Request 보내기

• PR 할 때는 develop 브런치에 한다.
• 깃허브에서 내가 개발한 feature에 pr 날리기
• pr 하기 전에 로컬에서 실행해서 오류나 버그 없는지를 반드시 확인해야 한다.

7-1. PR 템플릿

• 개요 → 어떤 문제를 얘기했는 지..
• 작업사항 → 어떻게 수정했는 지, 어떤 파일을 보면 되는지 → 중점적으로
• 변경로직 ( 옵션 )
  

8. Merge하기

• origin에서 원래의 Repo에 Pull Request를 보낸 후 Merge를 한다.
• Merge를 하면, upstream에 적용이 되었으므로 작업한 브랜치를 원래의 Repo와 origin, local에서 삭제한다.

9. 다시 1번부터 진행하기

• 다시 작업할때 작업 브랜치를 생성하여 그곳에서 작업한 후, 1번부터 다시 진행하면 된다.