SVN에서 Git으로 이동하는 중입니다. SVN에서 단일 SVN 저장소에 여러 개의 Eclipse 프로젝트가있어서 프로젝트를 탐색하는 데 편리합니다. 이클립스 프로젝트 당 하나의 git 저장소가있는 것으로 이동하려고했으나 EGit은 그렇지 않으면 제안합니다.각 Eclipse 프로젝트 또는 하나의 Git 저장소에 대한 여러 Git 저장소
EGit에 대한 가이드는 하나의 Git 저장소에 여러 프로젝트를 넣을 것을 제안합니다.
비슷한 질문이 있으시면 such as this은 저장소마다 하나의 프로젝트를 제안합니다.
어떤 접근 방식이 모범 사례이며 사람들은 무엇을 구현합니까?
이 프로젝트가 얼마나 밀접하게 관련되어 있는지에 따라 다릅니다. 다음과 같은 질문을하십시오.
모두 넣으면 위의 몇 가지 사항이 더 쉬울 것입니다. 하나의 저장소에서/tag/stash/commit을 사용하면 모든 저장소에 대해 별도로 수행하지 않고 분기해야합니다.
하지만 예를 들면 프로젝트의 릴리스주기를 따로 따로두면 각 프로젝트를 독립적 인 저장소에 두어야합니다.
나중에 언제든지 저장소를 분할하거나 여러 저장소를 기록을 잃지 않고 다시 하나로 결합 할 수 있습니다.
결합은 분할보다 약간 어렵습니다. 그래서 먼저 하나의 저장소로 가서 어떻게되는지 봅니다.
아마 여러 git 저장소를 만들면 더 효율적으로 작동 할 것입니다.
브랜치를 만들면 모든 프로젝트가 아닌 분기 된 프로젝트 파일 만 생성됩니다. 소규모 프로젝트는 분석하고 커밋하는 것이 더 빠릅니다. 작업 시간이 적게 걸립니다.
로그가 더 명확합니다. 여러 git 리포지토리가있는 경우 더 세분화 된 구성을 만들 수 있습니다.
프로젝트 당 1 개의 repo를 사용합니다.
일부 추론 :
당신이 여러 커밋 후 뭔가를 엉망 발견, 그것은 단지 하나 개의 프로젝트 때 해결하는 것이 훨씬 쉽다. 생각해 보면 두 개의 다른 프로젝트에 커밋을 했으므로 이제는 세 번째 프로젝트에서 수행 한 커밋을 수정해야합니다.
Fedir가 말했듯이, 기록과 로그는 훨씬 깨끗합니다. 해당 프로젝트의 커밋 만 표시합니다.
나는 개발 워크 플로우에서 더 잘 작동합니다. 나는 생산을위한 마스터 브랜치를 가지고 있으며, 개발을위한 브랜치 (branch)를 개발하고, 기능을 구현하는 브랜치를 생성한다. (여기에서 더 많은 것을 읽을 수있다 : http://blog.avirtualhome.com/development-workflow-using-git/)
팀에서 일하면서 " "git repo, 팀 구성원 모두 정말 다른 프로젝트도 필요합니까?
몇 가지 생각 만 들지만 다음과 같이 요약 할 수 있습니다.
나는이 질문이 내가 응답 한 here과 관련이 있다고 생각한다. 근본적으로 성격에 힘내는 프로젝트/저장소에 관해서는 매우 미세한 세분화 된 구조를 지원합니다. 나는 프로젝트 당 하나의 저장소가 거의 항상 최선의 방법이라는 것을 읽고 배웠다. 프로젝트를 분리하여 유지하면서 거의 아무 것도 잃지 않습니다.
저는 여러 프로젝트 (Eclipse 프로젝트)를 보유하고 있으며 실제 일일 개발 측면에서 다른 프로젝트를 시도해 보았습니다. 여기에 제가 발견 한 것이 있습니다. 나는 대부분의 사람들이 결과를 추적하고 그 결과를 객관적으로 분석한다면 똑같은 것을 발견 할 것이라고 생각합니다. 최상의 결과를 줄 것이다 다음과 같은 규칙을 적용 한마디로
:
프로젝트가 가깝게 (예를 들어, 다른 프로젝트에 연결되어 있지 않은 경우, 프로젝트 :
다음 지침
프로젝트가 다른 프로젝트에 종속되어 있거나 다른 프로젝트가 프로젝트에 종속되어있는 경우 정확히 어떻게 서로 연결되어 있는지, 얼마나 잘 패키지화 할 수 있는지, 각 프로젝트에서 얼마나 쉽게 분리 할 수 있는지에 따라 다릅니다. 다른.
A) 주 프로젝트 클래스 테스트 JUnit 테스트 클래스를 포함하는 테스트 프로젝트 두 프로젝트 매우 서로 연결되어있는 경우는 예를 들어, 쉽게 함께 패키징 될 수 있으며, 용이하게 할 수 없다 서로 분리되어있다. 이러한 프로젝트는 아래 파트 C에서 설명한 이유 때문에 동일한 저장소에 배치해야합니다.
B) 한 프로젝트가 어떤 종류의 공유 리소스를 제공하기 위해 다른 프로젝트에 의존하는 경우 실제로 함께 관리 할 수있는 방법과 서로 손쉽게 결합 할 수있는 방법이 매우 적절합니다. 예를 들어, 공유 된 자원을 가진 프로젝트가 많은 프로젝트에 의존한다면, 다른 관련없는 프로젝트는 공유 소스 코드 프로젝트의 변경으로 영향을 받기 때문에 자체 저장소에 저장해야합니다. 이와 같은 경우, 공유 자원 프로젝트는 종속 프로젝트와 직접 연결되는 대신 종속 프로젝트와 분리되어야합니다. 예를 들어 버전 관리 된 아카이브 파일 [예 : projectName ".1.0.1.0.jar과 같은 이름의 Jar 파일]을 만들고 프로젝트를 링크하여 자원을 공유하는 대신 각 프로젝트에 사본을 포함하는 것이 좋습니다 함께).
C) 여러 프로젝트가 연결되어 있으면 쉽게 관리 할 수 있지만 서로 쉽게 분리 할 수없는 경우 서로 밀접하게 연결되어 있는지 여부에 따라 다릅니다.
I) 프로젝트가 하나의 저장소에 저장되면 프로젝트가 커밋 될 때마다 저장소에서 서로 동기화되어 유지됩니다. 이는 프로젝트가 밀접하게 연결되어 있으면 실제 구원자가 될 수 있습니다. 그러나 이것도 위의 답변에 언급 된 문제를 만듭니다.
II) 프로젝트가 별도의 저장소에 저장되면 서로 동기화되어 커밋을 유지해야하며 동일한 동기 지점에 속한 커밋을 나타내는 일종의 메커니즘을 포함해야합니다 프로젝트 전체에 커밋 그룹이있을 때 (각 프로젝트의 커밋에 대한 주석에 동일한 동기 포인트 번호를 포함하는 것과 같은 의미 일 수 있습니다.)
III) 이와 같은 경우에는 거의 항상 이 프로젝트를 하나의 저장소에 두어 커밋을 동기화 할 때 인간 노력의 오버 헤드를 줄이고 커밋을 철회해야하는 경우 사람의 실수를 피하는 것이 좋습니다. 별도의 리포지토리에 배치하는 것이 더 좋은 경우는 프로젝트 중 하나만 정기적으로 변경하고 다른 연결된 프로젝트는 거의 변경되지 않는 경우입니다.
분할 또는 결합에 대한 링크 (또는 적어도 용어)를 알려줄 수 있습니까? 예를 들어 결합을 통해 당신은 서브 모듈 (또는 대안)을 의미 할 수도 있다고 가정하지만, 아마도 더 많을 수도 있습니다. 분열에 대해서 나는 전에 들어 본 적이 없기 때문에 나는 정말로 호기심이 많다. –
분할한다는 것은 하나의 저장소를 가져 와서 일회성 변환을 사용하여 여러 저장소로 분할한다는 것을 의미합니다. [git filter-branch - 하위 디렉토리 - 필터] (http://git-scm.com/docs/git-filter-branch#_examples)를 사용하십시오. 여러 개의 저장소를 가져 와서 결합 된 기록 (다시 한번 일회성 변환)을 사용하여 하나의 새 저장소를 만드는 것을 의미합니다. [스티치 - 레포 스크립트] (http://search.cpan.org/~book/Git-FastExport-0.07/script/git-stitch-repo). 분리 된 역사가 함께 짜여지기 때문에 결합이 더 어려워진다. – robinst
이 대답은 정말 유용합니다. 조금 더 나아가서 하나의 "작업"에 대해 여러 프로젝트를 결정한 경우 프로젝트에 대한 다른주기를 유지해야한다고 말합니다. 그렇지 않으면 단일 프로젝트를 만듭니다. 따라서 하나의 프로젝트를 만들고 미래에 분할해야 할 필요가있는 경우 분할하여 각 프로젝트에 대한 새로운 리포지토리를 생성하십시오. 보관 목적으로 보관하십시오. 계속 간단하게 유지하십시오. –