git-svn의 원격 브랜치는 일반 Git 원격과 거의 같습니다. 따라서 로컬 리포지토리에서 git-svn 복제본을 만들고 변경 사항을 GitHub에 푸시 할 수 있습니다. Git은 상관하지 않습니다. git-svn 클론을 생성하고 똑같은 변경 사항을 GitHub에 푸시하면 비공식 Google 코드 저장소 미러가 생깁니다. 나머지는 바닐라 힘입니다.

git svn clone http://example.googlecode.com/svn -s
git remote add origin git@github.com:example/example.git
git push origin master

이제 이것을 가지고 있으면 때때로 Subversion 저장소를 Git과 동기화해야합니다. 다음과 같이 보일 것입니다 :

git svn rebase
git push

gitk 또는 무엇이든, 이것은 다음과 같이 보일 것입니다 :

o [master][remotes/trunk][remotes/origin/master]
|
o
|
o

그리고 당신이 실행할 때 git svn rebase, 당신은 이것을 가질 것입니다 :

o [master][remotes/trunk]
|
o
|
o [remotes/origin/master]
|
o
|
o

이제 실행 git push하면 해당 커밋이 [원격 / 원점 / 마스터] 지점 인 GitHub로 푸시 됩니다. 그리고 첫 번째 ASCII 아트 다이어그램의 시나리오로 돌아갑니다.

이제 문제는 믹스에서 변경 사항을 어떻게 처리합니까? 아이디어는 git-svn-rebase-ing 및 git-pushing과 동일한 브랜치에 커밋하지 않는 것입니다. 변경을 위해 별도의 지점이 필요합니다. 그렇지 않으면 Subversion의 변경 사항을 기반으로 변경 사항을 다시 작성하여 Git 저장소를 복제하는 사람을 화나게 할 수 있습니다. 날 따라와? 자, 브랜치를 생성하고 “기능”이라고 부르겠습니다. 그리고 커밋을 만들고 기능 분기의 GitHub로 푸시합니다. 당신의 gitk는 다음과 같이 보일 것입니다 :

o [features][remotes/origin/features]
|
o
|
o [master][remotes/trunk][remotes/origin/master]
|
o

여기에 기능 분기에 Google 코드 분기보다 몇 가지 커밋이 있습니다. Google 코드에서 새로운 것을 통합하고 싶을 때 어떻게됩니까? git svn rebase먼저 실행 하고 이것을 얻으십시오.

                           o [features][remotes/origin/features]
[master][remotes/trunk] o  |
                        |  o
                        o /
                        |/
                        o[remotes/origin/master]
                        |
                        o

당신이 경우 git push밖으로 마스터, 당신이 상상할 수있는 [리모컨 / 원산지 / 마스터] 마스터와 동일 시점에서 인. 그러나 기능 분기에는 변경 사항이 없습니다. 이제 마스터를 기능으로 병합하거나 기능을 리베이스 할 수 있습니다. 병합은 다음과 같습니다

git checkout features
git merge master

            o [features]
           /|
          / o [remotes/origin/features]
[master] o  |
         |  o
         o /
         |/
         o
         |
         o

그런 다음 기능을 GitHub로 푸시합니다. 마스터가 공간을 절약하기 위해 리모컨을 사용하지 않았습니다 . [master] 와 같은 시점에 있습니다.

리베이스 접근 방식은 약간 더 악합니다. 푸시가 빨리 병합되지 않기 때문에 –force로 푸시해야합니다 (복제 한 사람 아래에서 기능 분기를 가져옵니다). 이 작업을 수행해도 괜찮다고 생각되지는 않지만 결정된 사람은 아무도 막을 수 없습니다. 패치가 약간 재 작업 된 형태로 업스트림에 승인 될 때와 같이 일부 작업도 더 쉬워집니다. 충돌로 인한 혼란을 막기 위해 업스트림 패치를 건너 뛰면됩니다. 어쨌든 rebase는 다음과 같습니다.

git rebase master features

         o [features]
         |
         o
         |  o [remotes/origin/features]
[master] o  |
         |  o
         o /
         |/
         o
         |
         o

그리고 당신은 git push --force그것을 해야 할 것 입니다. 당신은 왜 그것을 강요해야하는지 알 수 있습니다. 역사는 [원격 / 원산지 / 특징] 에서 새로운 현재 사후 후행 [특징]에 이르기까지 큰 오래된 분열을 가지고 있습니다 .

이 모든 것이 작동하지만 많은 노력이 필요합니다. 정기적으로 기고자가 되려면, 이렇게하는 것이 가장 좋은 방법이며, 패치를 업스트림으로 보내고 Subversion에 대한 커밋 액세스 권한이 있는지 확인하십시오. 실패하면 아마도 변경 사항을 GitHub로 푸시하지 마십시오. 지역을 유지하고 어쨌든 상류로 수용하도록하십시오.

답변

git svn clone https://foo.googlecode.com/svn/ git-foo
cd git-foo
git remote add git-foo git@github.com:username/foo.git
git push git-foo master

cd /path/to/git-foo
git svn fetch
git svn rebase
git push git-foo master