2017-05-10 2 views
0

두 개의 관련없는 프로젝트가 하나의 git 저장소에 있다고 가정합니다. 각 프로젝트는 자체 폴더에 있지만 두 폴더는 모두 마스터 브랜치에 있습니다. 망할 놈의 repo 구조는 다음과 같습니다GIT : 하나의 저장소에서 2 개의 프로젝트 분리

Folder structure: 
/path/to/projectfolders/ 
|- .git 
|- project1 
|- project2 

Branch master: 
p1_commit1 <- p2_commit1 <- mixed_commit <- p1_commit2 <- p2_commit3 <- master 

mixed_commit은 추가 있었다는 것을 의미합니다/프로젝트 1뿐만 아니라 프로젝트 2에서 수정.

Branch p1: 
p1_commit1 <- p1_mixed_commit <- p1_commit2 <- p1 

Branch p2: 
p2_commit1 <- p2_mixed_commit <- p2_commit3 <- p2 

을 내가 생각하고있는 전략은 처음에 경우 : REPO는 다음과 같이 수 있도록, 어떤 역사를 공유하지 않는 - P1과 P2 - 나는 두 개의 분리 된 지점에있는 두 개의 프로젝트를 넣어 싶습니다 두 가지 p1과 p2를 만듭니다. 그런 다음 p1을 점검하고 project2와 관련된 모든 커밋을 삭제하십시오. 이후에 p2를 점검하고 project1과 관련된 모든 커밋을 삭제하십시오.

마지막으로 마스터 분기를 삭제하십시오. 나는 아직도 이눔에 새로운 오전부터

, 나는 이것에 대해 두 가지 질문이 있습니다

  1. 이 안전한 전략 또는 내가 생각하지 아니하는 단점이있다?

  2. 전략이 ​​좋은 경우 각 분기에서 공통 커밋 기록을 삭제하는 가장 좋은 방법은 무엇입니까? 나는 rebase를 사용하고, 전용 브랜치에있는 프로젝트 인 에 속하는 커밋을 선택하는 것을 "간단히"생각하고있었습니다. 다른 프로젝트의 관련되지 않은 커밋을 없애기에 충분합니까? ?

PS : 사람들이 그것을 제안하는 두 개의 별도의 repos로 저장소를 분할 한 이후이 하지 옵션입니다. 그것은 하나의 저장소로 남아 있어야합니다.

+2

2 개의 저장소를 만들면 왜 그 모든 문제를 해결할 수 있습니까? 프로젝트가 정말로 관련이 없다면, 이것은 가장 논리적 인 일입니다. –

+0

두 개의 repos로 나누는 것이 더 합리적입니다. https://help.github.com/articles/splitting-a-subfolder-out-into-a-new-repository/ – Chrs

+0

@ J.Titus @Chrs 가져 주셔서 감사합니다. 관심이 있지만 프로젝트는 하나의 저장소에 남아 있어야합니다. 방대한 시행 착오 끝에 나는 아래에 답변으로 올린 해결책을 발견했다. 고급 git 사용자이고 바쁜 일정에서 시간을 할애 할 수 있다면 절차를보고 피드백을 줄 수 있다면 크게 감사하겠습니다. 나는 '자식'에 대해 아주 새로운데, 내 해결책에 함정이있을 가능성을 배제 할 수는 없다. – nautical

답변

0

마지막으로 master의 프로젝트를 전용 분기로 분리하는 솔루션이 생겼습니다. 프로젝트 2를 자체 지점으로 분리하는 데 필요한 단계를 수행 할 것입니다.

I는이 예를 들어, 다음과 저장소 폴더 구조를 가정한다 :

Folder structure: 
/path/to/projectfolders/ 
|- .git 
|- project1 
|- project2 

Branch master: 
p1_commit1 <- p2_commit1 <- mixed_commit <- p1_commit2 <- p2_commit3 <- master 

mixed_commit은 추가 있었다는 것을 의미/프로젝트 1뿐만 아니라 프로젝트 2의 변형.

1 단계

