[Git] Fork

1. 정의

fork는 오리지널 리포지토리에 있는 내용을 그대로 다른 계정의 리포지토리에 별도 복사하는 것을 의미한다.

 

 

 

2. 사용방식

기존과 달리 한 리포지토리에서의 변경사항에 따라 그대로 push 할 수 없는 특성을 가지기 때문에 별도의 과정을 거쳐야 한다. 

 

 

2-1. clone

리포지토리에서 로컬로 가져오는 방식은 기존과 같다. 다만 그 내용이 복사한 리포지토리라는 점에 차이가 있다.

 

 

2-2. commit / push

변경사항에 따라 리포지토리로 commit과 push를 하게 되면 복사했던 리포지토리에 반영된다. 이 후 만약 오리지널 리포지토리로 자기가 변경한 사항들을 반영하고자 한다면 다음 과정을 거친다.

 

 

2-3. pull-request / merge

fork를 한 다른 개발자는 오리지널 리포지토리로 pull-request를 통해 변경사항을 요청할 수 있는데 오리지널 측에선 이를 수락하여 원본에 반영(merge), 혹은 거절할 수 있다.

 

 

2-4. fork 리포지토리 업데이트

출처(https://velog.io/@k904808/Fork-%ED%95%9C-Repository-%EC%97%85%EB%8D%B0%EC%9D%B4%ED%8A%B8-%ED%95%98%EA%B8%B0)

merge되어 최신화 된 오리지널 리포지토리를 가져와 fork 리포지토리를 업데이트를 할 경우 리모트 저장소에 원본 저장소를 추가한 뒤 fetch 및 merge 과정을 거쳐 포크 저장소로 push한다.

 

 

 

3. 기대효과

- 형상관리를 하는데에 있어서 한 리포지토리 내에 이루어지는 것이 아닌 독립된 리포지토리로 분산하는 구조이기 때문에 변경사항과 기능추가에 대한 개발 부담이 상대적으로 적다.

- 해당 리포지토리를 public 형태로 공개하는 경우 누구든지 fork를 하여 폭넓게 오픈소스를 지속적으로 개발할 수 있는 개방성이 있다.(fork 기능의 의의)

- 최종적으로 merge 하는 곳은 오리지널 리포지토리이고 컨플릭트 발생시 이를 전담하여 관리할 수 있어 원하는 방향대로 변경사항들을 관리할 수 있다.

 

 

 

4. 단점(개인경험 기반)

- fork 하는 것도 결국엔 컨플릭트가 생기므로 형상 관리를 하는데에 있어서 관련 규칙 설정이 필요하다. (모든 팀원의 풀 리퀘스트를 수락하여 오리지널 리포지토리에 제대로 반영하기 전 까진 포크한 리포지토리 업데이트를 금지하는 등...)

- 팀 단위의 경우 사전에 계획했던 개발 방향 및 코드작성 규칙대로 진행할 수 있지만, 누구나 이용하는 public 형태의 경우 외부 인원에 의해 다른 방향으로 코드가 변경될 수 있는 우려가 있다.