사람들이 GitHub에서 리포지토리를 포크하는 이유는 무엇입니까? [닫은]


110

많은 GitHub 계정에 다른 계정에서 분기 된 저장소 만있는 것으로 나타났습니다 . 또한이 작업을 수행하는 사람들은 일반적으로 분기 저장소에 기여하지 않습니다.

사람들이 우표와 조개를 수집한다고 들었는데 왜 리포지토리를 수집하려고합니까? 개인적으로 저장소를 변경하려는 경우에만 저장소를 포크합니다.


84
그들은 프로젝트 소유자가 자신의 저장소를 삭제하고 사라질 경우 안정적인 백업을 유지하기를 원합니다.
ratchet freak

9
그것이 바로 GitHub에서 풀 요청이 작동하는 방식 때문입니다 (사람들이 약간 포크 행복하고 때로는 잊어 버리거나 프로젝트 아이디어를 버리고 포크를 제거하는 것을 잊었 기 때문에)
haylem

2
코드의 "백업"으로 사용하는 것으로 이해하지만 리포지토리를 업데이트하는 것이 올바른 포크 (백업을 위해)해야 할 때 저장소를 업데이트해도 "포크"에 영향을 미치지 않는다는 것을 잊거나 알지 못합니다. "리 포크 (re-fork)"를 수행 할시기를 알아야하는 저장소 "스타 (Star)", 즉 "포크"는 "스타"와 거의 같은 것으로 생각하고 오래된 코드를 알지 못한다.
Guilherme Nascimento

1
그들은 Github을 갖는 것이 핫 스타트 업에 고용되기에 충분하다고 들었 기 때문입니다.
Gaius

1
다음은 이유가없는 포크의 손상에 관한 게시물입니다. zbowling.github.io/blog/2011/11/25/github
gavenkoa

답변:


69

우리의 업무 라인에서 우리는 기술적 이유를 찾는 경향이 있지만, 제 생각에는 주된 이유는 기술적이지 않습니다. GitHub 도움말 이나 다른 GitHub 튜토리얼 을 살펴보면 리포지토리 포크는 GitHub를 "실행"하는 주요 단계 중 하나입니다.

사람들이 GitHub를 배우고 평가할 때, 거의 모든 튜토리얼이 학습 과정의 일부로 레포를 포크하도록 지시 할 것입니다. GitHub의 주요 목적은 기여하는 것이므로 표준 자습서를 통해 작업하는 많은 사람들은 읽기 전용 클론을 원한다면 먼저 포크를 할 필요가 없다는 것을 인식하지 못합니다.


42
기술적이지 않은 이유에 따라 : 나는 누가 포크를했는지보고 싶어서 '포크'버튼을 여러 번 클릭했다. 죄송합니다! 다른 사람이 똑같이했는지 확실하지 않습니다.
gdw2 2016

53
@gdw : "아, 포크!"
벤 잭슨

1
나는 첫번째 자식과 Github에서에 대해 알았을 때, 나는 가이드 및 자습서로 제안 듯해서 약간의 포크 (fork)했던 기억 컴퓨터에 코드를 자신의 사본을 얻을 수있는 방법을.
rmac

우리는 직장에서 GitLab을 사용하므로 클론과 포크의 차이점을 잘 알고 있습니다. 또한 pull (merge for GitLab) 요청을 원하지 않으면 포크 할 필요가 없다는 의견도 있습니다.
cst1992

3
@Jesse, 괜찮습니다. 그러나이 경우에는 일반적으로 필요하지 않습니다. 회사는 원본이 갑자기 사라지지 않도록하기 위해 의존하는 코드를 사용하여이를 수행 할 수 있습니다. 소스에서 빌드하기 만하면 복제가 더 간단 해집니다.
Karl Bielefeldt

101

귀하의 질문에서 언급했듯이 사람들은 저장소를 소유자가 공동 작업자로 추가하지 않은 한 원래 저장소에 대한 쓰기 권한이 없기 때문에 코드를 변경하려고 할 때 저장소를 포크합니다.

분기 저장소에서는 쓰기 액세스 권한이 있으며 변경 사항을 푸시 할 수 있습니다. 풀 요청을 사용하여 원래 리포지토리에 다시 기여할 수도 있습니다 .

사람들이 저장소를 포크하지만 변경하지 않는 이유는 여러 가지가 있다고 생각합니다.

  • 그들은 멋지게 보이는 저장소를 포크 할 수 있습니다 (쉽게 (단 한 번의 클릭으로 인해)) 포크하고 나중에 변경하고 싶을 것입니다.
  • 변경 사항을 작성하기 위해 저장소를 포크 한 다음 변경이 불필요하다는 것을 발견하고 자체 저장소를 삭제하는 것을 잊습니다.
  • 프로젝트 중 하나가 다른 저장소 (하위 모듈을 통해)에 의존하기 때문에 저장소를 포크 할 수 있으며 종속성으로 사용되는 저장소를 완전히 제어하려고합니다 (원래 저장소의 소유자는 github에서 Google 코드로 이동하기로 결정할 수 있음) )
  • 그들은 단순히 커밋을 푸시하는 것을 잊을 수도 있습니다.

