git 저장소에 히스토리에 저작권이있는 미디어가있는 프로젝트를 오픈 소스하는 방법은 무엇입니까?


15

무료 라이센스로 오디오 핑거 프린팅 소프트웨어 프로젝트를 릴리스하려고하지만 저장소에 저작권이있는 오디오 파일이 포함되어 있습니다. 테스트 사례는 현재 이러한 파일을 사용합니다. 최대 버전 기록으로 저작권을 위반하지 않고 코드를 일반인에게 공개하려면 어떻게해야합니까?

세부:

  • 코드는 git에서 버전이 지정됩니다. 릴리스 전에 모두 하나의 브랜치로 다시 접습니다.
  • 400MB의 오디오 데이터가 있습니다. 일부 파일은 Jamendo와 같은 무료 라이센스 음악이며 다른 파일은 개인 컬렉션의 MP3입니다.
  • 어떤 접근 방식을 사용하더라도 프로젝트 기록을 파괴하지 않도록 항상 원본 리포지토리를 변경할 수 없습니다.

주요 질문 : 공개 릴리스를 처리하는 방법은 무엇입니까?

  1. git 저장소에서 문제의 파일 히스토리를 정리하고 변경된 저장소를 해제하십시오. (v64 는 이것을 수행하는 방법을 지적했습니다 .)
  2. 또는 코드의 현재 상태에 대한 스냅 샷을 작성하고 시험판 코드의 공개 히스토리도 신경 쓰지 않아도됩니다.

부수적 인 질문 : 때때로 프로젝트 초기 단계에 개인 코드 나 미디어가 필요할 때 어떻게 이러한 딜레마를 피할 수 있었습니까?

답변:


13

GitHub에는 모든 기록에서 파일을 제거 하는 방법을 설명하는 페이지가 있습니다 . 민감한 데이터 제거 .

때때로 사용자는 실수로 비밀번호 또는 키와 같은 데이터를 자식 저장소에 커밋합니다. git rm파일을 제거하는 데 사용할 수 있지만 파일은 여전히 ​​리포지토리 기록에 있습니다. 다행히도 git을 사용하면 전체 저장소 기록에서 파일을 제거하는 것이 매우 간단합니다.

위험 : 커밋이 푸시되면 데이터가 손상된 것으로 간주해야합니다. 비밀번호를 커밋 한 경우 변경하십시오! 키를 커밋 한 경우 새 키를 생성하십시오.

저장소에서 파일을 제거하십시오.

이제 비밀번호가 변경되었으므로 파일을 히스토리에서 제거하고 .gitignore실수로 다시 커밋되지 않도록 파일에 추가하려고합니다 . 이 예 Rakefile에서는 GitHub gem 리포지토리 에서 제거하겠습니다 .


해당 작업에 적합한 도구 인 것 같습니다. 필자의 경우 코드베이스의 새로운 스냅 샷부터 시작하여 이것이 가장 적합한 지 여부는 여전히 확실하지 않습니다.
모드를 잘 치료하십시오

@phyzome : 역사가 얼마나 중요하다고 생각 하느냐에 달려 있습니다. filter-branch명령을 사용하여 정리를 쉽게 제거 할 수 있습니다. 리포지토리 복제본은 파괴적이며 실행 취소 할 수 없으므로 복제본에서 실행해야합니다.
Sharpie

8

부수적 인 질문 : 때때로 프로젝트 초기 단계에 개인 코드 나 미디어가 필요할 때 어떻게 이러한 딜레마를 피할 수 있었습니까?

큰 미디어 파일 (400MB의 오디오)을 추적하려면 별도의 저장소에 넣으십시오.

그것은 하나의 돌로 두 마리의 새를 죽입니다.

  1. 기본 리포지토리는 400MB 작습니다. (복제 할 때마다 400MB 분량의 콘텐츠를 다운로드 할 필요는 없습니다.)
  2. 미디어는 개인용 일 수 있으며 다른 모든 항목과 별도로 유지됩니다. 따라서 공용 저장소를 해제하기 위해 추가 작업을 수행 할 필요가 없습니다.

원하는 경우 미디어 저장소를 하위 모듈 로 만들어보다 편리하게 작업 할 수 있습니다 공개 (릴리스 계획) .

그렇게하면 (민감한) 내용 자체가 아닌 (개발 초기 단계) 포인터를 유지합니다. 그런 다음 repo를 공개적으로 공개 할 때 서브 모듈 참조를 제거하면 400MB 상당의 물건을 걸러 내기 위해 기록을 다시 작성하는 것보다 훨씬 덜 문제가되지 않습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.