2011-09-26 4 views
11

우리 git repo에는 더 이상 필요하지 않은 많은 파일들이있다. 여기에 설명 된 바와 같이,필터 브랜치 이후 변경된 git 히스토리에 모두 리베이스하기

http://git-scm.com/book/en/v2/Git-Internals-Maintenance-and-Data-Recovery

가 그때 우리의 공유 REPO이를 보낼 git push --force all를 사용할 것이다 : 나는 필터 가지 기술은 프로 힘내 설명 사용하여 제거 할

Update a development team with rewritten Git repo history, removing big files

하지만. Pro Git은 내가 역사를 바꿀 때부터 모두에게 rebase가 필요하다고 말했습니다. 우리는 리버스 (rebase)를 거의 사용하지 않고, 대개 병합을위한 대체 방법으로 사용합니다. 나는 모든 사람이 다시 복제하도록 할 수는 있지만 그것이 최후의 수단이다. 몇몇 개발자들은 유지하고 싶은 변경 사항이있는 로컬 브랜치를 가지고 있습니다.

So : 새로 변경된 공유 저장소에 리베이스하기 위해 모든 사람들이 로컬 저장소에서 정확히 수행해야 할 사항은 무엇입니까? 추적 지점마다 한 번해야합니까? 단계별로 알려주고 싶다면 우리 repo를 원점이라고하고 마스터 브랜치를 마스터라고합니다.

답변

3

다음은 옵션입니다.

  • 은 (대신 원래 master의) 지점에 당신으로 업데이트 마스터가 rebased_master라는 만듭니다.
  • 당신은 그 지점을 밀어서 모든 개발자들에게 내려 놓고 로컬 지점을 rebased_master에 리베이스하게 할 것입니다. 리베이스 이전의 커밋을 해제하고 제거하려는 파일을 변경하지 않은 경우 모두 이어야합니다. 나는이 테스트를하지 않은, 그래서 당신이 당신의 repo의 복사본이 있는지 확인 : 모든 사람이 rebased_master 자신의 dev에 지점을 이동하면
  • , 당신은 당신의 원래 mastermoverebased_mastermaster

메모를 삭제할 수 있습니다 문제가 생길 경우를 대비하여 복원하십시오.

+1

이 말이 맞아요. 실제로 작동하면 아침에 받아 들일 것입니다. –

+3

그래서? 작동합니까? 그날 아침에 나는 추측했다. – marton78

14

리팩터링을 마친 후에야 개별 개발자가 master에 대한 원래 참조를 잃지 않는 것이 핵심입니다. 이렇게하려면, 그들이 각 지역 지점에 대한 다음, 강제 푸시 후 fetch (하지 풀을) 할 수있는이 수행하는 일을 끝낼 때

git rebase --onto origin/master master <local_branch> 

는, 그들은 그들의 master을 체크 아웃하고하여 업데이트 할 수 있습니다 :

git pull --force 
관련 문제