체크 아웃 master 및 마스터의 HEAD를 가리키는 임시 지점 생성 :

git checkout master 
git checkout -b tmp 

단계를 2

로그를 통해 검색하는 커밋 식별 어떤 프로젝트에 기여했는지. 분리 할 프로젝트에 속한 가장 오래된 커밋을 확인하십시오. 예를 들어 프로젝트 2의 경우 p2_commit1이됩니다. 두 프로젝트 모두에 파일을 제공 한 mixed_commit과 같은 커밋에도주의하십시오.

git log --stat # write down commit hashes that belong to project 2 

3 단계

체크 아웃 고아 지점 (예를 이름, 프로젝트 p2 2) 초기 프로젝트 2의 커밋 즉,하지 않는 파일을 제거, 청소의 프로젝트 2에 속해 있습니다 : git이 고아 분기를 체크 아웃하면 이미 커밋 된이 커밋의 영향을받는 파일을 갖게됩니다. 인덱스를 삭제하면 쉽게 수정할 수 있습니다. 그럼 당신은이 프로젝트에 속하는 파일 만 무대와 새로 생성 된 지점은 이제 초기가 다시 프로젝트 2.

4 단계

스위치의 커밋이 들어 그들에게

git checkout --orphan p2 <hash of p2_commit1> 
rm .git/index # clear index 
rm -r project1 # remove any files/folders not related to project 2 
git add project2 
git commit -m "Created branch for project 2" 

를 저지 할 수 임시 지점. 그런 다음 tmp 분기를 대화 형으로 p2에 리베이스하십시오.

git checkout tmp 
git rebase -i p2 

이렇게하면 편집기를 시작할 때 대화 형 리베이스가 어떻게 표시 될 수 있습니다. 이미 p2 지점에 있기 때문에 p2_commit1이 제공되지 않습니다.

pick hash1 p1_commit1 
pick hash2 mixed_commit 
pick hash3 p1_commit2 
pick hash4 p2_commit3 

피크 만 커밋은 당신이 두 프로젝트에 대한 파일이 포함 된 수동으로 edit 커밋을해야합니다 2. 프로젝트에 속한다 (사람 당신은 2 단계에서 아래로 썼다). 따라서 최종 리베이스 파일은 다음과 같이 보일 수 있습니다 :

edit hash2 mixed_commit 
pick hash4 p2_commit3 

변경 사항을 저장하고 편집기를 닫으십시오. edit으로 표시된 커밋을 만날 때마다 rebase가 중단됩니다. 프로젝트 2에 속하지 않은 파일을 제거하고 해당 수정 프로그램을 수정하려면 수행해야 할 작업을 수행하십시오. 당신은, 결과 리베이스 프로세스를 계속하고 모든 커밋이 올바르게으로 업데이트되었는지 확인하기 위해 로그를 확인에 만족하면이 예제 시나리오의 절차

# git rm -r project1 
# git commit --amend 

처럼 보일 수 있습니다.

git rebase --continue 
git log --stat 

5 단계

현재, 우리는 임시 분기에 여전히. 체크섬 지점 p2을 체크하고 로그를 확인하십시오. 포함 된

git checkout p2 
git log --stat 

은 초기에는 3 단계에서 투입. 관련 커밋의 나머지는 임시 지점에있는, 그래서 우리는 병합해야합니다 : 모든 4 단계에서 잘 갔다

git merge tmp 

경우 마지막 명령은 빨리 감기 병합가 발생합니다.

우리는 마침내 project2에 대한 파일을 제공하는 커밋 만 포함하는 프로젝트 2의 전용 분기를 갖습니다. 이제 임시 분기가 더 이상 필요하지 않습니다.

6 단계

이 최종 정화 단계이다. 이제 더 이상 사용되지 않는 임시 분기를 제거하십시오.

git branch -D tmp 

완료.

지금 당신은 master

git checkout master 

을 체크 아웃하고 저장소에 남아있는 프로젝트를 분리하기 위해 1 단계 6 단계 을 통해을 반복 할 수 있습니다.