5
Github을 사용하지 않을 때는 구식 경로를 사용하여 프로젝트의 로컬 복제본 복사본을 만들어 수정할 수 있습니다. github에서 포크하면 많은 프로젝트에서 선호하는 풀 요청에 액세스 할 수 있습니다. 다른 프로젝트를 진행중인 경우 패치를 작성하여 검토를 위해 전송합니다.
Rudolf Olah

원격 추적 분기를 설정하는 간단한 1 단계 프로세스입니다. GitHub 외부의 git 저장소에 기여하려고 시도한 사람은 그것이 지루할 수 있다는 것을 알고 있습니다. 또한 원래 작성자가 AFK를 사용하는 경우 개발 그래프를 따라 여전히 활발하게 개발 된 포크를 찾을 수 있습니다. 다행히도 GitHub가 SourceForge와 같은 방식으로 죽은 프로젝트의 황무지로 퇴화되지 않게 할 수 있기를 바랍니다.
Evan Plaice 2013

프로젝트를 분기했지만 변경하지 않으면 어떻게됩니까? 이것이 불법으로 간주됩니까?
Jesse

@Jesse GitHub의 모든 공개 리포지토리 에는 오픈 소스 라이센스 (서비스 약관)가 있어야 하므로 전혀 문제가 없습니다. 특히 변경 사항이 없을 때.
MarcDefiant

28

가능한 이유 중 하나는 프로젝트에 의존하는 코드를 실행 중이며 빌드 프로세스에는 github에서 종속성을 가져 오는 것이 포함됩니다. 포크를 사용하면 변경 사항을 방지 할 수 있습니다. 버전을 태그하지 않는 프로젝트의 경우이를 달성하는 가장 쉬운 방법입니다.


3
앱의 릴리스 버전의 번호 또는 게시 된 버전을 커밋하도록 수정할 수 있습니다.
Roman M. Koss

26

Github의 핵심은 "사회적 코딩" 입니다.

개인적으로 다음과 같은 경우 리포지토리를 포크합니다.

  • 변경하고 싶습니다.
  • 프로젝트가 흥미롭고 향후에 사용하고 싶을 수도 있지만 현재 사용중인 장치에 나중에 쉽게 저장할 수있는 방법이 없습니다.
  • 해당 저장소의 일부 또는 모든 코드를 내 프로젝트의 시작점으로 사용하고 싶습니다.

사람들이 우표와 조개 껍질을 수집한다고 들었는데 왜 리포지토리를 수집하려고합니까?

왜 안돼?

개인적 즐거움을 위해 리포지토리를 포크하는 것에서 잘못 될 수있는 것은 (내가 생각할 수있는) 것이 없다. 솔직히, 나는 Github과 다른 곳에서 영감을 얻기 위해 흥미로운 프로젝트 폴더를 유지하고 있으며, 일부는 내가 괴짜이기 때문입니다. 코드를 읽기 위해 프로젝트를 포크 할 필요는 없지만 나중에 실제로 편집하고 싶을 수도 있습니다.

이제 포크를 시작하십시오.


9
"왜 안되나요?"+1 부분.
Llepwryd 2016

"왜 안돼?"에 추가 2 센트 섹션 : 기능에 대한 작업을 마친 후에는 항상 "git push"를 수행하는 습관이 있습니다. QED가 만족 스럽습니다 (원격 및 지사 이름을 쓸 때 얻지 못합니다). 따라서 리포지토리를 변경하고 싶을 가능성이 아주 적을 때마다 나중에 기본 "origin"리포지토리를 변경하는 대신 포크를 사용하는 것이 좋습니다.
yoniLavi 2016 년

1
"왜 안돼?" 섹션은 "별"의 작동 방식을 설명합니다 ...
TWiStErRob

2
나중에 볼 수 있도록 별표를주는 것이 어떻습니까?
친구

2
프로젝트가 재미있을 때 나는 별을 사용할 것입니다. 나는 나머지에 동의합니다.
Roman M. Koss

1

코드를 사용하고 싶거나 관심있는 프로젝트 인 경우 많은 repos를 포크합니다. 나중에 돌아와서 코드를 다시 살펴보고 싶을 때 내 코드가 목록에 있는지 더 쉽게 찾을 수 있습니다. 리포지토리. 나는 구글이 아니거나 이름이 무엇인지 정확히 기억하거나 "foo에 대한 repo를 어디서 보았습니까?" 내 저장소 중 하나라면 이러한 것들을 상기시키는 것이 더 쉽습니다.


레포를 주연 시켜도 같은 결과를 얻을 수 있습니다. 포크 할 필요는 없습니다.
valiano
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.