강제 푸시없이 어떻게 git rebase를 사용할 수 있습니까?

강제 푸시없이 어떻게 git rebase를 사용할 수 있습니까?

---

git nirvana를 달성하기 위해 현재 병합하는 상황에서 리베이스를 활용하는 방법을 배우는 데 하루를 보내고 있습니다.

내가 git 101 흐름이라고 생각하는 것을 실행할 때 (아래에서 설명합니다), push --force변경 사항을 원점으로 되돌릴 때해야합니다.

(참조 나는이 덮여 땅임을 알 - 난 안 유일한 사람 1 , 2 , 3 , 4 , 5 ), 나는 기술적 인 이유를 이해 왜 힘이 필요하다. 내 문제가 있습니다 REBASE의 칭찬을 노래 많은 (많은) 블로그 항목이하고 (참조 자신의 삶을 변화 어떻게 --- 이것이다 1 , 2 , 3 , 4는 몇 가지를 나열),하지만 그들 중 누구도 그 언급하지 push --force의 일부입니다 그들의 흐름. 그러나 기존의 스택 오버플로 질문에 대한 거의 모든 답변은 "예, 리베이스하려면 사용해야합니다 push --force" 와 같은 내용을 말합니다 .

리베이스 옹호자의 수와 종교성을 감안할 때 '푸시-포스'를 사용하는 것은 리베이스 흐름의 내재 된 부분이 아니며 종종 푸시를 강요해야하는 경우 뭔가 잘못하고 있다고 믿어야합니다 .

push --forceA는 나쁜 일 .

여기 내 흐름이 있습니다. 어떤 방식으로 힘없이 동일한 결과를 얻을 수 있습니까?

간단한 예

두 가지 :

• v1.0- 릴리스 브랜치, 패치 만 포함
• master- 다음 주요 릴리스를위한 모든 것.

다음 릴리스를 위해 몇 가지 패치 커밋과 몇 가지 커밋이 있습니다.

다음 릴리스에서 손실되지 않도록 패치를 마스터에 통합하고 싶습니다. 깨달음 전 저는 간단히 :

git checkout master
git merge v1.0

하지만 지금은 노력하고 있어요

git checkout master
git rebase v1.0

그래서 지금 여기 있습니다.

시간 :

git push

주사위가 없습니다.

---

Rebasing은 훌륭한 도구이지만 마스터에 대한 토픽 분기에 대한 빨리 감기 병합을 만드는 데 사용할 때 가장 잘 작동합니다. 예를 들어, master에 대해 add-new-widget 브랜치를 리베이스 할 수 있습니다.

git checkout add-new-widget
git rebase -i master

분기를 마스터로 빨리 감기를 수행하기 전에 예를 들면 :

git checkout master
git merge --ff-only add-new-widget

이것의 장점은 모든 변경 사항이 병합 전에 마스터 팁에 다시 기반하기 때문에 기록에 복잡한 병합 커밋이나 병합 충돌이 많지 않다는 것입니다. 두 번째 이점은 리베이스했지만 git push --force마스터 브랜치에서 히스토리를 방해하지 않기 때문에 사용할 필요가 없다는 것 입니다.

그것은 확실히 리베이스의 유일한 사용 사례 또는 유일한 워크 플로는 아니지만 내가 본 것보다 더 현명한 용도 중 하나입니다. YMMV.

---

@CodeGnome이 맞습니다. 마스터를 v1.0 브랜치에서 리베이스하지 말고 마스터에서 v1.0 브랜치를 리베이스하면 모든 차이를 만들 수 있습니다.

git checkout -b integrate_patches v1.0
git rebase master
git checkout master
git merge integrate_patches

v1.0을 가리키는 새 브랜치를 생성하고 해당 새 브랜치를 마스터 위로 이동 한 다음 새 버전의 V1.0 패치를 마스터 브랜치에 통합합니다. 다음과 같은 결과를 얻게됩니다.

o [master] [integrate_patches] Another patch on v1.0
o A patch on v1.0
o Another change for the next major release
o Working on the next major release
|  o [v1.0] Another path on v1.0
|  o A patch on v1.0
| /
o Time for the release

rebase를 사용하는이 방법 은 공식 git 문서에서 권장 합니다 .

나는 당신이 옳다고 생각합니다 git push --force: 당신이 실수를 저질렀 고 원하지 않는 것을 밀 때만 사용해야합니다.

---

당신이 리베이스 경우 강제로 밀어가, 그리고 당신은 이미 변경, 권리를 게시 한?

I use rebase a whole bunch, but I either publish to something private where a force push doesn't matter (eg: my own clone on GitHub, as part of a pull request), or I rebase before I push for the first time.

This is the heart of the workflow where you use rebase, but don't force push much: don't publish things until they are ready, don't rebase after you push.

---

I think there's a good use-case for this rebase-then-force-push pattern that's not a result of a mistaken push: working on a feature branch by yourself from multiple locations (computers). I do this often, since I sometimes work at the office on my desktop, and sometimes from home/customer-site on my laptop. I need to rebase occasionally to keep up with the main branch and/or to make merges cleaner, but I also need to force-push when I leave one machine to go work on another (where I just pull). Works like a charm, as long as I'm the only one working on the branch.

---

Here's what I use (assuming your branch name is foobar):

git checkout master              # switch to master
git rebase   foobar              # rebase with branch
git merge -s ours origin/master  # do a basic merge -- but this should be empty
git push origin master           # aaand this should work

참고URL : https://stackoverflow.com/questions/11058312/how-can-i-use-git-rebase-without-requiring-a-forced-push