Git에서 원격 브랜치 리베이스


135

사람들이 복제하고 작업 할 수있는 원격 SVN 저장소를 미러링하기 위해 중간 Git 저장소를 사용하고 있습니다. 중간 리포지토리에는 업스트림 SVN에서 야간에 리베이스되는 마스터 브랜치가 있으며 기능 브랜치에서 작업하고 있습니다. 예를 들면 다음과 같습니다.

remote:
  master

local:
  master
  feature

기능 분기를 다시 원격으로 푸시하고 예상 한 결과를 얻을 수 있습니다.

remote:
  master
  feature

local:
  master
  feature

그런 다음 지점을 다시 설정하여 리모컨을 추적합니다.

remote:
  master
  feature

local:
  master
  feature -> origin/feature

그리고 모든 것이 잘됩니다. 여기에서 수행하려는 작업은 기능 분기를 원격의 마스터 분기로 리베이스하는 것이지만 로컬 컴퓨터에서 수행하고 싶습니다. 나는 할 수 있기를 원합니다 :

git checkout master
git pull
git checkout feature
git rebase master
git push origin feature

원격 기능 분기를 원격 마스터와 함께 최신 상태로 유지합니다. 그러나이 방법으로 Git은 다음과 같이 불평합니다.

To <remote>
 ! [rejected]        feature -> feature (non-fast-forward)
error: failed to push some refs to '<remote>'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes (e.g. 'git pull') before pushing again.  See the
'Note about fast-forwards' section of 'git push --help' for details.

git pull트릭을 수행하지만 피하고 싶은 병합 커밋을 유발합니다. 메시지가 feature -> feature아니라 오히려 메시지가 표시 될까 걱정 feature -> origin/feature하지만 이것은 단지 프레젠테이션 일 수 있습니다.

내가 뭔가를 놓치고 있거나 완전히 잘못된 방식으로 진행하고 있습니까? 원격 서버에서 리베이스를 수행하지 않는 것이 중요하지 않지만, 리베이스에서 병합 충돌을 수정하는 것이 훨씬 어렵습니다.


나는 같은 문제가 있었다. 지점 리베이스 모델을 시작하고 싶었습니다 ( 이와 같은 ). 그런 다음 실수를 한 것으로 나타났습니다. 리베이스하려는 경우 (리베이스를 마스터로 가져 오기 전에 원격 기능에 대한 변경 사항을 푸시해서는 안됩니다) 따라서 일부 코드는 해당 기능에 커밋합니다. 이제 원격 기능으로 푸시하려고합니다. 당신이 이것을하기를 좋아하십시오 :-필요하다면 마스터를 가져 와서 잡아 당기십시오. -당신이 당신의 기능에없는 마스터에 약간의 변경 사항이있는 경우 마스터에 rebase해야합니다. 이제 기능을 푸시해도 문제가 없습니다.
Markus

답변:


185

한 사람이이 기능을 사용하는지 아니면 다른 사람이이 기능을 사용하고 있는지에 따라 달라집니다.

리베이스 후에 당신이 강요한다면 푸시를 강제 할 수 있습니다 :

git push origin feature -f

그러나 다른 사람들이 작업하고 있다면 병합하지 말고 마스터를 리베이스하지 마십시오.

git merge master
git push origin feature

이렇게하면 공동 작업중인 사람들과 공통된 역사를 갖게됩니다.

다른 수준에서는 역 병합을 수행해서는 안됩니다. 당신이하고있는 일은 기능에 속하지 않은 다른 커밋으로 기능 지점의 기록을 오염시켜 해당 지점에 대한 후속 작업을 더 어렵게 만드는 것입니다.

이것은 기능 당 분기 라는 주제에 대한 내 기사입니다 .

도움이 되었기를 바랍니다.


29
에 +1 if others are working on it, you should merge and not rebase off of master하면 리베이스는 전용 지점에서만 사용하는 것이 좋습니다.
Hendra Uzia

6
푸시 원점 기능을 git로 대체하는 방법 -f 또한 원격 기능을 삭제하고 기능을 다시 푸시 할 수 있음
Markus

2
마스터를 브랜치에 병합하면 병합 커밋이 생성되고 변경 사항이 적용된 후 마스터의 다른 열린 기능 브랜치와 충돌이 발생합니다.
Steven

일에 대한 git push origin feature -f. 특정 상황에서는 원격 브랜치에서도 리베이스를 수행해야 할 수도 있습니다. 요점은 당신이하는 일을 알고 있습니다. 그리고 우리는 당신이 원격 저장소에서 커밋을 삭제하고 있다는 것을 인계해야합니다.
enagra

33

이 주제를 제기 해 주셔서 감사합니다.

이것은 자식 사용자 중 한 명이 알면 도움이되는 중요한 일 / 개념입니다. git rebase는 매우 강력한 도구이며 커밋을 함께 스쿼시하고 커밋을 제거하는 등의 작업을 수행 할 수 있습니다. 그러나 다른 강력한 도구와 마찬가지로 기본적으로 수행중인 작업을 알고 있거나 무언가 잘못 될 수 있습니다.

로컬에서 작업하고 로컬 브랜치를 어지럽히면 변경 사항을 중앙 저장소로 푸시하지 않는 한 원하는대로 할 수 있습니다. 이것은 당신이 당신의 자신의 역사를 다시 쓸 수 있지만 다른 역사는 다시 쓸 수 없다는 것을 의미합니다. 지역 물건 만 어지럽히면 다른 저장소에 영향을 미치지 않습니다.

따라서 커밋을 푸시 한 후에는 나중에 커밋하지 않아야한다는 점을 기억해야합니다. 이것이 중요한 이유는 다른 사람들이 커밋을 가져 와서 코드 기반에 대한 기여를 기반으로 작업을 수행 할 수 있고 나중에 콘텐츠를 한 곳에서 다른 곳으로 옮기고 (리베이스) 푸시하기로 결정하기 때문입니다. 다른 사람들은 문제를 겪고 코드를 리베이스해야합니다. 이제 1000 명의 개발자가 있다고 상상해보십시오.) 불필요한 재 작업이 많이 발생합니다.


나쁜 언어을 downvoted : meta.stackexchange.com/questions/22232/...

1
내 언어를 업데이트했습니다.
ralphtheninja

5

당신 feature은 새로운에 기반 을 두었 기 때문에 master, 당신의 지역 featureorigin/feature더 이상 빨리 감기되지 않습니다. 따라서이 경우에는을 수행하여 빨리 감기 검사를 무시하는 것이 git push origin +feature좋습니다. 구성에서 이것을 지정할 수도 있습니다

git config remote.origin.push +refs/heads/feature:refs/heads/feature

다른 사람이 위에 작업 origin/feature하는 경우이 강제 업데이트로 인해 방해를받습니다. rebasing 대신 new master를 병합하여이를 피할 수 있습니다 feature. 결과는 실제로 앞으로 나아갈 것입니다.


1

당신은을 사용하여 (당신이 정말로 있다면 당신이 당신이 무슨 일을하는지 알고)의 체크를 해제 할 수 있습니다 --force에 대한 옵션을 git push.


15
문제는 내가 무엇을하고 있는지 잘 모르겠다는 것입니다. :
kfb

@ r_ : 내 대답을 읽으십시오. 그것은 당신이하고있는 일을 이해하는 데 도움이 될 수 있습니다 :)
ralphtheninja
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.