기존 프로젝트를 완전히 다시 작성하기위한 적절한 에티켓은 무엇입니까?


12

저는 오픈 소스 세계에 익숙하지 않습니다. 내가 작업중 인 프로젝트는 Github에 있습니다. (참고로) 작업중 인 프로젝트는 Plex Media Server 용 플러그인입니다. 플러그인을 Plex에 제출하여 "app store"에 포함시킬 계획입니다. 이제 내 질문에.

내가 처음 시작했을 때, 내가 원했던 것 중 일부는 잘 수행하지 못한 오래된 반중간 플러그인을 발견했다. 나는 그 레포에 공헌하여 시작했다. 현재 소유자가 너무 바빠서 더 이상 엉망이 아니라고 말한 이후로 나는 즉시 repo에 대한 모든 권한을 가진 공동 작업자가되었습니다. 그러나 코드를 더 깊이 파기 시작하면서 코드가 쓸모가 없다는 것을 깨달았습니다. 기존 코드베이스는 끔찍했으며이를 고칠 수있는 효율적인 방법이 없었습니다. 나는 처음부터 시작했다. 새 플러그인에서 사용한 유일한 코드는 처음에 커밋 한 코드였습니다.

이제 프로젝트를 릴리스 할 준비가되었습니다. 그러나 나는 이것을하는 방법에 대해 확신하지 못한다. 옵션은 다음과 같습니다.

  1. 새 저장소를 만들고 기존 저장소를 잊어 버리십시오. 이전 리포지토리 및 / 또는 그 기여자를 언급해야할지 확실하지 않습니다. 해당 코드 / 리소스를 사용하지 않았으며 완전히 새로운 코드 기반을 만들었습니다. 플러그인은 이전 플러그인과 동일한 기능을 수행하지만 완전히 새로운 방식과보다 효율적인 방식으로 수행합니다.

  2. 기존 저장소를 포크하고 기존 코드를 삭제하고 새 코드를 커밋합니다. 나는 Git을 처음 접했기 때문에 이것이 가능한지 확실하지 않습니다.

  3. 기존 리포지토리에 대한 변경 내용을 커밋하고 현재 기고자들이 어떻게 말하는지 확인합니다.

세 가지 옵션 중 첫 번째 옵션을 강하게 기대하고 있습니다. 그러나! 저는 오픈 소스를 처음 접했고 적절한 에티켓에 따라 일을하고 싶습니다. 내 첫 프로젝트가 내 얼굴에 터져서 재난이되고 싶지는 않습니다. 옵션 2는 나쁘지 않지만 그렇게해야하는지 확실하지 않습니다. 역사와 차이점이 어떻게 작동하는지 잘 모르겠습니다. 우리는 최대 500-1000 줄의 코드에 대해서만 이야기하고 있습니다. 따라서 큰 코드 기반이 아닙니다.

제공 할 수있는 모든 입력에 감사드립니다!


10
그것은 모두 새로운 코드이기 때문에 오래된 프로젝트의 역사는 실제로 관련이 없기 때문에 # 1을 사용하는 경향이 있습니다. 그러나 "...의 아이디어를 바탕으로"라는 라인을 따라 README에 무언가를 추가하는 것이 좋을 것입니다.
피터 로웰

2
@PeterRowell 그 의견을 답장에 넣어 의견을 올리십시오!
MattDavey

@PeterRowell 조언 감사합니다. 좋은 아이디어야.
Matt Keller

1
2의 경우 기존 저장소를 삭제할 필요가 없습니다. 당신이 무엇을하든, 나는 원래 개발자가 당신이 그에게 프로젝트를 진행하고 있다고 말한 것에 대해 감사하게 생각합니다
James

답변:


13

새로운 코드이기 때문에 이전 프로젝트의 커밋 히스토리가 실제로 관련이 없기 때문에 # 1을 사용하는 경향이 있습니다. 그러나 "...의 아이디어를 바탕으로"라는 라인을 따라 README에 무언가를 추가하는 것이 좋을 것입니다.

나는 우리 (또는 우리의 알고리즘)가 어디에서 왔는지 인정하는 열렬한 팬입니다. 역사의 안개를 되돌아 보면, 우리 모두는 이전에 온 사람들 , 우리 모두 의 어깨에 서 있음을 알 수 있습니다 . 예를 들어, 1980 년대에 유사성 검색 엔진을 개발하고 마케팅했으며 일부 사람들에게는 상당히 급진적 인 것처럼 보였습니다 (부울은 당시 왕이었습니다). 그러나 내가 사용하고 있던 알고리즘의 핵심은 20 년 전 코넬의 Gerard Salton이 시작한 작업을 기반으로 한 것입니다.

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