현재 진행중인 프로젝트 코드 관리를 github에서 하고있는데, 협업 방법으로 issue를 사용하고 있다. 지금까지는 fork를 통해 협업을 했는데, 지금 사용하는 방법도 편한 것 같아서 이를 기억하고 나중에 또 쓰기 위해서 기록을 한다.

개발 시작

1. Origin Repository의 default branch(현재 dev)에서 issue를 생성합니다.

2. issue template 작성 후, Origin Repository의 dev branch에서 새로운 branch을 생성합니다.(issue생성 후 우측 하래에서 Create a Branch 를 눌러 생성할 수 있습니다.)

   • 브랜치 이름은 다음 규칙을 따릅니다.
     • 새로운 기능 개발 : feature/#[Issue의 번호]
       • ex) feature/#2 (← 이게 브랜치 이름입니다.)
     • 버그 픽스 : fix/#[Issue의 번호]
     • 기능 리팩토링 : refactor/#[Issue의 번호]

3. (IDE에서)Local에서 fetch를 통해 새로운 브랜치 정보를 들고옵니다

   git fetch origin

4. 해당 branch로 checkout 후 예정된 개발을 진행합니다.

   git checkout feature/#2
   (브랜치 명은 예시입니다.)

개발 종료

1. 예정된 개발 완료 후 Origin Repository의 branch로 변경 사항을 push합니다.(이때, 절대 dev branch로 바로 보내는 것이 아닌, 본인이 생성한 branch로 push합니다.)

   git push origin feature/#2
   (브랜치 명은 예시입니다.)

2. Push가 완료되면, dev branch에서 Compare & Pull Request 버튼을 눌러 PR을 작성합니다.

3. 작성 시, PR의 이름은 본인이 수정한 내용을 알아볼 수 있는 제목을 짓습니다. PR이름에 #number을 쓰지 않습니다.

4. 템플릿에서, 관련 이슈(Resolves)를 작성하는 란에 # 을 입력하면 issue를 불러올 수 있습니다.

5. Code Review 이후, 마지막 reviewer가 dev 브랜치로 Squash And Merge를 합니다.

6. PR을 정상적으로 마친 후, Local에서는 dev branch로 checkout 합니다.

   git checkout dev

7. Local에서 현재(origin) repository의 dev branch의 내용을 pull 받습니다.

   git pull origin dev

Squash And Merge ?

여러 커밋을 하나의 커밋으로 합쳐서 메인 브랜치에 병합하는 방법이다. 이를 통해 복잡한 커밋 히스토리를 단순화하고, 작업 단위를 명확히 하며, 브랜치 히스토리를 깔끔하게 유지할 수 있다. 코드 리뷰 후 PR을 승인할 때 사용되며, 특히 대규모 프로젝트에서 효율적인 히스토리 관리를 위해 유용하다.

위 작업방식대로
issue -> code change -> pull request -> code review -> squash and merge
순서로 작업하면, repository의 커밋 기록이 issue별로 나뉘어 깔끔하게 정리된다!