bestsource

리베이스 후 Git 분기가 분기되었습니다.

bestsource 2023. 7. 8. 11:01
반응형

리베이스 후 Git 분기가 분기되었습니다.

저는 이미 푸시된 지점을 로컬로 리베이스했습니다.

Git는 제 지점과 원격이 분리되었다고 조언하고 있습니다.

"그리고 각각 109개와 73개의 다른 커밋을 가지고 있습니다."

지점을 밀면 문제가 해결됩니까? 즉, 리베이스 후에 예상되는 문제입니까?

분기를 재배치할 때, 재배치할 분기의 커밋 위에 있는 커밋에 대한 커밋을 다시 작성해야 합니다.이는 커밋의 속성 중 하나가 상위(또는 상위)이기 때문입니다.기본값을 변경하면 분기에서 가장 오래된 로컬 커밋의 상위 항목이 변경되고, 따라서 모든 로컬 커밋의 커밋 해시가 변경됩니다. 이 변경 사항은 과도적 커밋을 통해 거품이 발생하기 때문입니다.

분기를 이미 푸시했으므로 소스 분기에 대해 기본 재배치하는 것이 아니라 소스 분기에 병합했어야 합니다.분기를 "합니다.-f플래그), 그러나 분기 기록의 무결성이 방해되기 때문에 일반적인 푸시는 작동하지 않습니다.이 분기에서 다른 사용자와 공동작업을 수행하는 경우 강제로 밀어넣기는 좋지 않습니다. 다른 공동작업자의 기록이 갑자기 일치하지 않을 때 다른 공동작업자가 매우 혼란스러워질 수 있기 때문입니다.

TL;DR - 상호협력하지 않을 경우 push -f를 사용하여 분기를 누릅니다.이 경우 분기를 이전 상태로 재설정하고 대신 원본 분기에서 병합합니다.

모든 커밋이 ID를 변경했으므로 전환은 진정한 분기가 아닙니다.

문제를 해결하려면 원격 지점을 덮어써야 합니다.

git push -f origin experiment

http://git-scm.com/book/ch3-6.html

설명:

이 이미지에서 C3가 리베이스 뒤에 C3가 아닌 C3'로 배치되는 방법을 확인하십시오.이것은 정확히 C3는 아니지만 코드가 모두 바뀌었기 때문입니다.

Rebase

이 다른 이미지에서는 원격이 관련될 때 기본 재배치가 표시되는 것과 전환이 있는 이유에 대한 그림을 볼 수 있습니다.

diverge and git push

어떤 경우에도 강제 푸시를 수행한 후에는 (강제 업데이트)를 수행했다는 메시지가 표시되므로 해당 시점에서는 문제가 없을 것입니다.

맨 위에 있는 링크를 체크아웃하고 "git push --force"를 검색합니다.더 자세한 설명을 보실 수 있습니다.

저는 다음을 수행함으로써 푸시를 위한 리베이스 분기를 성공적으로 처리했습니다.

git checkout mybranch
git pull
git push origin mybranch

그 당김으로 분기가 해소되었습니다.

당기기 전에

Your branch and 'origin/mybranch' have diverged,
and have 2 and 1 different commit(s) each, respectively.

PULL 출력

recursive.mypath/myfile에 의해 병합되었습니다.py | 12++++++++++++++- 1개 파일 변경, 11개 삽입((+), 1개 삭제((-)

후당김

귀사의 지점이 '오리진/마이 브랜치'보다 3 커밋 앞서 있습니다.

푸시 후

내 지점은 지점보다 3 앞에 있지만 여전히 열린 끌어오기 요청 병합 메시지가 커밋 기록에 추가되어 있습니다. 원격의 내 지점을 내 지점으로 병합합니다.

저는 이것이 아마도 포스 푸시가 하는 것이라고 추측하고 있고, 저는 확인하지 않았습니다.

다른 사람들이 말했듯이, 이미 열린 꺼내기 요청이 있는 경우에는 기본 재배치를 피하십시오.저는 이 사례를 저에게 효과가 있었던 사례로 제공하고 있습니다.

이 문제는 대상 분기를 현재 로컬 분기로 재배치하고 대상 분기로 전환한 다음 로컬 분기를 대상으로 재배치하여 강제 푸시 없이 해결할 수 있습니다.누락될 수 있는 커밋이 추가되어 더 이상 생성할 필요가 없기 때문에 이 값은 분산되지 않습니다.더 쉽게 설명할 수 있는 예:

  1. 주요 지점이 개발 중입니다.
  2. 분기 기능/doing_stuff를 확인합니다.
  3. 팀 구성원이 개발을 위한 새로운 약속을 추진합니다.

만약 당신이 당신의 develop 브랜치를 업데이트하지 않았다면, 체크아웃 이후 커밋이 추가되지 않았기 때문에 "git checkout develop" & & "git rebase feature/doing_stuff"가 올바르게 작동할 것입니다.그러나 develop을 체크아웃하고 새 커밋을 풀다운한 경우 새 커밋이 표시되어 기본 재배치를 시도하면 이러한 차이가 나타납니다.무리하지 않고 쉽게 해결할 수 있는 방법은 다음과 같습니다(일반적으로 팀 환경에서는 좋은 생각이 아닙니다).

  1. git 체크아웃 기능/실행_stuff
  2. Gitrebase 개발
  3. git 체크아웃 개발
  4. gitrebase 피쳐/실행_stuff

2단계의 기본 재배치는 누락된 커밋을 feature/doing_stuff로 가져오므로 4단계가 수행될 때 최신 상태가 되며 변경을 위한 새 커밋을 생성할 필요가 없습니다.

이것은 제가 효과가 있다는 것을 알고 있는 해결책입니다. 왜냐하면 저는 이것을 우연히 만나 위의 단계들을 수행하여 강요하지 않고 개발을 성공적으로 추진했기 때문입니다.저는 50명이 넘는 개발자들로 구성된 팀에서 일하고 있기 때문에 제 테스트 지점 이외의 다른 지점을 강제로 밀어내는 것이 금지되어 있어 해결책을 찾아야 했습니다.

언급URL : https://stackoverflow.com/questions/19016698/git-branch-diverged-after-rebase

반응형