[github 내 프로필 id]/fork파일이름
주소로 새로운 파일이 내 깃헙으로 들어온다!실제로 내가 이 유명한 페이지인 https://github.com/apache/hadoop를 포크 떠서 내 레포에 옮겨보니,
이렇게 새롭게 github이 생겨있다.
이 사진에서의 빨간색 박스의 주소를 복사해서 기존 clone 과정과 동일하게 진행하여
로컬에 클론한 후, 수정작업을 진행하면 된다.
작업 진행 후, add - commit - push 과정을 거치면, 해당 수정에 대해서
fork를 딴 원 출처인 Main Repository와 fork를 따온 개인 repository에 모두 PR 메시지가 뜬다.
그리고 PR을 날리면 해당 PR은
fork를 딴 원 출처인 Main Repository에 올라가고, Merge 할 수 있는 상태가 된다.
이 때 merge를 하면 Main Repository의 master에 합쳐지게 되는 것.
이번 2차 프로젝트에서 교훈을 얻은대로
꼭! 브랜치를 따서 작업하자
우선 지금부터 작업해본다.
<1차 수정>
작업 결과
1. git fork를 따고 clone받아 작업한 후, 다시 add - commit - push 하는 것은 전혀 어렵지 않다.
2. 단 나의 궁금증에서는 이 방법이 그렇게 시원한 방법은 아니었다.나의 궁금증: 나와 팀원이 함께 작업한 프로젝트에 대해(해당 작업물 내에서 둘이 공동작업한 브랜치는 없었음) 본인 작업만 수정하는 것이 아닌, 팀원의 작업도 수정하고 싶다. 팀원도 만일 내 작업물에 대해 수정하고 싶다고 가정하자. 이런 상황일 때 git fork를 따서 작업을 한다면 둘의 충돌이 없는 것인지?
--> 있다. git fork를 따서 로컬에서 작업한다고 해도 push 이후 pr은 둘의 공동 작업 repository로 올라간다. 이 때, merge를 할 경우 공동 작업 repository의 master branch(==base branch)로 합쳐지게 된다. 그럼 결국 팀원과 내가 함께 만든 master branch의 내용이 바뀌게 되는 것. 근데 만일, 둘이 공통된 부분을 수정한다고 가정하면(그것이 원래 팀원의 작업물이든 나의 작업물이든) 첫 머지를 하는 사람은 문제가 없을 것이다. 다만 두번째로 머지하는 사람은 엄청난 conflict을 만나게 될 것이다. 문제는 여기서 끝나지 않는다. conflict을 어찌저찌 해결하더라도, 2차 머지한 사람의 코드로 master branch가 바뀔 경우, 다른 코드가 오작동할 수 있다. 그런 위험 요소가 있는 작업이므로 아무리 fork를 떠서 작업한다해도 둘이 만일 동일한 부분을 수정할 경우, merge는 신중하게(상의 하에) 하는 것이 좋다. 혹은, 같은 부분을 수정하고 싶다면 수정 전에 팀원 간의 선 상의가 필요하다.
references:
https://medium.com/@tharis63/git-fork-vs-git-clone-8aad0c0e38c0