TL; DR

의심스러운 경우 merge를 사용하십시오.

짧은 답변

리베이스와 병합의 유일한 차이점은 다음과 같습니다.

• 히스토리의 결과 트리 구조 (일반적으로 커밋 그래프를 볼 때만 눈에))는 다릅니다 (하나는 가지가 있고 다른 하나는 가지지 않습니다).
• 병합은 일반적으로 추가 커밋 (예 : 트리의 노드)을 만듭니다.
• 병합과 리베이스는 충돌을 다르게 처리합니다. Rebase는 병합이 한 번에 하나의 커밋을 표시하는 한 번에 한 번의 커밋을 나타냅니다.

따라서 짧은 대답은 당신의 역사가 어떻게 보이길 원하는지를 기반으로 리베이스 또는 병합 을 선택하는 것 입니다.

긴 답변

사용할 작업을 선택할 때 고려해야 할 몇 가지 요소가 있습니다.

변경을 받고있는 지점이 팀 외부의 다른 개발자 (예 : 공개 소스, 공개)와 공유됩니까?

그렇다면 리베이스하지 마십시오. Rebase는 지사를 파괴하고 개발자가 사용하지 않는 한 해당 저장소가 손상되었거나 일관되지 않습니다 git pull --rebase. 이것은 다른 개발자들을 빠르게 화나게하는 좋은 방법입니다.

개발팀은 얼마나 능숙합니까?

Rebase는 파괴적인 작업입니다. 즉, 제대로 적용하지 않으면 커밋 된 작업이 손실되거나 다른 개발자 리포지토리의 일관성이 손상 될 수 있습니다.

저는 회사가 지점과 합병에 대한 전담 직원을 감당할 수있는 시점에서 개발자가 모두 온 팀에서 일했습니다. 그 개발자들은 Git에 대해 잘 모르고 많이 알고 싶지 않습니다. 이 팀에서 나는 어떤 이유로 든 rebasing을 추천 할 위험이 없습니다.

지점 자체가 유용한 정보를 나타 냅니까

일부 팀은 각 지점이 기능 (또는 버그 수정 또는 하위 기능 등)을 나타내는 기능별 지점 모델을 사용합니다.이 모델에서 지점은 관련 커밋 세트를 식별하는 데 도움이됩니다. 예를 들어, 해당 분기의 병합을 되돌려 서 피쳐를 신속하게 되돌릴 수 있습니다 (공평하게도 드문 작업입니다). 또는 두 가지를 비교하여 기능을 비교하십시오 (더 일반적). Rebase는 지점을 파괴하고 이것은 간단하지 않습니다.

또한 개발자 당 지점 모델을 사용하는 팀에서 일했습니다 (모두가 있었음). 이 경우 지점 자체는 추가 정보를 전달하지 않습니다 (커밋에는 이미 작성자가 있음). 리베이스에 아무런 해가 없습니다.

어떤 이유로 든 병합을 되 돌리시겠습니까?

취소 취소와 같이 리베이스를 되 돌리는 것은 병합을 되 돌리는 것과 비교하여 상당히 어렵거나 불가능합니다 (리베이스에 충돌이있는 경우). 되돌릴 가능성이 있다고 생각되면 되돌리기를 사용하고 병합을 사용하십시오.

팀에서 일하십니까? 그렇다면이 지점에 대해 전혀 또는 전혀 접근하지 않겠습니까?

Rebase 작업은 해당으로 가져와야합니다 git pull --rebase. 혼자서 작업하는 경우 적절한 시간에 사용해야하는 것을 기억할 수 있습니다. 팀에서 작업하는 경우 조정하기가 매우 어렵습니다. 이것이 대부분의 rebase 워크 플로우가 모든 병합 (및 git pull --rebase모든 풀)에 rebase를 사용하도록 권장하는 이유 입니다.

일반적인 신화

병합은 역사를 파괴합니다 (커밋을 과장)

다음과 같은 병합이 있다고 가정합니다.

    B -- C
   /      \
  A--------D

어떤 사람들은 병합이 커밋 히스토리를 “파괴”한다고 말하는데, 이는 마스터 브랜치 (A-D)의 로그 만 살펴보면 B와 C에 포함 된 중요한 커밋 메시지를 놓치기 때문입니다.

이것이 사실이라면 우리는 이와 같은 질문 이 없을 것 입니다. 기본적으로 B와 C를 보지 않으면 명시 적으로 보지 않는 한 (–first-parent 사용) B가 표시됩니다. 이것은 스스로 시도하기가 매우 쉽습니다.

Rebase를 사용하면보다 안전하고 간단한 병합이 가능합니다

두 가지 접근 방식은 서로 다르게 병합되지만 하나가 항상 다른 것보다 낫다는 것은 확실하지 않으며 개발자 워크 플로에 따라 달라질 수 있습니다. 예를 들어, 개발자가 정기적으로 커밋하는 경향이있는 경우 (예 : 직장에서 집으로 전환 할 때 하루에 두 번 커밋) 지정된 브랜치에 대해 커밋이 많이있을 수 있습니다. 이러한 커밋의 대부분은 최종 제품과 같이 보이지 않을 수도 있습니다 (기능마다 한두 번 내 접근 방식을 리팩터링하는 경향이 있습니다). 다른 사람이 관련 코드 영역에서 작업하고 있고 내 변경 사항을 리베이스하려고하면 상당히 지루한 작업 일 수 있습니다.

Rebase는 더 시원하고 더 섹시하고 전문적입니다

“시간 절약” 으로 별칭 rm을 지정 rm -rf하려면 rebase가 적합합니다.

내 두 센트

저는 언젠가 Git rebase가 문제를 해결하는 멋진 도구 인 시나리오를 보게 될 것이라고 생각합니다. Git reflog가 내 문제를 해결하는 멋진 도구 인 시나리오를 보게 될 것이라고 생각합니다. 나는 지금 5 년 이상 Git과 함께 일했다. 일어나지 않았습니다.

지저분한 역사는 실제로 나에게 문제가되지 않았습니다. 나는 신나는 소설처럼 내 커밋 역사를 읽지 않습니다. 어쨌든 Git 비난이나 Git bisect를 사용할 역사가 필요합니다. 이 경우 병합 커밋을 갖는 것이 실제로 유용합니다. 병합에서 문제가 발생하면 의미있는 정보가되기 때문입니다.

업데이트 (4/2017)

내 일반적인 조언은 여전히 ​​유효하지만 rebase 사용을 개인적으로 부드럽게했다고 언급 할 의무가 있습니다. 최근에 Angular 2 Material 프로젝트 와 많은 상호 작용을 해왔습니다 . 그들은 rebase를 사용하여 매우 깨끗한 커밋 기록을 유지했습니다. 이를 통해 커밋이 특정 결함을 수정 한 내용과 해당 커밋이 릴리스에 포함되었는지 여부를 매우 쉽게 확인할 수있었습니다. 리베이스를 올바르게 사용하는 좋은 예입니다.

---

답변