[Git] 분산 환경에서의 Git - 프로젝트에 기여하기

프로젝트 기여 방식에 영향을 끼치는 변수들

• 활발히 기여하는 개발자의 수
• 선택한 워크플로 종류
• 개발자 접근 권한 부여 방식
• 외부에서 기여 가능 여부

---

커밋 가이드라인

 

1. 공백문자를 정리하고 커밋하라

git diff --check

• working directory와 staging area와 비교

git diff --check HEAD

• 특정 커밋을 언급할 경우, 그 커밋과 stating area와 비교

 

2. 논리적으로 구분되는 변경사항

• 수정사항을 한 주제로 요약할 수 있어야 한다.
• 여러 이슈의 수정을 한 커밋에 담지 않아야 한다.
• 한 파일의 다른 부분을 수정하는 경우

git add -patch(-p)

 

3. 커밋 메시지 자체

• 50자가 넘지 않는 간략한 메시지로 해당 커밋 요약
• 한 라인 비우고 자세한 설명 시작

---

비공개 소규모 팀

• 소스코드가 외부에서 접근할 수 없는 경우
• 모든 개발자는 공유 저장소에 쓰기 권한이 있다

pull = fetch + merge

• 2개의 커밋이 공통이고, 내가 하나의 커밋을 로컬에서 만들고 다른 사람이 새로운 커밋을 원격 저장소에 올린 경우

fetch를 하게 되면 원격 저장소에 있는 커밋과 원격저장소의 master브랜치가 넘어온다.

 

여기서 HEAD가 master를 가리키고있다면

git merge origin/master

이렇게 된다.

 

이 변경사항을 다시 원격 저장소(origin)에 올린다.

git push origin master

 

그러고 나면 origin의 master 브랜치도 업데이트 된다.

---

비공개 대규모 팀

비공개 저장소를 사용하지만 규모가 커서 동시에 여러 기능을 개발하는 경우

 

• 저장소는 비공개 저장소 하나만 사용
• 모든 작업자가 비공개 저장소에 push 권한이 있음

사용법

1. 각 팀원은 기능별로 브랜치를 파서 로컬에서 작업한다
2. 작업이 완료되면 그 브랜치를 비공개 저장소로 Push한다
3. Integration-manager는 그 브랜치를 로컬로 가져와 테스트를 한다
4. 테스트에 이상이 없으면 로컬에서 master 브랜치에 merge하고 master 브랜치를 비공개 저장소의 master에 push한다

---

공개 프로젝트 fork

공개되어 있는 공식 저장소가 있고, 개발자들이 이 저장소에 push 권한이 없는 경우

-> 각 개발자들은 공식 저장소를 fork한 뒤, fork 해온 저장소에 작업 결과를 push한다. 이를 관리자에게 PR을 보낸다.

 

Fork

• 쓰기 권한이 없는 저장소(공식 저장소)를 Fork하면 같은 내용의 쓰기 권한이 있는 저장소가 생성됨
• 이후 쓰기 권한이 있는 저장소에 작업 결과를 push함

Pull Request

• Fork해온 개인 저장소에서의 변경사항을 원본 저장소의 관리자에게 Pull 할 것을 요청하는 것

유의사항

• Fork해온 저장소를 로컬에서 작업할 때 master가 아닌 토픽 브랜치를 파서 작업하는 것이 좋다
• 이렇게 하면 작업을 쉽게 버리거나 선택할 수 있다
• 새롭게 토픽 브랜치를 팔 때는 최신 master 브랜치에서 시작하는 것이 좋다

* 본 포스트는 ProGit(https://git-scm.com/book/en/v2)의 내용을 바탕으로 작성되었습니다.