[초보자 본방사수!?]git rebase 사용 시기😈

결론

대신 git merge 사용하세요!

서문

본 기사에서 리베이스 초보자의'리베이스는 어디서 어떻게 사용해야 좋을까요?'🤔」의문
리베이스는 초통용 명령이기 때문에.
저는 Git 마스터 여러분께는 부족하다고 생각합니다. 양해해 주십시오.🙇

자세한 설명

git rebase

해설문.
중요한 것은 지점의 역사 왜곡 명령이다.

git merge

해설문.
관건은 지점과 지점을 통합하는 명령이다.

왜 일부러 Rebase를 사용합니까?

전제 조건

현재 부모 지점 마스터와 하위 지점 개발자가 있다고 가정하십시오.
그림의 숫자는 시간순으로 제출된 순서입니다.
시간 서열이master→develop→master인지 알고 싶습니다.
기계 분기

develop 분기

로그 더럽히기 제출

gitmerge는 강력한 분기 합병 명령이다コミットログがぐちゃぐちゃになっていく의 문제.
요소 1: 작업 지점의 제출 사이에 다른 지점의 제출이 포함됨
이것은 개발자에서 $gitmergemaster를 실행한 결과입니다.

개발자가 제출하는 동안 마스터 지점의 제출이 왔습니다.
gitmerge라면 시간 순서대로 배열하고 통합해서 제출하기 때문에 어쩔 수 없습니다.
왠지 개발자의 제출이 통일되고 싶지 않나요?
요소 2:merge 메시지 생성
위의 그림의 맨 위에commit이 기억하지 못하는 제출이 있습니다.
이것은 합병할 때 반드시 생성해야 하는 제출이다.
매번merge가 생성되기 때문에 상당히 높은 주파수로 들어갑니다.
평론가와 인코더가 제출한 이력을 추적할 때는 전혀 필요하지 않죠?
최대한 줄이고 싶지 않아요?

그러니까 리베이스를 사용하세요!

지금,merge가 아닌 $git rebase 마스터를 실행한 결과를 보겠습니다.

합의하다

그림처럼 마스터 지점의 제출 아래로
현재 개발자의 모든 제출은 위에 있습니다.너무 예뻐요!🔅

커밋 병합 실패

gitmerge 시 생성된 합병 제출이 없습니다!아름답다

사용할 수 없는rebase

이렇게 아름다운 제출 로그를 만드는rebase는 사용할 수 없는 장면이 있습니다.
그것은 複数人が参照しているブランチ에 변경이 포함된 상황이다.
다음은 대여 이미지 모 페이지
개발 지점에서 두 개의 기능 개발 지점이 분리되었습니다.

모든 피처의 지점만이 이런 지점 구조에서rebase를 진행할 수 있습니다!
개발자 지점에서 여러 개의 기능 지점에 인용됨
리베이스를 제어하는 데 비교적 노력한다.

왜 못 써요?

자신보다 더 상세하게 설명하는 사이트가 많아요!
예를 들면 이 사이트.
요컨대 리베이스는 역사를 바꾸는 처리이다.
그래서 feature는 개발자의 오래된 역사에 있습니다.
의존할 때 개발자의 역사가 완전히 다르다면
그리고 피처 지점을 개발자 지점에 넣으면 충돌하는 빗방울이 나타납니다.😭

그럼 어디에서 사용해야 하나요?

기능 추가 또는 수정 등
자신이 자료고에서 무슨 일을 할 때 반드시 지점을 끊어야 하지 않겠습니까?
이런 1人しか見ていない、参照していないブランチ에서rebase를 사용하면 됩니다.
예를 들어,rebase를 사용하여
작고 예쁜 제출을 할 수 있고 대량 생산 합병 제출을 하지 않아도 된다.

그럼 rebase는 merge에서만 쓰면 돼요!

사실,rebase의 진정한 의미는git역사를 개작하는 명령이다
merge와 같지 않습니다.
rebase는 더 많은 가능성을 가지고 있습니다. 반드시 다른 용도를 찾으십시오.

결론

따라서rebase는 혼자서 참조하는 말단의 지점에서 진행합니다!
merge를 사용하여 마스터와 개발자 등 여러 인코더가 인용하는 지점을 처리하세요!
좋은 Git 생활~😘