GitHub 분기 저장소를 영원히 유지해야합니까?

314

그래서 다른 사람의 저장소를 포크하고 몇 가지 사항을 변경하고 풀 요청을 제출했으며 내 변경 사항이 제품으로 변경되었습니다. 큰!

하지만 ... 포크 저장소로 무엇을해야합니까? 저장소를 보관해야하는 강력한 이유가 있습니까? 아니면 계속해서 삭제해야합니까? 추가 기부를 할 계획은 없지만 마음이 바뀌면 언제든지 다시 갈 수 있다고 가정합니다.

백업 유지에 대해 걱정하지 않습니다. 링크 끊기, 커밋 메시지 손실 등이 더 걱정됩니다.

github 
— 브랜트 바비
소스
80
삭제하지 않으면 github에서 해시가 부족합니다.
— Armand
3
중복 코드는 악하다. 그리고 그것은 또한 자식 경계를 넘어갑니다.
— stijn
7
@stijn-나는 이것을 "중복"보다 "백업"으로 더 읽었다. 그리고 백업 코드가 악하다고 주장하는 사람은 없다고 생각합니다.
— Beekguk
3
삭제하십시오. 결국 프로젝트 저장소에서 항상 마지막 상태 (어쨌든 계속 작업 할 상태)를 다운로드 할 수 있습니다.
— Rook
원본 리포지토리가 삭제되고 포크가 남아 있지 않으면 어떻게됩니까? 이 경우 repo / fork에 다시 액세스하는 방법은 무엇입니까?
— Kromster

답변:

40

갈래 리포지토리를 삭제하면 풀 요청에서 기록이 지워집니다.

알 수없는 저장소가있는 PR

분기 저장소를 삭제하면 저장소와 관련된 모든 정보가 삭제됩니다. 이는 이미 병합 된 풀 요청을 포함하여 리포지토리에 대한 모든 참조에 소급 적용됩니다. ( 포크 삭제 후 끌어 오기 요청에 "알 수없는 저장소"가 표시됨)

리포지토리와 연결된 모든 끌어 오기 요청에 대해서는 사용자 의견과 커밋 을 유지 해야 하지만 사용자는 자신의 책임을 져야합니다.

그러나 병합 후 오래된 분기를 삭제하는 것은 완벽하게 안전합니다.

리포지토리 삭제는 피해야하지만 사용하지 않는 분기를 삭제하는 것은 완벽하게 허용됩니다. 실제로 GitHub는 오래된 브랜치를 삭제하도록 권장합니다 .

풀 요청 후 정리

GitHub에서는 하루 종일 풀 요청을 사용하는 것을 좋아합니다. 유일한 문제는 풀 요청이 병합되거나 닫힌 후 많은 기능이 부족한 분기로 끝나는 것입니다. 때때로, 우리 중 한 명이 스크립트로 이러한 브랜치를 정리할 것이지만, GitHub.com에서 정기적 인 워크 플로우의 일부로이 단계를 처리하는 것이 더 좋을 것이라고 생각했습니다.

오늘부터 풀 요청이 병합 된 후 느린 분기를 삭제하는 버튼이 표시됩니다.

이 지점 삭제 버튼

풀 요청이 병합되지 않고 닫히면 병합되지 않은 커밋 삭제에 대해 경고하기 위해 버튼이 약간 다르게 보입니다.

경고로 분기 삭제

물론, 푸시 액세스 권한이있는 리포지토리의 분기 만 삭제할 수 있습니다.

깔끔한 리포지토리를 즐기십시오!

또는 실제로 보관하지 않으려 는 경우 리포지토리 를 보관하여 더 이상 적극적으로 유지 관리되지 않음을 나타낼 수 있습니다 .

또한보십시오

— 스테보 이삭
소스
1
분기를 삭제할 때 병합되지 않은 닫힌 풀 요청은 정확히 어떻게됩니까 (인용 기사의 두 번째 경우)? 커밋은 히스토리없이 풀 요청에서 계속 사용할 수 있습니까? 아니면 완전히 사라 집니까?
— 오타
2
— Stevoisiak
207

풀 요청이 승인되었고 개인적으로 사용할 수있는 다른 변경 사항이없는 경우 삭제해야합니다.

  1. 삭제해도 아무런 문제가 없습니다.
  2. 필요한 경우 언제든지 다시 갈 수 있습니다.
  3. 사람들이 무언가를 검색 할 때 검색 결과에서 쓸모없는 저장소를 줄입니다.
  4. 잠재적 인 작업 / 계약을위한 일종의 이력서로 GitHub를 사용하는 경우, 현재 작업하고 있지 않은 수십 개의 포크 리포지토리가없는 것이 좋습니다. 보다 효율적으로 나타납니다.
  5. 수백 개의 쓸모없는 저장소를 페이징 할 필요가 없을 때 자신의 정신을 유지하는 데 도움이됩니다.
  6. GitHub에 더 좋습니다. :)
