Git 협업
Github으로 협업하는 이유와 방법
왜 git으로 협업해야 하는가?
1. 소스코드, 프로젝트의 공유가 편리하다. Git은 분산형 버전 관리 시스템으로 코드 뿐만 아니라 코드의 변경 내역까지 모두 가져올 수 있다.
- 포트폴리오 관리에 용이하다.
Forking Workflow
-
모든 프로젝트 참여자가 개인 로컬 저장소와 공개된 자신의 원격 저장소(중앙 원격 저장소를 fork한 것), 이 두개의 저장소를 가지고 협업을 진행하는 방식이다.
-
모든 코드 기여자가 중앙 저장소에 푸시하는 것이 아니라, 각자 자신의 원격 저장소에 푸시하고 이 내용을 중앙 원격 저장소에 Pull Request 한다. 그리고 프로젝트 관리자(Owner)가 다른 개발자들의 기여분(PR)을 중앙 원격 저장소에 병합할지 안할지 결정하는 것이 특징이다.
-
오픈소스 프로젝트에 많이 사용하는 방식
-
다른 방식들 참고
https://devlog-h.tistory.com/6
중앙 원격 저장소, 자신의 원격 저장소, 로컬 저장소 개념
- 중앙 원격 저장소 : 여러 명이 같은 프로젝트를 관리하는 데 사용되는 그룹 계정(Organization)의 중립된 원격 저장소
- 자신의 원격 저장소 : remote repository, 내 깃허브의 repository
- 로컬 저장소 : local repository, 내 PC에 저장되는 개인 전용 저장소
forking workflow 협업의 큰 틀
- 프로젝트 repository를 fork해 개인 github에 복사한다
- 각자의 로컬 환경에서 개발한 내용을 upstream에 pr한다.
- 리뷰를 통해 최종 수정된 pr은 upstream에 merge한다.
- 변경된 upstream의 내용을 pull 명령어로 로컬에 반영한다.
- 2번~4번을 반복한다
프로젝트 가져오기
- 중앙 원격 저장소인 프로젝트 repository 개설 후 중앙 원격 저장소를 fork해 자신만의 개인 원격 저장소를 만든다.
- 중앙 원격 저장소를 나의 깃허브 계정 저장소에 복제한다는 개념.
- 자신의 깃허브 계정에 중앙 원격 저장소와 똑같은 내용의 저장소가 복제된다.
- 개인 공개 저장소로 저장되므로 중앙 원격 저장소와 독립적으로 운영된다.
- 프로젝트 참여자는 git clone 명령으로 로컬 저장소를 만든다.(최초 1회)
git clone [fork해 온 개인 원격 저장소 https url]
- 중앙 원격 저장소와의 연결을 위해 프로젝트에 upstream을 설정한다.
git remote add upstream [중앙 원격 저장소 레포의 https url]
- 깃허브 저장소에 push 하거나 pull 할때 매번 url를 작성하기 번거롭기 때문에 각 url에 이름을 붙여줄 수 있다.
- 아무렇게나 이름을 붙여도 상관업지만, 일반적으로 자신의 원격 저장소는 origin, 프로젝트 중앙 원격 저장소는 upstream으로 이름 붙인다.
- Origin : Fork를 통해 복사해 내 github에 생성된 repository, 즉 나의 작업 내용을 push하는 공간
- Upstream : 가장 근본이 되는 repository. 오류가 없는 최종적인 코드가 저장되는 공간
- 브랜치를 생성한다.
- 새로운 기능 개발을 위해, main 브랜치와 격리된 새로운 branch를 만들어야한다.
- 구현할 기능 이름으로 브랜치 이름을 짓는다. (ex. map branch, weapon branch . . .)
- 주의! 반드시 main 브랜치에서 브랜치를 생성해야 한다!
- 브랜치란?
- 여러 명이서 동시 작업을 할 때, 다른 사람의 작업에 영향을 주거나 받지 않도록 하는 자신의 독립적인 작업 단위
- 브랜치로 그 작업의 기록을 중간중간에 남기게 되므로 문제가 발생했을 경우, 원인이 되는 작업을 찾아내거나 그에 따른 대책을 세우기 쉬워진다.
git branch [branch name] // 새로운 브랜치 생성
git checkout [branch name] // 해당 프랜치로 작업 위치 이동
git checkout -b [branch name] // 위 두 명령어를 합한 것
git branch -d [branch name] //브랜치 삭제
git branch // 전체 브랜치 조회
- 여기서 origin의 main branch는 오류없이 정상작동하는 마지막으로 pull한 code
- origin의 새로 생성한 branch는 문제 발생 시 삭제해도 괜찮은 branch로 현재 작업중인 코드가 있는 branch이다.
- 로컬 저장소에서 커밋한 이력을 자신의 원격 저장소로 push 한다.
- 기능 구현을 마친 후 커밋한 내용을 푸시 할 때는 복제(clone)했던 자신의 원격 저장소로 푸시한다.
- 푸시하고 나면 나의 원격 저장소에도 똑같은 브랜치가 생긴다.
// 자신이 변경, 추가한 모든 파일을 스테이징 영역(커밋 준비 상태)에 추가
git add .
// add 한 파일들을 커밋한다.
git commit -m "커밋 메세지"
// [branch name]에 해당하는 브랜치를 자신의 원격 저장소에 push
git push origin [branch name]
- commit rule
- 유의미한 Commit message 작성하기
- Commit message를 통해 작업 내용을 쉽게 유추할 수 있도록 작성하는 것이 중요하다.
- 팀별로 규칙을 생성하는 방법도 추천!
- 보통은 Angular JS Git Commit Message Conventions Document 를 따른다
feat : 새로운 기능
fix : 버그 수정
build : 빌드 관련 파일 수정
chore : 그 외 자잘한 수정
ci : CI 관련 설정 수정
docs : 문서 수정
style : 코드 스타일 혹은 포맷 등
refactor : 코드 리팩토링
test : 테스트 코드 수정
- 작업한 내용 올리기
-
내가 만든 기능을 중앙 원격 저장소에 반영하기 위해선, 프로젝트 관리자에게 반영 요청(pull request)해야 한다.
-
나의 원격저장소 깃허브 페이지에서 구현한 기능의 브랜치를 선택해 pull request 버튼을 눌러 요청한다.
- Github에서 origin 혹은 upstream repository 접속
- 초록색의 compare & pull request 버튼을 눌러 pr 작성
- Git add, commit, push가 정상적으로 완료된 상태라면 버튼이 활성화 된다.
-
PR 작성법
- 제목에 작업 내용 간단히 요약 후 내용에 작성한 부분에 대한 자세한 설명한다. 또한 Pr에 해당하는 label이나 issue 추가한다.
- Pr에 수정사항이 생긴 경우, 로컬에서 작업하던 브랜치에서 이어서 수정한다.
- 수정한 작업 내용을 그대로 git add, commit, push 하면 pr에 자동으로 해당 커밋이 올라간다.
-
PR 리뷰하기
- 프로젝트 관리자는 변경 내용을 확인한 후 중앙 원격 코드에 병합(merge)한다.
- 모든 팀원이 변경한 코드 내용을 확인하고 프로젝트 관리자는 병합(merge)를 진행한다.
- Pr을 받은 중앙 원격 저장소 관리자는 변경 내용을 확인한 후 중앙 원격 코드 베이스에 병합(merge)여부를 결정한다.
- 충돌이 일어날 수 있으니 꼼꼼히 확인 후 merge해 main에 코드를 반영해야한다.
- 병합에 성공하면 중앙 원격 저장소의 main branch에 해당 내용이 갱신된다.
- merge한 branch는 delete branch를 해주는 것이 관리에 좋다.
- 중앙 원격 저장소와 자신의 로컬 저장소를 동기화해 최신화시킨다
- 중앙 코드 베이스가 변경되었으므로, 자신의 로컬 저장소를 동기화 해서 최신상태로 만들어야한다.
- 최신상태로 만들기 이전에 로컬 저장소 작업 위치를 main 브랜치로 이동해야한다.
- 주의! 반드시 master 브랜치로 이동 한 후 새로운 내용(중앙 원격 저장소 변경 내용)을 받아와야 한다.
git checkout main
git pull [pr올린 팀원 repository https url][팀원의 작업 branch 이름]
- 중앙 원격 저장소의 코드 베이스에 새로운 커밋이 있다면 로컬 저장소에 갱신한다.
- 중앙 코드 베이스가 변경되었으므로, 모든 프로젝트 팀원은 자신의 로컬 저장소를 동기화 해서 최신상태로 만들어야한다.
- 아래의 명령어를 이용해 최신 상태로 동기화 한다.
git pull upstream main
최종정리
git clone [fork해 온 내 깃허브 레포의 https url]
git checkout -b [branch name] // 새로운 브랜치 생성 후 해당 브랜치로작업 위치 이동
git branch -d [branch name] //브랜치 삭제
git add .
git commit -m "커밋 메세지"
git push origin [branch name]
git checkout main
git pull upstream main
협업을 위한 꿀팁!
- Issue를 등록해 작업 목록을 정리하자.
Pr 라벨을 추가해 작업 유형을 나타내자.
- 커밋 단위는 세세하게 나누어 혹시 모를 문제 상황에 대비하자.
- 구글 드라이브, 슬랙, 디스코드, 트렐로, 노션 등 협업 툴을 사용하자!
우리 팀만의 협업 룰을 정하자
reference
GitHub] GitHub로 협업하는 방법[2] - Forking Workflow
Git으로 협업하기! - forking workflow에서 git flow로 변경한 이유
알아서 잘 딱 깔끔하고 센스있게 정리하는 GitHub 핵심 개념