두 명의 커미터가 공유하는 git 브랜치가 커밋을 두 번하는 이유는 무엇입니까? (자식-SVN과 함께 가능한 상호 작용) 내가 한

Question

내가 설정 내 지점 :

다음

git svn rebase 
git checkout -b branch-a 

나는 원격 자식 저장소 및 동료에게 해당 분기를 밀어 나는 git commit, git pull 및 git push를 사용하여 작업을했다 .

git checkout master 
git svn rebase 
git checkout branch-a 
git rebase master 

을 나는 혼란 스러워요이 시점에서 : 내가 한 있도록

지금, 나는 전복의 모든 새로운 변화를 가져 싶었다. 일어난 일은 git이 하나 이상의 갈등으로 커밋을하고 해결하도록 강요하는 것입니다. 그러나 갈등은 HEAD가 트리 끝 (최신 코드 포함)을 가리킨 다음 모든 변경 사항을 상단의 에 하나씩 적용하여 원래 분기점에 적용하는 것처럼 보이도록했습니다..

내가 모든 코드를 다시 작성한 것처럼 느껴졌으며 대부분의 해결 방법은 HEAD 청크를 유지하고 커밋 청크를 제거하는 것이 었습니다.

내 기대치는 git rebase master 명령이 분기 전에 커밋에서 시작하고 모든 커밋을 master에서 추가 한 다음 분기의 모든 커밋을 추가하는 것입니다. 이렇게하면 브랜치에서 리베이스 이전의 팁과 거의 동일한 팁을 얻을 수 있습니다.

그래서 아무도 내가 이해하지 못하는 것을 설명 할 수 있습니까? 그게 아니라면, 아무도 git이 그것을 결정하는 이유를 찾는 방법을 제안 할 수 있습니다. git log에서 내가 왜 그 일을하고 있었는지 알고 싶습니다.

편집 : 우리가 거기에만라고 생각하면 더 많은 연구가 여러 가지를 보여주는 우리가 git log --graph에서 우리의 지사 및 지점의 구조에 커밋 부부의 여러 복사본을 갖고있는 것 같다 것으로 나타났습니다 2012-03-06 하나.

스 니펫 (제거 세부 사항을 확인하고 커밋 메시지는 메시지 - N로 대체되었습니다 메시지 - N가 동일한 메시지를 의미합니다.) :

| * | commit f5c48df66ed9d733364562d8f125866aa6483c1e 
| | | Author: commiter-b 
| | | Date: Mon Feb 27 16:18:05 2012 -0800 
| | | 
| | |  Message-4 
| | |  
| * | commit e6115229e629c237b08d0b2e149353f33ff66bd1 
| | | Author: commiter-a 
| | | Date: Mon Feb 27 15:49:02 2012 -0800 
| | | 
| | |  Message-3 
| | |  
| * | commit f85981736c59231dc34a7cef4fceab5cffdbdff2 
| |/ Author: committer-a 
| | Date: Mon Feb 27 14:20:56 2012 -0800 
| | 
| |  Message-2 
| | 
| * commit b09ba82e6290f5905d4c98fdcfbe2220d221e762 
| Author: committer-a 
| Date: Mon Feb 27 14:04:13 2012 -0800 
| 
|  Message-1 
| 
* commit 4d2892c239acfab5c9845518fde98ba551f273e6 
| Author: committer-a 
| Date: Mon Mar 5 09:13:19 2012 -0800 
| 
|  UN-3710 Fixes after merge from svn 

---8<----- snip 

* commit 8307d1ae8214ebe3eac5bdc5b835c21f89d727bd 
| Author: committer-b 
| Date: Mon Feb 27 16:18:05 2012 -0800 
| 
|  Message-4 
| 
* commit 859acc56de59877cb721914443c63ad97882cb41 
| Author: committer-a 
| Date: Mon Feb 27 15:49:02 2012 -0800 
| 
|  Message-3 
| 
* commit 93e15921d735333194970cefc673a8b953e80838 
| Author: committer-a 
| Date: Mon Feb 27 14:20:56 2012 -0800 
| 
|  Message-2 
| 
* commit 7a863bb44be5c5019a0e0958460324dc3cfb2e6b 
    Author: committer-a 
    Date: Mon Feb 27 14:04:13 2012 -0800 

     Message-1 

우리의 자식 워크 플로우는 보수적이다, 나는 생각합니다. 우리는 git-svn을 사용하여 master을 유지 관리하며 원격 자식 저장소에 푸시됩니다. 우리는 master을 분기하고 둘 이상의 커미터가 git pull origin branch-a 및 git push origin을 사용하여 작업합니다.

이제 우리는 문제의이 기능을 알아 냈으므로 앞으로 어떤 이벤트가 발생하는지주의 깊게 관찰 할 것입니다.

Answer 1

먼저 무엇을 git rebase의 빠른 요약.

이 보이는 역사를 가지고있는 경우 :

trunk branch 
    | /
    B C 
    |/
    |/ 
    A 
    | 
    | 

그리고 당신은 branch에있을 때 당신이 여기에 당신이 무엇을 얻을 git rebase trunk : 왜이 ​​rebase라고 있어요

trunk/branch 
    | 
    C 
    | 
    B 
    | 
    A 
    | 
    | 

- 이전 베이스이 branch 인 경우 커밋 A이 커밋되었습니다. 이것이 바로 "업스트림"지점 인 trunk에서 분기 된 지점입니다. 작업 후 새 기본 숫자는 B이고 HEAD은 trunk입니다. 당신은 그것을 다시 기반으로했습니다.

git svn rebase이 작업은 SVN에서 들어오는 새로운 커밋에 대한 변경 사항을 자동으로 이식합니다.

이제는 하나의 잡화가 있습니다. 히스테릭 건포도의 경우 git-svn은 git notes를 사용하여 메타 데이터를 저장하지 않습니다. 대신 커밋 객체 자체를 다시 작성하고 각 커밋 메시지의 끝에 git-svn-id 행을 추가합니다. 이로 인해 각 커밋의 SHA1 식별자가 변경됩니다. 따라서 동일한 커밋조차도 달라지며 대체 유니버스 버전과 충돌 할 수 있습니다!

이 가능성이 당신이 branch-a에서 git rebase master 할 때 당신이보고있는 것입니다 : 당신이, 당신은거야 병합 할 때 branch-a은 그래서 지금, master의 이전 상태의 일부가 아닌 최선을 다하고 - 투 - SVN 버전에서 분기 양쪽에서 변화된 것들 사이에서 갈등을 일으킨다.

이

은 git-svn의 제한 사항입니다 : 당신은 SVN의 변경을 추진 한 번만 커밋의 밀어 - 투 - SVN 다시 버전을 사용하려면 , 당신은주의해야합니다. 동일한 내용으로 "다른"변경 사항이기 때문에 사전 커밋 된 양식과 사후 커밋 된 양식을 함께 사용할 수 없습니다.

변경 사항을 git merge-base master branch-a에서 master 및 branch-a까지 검토하여 변경 사항을 확인하실 수 있습니다. 당신은 양쪽에서 같은 변화를 볼 것입니다.

은, 당신의 지점을 삭제,이 특별한 경우에 틀에 박힌 생활에서 자신을 얻을 master에서 새로운 하나를 만들려면 다음 git cherry-pickmaster 이미 들어있는 사람들을 생략 위해 branch-a의 변경. 앞으로는 아직 SVN 버전을 사용하지 않도록 조심하십시오 ...