리베이스와 푸시 된 커밋을 리베이스하는 것은 무엇을 의미합니까?

리베이스와 푸시 된 커밋을 리베이스하는 것은 무엇을 의미합니까?

---

이미 푸시 한 커밋을 리베이스해서는 안된다고 종종 말합니다. 그게 무슨 의미일까요?

---

ProGit 책은 이 좋은 설명을 .

질문에 대한 구체적인 답은 " 리베이스의 위험 "섹션에서 찾을 수 있습니다 . 해당 섹션의 인용문 :

리베이스 할 때 기존 커밋을 버리고 비슷하지만 다른 커밋을 새로 만듭니다. 커밋을 어딘가에 푸시하고 다른 사람들이 커밋을 아래로 내리고 기본 작업을 한 다음 해당 커밋을 git rebase로 다시 작성하고 다시 밀어 올리면 공동 작업자가 작업을 다시 병합해야하며 시도 할 때 작업이 지저분해질 것입니다. 그들의 작업을 당신의 것으로 되돌립니다.

업데이트 :
아래 의견에 따르면 Git 워크 플로에 문제가있는 것 같습니다. 다음은 도움이 될 수있는 몇 가지 참고 자료입니다.

• gitworkflows매뉴얼 페이지 페이지의 "위쪽으로 병합"과 "주제 지점을"
• ProGit : " 개인 관리 팀 "참조
• Jarrod Spillers 블로그 : " git merge vs git rebase : avoiding Rebase Hell "참조

---

이것을 이해하려면 git의 작동 방식에 대해 조금 이해해야합니다. git 저장소는 트리의 노드가 커밋되는 트리 구조입니다. 다음은 매우 간단한 저장소의 예입니다.

마스터 브랜치에 4 개의 커밋이 있고 각 커밋에는 ID (이 경우 a, b, c, d)가 있습니다. d가 현재 마스터 브랜치의 최신 커밋 (또는 HEAD)임을 알 수 있습니다.

여기에는 master와 my-branch의 두 가지 분기가 있습니다. master와 my-branch는 모두 커밋 a와 b를 포함하지만 분기하기 시작합니다. master에는 c와 d가 포함되고 my-branch에는 e와 f가 포함됩니다. b는 master와 비교하여 my-branch의 "병합베이스"또는 더 일반적으로 "베이스"라고합니다. 의미가 있습니다. my-branch가 이전 버전의 master를 기반으로한다는 것을 알 수 있습니다.

따라서 my-branch가 오래되어 최신 버전의 master로 업데이트하려고한다고 가정 해 보겠습니다. 다시 말해서 my-branch는 c와 d를 포함해야합니다. 병합을 수행 할 수 있지만 이로 인해 분기에 풀 요청 검토를 훨씬 더 어렵게하는 이상한 병합 커밋이 포함됩니다. 대신 리베이스를 수행 할 수 있습니다.

When you rebase, git finds the base of your branch (in this case, b), finds all the commits between that base and HEAD (in this case, e and f), and re-plays those commits on the HEAD of the branch you're rebasing onto (in this case, master). Git actually creates new commits that represent what your changes look like on top of master: in the diagram, these commits are called e′ and f′. Git doesn't erase your previous commits: e and f are left untouched, and if something goes wrong with the rebase, you can go right back to the way things used to be.

When many different people are working on a project simulateously, pull requests can go stale quickly. A "stale" pull request is one that is no longer up to date with the main line of development, and it needs to be updated before it can be merged into the project. The most common reason why pull requests go stale is due to conflicts: if two pull requests both modify similar lines in the same file, and one pull request gets merged, the unmerged pull request will now have a conflict. Sometimes, a pull request can go stale without conflicts: perhaps changes in a different file in the codebase require corresponding changes in your pull request to conform to the new architecture, or perhaps the branch was created when someone had accidentally merged failing unit tests to the master branch. Regardless of the reason, if your pull request has gone stale, you will need to rebase your branch onto the latest version of the master branch before it can be merged.

---

Rebasing rewrites history. If nobody knows about that history, then that is perfectly fine. If, however, that history is publicly known, then rewriting history in Git works just the way it does in the real world: you need a conspiracy.

Conspiracies are really hard keep together, so you better avoid rebasing public branches in the first place.

Note that there are examples of successful conspiracies: the pu branch of Junio C. Hamano's git repository (the official repository of the Git SCM) is rebased frequently. The way that this works is that pretty much everybody who uses pu is also subscribed to the Git developer mailinglist, and the fact that the pu branch is rebased is widely publicized on the mailinglist and the Git website.

---

리베이스는 저장소의 기록을 변경합니다. 커밋을 다른 사람이 사용할 수 있도록 만든 다음 커밋 기록에 대한보기를 변경하면 커밋을 세계로 푸시하고 이전 기록을 가진 사람과 함께 작업하기가 어려워집니다.

유해한 것으로 간주되는 Rebase 는 좋은 개요라고 생각합니다.

참고 URL : https://stackoverflow.com/questions/2715085/rebasing-and-what-does-one-mean-by-rebasing-pushed-commits