— 해리스
소스
50
이것에 대한 유일한 단점은 풀 요청이 "머지 된 커밋 <commit> <repo>from from unknown repository<date>"을 표시한다는 것입니다.
— PLPeeters
18
@PLPeeters, 사실 그것은 꽤 큰 단점입니다.
— Pacerier
4
remove-github-forks"메인 리포지토리에없는 커밋이없는 모든 포크를 삭제 하는 데 사용 하는 것이 좋습니다 ." 매력처럼 작동합니다.
— fregante
3
@SteveMoser 내가 틀렸을 수도 있지만 여전히 "기여한 저장소"목록을 유지한다고 생각합니다. 나는 사이에 모든 연결을 제거하고 어떻게 든 거기에 머물러 있지만 여전히 우연일지도 모른다 : P
— Mark Pieszak-Trilon.io
17
위험을 감수하고 분기 저장소를 삭제했으며 내 기여 목록이 영향을받지 않았으므로 분기 저장소를 삭제해도 기여 크레딧에 영향을 미치지 않는다고 안전하게 말할 수 있습니다.
— Amin Mohamed Ajani
76

끌어 오기 요청을 제출하는 즉시 병합 여부에 관계없이 포크를 삭제할 수 있습니다 . GitHub는 모든 PR을 업스트림 저장소에 저장 하므로 포크를 삭제하더라도 제안 된 변경 사항이 추적됩니다.

이는 의사 결정을 단순화합니다.

다음과 같은 경우 여전히 포크를 유지하고 싶을 수도 있습니다.

  • 더 빨리 기여할 수 있습니다 (예 : 기존 PR 확장 또는 새 PR 열기)

다음과 같은 경우 포크를 삭제할 수 있습니다.

  • 당신은 당신의 이름으로 깨끗한 프로젝트 포트폴리오를 원합니다
— 데니스
소스
7
"풀 요청을 보내 자마자 포크를 삭제할 수 있습니다."이것이 제가 찾던 것입니다!
— Unnawut
나도 그래도 대답은 "풀 요청이 수락 된 경우 ..."로 시작합니다. 시도해 보셨습니까 : D
— Legends
4
경고 : 포크를 삭제하면 보류중인 풀 요청에서 원래 분기 이름이 제거됩니다. ( Stevoisiak는에 커밋 1을 병합 싶어 Drugoy:master에서unknown repository )
— Stevoisiak
20

tar / gzip 파일을 압축하여 아카이브 디렉토리에 넣은 다음 3 년 후에 삭제합니다. ;) 솔직히 앞으로 몇 달 동안 다시 작업하지 않고 한동안 사용하지 않으면 삭제해도 안전하다고 생각합니다.

— 재커리 K
소스
9

제공된 답변에 추가하기 위해 GitHub 자체는 분기 된 저장소를 병합 한 후 삭제 ( "정렬") 할 것을 권장합니다.

이 작업은 병합 후 풀 요청에서 바로 수행 할 수 있습니다 . 이 블로그 게시물을 참조하십시오 .

또한, 현재로서는 의견에서 어떤 단점도 발견되지 않았습니다.

  • 분기 저장소를 삭제 한 후에도 풀 요청에 올바른 메시지가 있습니다 ( "알 수없는 저장소"없음).
  • 기고 한 저장소는 여전히 기고 활동에 나열됩니다.
  • 여전히 해당 저장소의 기고자에 나열되어 있습니다.

저자가 요청한 경우 코드를 약간 수정해야 할 수도 있으므로 @Dennis가 제안한대로 병합하기 전에 삭제하지 않는 것이 좋습니다.

— 마리우스 발치 티스
소스
2
방금 분기 저장소를 삭제했으며 이제 풀 요청에라고 표시 unknown repository됩니다. 오 잘
— Krassi
10
귀하의 링크는 성공적인 PR 병합 후 지점 을 삭제하는 방법을 설명하는 기사로 이동합니다 . 그러나이 질문은 저장소 삭제에 대해 묻습니다 . 자신의 프로젝트 포크 ( 저장소 ) 를 삭제할 때 "알 수없는 저장소"만 관찰됩니다 .
— stakx
2
문제는 분기가 아닌 포크 삭제에 관한 것입니다.
— Andy
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.