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

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

---

사람들이 복제하고 작업 할 수있는 원격 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하지만 이것은 단지 프레젠테이션 일 수 있습니다.

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

---

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

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

git push origin feature -f

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

git merge master
git push origin feature

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

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

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

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

---

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

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

When you are working locally and messing around with your local branches, you can do whatever you like as long as you haven't pushed the changes to the central repository. This means you can rewrite your own history, but not others history. By only messing around with your local stuff, nothing will have any impact on other repositories.

This is why it's important to remember that once you have pushed commits, you should not rebase them later on. The reason why this is important, is that other people might pull in your commits and base their work on your contributions to the code base, and if you later on decide to move that content from one place to another (rebase it) and push those changes, then other people will get problems and have to rebase their code. Now imagine you have 1000 developers :) It just causes a lot of unnecessary rework.

---

Because you rebased feature on top of the new master, your local feature is not a fast-forward of origin/feature anymore. So, I think, it's perfectly fine in this case to override the fast-forward check by doing git push origin +feature. You can also specify this in your config

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

If other people work on top of origin/feature, they will be disturbed by this forced update. You can avoid that by merging in the new master into feature instead of rebasing. The result will indeed be a fast-forward.

---

You can disable the check (if you're really sure you know what you're doing) by using the --force option to git push.

참고URL : https://stackoverflow.com/questions/6199889/rebasing-remote-branches-in-git