Github으로 협업하기 (Collaborators)

프로젝트를 공유하고 협업하기

본인이 만든 레포지토리에 다른 깃헙 유저를 초대하여 본인의 레포지토리에 수정 권한을 주고, 함께 기능을 구현하는 협업 방법입니다.
이를 위해 레포지토리의 settings-collaborator 항목에 들어가 유저를 초대합니다.

collaborators와 협업 시 업무 세부 순서는 아래와 같습니다.

1. 초대받은 유저는 프로젝트 레포지토리를 git clone 합니다.
2. 팀장이 issues란에 To do list를 정리해 뒀다면 담당 업무를 확인합니다.
3. git checkout -b 브랜치이름을 통해 브랜치를 생성합니다.
   • 브랜치명은 영어로 작성하시되 컨벤션을 지켜주세요. (작업형태/내용)
   • ex) 상세페이지 기능구현 시 feat/detail_page_html와 같은 형태로 지어주세요.
4. 생성한 브랜치에 머무르는 상태에서 git pull origin main을 입력해서 최신 데이터를 가져옵니다.
5. 기능 구현 시작 (반드시 주어진 업무 만큼만 구현합니다.)
6. git add . 을 입력하여 작업 내용을 스테이지에 올립니다.
7. git commit을 입력하여 커밋 메시지를 작성합니다. (하단의 컨벤션 참조)
   • 커밋 작성 예시는 아래와 같습니다.

feat: 상세 페이지 html, css 틀 구현
(한 줄 띄우고)
상세페이지 기능 구현 완료하였습니다. 코드 확인 부탁드립니다.

8. git push origin 브랜치이름을 통해 push 합니다.
9. git clone했던 레퍼지토리 사이트로 이동합니다.
10. 정상적으로 push가 완료되었다면 아래와 같은 그림이 떠야 합니다.

11. Create pull request를 클릭하여 PR을 생성합니다.
12. 만약 아래와 같이 Conflict가 발생했다면 해결이 필요합니다.

Conflict는 이래야 발생하지 않습니다.
내가 git clone 또는 git pull 한 시점 이후로 레포지토리의 코드가 변경된 경우, 그런데 그 변경된 파일이 지금 내가 수정한 파일인 경우

13. confilict까지 해결이 되었다면 다른 팀원들에게 코드리뷰를 받고, 수정사항이 있다면 수정합니다.

• pull request는 각 업무당 최초에 한 번 생성합니다. 코드 수정 시에는 git push origin 브랜치이름만 해도 됩니다.

14. 다른 프로젝트 팀원의 승인(Approval)을 받으면 main 브랜치에 코드를 등록합니다. (owner가 정한 최소 승인 개수를 초과해야 merge가 가능합니다.)
15. 이제 main 브랜치의 코드가 변동되었기 때문에 다른 작업자들은 각자의 브랜치에서 git pull origin main을 또 진행해야 합니다. 이 과정에서 conflict가 발생할 수 있으며 이 또한 팀원과의 소통을 통해 해결해가야 합니다.
16. issues에 등록된 본인의 업무를 완수했다면 새로운 업무를 시작합니다. 그리고 기능 구현을 마무리할 때 마다 위 작업을 반복합니다.

기억해야할 핵심 정리
- branch를 만드는 이유는 기능 구현을 issue나 기능 단위로 쪼개어 작업하고 프로젝트 기록에 남기기 위함입니다. 여러 작업을 한꺼번에 하고서 git commit을 하면 프로젝트 진행 사항을 파악하기 어려워 집니다.
- PR을 하는 이유는 내가 작성한 코드를 서로 리뷰하는 커뮤니케이션의 장을 열기 위함입니다.

Git 컨벤션 참고

태그명	설명
feat	새로운 기능 추가
fix	버그 수정
refactor	리팩토링
style	스타일 (코드 형식, 세미콜론 추가: 비즈니스 로직에 변경 없음)
docs	문서 (문서 추가, 수정, 삭제)
test	테스트 (테스트 코드 추가, 수정, 삭제: 비즈니스 로직에 변경 없음)
chore	기타 변경사항 (빌드 스크립트 수정 등)