git rebase은 커밋 기록을 다시 작성합니다. 다시 작성하려는 커밋 내역이 원격 저장소에 아직 제출되지 않은 경우, 즉 다른 사람과 공유하기 전 커밋 내역은 비공개이므로 원하는 대로 다시 작성할 수 있습니다. .
리모컨에 제출한 후 다시 기록해 보면 분명 다른 사람의 기록과는 다를 것입니다. git push, git은 커밋 기록을 비교합니다. 일치하지 않으면 커밋 작업이 거부됩니다. 이때 git은 -f 매개변수를 가져와서 원격 저장소를 덮어쓰는 것입니다. 커미터의 이력을 기록하여 코드 제출을 완료합니다. 코드를 제출했지만 이로 인해 다른 사람의 작업물이 손실될 수 있으므로 -f 매개변수를 주의해서 사용하세요.
원본 포스터에서 발생한 문제는 공개 커밋 기록을 다시 작성하여 발생했습니다. 이 문제를 해결하려면 제출 프로세스를 표준화해야 합니다.
올바른 프로세스의 예를 들어주세요.
포스터 팀에 Tom과 Jerry라는 두 명의 개발자가 있다고 가정합니다. 그들은 원격 저장소를 공동으로 사용하고 이를 자신의 컴퓨터에 복제합니다. 설명을 단순화하기 위해 master라는 분기만 있다고 가정합니다.
현재 톰머신의 레포는 master, origin/master 2개의 브랜치가 있습니다.
Jerry의 기계에도 두 개의 분기가 있습니다 master, origin/master
둘 다 아래 사진에 나와 있습니다
Tom과 Jerry는 각각 자신만의 새로운 기능을 개발하고 새로운 커밋이 각자의 개인 커밋 기록에 지속적으로 제출되므로 마스터 포인터가 계속해서 앞으로 이동하여 다른 커밋을 가리킵니다. 그리고 그 중 git fetch 및 git push이 없으므로 origin/master은 변경되지 않습니다.
Jerry의 레포는 다음과 같습니다
Tom의 repo는 다음과 같습니다. 위 그림의 T1과 J1은 서로 다른 커밋입니다
.
이때 Tom은 먼저 원격 저장소에 커밋을 제출한 다음 로컬 origin/master 포인터가 다음과 같이 master 포인터와 일치하도록 발전합니다.
원격 저장소는 다음과 같습니다
이제 Jerry는 자신의 커밋을 원격 저장소에 제출하고 git push을 실행하려고 합니다. 그런데 아무런 놀랄 것도 없이 실패하므로 git fetch 그렇게 하고 T1 이전에 Tom이 제출한 원격 저장소를 넣습니다. 다음과 같이 그의 로컬 저장소로 가져왔습니다.
Tom이 이전에 제출한 콘텐츠를 자신의 작업에 포함하려는 경우 한 가지 방법은 git merge을 사용하는 것입니다. 그러면 Tom의 제출물과 Jerry의 커밋이 모두 포함된 커밋이 자동으로 생성됩니다. 두 개의 분기된 커밋을 다시 병합합니다. 하지만 자동으로 생성된 이 커밋에는 두 개의 상위 커밋이 있으므로 코드를 검토할 때 두 번 비교해야 하므로 매우 불편합니다.
커밋 내역의 선형성을 보장하기 위해 jerry는 git rebase라는 다른 방법을 사용하기로 결정했습니다. Jerry의 커밋 J1은 현재 원격 저장소에 제출되지 않았으며 이는 그에게 완전히 비공개인 커밋이므로 git rebase을 사용하여 J1의 기록을 다시 작성하는 데 문제가 없습니다. 다음과 같습니다
J1은 T1 다음에 다시 작성되어 J1`
이 되었습니다.
git push 이후 로컬 저장소
그리고 원격 저장소
유난히 여유로움, 직선, 아무것도 없음-f
따라서 -f을 사용하지 않고 트리를 깔끔하게 유지하려면 git push 이전에 git fetch을 먼저 사용한 다음 git rebase하는 방법이 좋습니다.
위의 답변은 모두 맞습니다. 개인적으로 특정 브랜치에서 작업하는 유일한 사람이 아니라면 어떻게 리베이스해도 문제가 없지만 마스터라면 문제가 없습니다. 또는 개발이런 종류의 브랜치를 리베이스하면 팀원 모두가 당신을 이기고 싶어할 것으로 추정됩니다. 특히 git에 익숙하지 않은 팀원이 당황하는 것은 매우 정상입니다.
rebase 이후 push -f가 밀리는 상황은 단 하나, 즉 저와 같은 강박장애를 갖고 있는 대상이 컴퓨터 다운타임, 시스템 충돌 등 고통스러운 일을 두려워하는 상황(피의 비극적 역사)이 딱 하나 있습니다. 그리고 눈물) 기능 커밋을 완료한 후 원격 은 귀하의 브랜치에만 속합니다 . 개인적으로는 문제가 없다고 생각합니다. 결국 자신에게만 영향을 미치게 됩니다(그리고 그것이 옳다는 것을 알고 있습니다).
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
git rebase은 커밋 기록을 다시 작성합니다. 다시 작성하려는 커밋 내역이 원격 저장소에 아직 제출되지 않은 경우, 즉 다른 사람과 공유하기 전 커밋 내역은 비공개이므로 원하는 대로 다시 작성할 수 있습니다. .리모컨에 제출한 후 다시 기록해 보면 분명 다른 사람의 기록과는 다를 것입니다.
git push, git은 커밋 기록을 비교합니다. 일치하지 않으면 커밋 작업이 거부됩니다. 이때 git은-f매개변수를 가져와서 원격 저장소를 덮어쓰는 것입니다. 커미터의 이력을 기록하여 코드 제출을 완료합니다. 코드를 제출했지만 이로 인해 다른 사람의 작업물이 손실될 수 있으므로-f매개변수를 주의해서 사용하세요.원본 포스터에서 발생한 문제는 공개 커밋 기록을 다시 작성하여 발생했습니다. 이 문제를 해결하려면 제출 프로세스를 표준화해야 합니다.
올바른 프로세스의 예를 들어주세요.
포스터 팀에 Tom과 Jerry라는 두 명의 개발자가 있다고 가정합니다. 그들은 원격 저장소를 공동으로 사용하고 이를 자신의 컴퓨터에 복제합니다. 설명을 단순화하기 위해
master라는 분기만 있다고 가정합니다.현재 톰머신의 레포는
master,origin/master2개의 브랜치가 있습니다. Jerry의 기계에도 두 개의 분기가 있습니다
master,origin/master둘 다 아래 사진에 나와 있습니다
Tom과 Jerry는 각각 자신만의 새로운 기능을 개발하고 새로운 커밋이 각자의 개인 커밋 기록에 지속적으로 제출되므로 마스터 포인터가 계속해서 앞으로 이동하여 다른 커밋을 가리킵니다. 그리고 그 중
git fetch및git push이 없으므로origin/master은 변경되지 않습니다.Jerry의 레포는 다음과 같습니다
Tom의 repo는 다음과 같습니다. 위 그림의
.T1과J1은 서로 다른 커밋입니다이때 Tom은 먼저 원격 저장소에 커밋을 제출한 다음 로컬
origin/master포인터가 다음과 같이master포인터와 일치하도록 발전합니다.원격 저장소는 다음과 같습니다
이제 Jerry는 자신의 커밋을 원격 저장소에 제출하고
git push을 실행하려고 합니다. 그런데 아무런 놀랄 것도 없이 실패하므로git fetch그렇게 하고T1이전에 Tom이 제출한 원격 저장소를 넣습니다. 다음과 같이 그의 로컬 저장소로 가져왔습니다.Tom이 이전에 제출한 콘텐츠를 자신의 작업에 포함하려는 경우 한 가지 방법은
git merge을 사용하는 것입니다. 그러면 Tom의 제출물과 Jerry의 커밋이 모두 포함된 커밋이 자동으로 생성됩니다. 두 개의 분기된 커밋을 다시 병합합니다. 하지만 자동으로 생성된 이 커밋에는 두 개의 상위 커밋이 있으므로 코드를 검토할 때 두 번 비교해야 하므로 매우 불편합니다.커밋 내역의 선형성을 보장하기 위해 jerry는
git rebase라는 다른 방법을 사용하기로 결정했습니다. Jerry의 커밋J1은 현재 원격 저장소에 제출되지 않았으며 이는 그에게 완전히 비공개인 커밋이므로git rebase을 사용하여J1의 기록을 다시 작성하는 데 문제가 없습니다. 다음과 같습니다
이 되었습니다.J1은T1다음에 다시 작성되어J1`git push이후 로컬 저장소그리고 원격 저장소
유난히 여유로움, 직선, 아무것도 없음
-f따라서
으아악-f을 사용하지 않고 트리를 깔끔하게 유지하려면git push이전에git fetch을 먼저 사용한 다음git rebase하는 방법이 좋습니다.필독을 적극 권장합니다
당신만 사용하는 것이 아니라면
push --force을 사용하는 사람은 모두 죽어야 합니다.로컬 지점과 원격 지점의 바인딩(추적) 및 리베이스 전략:
으아악이렇게 하면 코드 업데이트(
pull) 시 개입이 필요한 3자 병합으로 인한 충돌과 같은 다른 상황이 아닌 한 병합 커밋을 생성하는 대신 리베이스가 자동으로 적용됩니다. 대부분의 경우 팀의 습관이 좋으면 매우 깨끗하고 아름다운 나무 모양이 유지될 수 있습니다.사실 트리 구조를 더 아름답고 명확하게 만드는 방법은 여러 가지가 있지만, 먼저 팀이 어떤 Git 모델을 사용하는지에 따라 다르며, 그에 맞는 약을 처방하면 됩니다. 여기서 요약할 방법은 없습니다.
그리고 윗분 말이 맞으니 주의해서 사용하세요
push -f!이것은 git 워크플로우 문제여야 합니다. 우리 팀에서는 커밋 정보의 청결성을 보장하기 위해 rebase를 사용해 왔지만
push -f과 같은 작업은 사용하지 않을 것입니다.Git 워크플로에 관해서는 의견의 문제입니다. 다음 기사를 읽고 팀에 적합한 기사를 찾으세요. 하지만 가장 중요한 것은 팀원 모두가 Git에 익숙해지도록 하는 것입니다. 만들어진.
팀워크를 위해 github을 사용한다면 끌어오기 요청을 잘 활용하면
push -f이 어리석은 문제를 해결할 수 있습니다!모든 사람은 제출하기 전에 수정 사항을 서버의 최신 코드로 리베이스해야 합니다. 이 규칙을 따르면 문제가 없습니다. 강제 푸시가 필요하다는 것은 강제 푸시가 필요하기 전에 서버 코드를 로컬 브랜치로 리베이스한다는 의미입니다.
Pro Git http://git-scm.com/book/zh/Git-%E5%88%86%E6%94%AF-%E5%88% 에서 rebase에 관한 장을 참고하는 것이 좋습니다. 86%E6% 94%AF%E7%9A%84%E8%A1%8D%E5%90%88
내가 아는 한. 리베이스 후에
push -f를 사용해야 한다면 리베이스 작업이 부적절하다는 의미여야 합니다. 커밋 기록을 수정하려는 경우가 아니면.push -f가 필요하지 않습니다. 브랜치가 뒤처지면 pull --rebase를 사용하세요
위의 답변은 모두 맞습니다. 개인적으로 특정 브랜치에서 작업하는 유일한 사람이 아니라면 어떻게 리베이스해도 문제가 없지만 마스터라면 문제가 없습니다. 또는 개발이런 종류의 브랜치를 리베이스하면 팀원 모두가 당신을 이기고 싶어할 것으로 추정됩니다. 특히 git에 익숙하지 않은 팀원이 당황하는 것은 매우 정상입니다.
rebase 이후 push -f가 밀리는 상황은 단 하나, 즉 저와 같은 강박장애를 갖고 있는 대상이 컴퓨터 다운타임, 시스템 충돌 등 고통스러운 일을 두려워하는 상황(피의 비극적 역사)이 딱 하나 있습니다. 그리고 눈물) 기능 커밋을 완료한 후 원격 은 귀하의 브랜치에만 속합니다 . 개인적으로는 문제가 없다고 생각합니다. 결국 자신에게만 영향을 미치게 됩니다(그리고 그것이 옳다는 것을 알고 있습니다).
개인적으로 특정 브랜치에서 팀으로 작업할 때 rebase를 사용하는 것은 정말 무리라고 생각합니다. 그리고 잘못되기 쉽습니다. 주의해서 사용하세요 push --force
Git rebase는 일반적으로 제출 기록을 깨끗하게 유지하기 위해 단독으로 개발할 때 사용됩니다. github에 업로드한 후에는 git rebase를 사용하면 안 됩니다. 그렇지 않으면 혼나서 죽게 됩니다.