[Git & Github] 14. Git 협업 워크플로우

Critical

• 중앙 집중형(단일 브랜치) 작업의 문제
• 피처 브랜치의 워크플로우
• 풀 리퀘스트(Pull Requests, PR)
• 포크(Forks)
• 포크와 클론의 워크플로우

 

Important

• 브랜치 보호 규칙

 

중앙 집중형 워크 플로우 에서는 모든 사람이 단일(주로 main) 브랜치에서 작업한다.

원격 및 로컬 저장소에서 단일 브랜치를 사용한다면 협업에 큰 문제가 생길 수 있다.

 

예를 들어서 미완성된 작업물에 대해 도움을 받기 위해 공유를 위해서 푸시를 하게 되면 브랜치가 하나밖에 존재하지 않기 때문에 미완성된 작업물 그대로 브랜치에 커밋이 되어버린다. 이렇게 되면 모두가 미완성된 작업물을 가지게 되므로 아주 큰 문제가 발생한다.

 

브랜치가 단일로 존재하기 때문에 어느 누구도 기본 코드를 건드리지 않고서는 작업할 수가 없다.

게다가 커밋 충돌이 너무 자주 일어나기 때문에 시간의 낭비도 심해진다.

 

---

 

위와 같은 문제는 피처 브랜치를 사용함으로써 해결할 수 있다. 각자의 작업을 종류나 중요도에 관계 없이 개별 브랜치에서 수행하면 된다.

 

미완성된 작업을 푸시하더라도 브랜치가 다르기때문에 main 브랜치에 영향을 주지 않고 해당 작업을 받아서 협업하는 쪽도 페칭을 하기 때문에 main 브랜치나 자신이 작업중인 브랜치에 전혀 영향을 미치지 않는다.

 

 

일반적으로 main 브랜치는 언제나 배포가능한 상태로 유지한다.

 

 

* 풀 리퀘스트(Pull Requests, PR)

피처 브랜치에서 작업한 내용은 언젠가는 누군가에 의해 main 브랜치로 병합이 될 것이다.

다만 여기서 누구나 main 브랜치에 푸시 및 병합을 하게 된다면 문제가 발생하기 때문에 작업물 검토를 요청해서 병합을 승인하거나 반려해달라고 할 수 있다.

 

movie 브랜치의 병합을 요청한다

브랜치를 병합할 때, 빨리 감기 또는 충돌에 의한 병합 커밋이 만들어 지는것을 알고있다.

PR 역시 병합이기 때문에 충돌 발생시 처리를 해주어야 한다.

파일이나 수정사항이 몇개 되지 않는다면 깃허브의 웹상에서 처리할 수 있지만 작업량이 많다면 깃허브에서 처리하는것은 불편하므로 로컬에서 처리하는것이 편할것이다.

 

기본적인 처리 과정은 로컬에서 빨리 감기 여부와 관계 없이 병합 커밋을 만들어서 main 브랜치에 푸시하는 것이다.

 

추가로 PR은 깃의 기능이 아니라 깃허브같은 원격 저장소의 기능이다.

 

* 브랜치 보호 규칙 설정

main 브랜치같이 엄격하게 관리되어야 하는 브랜치에 규칙을 설정하여 엄격하게 관리할 수 있다.

 

 

* Fork란?

다른 원격 저장소를 나의 원격 저장소로 복사한다.

클론이 원격 저장소를 나의 로컬 저장소에 복사하는 것이라면 포크는 원격 저장소를 나의 원격 저장소에 복사하는 것이다. 둘의 차이는 클론은 공동 작업자로 등록되지 않는이상 푸시 권한이 없다는 것이지만 포크는 나의 원격 저장소이기 때문에 권한이 있다.

 

마치 로컬-원격의 관계처럼 원격-원격 관계가 성립한다. 정확히는 로컬-원격-원격일 것이다.

그렇기 때문에 포크해온 나의 원격 저장소에 변경된 작업을 푸시하고 해당 브랜치를 원래 프로젝트에 PR할 수도 있다.

 

기본적으로 원격 저장소에 참여해서 푸시할 권한을 가지려면 공동 작업자로 등록하는 절차가 반드시 필요하다.

하지만 규모가 매우 큰 오픈 프로젝트의 경우라면 매번 공동 작업자로 등록하는 절차가 번거로울것이다. 이 때 원격 저장소를 포크해서 변경사항을 PR한다면 기여자로써 등록이 된다.

 

Fork 역시 PR과 마찬가지로 깃의 기능이 아니다.