git rebase and git push : non-fast forward, why use?

git rebase and git push : non-fast forward, why use?

---

다른 기여자가 사용할 수 있어야하고 마스터와 지속적으로 최신 상태를 유지해야하는 브랜치가 있습니다.

안타깝게도 'git rebase'를 한 다음 푸시를 시도 할 때마다 'non-fast forward'메시지와 푸시 중단이 발생합니다. 여기에 밀어 넣는 유일한 방법은 --force를 사용하는 것입니다. 내 브랜치가 공개되고 다른 브랜치가 작업중인 경우 리베이스 대신 'git merge'를 사용해야 함을 의미합니까?

---

git 작동 방식에 대한 몇 가지 참고 사항 (기술적이지 않음) :

리베이스 할 때 git은 문제의 커밋을 가져 와서 깨끗한 히스토리 위에 "재 커밋"합니다. 이것은 기록이 표시되지 않도록하기위한 것입니다.

Description: tree -> mywork -> merge -> mywork -> merge -> mywork -> merge
Commit SHA1: aaaa -> bbbb   -> cccc  -> dddd   -> eeee  -> ffff   -> gggg

리베이스 후에는 다음과 같이 보일 수 있습니다.

Description: tree -> rebase
Commit SHA1: aaaa -> hhhh

문제는 푸시하려는 새 커밋이 푸시하려는 분기 끝에 커밋 의 자손 이 없다는 것입니다 .

이제 동일한 정보가 커밋에 있음을 알고 있지만 git은 해당 커밋을 덮어 쓰는 것만이 아닙니다 (위 예제에서는 bbbb-gggg).

---

공유 저장소 모델

공유 저장소를 사용하는 경우 이와 같은 것들이 매우 혼란 스러울 수 있습니다. 이유를 설명하겠습니다. 다른 개발자가 브랜치를 가져 왔고 브랜치에서 aaaa-> gggg 를 커밋했다고 가정 해 보겠습니다 . 그런 다음 그들은 커밋을 만듭니다.

그 동안 리베이스하고 강제로 푸시하여 트리가 다음과 같이 보이도록합니다.

Description: tree -> rebase
Commit SHA1: aaaa -> hhhh

다른 개발자가 푸시를 시도하면 "빨리 감기가 아님"메시지가 표시됩니다. 그가 병합하면 두 기록이 함께 다시 연결되고 엉망으로 끝납니다.

다음과 같은 것 (지저분 함) :

Description: tree -> rebase -> mywork -> merge -> mywork -> merge -> mywork -> merge -> devwork -> merge 
Commit SHA1: aaaa -> hhhh   -> bbbb   -> cccc  -> dddd   -> eeee  -> ffff   -> gggg -> iiii    -> jjjj

즉, 다른 사람들이 당기고 밀고 있다면 git merge를 고수하거나 rebase가 끝날 때까지 PUSHING을 피하는 것이 좋습니다 .

---

공개적으로 표시되는 저장소 모델

아마도 사람들이 리포지토리에서 가져올 수 있기를 바라는 다른 (더 거창한) 모델을 사용하고있을 수 있습니다. 이 경우 git push --force는 그렇게 나쁘지 않습니다. 왜냐하면 그들은 그것을 따라갈 수 있기 때문입니다. 그들은 리베이스 수있는 변경 사항을 당신에게 자신의 패치를 제공하기 전에 변경의 상단에있을 수 있습니다. 리포지토리가 모두 엉망이되는 것을 방지합니다.

그러나 더 나은 방법이있을 수 있습니다. git push --mirror

http://www.kernel.org/pub/software/scm/git/docs/git-push.html에서

푸시 할 각 참조의 이름을 지정하는 대신 $ GIT_DIR / refs / (refs / heads /, refs / remotes / 및 refs / tags /를 포함하지만 이에 국한되지 않음) 아래의 모든 참조가 원격 저장소에 미러링되도록 지정합니다. 새로 생성 된 로컬 참조는 원격 끝으로 푸시되고 로컬로 업데이트 된 참조는 원격 끝에서 강제 업데이트되며 삭제 된 참조는 원격 끝에서 제거됩니다. 구성 옵션 remote..mirror가 설정된 경우 이것이 기본값입니다.

---

git의 장점 중 하나 는 매우 유연하고 다양한 종류의 워크 플로를 허용한다는 것입니다. 하지만 이것이 진정한 강점은 분산 모델이라는 사실에 있습니다. 그래서 저는 그것을 사용함으로써 가장 많은 ROI를 얻을 수 있다고 믿습니다.

---

아니요, 리베이스는 공개 저장소에서 완벽하게 합법적이며 역사를 유창하게 유지하는 것이 바람직 할 수도 있습니다. 원격으로 게시 된 커밋의 기록을 다시 작성하기 위해 rebase를 사용해서는 안됩니다. 즉, rebase는 게시 한 적이없는 자신의 로컬 커밋에만 적용 할 수 있습니다. 리베이스를 사용하여 가져올 때 커밋을 맨 위에 배치 한 다음 아마도 거기에서 조정하십시오. 이러한 메시지를받을 수있는 또 다른 이유는 푸시 한 브랜치가 업데이트되었고 동기화해야하기 때문입니다. 가져온 것 위에 커밋을 가져 와서 리베이스해야합니다.

참고 URL : https://stackoverflow.com/questions/559917/git-rebase-and-git-push-non-fast-forward-why-use