힘내 병합 전략 옵션
git-revert - 기존 커밋을 되돌립니다.
기술.
하나 이상의 기존 커밋이 주어지면 관련 패치가 도입 한 변경 사항을 되돌리고 새로운 커밋을 기록합니다. 이렇게하려면 작업 트리가 깨끗해야합니다 (HEAD 커밋을 수정하지 않아야합니다).
참고 : git revert는 일부 커밋 (일부 커밋)의 영향을 취소하기 위해 새로운 커밋을 기록하는 데 사용됩니다. 커밋되지 않은 모든 변경 사항을 작업 디렉토리에 버리려면 git-reset [1], 특히 --hard 옵션이 표시되어야합니다. 특정 파일을 다른 커밋과 마찬가지로 추출하려면 git checkout [1], 특히 git checkout & lt; commit & gt; & lt; filename & gt; 통사론. 두 가지 방법 모두 작업 디렉토리에서 커밋되지 않은 변경 사항을 무시하므로 이러한 대안으로주의하십시오.
되 돌리는 커밋. 커밋 이름의 철자를 지정하는 방법에 대한 자세한 내용은 gitrevisions [7]를 참조하십시오. 커밋 세트도 지정할 수 있지만 기본적으로 트래버스가 수행되지 않습니다. git-rev-list [1] 및 --no-walk 옵션을 참조하십시오.
이 옵션을 사용하면 되돌리기를 커밋하기 전에 커밋 메시지를 편집 할 수 있습니다. 터미널에서 명령을 실행하면 이것이 기본값입니다.
-m parent-number --mainline 상위 번호.
일반적으로 병합의 어느 쪽을 메인 라인으로 간주해야할지 모르기 때문에 병합을 되돌릴 수 없습니다. 이 옵션은 메인 라인의 부모 번호 (1부터 시작)를 지정하고 복귀하여 지정된 부모에 대한 변경을 되돌릴 수 있습니다.
병합 커밋을 되 돌리면 병합으로 가져온 트리 변경을 절대로 원하지 않는다고 선언됩니다. 결과적으로 나중의 병합은 이전에 되돌려 진 병합의 조상이 아닌 커밋에 의해 도입 된 트리 변경 사항 만 가져옵니다. 이것은 당신이 원하는 것일 수도 아닐 수도 있습니다.
이 옵션을 사용하면 git 되돌리기가 커밋 메시지 편집기를 시작하지 않습니다.
일반적으로 명령은 커밋이 복귀 된 커밋 로그 메시지가있는 커밋을 자동으로 만듭니다. 이 플래그는 명명 된 커밋을 작업 트리와 인덱스로 되돌리기 위해 필요한 변경 사항을 적용하지만 커밋을하지는 않습니다. 또한이 옵션을 사용하면 인덱스가 HEAD 커밋과 일치하지 않아도됩니다. 되돌리기는 색인의 시작 상태에 대해 수행됩니다.
이 기능은 하나 이상의 행에 커밋 효과를 인덱스로 되돌릴 때 유용합니다.
GPG - 서명이 커밋됩니다. keyid 인수는 선택적이며 커미터 ID로 기본 설정됩니다. 지정된 경우 공백없이 옵션에 고정되어야합니다.
추가 커밋 메시지의 끝에 서명 된 회선을 추가합니다. 자세한 정보는 git-commit [1]의 signoff 옵션을 참조하십시오.
주어진 병합 전략을 사용하십시오. 한 번만 사용해야합니다. 자세한 내용은 git-merge [1]의 MERGE STRATEGIES 섹션을 참조하십시오.
병합 전략 관련 옵션을 병합 전략에 전달하십시오. 자세한 내용은 git-merge [1]를 참조하십시오.
SEQUENCER SUBCOMMANDS.
.git / sequencer의 정보를 사용하여 진행중인 작업을 계속 진행하십시오. 체리 피킹 실패 또는 되돌리기에서 충돌을 해결 한 후에 계속 사용할 수 있습니다.
현재 진행중인 작업은 잊어 버려야합니다. 체리 피킹 또는 되돌리기 실패 후 시퀀서 상태를 지우는 데 사용할 수 있습니다.
작업을 취소하고 사전 시퀀스 상태로 돌아갑니다.
HEAD에서 네 번째 마지막 커밋에 지정된 변경 사항을 되돌리고 되돌리기 변경 내용을 사용하여 새 커밋을 만듭니다.
git revert - n master.
master (포함)의 마지막 다섯 번째 커밋에서 master (포함 된)의 세 번째 마지막 커밋까지의 커밋에 의해 수행 된 변경 사항을 되돌리고, 되돌리기 된 변경 사항을 가진 커밋을 생성하지 않습니다. 되돌리기는 작업 트리와 색인 만 수정합니다.
힘내 병합 전략 옵션
App Store를 통해 가져 오기 우리의 응용 프로그램 에서이 게시물을 읽으십시오!
힘내는 재귀 적 전략과 인내 옵션을 사용하여 합치십시오.
재귀 적 전략에 의해 제공되는 인내 옵션을 사용하여 git과 브랜치를 병합하는 방법은 무엇입니까? 나는 자식 버전 1.7.3.1.msysgit.0을 사용하고있다.
문서조차도 일관성이 없으며 실제 명령이 출력하는 것과 다릅니다.
git merge [-s & lt; strategy & gt; ] [-X & lt; strategy-option & gt; ] & lt; 커밋 & gt;
그리고 더 본문에서 :
명령의 출력은 다음과 같습니다.
그래서 나는 다음과 같은 결과로 몇 가지 버전을 시도 :
옵션이 구현되지 않은 것처럼 보입니다.
git merge-recursive의 --patience 옵션이 커밋 58a1ece478c6038a7eb0b6e494d563bd5e6d5978에 도입되었습니다. git. git의 복제본에서 git 태그로이 변경 사항을 포함하는 버전을 확인할 수 있습니다 - 58a1ece478 포함 :
그래서 저는 여러분이 mSysGit의 약간 낡은 버전을 사용하고 있다고 의심합니다. 현재 1.7.4 버전의 미리보기 버전을 사용할 수 있습니다. 이 버전을 사용해보아야합니다.
나는 단지 git 버전 1.7.4에서이 것을 시도해 보았고, 다음과 같은 명령 행 문법이 나에게 도움이되었다.
Git1.7.2.2를 기반으로 재귀 적 병합 전략에 인내심 옵션을 도입 한 패치를 보았습니다. 그러나 이후의 릴리스 노트에서는 보이지 않습니다.
그러나 인내 diff 알고리즘은 2009 년부터 제공되었으며 여기에서 자세히 설명합니다.
병합 명령은이 옵션을 이해해야합니다. 아래의이 함수는 결코 호출되지 않는 것 같습니다 (merge-recursive. c 나 다른 *.c 파일의 어느 곳에도 존재하지 않습니다!) :
"알 수없는 옵션"오류 메시지는 git. c의 handle_options 함수에 의해서만 인쇄됩니다.
그리고 XDF_PATIENCE_DIFF는 git 소스 (1.7.4)의 다른 곳에서는 보이지 않습니다. 그래서 네, 병합을 위해 이것이 어떻게 구현 될지 모르겠습니다.
힘내 병합 전략 옵션
git-merge - 두 개 이상의 개발 기록을 함께 결합합니다.
기술.
그들의 커밋이 현재 브랜치에서 분기 된 이후로 명명 된 커밋의 변경 사항을 현재 브랜치에 반영합니다. 이 명령은 git pull이 다른 저장소의 변경 내용을 통합하는 데 사용되며 한 지점에서 다른 지점으로 변경 사항을 병합하기 위해 손으로 사용할 수 있습니다.
다음 기록이 존재하고 현재 분기가 "마스터"라고 가정합니다.
그런 다음 "git merge topic"은 마스터 (즉, E)에서 현재 커밋 (C)까지 마스터 분기와 분기 된 이후의 주제 분기에 대한 변경 사항을 재생하고 이름과 함께 새로운 커밋에 결과를 기록합니다 두 개의 상위 커밋과 변경 사항을 설명하는 사용자의 로그 메시지가 표시됩니다.
두 번째 구문 ( "git merge --abort")은 병합 결과 충돌이 발생한 후에 만 실행할 수 있습니다. git merge --abort는 병합 프로세스를 중단하고 병합 전 상태를 재구성합니다. 그러나 병합이 시작될 때 커밋되지 않은 변경 사항이있는 경우 (특히 병합이 시작된 후 변경 사항이 더 많이 수정 된 경우) git merge --abort는 경우에 따라 원래의 병합 변경 사항을 재구성 할 수 없습니다. 따라서:
경고 : 커밋되지 않은 커밋되지 않은 변경 사항으로 git merge를 실행하는 것은 권장하지 않습니다. 가능하면 충돌이 발생해도 복구가 어려울 수 있습니다.
네 번째 구문 ( "git merge --continue")은 병합이 충돌 한 후에 만 실행할 수 있습니다.
병합을 수행하고 결과를 커밋하십시오. 이 옵션을 사용하여 --no-commit을 대체 할 수 있습니다.
--no-commit을 사용하면 병합을 수행하지만 병합을 실패한 것으로 가정하고 자동 커밋하지 않으므로 사용자가 커밋하기 전에 병합 결과를 검사하고 추가 조정할 수 있습니다.
성공적인 기계적 병합을 커밋하기 전에 편집기를 호출하여 자동 생성 된 병합 메시지를 추가로 편집하여 사용자가 병합을 설명하고 정당화 할 수 있도록합니다. --no-edit 옵션을 사용하여 자동 생성 된 메시지를 수락 할 수 있습니다 (일반적으로 권장하지 않음). --edit (또는 - e) 옵션은 명령 행에서 - m 옵션과 함께 초안 메시지를 제공하고 편집기에서 편집하려는 경우 여전히 유용합니다.
이전 스크립트는 사용자가 병합 로그 메시지를 편집하지 못하도록하는 이전 동작에 따라 달라질 수 있습니다. git merge를 실행할 때 열리는 편집기를 볼 수 있습니다. 이러한 스크립트를 업데이트 된 동작으로 쉽게 조정할 수 있도록 환경 변수 GIT_MERGE_AUTOEDIT는 시작 부분에서 no로 설정할 수 있습니다.
병합이 빨리 감기로 해결되면 병합 커밋을 만들지 않고 분기 포인터 만 업데이트하십시오. 이는 기본 동작입니다.
병합이 빨리 감기로 해결되는 경우에도 병합 커밋을 만듭니다. 주석이있는 (그리고 아마도 서명 된) 태그를 병합 할 때의 기본 동작입니다.
현재 HEAD가 이미 최신 상태이거나 병합을 빨리 감기로 해결할 수없는 경우가 아니면 0이 아닌 상태로 병합 및 종료를 거부합니다.
결과 병합 커밋에 GPG 서명하십시오. keyid 인수는 선택적이며 커미터 ID로 기본 설정됩니다. 지정된 경우 공백없이 옵션에 고정되어야합니다.
브랜치 이름 외에도 로그 메시지에 기껏해야 & lt; n & gt; 병합중인 실제 커밋 git-fmt-merge-msg [1]를 참고하십시오.
--no-log를 사용하면 병합중인 실제 커밋의 한 줄 설명을 나열하지 않습니다.
병합이 끝나면 diffstat를 표시합니다. diffstat도 구성 옵션 merge. stat에 의해 제어됩니다.
-n 또는 --no-stat를 사용하면 병합이 끝날 때 diffstat가 표시되지 않습니다.
실제 병합이 일어난 것처럼 작업 트리와 인덱스 상태를 생성하지만 (머지 정보 제외) 실제로 커밋하지 않고 HEAD를 이동하거나 $ GIT_DIR / MERGE_HEAD를 기록합니다 (다음 git commit 명령으로 병합 커밋). 이렇게하면 다른 브랜치 (또는 문어의 경우 더 많이)를 병합하는 것과 동일한 효과를 가지는 현재 브랜치의 맨 위에 단일 커밋을 생성 할 수 있습니다.
--no-squash를 사용하면 병합을 수행하고 결과를 커밋합니다. 이 옵션은 --squash를 무시하는 데 사용할 수 있습니다.
주어진 병합 전략을 사용하십시오. 시도해야하는 순서대로 지정하기 위해 두 번 이상 제공 할 수 있습니다. - s 옵션이 없으면 대신 내장 전략 목록이 사용됩니다 (단일 헤드를 병합 할 때 git merge-recursive, 그렇지 않으면 git merge-octopus).
-X & lt; 옵션 & gt; --strategy-option = & lt; 옵션 & gt;
병합 전략 특정 옵션을 통해 병합 전략에 전달하십시오.
병합중인 사이드 분기의 팁 커밋이 유효한 키, 즉 유효한 uid가있는 키로 서명되었는지 확인합니다. 기본 신뢰 모델에서는 서명 키가 신뢰할 수있는 키로 서명되었음을 의미합니다. 사이드 브랜치의 팁 커밋이 유효한 키로 서명되지 않으면 병합이 중단됩니다.
--stat와 --no-stat의 동의어; 이것들은 더 이상 사용되지 않으며 앞으로 제거 될 것입니다.
조용히 작동하십시오. 암시 - 진전 없음.
진행 상태를 명시 적으로 켜고 끕니다. 둘 다 지정하지 않으면 표준 오류가 터 L 널에 연결된 경우 진행이 표시됩니다. 모든 병합 전략이 진행률보고를 지원하지는 않습니다.
기본적으로 git merge 명령은 공통 조상을 공유하지 않는 기록을 병합하는 것을 거부합니다. 이 옵션은 생명을 독립적으로 시작한 두 프로젝트의 기록을 병합 할 때이 안전을 무시하는 데 사용할 수 있습니다. 매우 드물기 때문에 기본적으로이를 활성화하는 구성 변수가 없으므로 추가되지 않습니다.
Commit 로그 메시지의 끝에 Committer에 의해 Signed-by-by 행을 추가하십시오. 사인의 의미는 프로젝트에 따라 다르지만 일반적으로 커미터가 동일한 라이선스로이 저작물을 제출할 권한이 있으며 개발자 원산지 증명서 (개발자 인증서 참조)에 동의한다는 것을 증명합니다.
병합 커밋에 사용될 커밋 메시지를 설정합니다 (생성 된 경우).
--log가 지정되면 병합중인 커밋의 짧은 로그가 지정된 메시지에 추가됩니다.
git fmt-merge-msg 명령은 자동화 된 git merge 호출에 좋은 기본값을 제공하는 데 사용할 수 있습니다. 자동화 된 메시지에는 분기 설명이 포함될 수 있습니다.
가능하다면 rerere 메커니즘이 자동 충돌 해결의 결과로 색인을 갱신하도록하십시오.
현재 충돌 해결 프로세스를 중단하고 병합 전 상태를 재구성하십시오.
병합이 시작될 때 커밋되지 않은 작업 트리 변경 사항이 있으면 git merge --abort가 경우에 따라 이러한 변경 사항을 재구성 할 수 없습니다. 따라서 git merge를 실행하기 전에 변경 사항을 항상 커밋하거나 숨겨 두는 것이 좋습니다.
git merge --abort는 MERGE_HEAD가있는 경우 git reset --merge와 같습니다.
git merge가 충돌로 멈춘 후에는 git merge --continue를 실행하여 병합을 마칠 수 있습니다 (아래의 "충돌 문제 해결 방법"참조).
우리 지점으로 합병하기 위해 대개 다른 지점장을 임명합니다. 두 개 이상의 커밋을 지정하면 두 개 이상의 부모와 병합이 생성됩니다 (옥토퍼 병합이라고도 함).
명령 줄에서 커밋을하지 않으면 현재 분기가 업스트림으로 사용하도록 구성된 원격 추적 분기를 병합합니다. 이 매뉴얼 페이지의 설정 부분을 참고하십시오.
FETCH_HEAD (및 다른 커밋 없음)가 지정되면 병합을 위해 git fetch를 이전에 호출하여. git / FETCH_HEAD 파일에 기록 된 분기가 현재 분기에 병합됩니다.
예비 병기 검사.
외부 변경 사항을 적용하기 전에 올바른 모양으로 작업하고 로컬로 커미트해야하므로 충돌이 발생해도 문제가 해결되지 않습니다. git-stash [1]를 참고하십시오. git pull 및 git merge는 로컬 uncommitted 변경이 git pull / git merge가 업데이트해야 할 수도있는 파일과 겹칠 때 아무 작업도하지 않고 중단됩니다.
헤더 커밋과 관련된 인덱스에 등록 된 변경 사항이 있으면 병합 커밋에서 관련이없는 변경 사항을 기록하지 않도록 git pull 및 git merge도 중단됩니다. (한 가지 예외는 변경된 색인 항목이 이미 병합 된 상태 일 때입니다.)
모든 명명 된 커밋이 이미 HEAD의 조상 인 경우 git 병합은 "Already up to date"메시지와 함께 일찍 종료됩니다.
신속한 병합.
종종 현재 브랜치 헤드는 명명 된 커밋의 조상입니다. 이것은 git pull에서 호출 할 때 가장 흔한 경우입니다. 업스트림 저장소를 추적하고 로컬 변경 사항을 커밋하지 않았으며 이제는 새로운 업스트림 리비전으로 업데이트하려고합니다. 이 경우, 새로운 커밋은 결합 된 히스토리를 저장하는 데 필요하지 않다; 대신, HEAD (색인과 함께)는 추가 병합 확약을 작성하지 않고 명명 된 확약을 가리 키도록 갱신됩니다.
이 동작은 --no-ff 옵션으로 생략 할 수 있습니다.
TRUE MERGE.
빨리 감기 병합 (위 참조)을 제외하고, 병합 할 브랜치는 양쪽 모두를 부모로 가지는 병합 커밋에 의해 묶여 야합니다.
병합 할 모든 분기의 변경 사항을 조정하는 병합 된 버전이 커밋되고 HEAD, 색인 및 작업 트리가 커밋됩니다. 겹치지 않는 한 작업 트리를 수정할 수 있습니다. 업데이 트가 그들을 보존합니다.
변경 사항을 조정하는 방법이 명확하지 않으면 다음이 발생합니다.
HEAD 포인터는 그대로 유지됩니다.
MERGE_HEAD ref는 다른 브랜치 헤드를 가리 키도록 설정됩니다.
깔끔하게 병합 된 경로는 인덱스 파일과 작업 트리에서 모두 업데이트됩니다.
충돌하는 경로의 경우 색인 파일은 최대 세 가지 버전을 기록합니다. 1 단계는 공통 조상의 버전, HEAD의 2 단계, MERGE_HEAD의 3 단계를 저장합니다 (git ls-files - u를 사용하여 스테이지를 검사 할 수 있음). 작업 트리 파일에는 "병합"프로그램의 결과가 포함됩니다. 3-way merge) 결과를 친숙한 갈등 마커 (& lt; === & gt; & gt; & gt; .
다른 변경 사항은 없습니다. 특히 병합을 시작하기 전에 가지고 있던 로컬 수정 사항은 동일하게 유지되고 색인 항목은 그대로, 즉 HEAD와 일치하게 유지됩니다.
복잡한 충돌을 일으키고 다시 시작하려는 병합을 시도한 경우 git merge --abort를 사용하여 복구 할 수 있습니다.
머기 태그.
주석이 달린 (그리고 아마도 서명 된) 태그를 병합 할 때 Git은 빨리 감기 병합이 가능하다하더라도 항상 병합 커밋을 생성하고, 커밋 메시지 템플릿은 태그 메시지와 함께 준비됩니다. 또한 태그가 서명 된 경우 서명 확인은 메시지 템플리트에서 주석으로보고됩니다. git-tag [1]를 참고하십시오.
태그가 붙은 커밋으로 이어지는 작업과 통합하려는 경우 (예 : 업스트림 릴리스 포인트와 동기화 할 때 불필요한 병합 완료를 원하지 않을 수 있습니다.
이 경우, git merge에 넘기 전에 태그를 "unwrap"할 수 있고, 스스로 작업하지 않았을 때만 - ff-pass를 전달할 수 있습니다. 예 :
충돌이 나타나기 시작합니다.
병합하는 동안 작업 트리 파일은 병합 결과를 반영하도록 업데이트됩니다. 공통 조상의 버전에 대한 변경 사항 중 중복되지 않는 항목 (즉, 파일의 영역을 변경하고 다른 영역은 그대로 남겨 두거나 그 반대의 경우도 마찬가지 임)은 최종 결과에 그대로 통합됩니다. 그러나 양측이 같은 영역을 변경하면 Git은 한쪽을 다른 쪽보다 무작위로 선택할 수 없으며 양측이 그 영역에 남긴 것을 남겨 두어 해결하도록 요청합니다.
기본적으로 Git은 RCS 제품군의 "병합"프로그램에서 사용하는 스타일과 동일한 스타일을 사용하여 다음과 같이 충돌하는 이러한 혼란을 표시합니다.
충돌하는 한 쌍의 변화가 발생한 영역은 & lt; & lt; & lt; & lt; & lt; & lt; & lt; , =======, & gt; & gt; & gt; & gt; & gt; & gt; & gt; . 그 부분은 전형적으로 당신 쪽이고, 그 부분은 전형적으로 그들 편입니다.
기본 서식에는 충돌 영역에서 원본이 말한 내용이 표시되지 않습니다. 얼마나 많은 라인이 삭제되어 바비의 발언으로 바뀌 었는지 말할 수 없습니다. 당신이 말할 수있는 유일한 것은 당신 측이 그것이 어렵다고 말하기를 원하고 당신이 쇼핑을 선호하는 반면, 다른 측은 그것이 쉽다는 것을 주장하기를 원한다는 것입니다.
"merge. conflictStyle"구성 변수를 "diff3"으로 설정하여 대체 스타일을 사용할 수 있습니다. "diff3"스타일에서는 위의 충돌이 다음과 같이 보일 수 있습니다.
또한, & lt; & lt; & lt; & lt; & lt; & lt; , =======, & gt; & gt; & gt; & gt; & gt; & gt; & gt; 다른 마커를 사용합니다. ||||||| 마커 다음에 원래 텍스트가옵니다. 당신은 원고가 사실을 진술했다고 말할 수 있으며, 당신 측은 그 진술에 단순히 포기하고 포기하고 다른 측은보다 긍정적 인 태도를 취하려고했습니다. 원본을보고 더 나은 해상도를 얻을 수도 있습니다.
분쟁을 해결하는 방법.
충돌을 본 후에는 다음 두 가지 작업을 수행 할 수 있습니다.
병합하지 않기로 결정하십시오. 필요한 정리 작업은 인덱스 파일을 HEAD 커밋으로 재설정하여 2를 되돌리고 작업 트리 변경 사항을 2와 3으로 정리하는 것입니다. git merge --abort를 사용하면됩니다.
갈등을 해결하십시오. Git은 작업 트리의 충돌을 표시합니다. 파일을 모양으로 편집하고 git을 사용하여 색인에 추가하십시오. git commit 또는 git merge --continue를 사용하여 거래를 봉인하십시오. 후자의 명령은 git commit을 호출하기 전에 (중단 된) 병합 진행 여부를 확인합니다.
다음과 같은 여러 도구를 사용하여 충돌 문제를 해결할 수 있습니다.
병합 도구를 사용하십시오. git mergetool을 사용하여 병합을 통해 작동하는 그래픽 mergetool을 시작하십시오.
차이점을보세요. git diff는 HEAD 및 MERGE_HEAD 버전의 변경 사항을 강조하는 3 방향 diff를 보여줍니다.
각 지점에서 diff를보십시오. git log --merge - p & lt; path & gt; 먼저 HEAD 버전과 MERGE_HEAD 버전의 diff가 표시됩니다.
원본을보십시오. git show : 1 : filename은 일반적인 조상을 보여줍니다. git show : 2 : filename은 HEAD 버전을 나타내며 git show : 3 : filename은 MERGE_HEAD 버전을 보여줍니다.
현재 브랜치 상단에 브랜치 수정 사항과 향상된 기능을 병합하여 문어 병합을 만듭니다.
우리의 병합 전략을 사용하여 현재 분기에 쓸모없는 분기를 병합하십시오.
현재의 브랜치에 브랜치 maint를 병합 시키지만, 새로운 커밋을 자동으로하지는 마십시오 :
병합에 대한 추가 변경 사항을 포함하거나 자체 병합 완료 메시지를 작성하려는 경우에 사용할 수 있습니다.
병합 커밋에 대한 실질적인 변경 사항을 몰래 사용하려면이 옵션을 악용하지 않아야합니다. bumping release / version name과 같은 작은 픽스 업도 허용됩니다.
병합 전략.
병합 메커니즘 (git merge 및 git pull 명령)을 사용하면 - s 옵션을 사용하여 백엔드 병합 전략을 선택할 수 있습니다. 일부 전략은 자체 옵션을 취할 수도 있습니다. 이 옵션은 - X & lt; option & gt; 자식 병합 및 / 또는 자식 끌어 인수.
이렇게하면 3 방향 병합 알고리즘을 사용하여 두 개의 헤드 (즉, 현재 브랜치와 다른 브랜치)를 해결할 수 있습니다. 그것은 십자가 병합 모호성을 신중하게 탐지하려고 시도하며 일반적으로 안전하고 빠른 것으로 간주됩니다.
이 방법은 3 방향 병합 알고리즘을 사용하는 두 개의 헤드 만 해결할 수 있습니다. 3 방향 병합에 사용할 수있는 공통 조상이 둘 이상이면 공통 조상의 병합 된 트리를 만들어이를 3 방향 병합을위한 참조 트리로 사용합니다. 이는 Linux 2.6 커널 개발 이력에서 가져온 실제 병합 커밋에 대한 테스트로 인해 불일치가 발생하지 않고 병합 충돌이 줄어들 었다고보고되었습니다. 또한 이름 변경과 관련된 병합을 감지하고 처리 할 수 있습니다. 하나의 분기를 가져 오거나 병합 할 때 기본 병합 전략입니다.
재귀 적 전략에는 다음과 같은 옵션이 있습니다.
이 옵션은 우리의 버전을 선호함으로써 충돌하는 덩어리를 자동으로 자동 해결하도록합니다. 우리 쪽과 충돌하지 않는 다른 트리의 변경 사항이 병합 결과에 반영됩니다. 이진 파일의 경우 전체 내용이 우리 측에서 가져옵니다.
이것은 우리의 머지 전략과 혼동되어서는 안됩니다. 이 전략은 다른 트리가 전혀 포함하지 않는 것을 보지 않습니다. 그것은 다른 나무가 한 모든 것을 버리고 우리의 역사에는 그 안에 일어났던 모든 것이 들어 있다고 선언합니다.
이것은 우리와 반대입니다. 우리와 달리, 이 병합 옵션을 혼란스럽게하는 병합을 병합하는 것은 없습니다.
이 옵션을 사용하면 병합 - 재귀 적으로 약간의 시간을 소비하여 중요하지 않은 일치 행 (예 : 별개의 기능에서 오는 중괄호)으로 인해 발생하는 불일치를 피할 수 있습니다. 병합 할 분기가 격렬하게 갈라 졌을 때 이것을 사용하십시오. git-diff [1] --patience를 참고하십시오.
병합 - 재귀 적으로 다른 diff 알고리즘을 사용하도록 지정합니다. 중요하지 않은 매칭 라인 (뚜렷한 기능의 중괄호)으로 인해 발생하는 불일치를 피할 수 있습니다. git-diff [1] --diff-algorithm도 참조하십시오.
ignore-space-change ignore-all-space ignore-space-at-eol.
3 방향 병합을 위해 표시된 공백 변경 유형의 행을 변경되지 않은 것으로 처리합니다. 행에 대한 다른 변경 사항과 혼합 된 공백 변경 사항은 무시되지 않습니다. git-diff [1] - b, - w 및 --ignore-space-at-eol도 참조하십시오.
그들의 버전이 라인에 공백 변경만을 도입한다면, 우리의 버전이 사용됩니다;
우리의 버전이 공백 변경을 도입했지만 그들의 버전이 상당한 변화를 포함한다면, 그들의 버전이 사용됩니다;
그렇지 않으면 병합은 일반적인 방법으로 진행됩니다.
3 방향 병합을 해결할 때 가상 체크 아웃을 실행하고 파일의 모든 3 단계를 체크인합니다. 이 옵션은 다른 깨끗한 필터 또는 줄 끝 정규화 규칙으로 분기를 병합 할 때 사용하기위한 것입니다. 자세한 내용은 gitattributes [5]의 "checkin / checkout 속성이 다른 분기를 병합"을 참조하십시오.
재 정규화 옵션을 비활성화합니다. 이것은 merge. renormalize 구성 변수를 겹쳐 씁니다.
이름 바꾸기 감지 기능을 해제하십시오. git-diff [1] --no-renames도 참조하십시오.
이름 바꾸기 감지 기능을 켜고 필요에 따라 유사도 임계 값을 설정합니다. 이것이 기본값입니다. git-diff [1] --find-renames를 참고하십시오.
find-renames = & lt; n & gt;에 대한 더 이상 사용되지 않는 동의어입니다. .
이 옵션은 병합 할 때 두 트리를 서로 맞춰야하는 방식을 추측하는 하위 트리 전략의 고급 형식입니다. 대신 지정된 경로가 두 개의 트리 모양을 일치시키기 위해 접두사로 사용됩니다 (또는 처음부터 제거됩니다).
이 경우 두 개 이상의 헤드가있는 경우는 해결되지만 수동으로 해결해야하는 복잡한 병합은 수행되지 않습니다. 주제 머리말을 함께 묶는 데 주로 사용됩니다. 둘 이상의 분기를 가져 오거나 병합 할 때 기본 병합 전략입니다.
이렇게하면 여러 개의 머리가 처리되지만 병합 된 결과 트리는 항상 현재 분기 헤드의 트리이므로 다른 모든 분기의 모든 변경 사항을 무시합니다. 그것은 사이드 브랜치의 오래된 개발 이력을 대체하기 위해 사용됩니다. 이것은 재귀 병합 전략에 대한 - Xours 옵션과 다릅니다.
이는 수정 된 재귀 적 전략입니다. 나무 A와 B를 병합 할 때 B가 A의 하위 트리에 해당하면 B는 먼저 같은 레벨의 나무를 읽지 않고 A의 트리 구조와 일치하도록 조정됩니다. 이 조정은 공통 조상 트리에서도 수행됩니다.
3- 방향 병합을 사용하는 전략 (기본값, 재귀 포함)을 사용하면 두 분기에서 변경이 이루어 지지만 나중에 분기 중 하나에서 되돌릴 경우 변경 내용이 병합 된 결과에 나타납니다. 어떤 사람들은이 행동이 혼란 스럽다는 것을 알게됩니다. 병합을 수행 할 때 헤드 및 병합베이스 만 고려되므로 개별 커밋이 고려되지 않기 때문에 발생합니다. 따라서 병합 알고리즘은 복귀 된 변경 사항을 전혀 변경되지 않은 것으로 간주하고 대신 변경된 버전으로 대체합니다.
구성.
병합시 충돌 트리가 작업 트리 파일에 쓰여지는 스타일을 지정하십시오. 기본값은 & lt; & lt; & lt; & lt; & lt; & lt; & lt; & lt; 충돌 마커, 한쪽면의 변경 사항, ======= 마커면, 다른 쪽면의 변경 사항, 그리고 & gt; & gt; & gt; & gt; & gt; & gt; 채점자. 다른 스타일 인 "diff3"은 |||||||을 추가합니다. 마커와 원래 텍스트 앞에 ======= 마커가 있습니다.
커밋 인수없이 merge가 호출되면 원격 브랜치 분기에 저장된 마지막 관찰 값을 사용하여 현재 분기에 대해 구성된 업스트림 브랜치를 병합합니다. & lt; branch & gt;.remote라는 브랜치의 이름을 브랜치 & lt; current branch & gt;.remote에 의해 명명 된 리모트에서 브랜치의 이름을 붙이고 & lt; remote & gt;.fetch 해당 원격 추적 브랜치를 추적하고 이러한 추적 분기의 팁을 병합합니다.
기본적으로 Git은 현재 커밋의 자손 인 커밋을 병합 할 때 추가 병합 커밋을 생성하지 않습니다. 대신 현재 분기의 끝이 빨리 전달됩니다. false로 설정하면, 이 변수는 Git에게 그러한 경우에 여분의 병합 커밋을 생성하게합니다 (커맨드 라인에서 --no-ff 옵션을주는 것과 같습니다). only로 설정하면, 그러한 빨리 감기 병합 만 허용됩니다 (명령 행에서 --ff-only 옵션을주는 것과 같습니다).
분기 이름 외에도 로그 메시지에 연관된 분기 설명 텍스트를 채 웁니다. 기본값은 false입니다.
분기 이름 외에도 병합중인 실제 커밋의 지정된 수의 한 줄 설명으로 로그 메시지를 채 웁니다. 기본값은 false이고 true는 20의 동의어입니다.
병합 중에 이름 바꾸기 검색을 수행 할 때 고려해야 할 파일 수. 지정하지 않으면 diff. renameLimit 값이 기본값으로 사용됩니다.
저장소에서 파일의 표준 표현이 시간이 지남에 따라 변경되었음을 Git에게 알려줍니다 (예 : 이전 커밋은 CRLF 행 끝으로 텍스트 파일을 기록하지만 최근에는 LF 행 끝을 사용함). 이러한 저장소에서 Git은 불필요한 충돌을 줄이기 위해 병합을 수행하기 전에 커밋에 기록 된 데이터를 표준 형식으로 변환 할 수 있습니다. 자세한 내용은 gitattributes [5]에서 "checkin / checkout 속성이 다른 분기를 병합"섹션을 참조하십시오.
병합 끝에서 ORIG_HEAD와 병합 결과 사이에 diffstat를 인쇄할지 여부. 기본값은 True입니다.
git-mergetool [1]이 병합 도구를 사용하는 방법을 제어합니다. 아래 목록은 유효한 내장 값을 보여줍니다. 다른 모든 값은 사용자 지정 병합 도구로 취급되며 해당하는 mergetool. & lt; tool & gt;.cmd 변수가 정의되어 있어야합니다.
재귀 적 병합 전략에 의해 표시되는 출력의 양을 제어합니다. 레벨 0은 충돌이 감지되면 최종 오류 메시지를 제외하고는 아무 것도 출력하지 않습니다. 레벨 1은 충돌 만 출력하고, 출력 충돌은 2 개, 파일 변경은 2 개입니다. 레벨 5 이상은 디버깅 정보를 출력합니다. 기본값은 레벨 2입니다. GIT_MERGE_VERBOSITY 환경 변수로 겹쳐 쓸 수 있습니다.
사용자 지정 저수준 병합 드라이버에 대한 사람이 읽을 수있는 이름을 정의합니다. 자세한 내용은 gitattributes [5]를 참조하십시오.
사용자 지정 저수준 병합 드라이버를 구현하는 명령을 정의합니다. 자세한 내용은 gitattributes [5]를 참조하십시오.
공통 조상간에 내부 병합을 수행 할 때 사용할 저수준 병합 드라이버를 명명합니다. 자세한 내용은 gitattributes [5]를 참조하십시오.
& lt; name & gt; 분기로 병합하기위한 기본 옵션을 설정합니다. 구문과 지원되는 옵션은 git merge의 옵션과 동일하지만 공백 문자가 포함 된 옵션 값은 현재 지원되지 않습니다.
힘내 병합 전략 옵션
git-rebase - 다른 기본 팁 위에 커밋을 다시 적용합니다.
기술.
& lt; branch & gt; git rebase가 자동 git checkout & lt; branch & gt;을 수행합니다. 다른 일을하기 전에. 그렇지 않으면 현재 분기에 남아 있습니다.
& lt; upstream & gt; & name. remote 및 branch. & lt; name & gt;.merge 옵션이 사용되며 (자세한 내용은 git-config [1] 참조) --fork-point 옵션이 가정됩니다 . 현재 어떤 지점에도 없거나 현재 분기에 업스트림이 구성되어 있지 않으면 rebase가 중단됩니다.
현재 브랜치에서 커밋에 의해 이루어진 모든 변경 사항은 & lt; 업스트림 & gt; 임시 영역에 저장됩니다. git log & lt; upstream & gt;이 보여줄 커밋과 동일한 커밋 세트입니다. HEAD; 또는 git log 'fork_point'. HEAD, --fork-point가 활성화 된 경우 (아래의 --fork-point에 대한 설명 참조); 또는 - root 옵션이 지정된 경우 git log HEAD 명령을 사용하십시오.
현재 브랜치는 & lt; upstream & gt; 또는 & lt; newbase & gt;로 리셋된다. --onto 옵션이 제공된 경우. 이것은 git reset - hard & lt; upstream & gt;와 똑같은 효과가 있습니다. (또는 & lt; newbase & gt;). ORIG_HEAD는 재설정 전에 분기의 끝을 가리 키도록 설정됩니다.
이전에 임시 영역에 저장된 커밋은 순서대로 현재 분기에 하나씩 다시 적용됩니다. HEAD의 커밋과 동일한 텍스트 변경을 도입하는 HEAD의 커밋은 & lt; upstream & gt; (즉, 다른 커밋 메시지 또는 타임 스탬프로 이미 업스트림에서 수용된 패치는 스킵 될 것이다).
병합 실패로 인해이 프로세스가 완전히 자동으로 수행되지 않을 수도 있습니다. 그런 병합 실패를 해결하고 git rebase --continue를 실행해야합니다. 또 다른 옵션은 병합 실패를 일으킨 커밋을 git rebase --skip으로 우회하는 것입니다. 원래 & lt; branch & gt;.git / rebase-apply 작업 파일을 제거하려면 대신 git rebase --abort 명령을 사용하십시오.
다음 기록이 존재하고 현재 분기가 "주제"라고 가정합니다.
이 시점에서 다음 명령 중 하나의 결과 :
참고 : 후자의 양식은 git checkout 주제의 짧은 손으로 git rebase 마스터가 뒤따른 것입니다. 리베이스 종료시 토픽은 체크 아웃 된 브랜치로 유지됩니다.
업스트림 브랜치에 이미 변경 사항이 포함 된 경우 (예 : 업스트림에 적용된 패치를 메일로 보냈기 때문에) 커밋을 건너 뜁니다. 예를 들어, 다음 기록에서 git rebase master를 실행합니다 (A '와 A는 동일한 변경 집합을 도입하지만 커미터 정보는 다릅니다).
한 브랜치를 기반으로 토픽 브랜치를 다른 브랜치에 이식하여 rebase --onto를 사용하여 후반 브랜치에서 토픽 브랜치를 포크 한 것처럼 가장하는 방법이 있습니다.
먼저 주제가 다음 분기를 기반으로한다고 가정 해 보겠습니다. 예를 들어, 주제에서 개발 된 기능은 다음에 나오는 일부 기능에 따라 다릅니다.
브랜치 마스터에서 토픽을 포크로 만들고 싶습니다. for example, because the functionality on which topic depends was merged into the more stable master branch. We want our tree to look like this:
We can get this using the following command:
Another example of --onto option is to rebase part of a branch. If we have the following situation:
then the command.
would result in:
This is useful when topicB does not depend on topicA.
A range of commits could also be removed with rebase. If we have the following situation:
then the command.
would result in the removal of commits F and G:
This is useful if F and G were flawed in some way, or should not be part of topicA. Note that the argument to --onto and the <upstream> parameter can be any valid commit-ish.
In case of conflict, git rebase will stop at the first problematic commit and leave conflict markers in the tree. You can use git diff to locate the markers (<<<<<<) and make edits to resolve the conflict. For each file you edit, you need to tell Git that the conflict has been resolved, typically this would be done with.
After resolving the conflict manually and updating the index with the desired resolution, you can continue the rebasing process with.
Alternatively, you can undo the git rebase with.
CONFIGURATION.
Whether to show a diffstat of what changed upstream since the last rebase. False by default.
If set to true enable --autosquash option by default.
If set to true enable --autostash option by default.
If set to "warn", print warnings about removed commits in interactive mode. If set to "error", print the warnings and stop the rebase. If set to "ignore", no checking is done. "ignore" by default.
Custom commit list format to use during an --interactive rebase.
Starting point at which to create the new commits. If the --onto option is not specified, the starting point is <upstream>. May be any valid commit, and not just an existing branch name.
As a special case, you may use "A. B" as a shortcut for the merge base of A and B if there is exactly one merge base. You can leave out at most one of A and B, in which case it defaults to HEAD.
Upstream branch to compare against. May be any valid commit, not just an existing branch name. Defaults to the configured upstream for the current branch.
Working branch; defaults to HEAD.
Restart the rebasing process after having resolved a merge conflict.
Abort the rebase operation and reset HEAD to the original branch. If <branch> was provided when the rebase operation was started, then HEAD will be reset to <branch>. Otherwise HEAD will be reset to where it was when the rebase operation was started.
Abort the rebase operation but HEAD is not reset back to the original branch. The index and working tree are also left unchanged as a result.
Keep the commits that do not change anything from its parents in the result.
Restart the rebasing process by skipping the current patch.
Edit the todo list during an interactive rebase.
Use merging strategies to rebase. When the recursive (default) merge strategy is used, this allows rebase to be aware of renames on the upstream side.
Note that a rebase merge works by replaying each commit from the working branch on top of the <upstream> branch. Because of this, when a merge conflict happens, the side reported as ours is the so-far rebased series, starting with <upstream>, and theirs is the working branch. In other words, the sides are swapped.
Use the given merge strategy. If there is no - s option git merge-recursive is used instead. This implies --merge.
Because git rebase replays each commit from the working branch on top of the <upstream> branch using the given strategy, using the ours strategy simply discards all patches from the <branch>, which makes little sense.
Pass the <strategy-option> through to the merge strategy. This implies --merge and, if no strategy has been specified, - s recursive . Note the reversal of ours and theirs as noted above for the - m option.
GPG-sign commits. The keyid argument is optional and defaults to the committer identity; if specified, it must be stuck to the option without a space.
Be quiet. Implies --no-stat.
Be verbose. Implies --stat.
Show a diffstat of what changed upstream since the last rebase. The diffstat is also controlled by the configuration option rebase. stat.
Do not show a diffstat as part of the rebase process.
This option bypasses the pre-rebase hook. See also githooks[5].
Allows the pre-rebase hook to run, which is the default. This option can be used to override --no-verify. See also githooks[5].
Ensure at least <n> lines of surrounding context match before and after each change. When fewer lines of surrounding context exist they all must match. By default no context is ever ignored.
Force a rebase even if the current branch is up to date and the command without --force would return without doing anything.
You may find this (or --no-ff with an interactive rebase) helpful after reverting a topic branch merge, as this option recreates the topic branch with fresh commits so it can be remerged successfully without needing to "revert the reversion" (see the revert-a-faulty-merge How-To for details).
Use reflog to find a better common ancestor between <upstream> and <branch> when calculating which commits have been introduced by <branch>.
When --fork-point is active, fork_point will be used instead of <upstream> to calculate the set of commits to rebase, where fork_point is the result of git merge-base --fork-point <upstream> <branch> command (see git-merge-base[1]). If fork_point ends up being empty, the <upstream> will be used as a fallback.
If either <upstream> or --root is given on the command line, then the default is --no-fork-point , otherwise the default is --fork-point .
These flag are passed to the git apply program (see git-apply[1]) that applies the patch. Incompatible with the --interactive option.
These flags are passed to git am to easily change the dates of the rebased commits (see git-am[1]). Incompatible with the --interactive option.
This flag is passed to git am to sign off all the rebased commits (see git-am[1]). Incompatible with the --interactive option.
Make a list of the commits which are about to be rebased. Let the user edit that list before rebasing. This mode can also be used to split commits (see SPLITTING COMMITS below).
The commit list format can be changed by setting the configuration option rebase. instructionFormat. A customized instruction format will automatically have the long commit hash prepended to the format.
Recreate merge commits instead of flattening the history by replaying commits a merge commit introduces. Merge conflict resolutions or manual amendments to merge commits are not preserved.
This uses the --interactive machinery internally, but combining it with the --interactive option explicitly is generally not a good idea unless you know what you are doing (see BUGS below).
Append "exec <cmd>" after each line creating a commit in the final history. <cmd> will be interpreted as one or more shell commands.
You may execute several commands by either using one instance of --exec with several commands:
or by giving more than one --exec :
If --autosquash is used, "exec" lines will not be appended for the intermediate commits, and will only appear at the end of each squash/fixup series.
This uses the --interactive machinery internally, but it can be run without an explicit --interactive .
Rebase all commits reachable from <branch>, instead of limiting them with an <upstream>. This allows you to rebase the root commit(s) on a branch. When used with --onto, it will skip changes already contained in <newbase> (instead of <upstream>) whereas without --onto it will operate on every change. When used together with both --onto and --preserve-merges, all root commits will be rewritten to have <newbase> as parent instead.
When the commit log message begins with "squash! …" (or "fixup! …"), and there is already a commit in the todo list that matches the same . , automatically modify the todo list of rebase - i so that the commit marked for squashing comes right after the commit to be modified, and change the action of the moved commit from pick to squash (or fixup ). A commit matches the . if the commit subject matches, or if the . refers to the commit’s hash. As a fall-back, partial matches of the commit subject work, too. The recommended way to create fixup/squash commits is by using the --fixup / --squash options of git-commit[1].
This option is only valid when the --interactive option is used.
If the --autosquash option is enabled by default using the configuration variable rebase. autoSquash , this option can be used to override and disable this setting.
Automatically create a temporary stash entry before the operation begins, and apply it after the operation ends. This means that you can run rebase on a dirty worktree. However, use with care: the final stash application after a successful rebase might result in non-trivial conflicts.
With --interactive, cherry-pick all rebased commits instead of fast-forwarding over the unchanged ones. This ensures that the entire history of the rebased branch is composed of new commits.
Without --interactive, this is a synonym for --force-rebase.
You may find this helpful after reverting a topic branch merge, as this option recreates the topic branch with fresh commits so it can be remerged successfully without needing to "revert the reversion" (see the revert-a-faulty-merge How-To for details).
MERGE STRATEGIES.
The merge mechanism ( git merge and git pull commands) allows the backend merge strategies to be chosen with - s option. Some strategies can also take their own options, which can be passed by giving - X<option> arguments to git merge and/or git pull .
This can only resolve two heads (i. e. the current branch and another branch you pulled from) using a 3-way merge algorithm. It tries to carefully detect criss-cross merge ambiguities and is considered generally safe and fast.
This can only resolve two heads using a 3-way merge algorithm. When there is more than one common ancestor that can be used for 3-way merge, it creates a merged tree of the common ancestors and uses that as the reference tree for the 3-way merge. This has been reported to result in fewer merge conflicts without causing mismerges by tests done on actual merge commits taken from Linux 2.6 kernel development history. Additionally this can detect and handle merges involving renames. This is the default merge strategy when pulling or merging one branch.
The recursive strategy can take the following options:
This option forces conflicting hunks to be auto-resolved cleanly by favoring our version. Changes from the other tree that do not conflict with our side are reflected to the merge result. For a binary file, the entire contents are taken from our side.
This should not be confused with the ours merge strategy, which does not even look at what the other tree contains at all. It discards everything the other tree did, declaring our history contains all that happened in it.
This is the opposite of ours ; note that, unlike ours , there is no theirs merge stragegy to confuse this merge option with.
With this option, merge-recursive spends a little extra time to avoid mismerges that sometimes occur due to unimportant matching lines (e. g., braces from distinct functions). Use this when the branches to be merged have diverged wildly. See also git-diff[1] --patience .
Tells merge-recursive to use a different diff algorithm, which can help avoid mismerges that occur due to unimportant matching lines (such as braces from distinct functions). See also git-diff[1] --diff-algorithm .
ignore-space-change ignore-all-space ignore-space-at-eol.
Treats lines with the indicated type of whitespace change as unchanged for the sake of a three-way merge. Whitespace changes mixed with other changes to a line are not ignored. See also git-diff[1] - b , - w , and --ignore-space-at-eol .
If their version only introduces whitespace changes to a line, our version is used;
If our version introduces whitespace changes but their version includes a substantial change, their version is used;
Otherwise, the merge proceeds in the usual way.
This runs a virtual check-out and check-in of all three stages of a file when resolving a three-way merge. This option is meant to be used when merging branches with different clean filters or end-of-line normalization rules. See "Merging branches with differing checkin/checkout attributes" in gitattributes[5] for details.
Disables the renormalize option. This overrides the merge. renormalize configuration variable.
Turn off rename detection. See also git-diff[1] --no-renames .
Turn on rename detection, optionally setting the similarity threshold. This is the default. See also git-diff[1] --find-renames .
Deprecated synonym for find-renames=<n> .
This option is a more advanced form of subtree strategy, where the strategy makes a guess on how two trees must be shifted to match with each other when merging. Instead, the specified path is prefixed (or stripped from the beginning) to make the shape of two trees to match.
This resolves cases with more than two heads, but refuses to do a complex merge that needs manual resolution. It is primarily meant to be used for bundling topic branch heads together. This is the default merge strategy when pulling or merging more than one branch.
This resolves any number of heads, but the resulting tree of the merge is always that of the current branch head, effectively ignoring all changes from all other branches. It is meant to be used to supersede old development history of side branches. Note that this is different from the - Xours option to the recursive merge strategy.
This is a modified recursive strategy. When merging trees A and B, if B corresponds to a subtree of A, B is first adjusted to match the tree structure of A, instead of reading the trees at the same level. This adjustment is also done to the common ancestor tree.
With the strategies that use 3-way merge (including the default, recursive ), if a change is made on both branches, but later reverted on one of the branches, that change will be present in the merged result; some people find this behavior confusing. It occurs because only the heads and the merge base are considered when performing a merge, not the individual commits. The merge algorithm therefore considers the reverted change as no change at all, and substitutes the changed version instead.
You should understand the implications of using git rebase on a repository that you share. See also RECOVERING FROM UPSTREAM REBASE below.
When the git-rebase command is run, it will first execute a "pre-rebase" hook if one exists. You can use this hook to do sanity checks and reject the rebase if it isn’t appropriate. Please see the template pre-rebase hook script for an example.
Upon completion, <branch> will be the current branch.
INTERACTIVE MODE.
Rebasing interactively means that you have a chance to edit the commits which are rebased. You can reorder the commits, and you can remove them (weeding out bad or otherwise unwanted patches).
The interactive mode is meant for this type of workflow:
have a wonderful idea.
hack on the code.
prepare a series for submission.
where point 2. consists of several instances of.
finish something worthy of a commit.
b) independent fixup.
realize that something does not work.
Sometimes the thing fixed in b.2. cannot be amended to the not-quite perfect commit it fixes, because that commit is buried deeply in a patch series. That is exactly what interactive rebase is for: use it after plenty of "a"s and "b"s, by rearranging and editing commits, and squashing multiple commits into one.
Start it with the last commit you want to retain as-is:
An editor will be fired up with all the commits in your current branch (ignoring merge commits), which come after the given commit. You can reorder the commits in this list to your heart’s content, and you can remove them. The list looks more or less like this:
The oneline descriptions are purely for your pleasure; git rebase will not look at them but at the commit names ("deadbee" and "fa1afe1" in this example), so do not delete or edit the names.
By replacing the command "pick" with the command "edit", you can tell git rebase to stop after applying that commit, so that you can edit the files and/or the commit message, amend the commit, and continue rebasing.
If you just want to edit the commit message for a commit, replace the command "pick" with the command "reword".
To drop a commit, replace the command "pick" with "drop", or just delete the matching line.
If you want to fold two or more commits into one, replace the command "pick" for the second and subsequent commits with "squash" or "fixup". If the commits had different authors, the folded commit will be attributed to the author of the first commit. The suggested commit message for the folded commit is the concatenation of the commit messages of the first commit and of those with the "squash" command, but omits the commit messages of commits with the "fixup" command.
git rebase will stop when "pick" has been replaced with "edit" or when a command fails due to merge errors. When you are done editing and/or resolving conflicts you can continue with git rebase --continue .
For example, if you want to reorder the last 5 commits, such that what was HEAD.
4 becomes the new HEAD. To achieve that, you would call git rebase like this:
And move the first patch to the end of the list.
You might want to preserve merges, if you have a history like this:
Suppose you want to rebase the side branch starting at "A" to "Q". Make sure that the current HEAD is "B", and call.
Reordering and editing commits usually creates untested intermediate steps. You may want to check that your history editing did not break anything by running a test, or at least recompiling at intermediate points in history by using the "exec" command (shortcut "x"). You may do so by creating a todo list like this one:
The interactive rebase will stop when a command fails (i. e. exits with non-0 status) to give you an opportunity to fix the problem. You can continue with git rebase --continue .
The "exec" command launches the command in a shell (the one specified in $SHELL , or the default shell if $SHELL is not set), so you can use shell features (like "cd", ">", ";" …). The command is run from the root of the working tree.
This command lets you check that intermediate commits are compilable. The todo list becomes like that:
SPLITTING COMMITS.
In interactive mode, you can mark commits with the action "edit". However, this does not necessarily mean that git rebase expects the result of this edit to be exactly one commit. Indeed, you can undo the commit, or you can add other commits. This can be used to split a commit into two:
Start an interactive rebase with git rebase - i <commit>^ , where <commit> is the commit you want to split. In fact, any commit range will do, as long as it contains that commit.
Mark the commit you want to split with the action "edit".
When it comes to editing that commit, execute git reset HEAD^ . The effect is that the HEAD is rewound by one, and the index follows suit. However, the working tree stays the same.
Now add the changes to the index that you want to have in the first commit. You can use git add (possibly interactively) or git gui (or both) to do that.
Commit the now-current index with whatever commit message is appropriate now.
Repeat the last two steps until your working tree is clean.
Continue the rebase with git rebase --continue .
If you are not absolutely sure that the intermediate revisions are consistent (they compile, pass the testsuite, etc.) you should use git stash to stash away the not-yet-committed changes after each commit, test, and amend the commit if fixes are necessary.
RECOVERING FROM UPSTREAM REBASE.
Rebasing (or any other form of rewriting) a branch that others have based work on is a bad idea: anyone downstream of it is forced to manually fix their history. This section explains how to do the fix from the downstream’s point of view. The real fix, however, would be to avoid rebasing the upstream in the first place.
To illustrate, suppose you are in a situation where someone develops a subsystem branch, and you are working on a topic that is dependent on this subsystem . You might end up with a history like the following:
If subsystem is rebased against master , the following happens:
If you now continue development as usual, and eventually merge topic to subsystem , the commits from subsystem will remain duplicated forever:
Such duplicates are generally frowned upon because they clutter up history, making it harder to follow. To clean things up, you need to transplant the commits on topic to the new subsystem tip, i. e., rebase topic . This becomes a ripple effect: anyone downstream from topic is forced to rebase too, and so on!
There are two kinds of fixes, discussed in the following subsections:
This happens if the subsystem rebase was a simple rebase and had no conflicts.
Hard case: The changes are not the same.
This happens if the subsystem rebase had conflicts, or used --interactive to omit, edit, squash, or fixup commits; or if the upstream used one of commit --amend , reset , or filter-branch .
The easy case.
Only works if the changes (patch IDs based on the diff contents) on subsystem are literally the same before and after the rebase subsystem did.
In that case, the fix is easy because git rebase knows to skip changes that are already present in the new upstream. So if you say (assuming you’re on topic )
you will end up with the fixed history.
The hard case.
Things get more complicated if the subsystem changes do not exactly correspond to the ones before the rebase.
The idea is to manually tell git rebase "where the old subsystem ended and your topic began", that is, what the old merge-base between them was. You will have to find a way to name the last commit of the old subsystem , for example:
With the subsystem reflog: after git fetch , the old tip of subsystem is at subsystem . Subsequent fetches will increase the number. (See git-reflog[1].)
Relative to the tip of topic : knowing that your topic has three commits, the old tip of subsystem must be topic.
You can then transplant the old subsystem..topic to the new tip by saying (for the reflog case, and assuming you are on topic already):
The ripple effect of a "hard case" recovery is especially bad: everyone downstream from topic will now have to perform a "hard case" recovery too!
The todo list presented by --preserve-merges --interactive does not represent the topology of the revision graph. Editing commits and rewording their commit messages should work fine, but attempts to reorder commits tend to produce counterintuitive results.
For example, an attempt to rearrange.
by moving the "pick 4" line will result in the following history:
App Store를 통해 가져 오기 우리의 응용 프로그램 에서이 게시물을 읽으십시오!
힘내는 재귀 적 전략과 인내 옵션을 사용하여 합치십시오.
재귀 적 전략에 의해 제공되는 인내 옵션을 사용하여 git과 브랜치를 병합하는 방법은 무엇입니까? 나는 자식 버전 1.7.3.1.msysgit.0을 사용하고있다.
문서조차도 일관성이 없으며 실제 명령이 출력하는 것과 다릅니다.
git merge [-s & lt; strategy & gt; ] [-X & lt; strategy-option & gt; ] & lt; 커밋 & gt;
그리고 더 본문에서 :
명령의 출력은 다음과 같습니다.
그래서 나는 다음과 같은 결과로 몇 가지 버전을 시도 :
옵션이 구현되지 않은 것처럼 보입니다.
git merge-recursive의 --patience 옵션이 커밋 58a1ece478c6038a7eb0b6e494d563bd5e6d5978에 도입되었습니다. git. git의 복제본에서 git 태그로이 변경 사항을 포함하는 버전을 확인할 수 있습니다 - 58a1ece478 포함 :
그래서 저는 여러분이 mSysGit의 약간 낡은 버전을 사용하고 있다고 의심합니다. 현재 1.7.4 버전의 미리보기 버전을 사용할 수 있습니다. 이 버전을 사용해보아야합니다.
나는 단지 git 버전 1.7.4에서이 것을 시도해 보았고, 다음과 같은 명령 행 문법이 나에게 도움이되었다.
Git1.7.2.2를 기반으로 재귀 적 병합 전략에 인내심 옵션을 도입 한 패치를 보았습니다. 그러나 이후의 릴리스 노트에서는 보이지 않습니다.
그러나 인내 diff 알고리즘은 2009 년부터 제공되었으며 여기에서 자세히 설명합니다.
병합 명령은이 옵션을 이해해야합니다. 아래의이 함수는 결코 호출되지 않는 것 같습니다 (merge-recursive. c 나 다른 *.c 파일의 어느 곳에도 존재하지 않습니다!) :
"알 수없는 옵션"오류 메시지는 git. c의 handle_options 함수에 의해서만 인쇄됩니다.
그리고 XDF_PATIENCE_DIFF는 git 소스 (1.7.4)의 다른 곳에서는 보이지 않습니다. 그래서 네, 병합을 위해 이것이 어떻게 구현 될지 모르겠습니다.
힘내 병합 전략 옵션
git-merge - 두 개 이상의 개발 기록을 함께 결합합니다.
기술.
그들의 커밋이 현재 브랜치에서 분기 된 이후로 명명 된 커밋의 변경 사항을 현재 브랜치에 반영합니다. 이 명령은 git pull이 다른 저장소의 변경 내용을 통합하는 데 사용되며 한 지점에서 다른 지점으로 변경 사항을 병합하기 위해 손으로 사용할 수 있습니다.
다음 기록이 존재하고 현재 분기가 "마스터"라고 가정합니다.
그런 다음 "git merge topic"은 마스터 (즉, E)에서 현재 커밋 (C)까지 마스터 분기와 분기 된 이후의 주제 분기에 대한 변경 사항을 재생하고 이름과 함께 새로운 커밋에 결과를 기록합니다 두 개의 상위 커밋과 변경 사항을 설명하는 사용자의 로그 메시지가 표시됩니다.
두 번째 구문 ( "git merge --abort")은 병합 결과 충돌이 발생한 후에 만 실행할 수 있습니다. git merge --abort는 병합 프로세스를 중단하고 병합 전 상태를 재구성합니다. 그러나 병합이 시작될 때 커밋되지 않은 변경 사항이있는 경우 (특히 병합이 시작된 후 변경 사항이 더 많이 수정 된 경우) git merge --abort는 경우에 따라 원래의 병합 변경 사항을 재구성 할 수 없습니다. 따라서:
경고 : 커밋되지 않은 커밋되지 않은 변경 사항으로 git merge를 실행하는 것은 권장하지 않습니다. 가능하면 충돌이 발생해도 복구가 어려울 수 있습니다.
네 번째 구문 ( "git merge --continue")은 병합이 충돌 한 후에 만 실행할 수 있습니다.
병합을 수행하고 결과를 커밋하십시오. 이 옵션을 사용하여 --no-commit을 대체 할 수 있습니다.
--no-commit을 사용하면 병합을 수행하지만 병합을 실패한 것으로 가정하고 자동 커밋하지 않으므로 사용자가 커밋하기 전에 병합 결과를 검사하고 추가 조정할 수 있습니다.
성공적인 기계적 병합을 커밋하기 전에 편집기를 호출하여 자동 생성 된 병합 메시지를 추가로 편집하여 사용자가 병합을 설명하고 정당화 할 수 있도록합니다. --no-edit 옵션을 사용하여 자동 생성 된 메시지를 수락 할 수 있습니다 (일반적으로 권장하지 않음). --edit (또는 - e) 옵션은 명령 행에서 - m 옵션과 함께 초안 메시지를 제공하고 편집기에서 편집하려는 경우 여전히 유용합니다.
이전 스크립트는 사용자가 병합 로그 메시지를 편집하지 못하도록하는 이전 동작에 따라 달라질 수 있습니다. git merge를 실행할 때 열리는 편집기를 볼 수 있습니다. 이러한 스크립트를 업데이트 된 동작으로 쉽게 조정할 수 있도록 환경 변수 GIT_MERGE_AUTOEDIT는 시작 부분에서 no로 설정할 수 있습니다.
병합이 빨리 감기로 해결되면 병합 커밋을 만들지 않고 분기 포인터 만 업데이트하십시오. 이는 기본 동작입니다.
병합이 빨리 감기로 해결되는 경우에도 병합 커밋을 만듭니다. 주석이있는 (그리고 아마도 서명 된) 태그를 병합 할 때의 기본 동작입니다.
현재 HEAD가 이미 최신 상태이거나 병합을 빨리 감기로 해결할 수없는 경우가 아니면 0이 아닌 상태로 병합 및 종료를 거부합니다.
결과 병합 커밋에 GPG 서명하십시오. keyid 인수는 선택적이며 커미터 ID로 기본 설정됩니다. 지정된 경우 공백없이 옵션에 고정되어야합니다.
브랜치 이름 외에도 로그 메시지에 기껏해야 & lt; n & gt; 병합중인 실제 커밋 git-fmt-merge-msg [1]를 참고하십시오.
--no-log를 사용하면 병합중인 실제 커밋의 한 줄 설명을 나열하지 않습니다.
병합이 끝나면 diffstat를 표시합니다. diffstat도 구성 옵션 merge. stat에 의해 제어됩니다.
-n 또는 --no-stat를 사용하면 병합이 끝날 때 diffstat가 표시되지 않습니다.
실제 병합이 일어난 것처럼 작업 트리와 인덱스 상태를 생성하지만 (머지 정보 제외) 실제로 커밋하지 않고 HEAD를 이동하거나 $ GIT_DIR / MERGE_HEAD를 기록합니다 (다음 git commit 명령으로 병합 커밋). 이렇게하면 다른 브랜치 (또는 문어의 경우 더 많이)를 병합하는 것과 동일한 효과를 가지는 현재 브랜치의 맨 위에 단일 커밋을 생성 할 수 있습니다.
--no-squash를 사용하면 병합을 수행하고 결과를 커밋합니다. 이 옵션은 --squash를 무시하는 데 사용할 수 있습니다.
주어진 병합 전략을 사용하십시오. 시도해야하는 순서대로 지정하기 위해 두 번 이상 제공 할 수 있습니다. - s 옵션이 없으면 대신 내장 전략 목록이 사용됩니다 (단일 헤드를 병합 할 때 git merge-recursive, 그렇지 않으면 git merge-octopus).
-X & lt; 옵션 & gt; --strategy-option = & lt; 옵션 & gt;
병합 전략 특정 옵션을 통해 병합 전략에 전달하십시오.
병합중인 사이드 분기의 팁 커밋이 유효한 키, 즉 유효한 uid가있는 키로 서명되었는지 확인합니다. 기본 신뢰 모델에서는 서명 키가 신뢰할 수있는 키로 서명되었음을 의미합니다. 사이드 브랜치의 팁 커밋이 유효한 키로 서명되지 않으면 병합이 중단됩니다.
--stat와 --no-stat의 동의어; 이것들은 더 이상 사용되지 않으며 앞으로 제거 될 것입니다.
조용히 작동하십시오. 암시 - 진전 없음.
진행 상태를 명시 적으로 켜고 끕니다. 둘 다 지정하지 않으면 표준 오류가 터 L 널에 연결된 경우 진행이 표시됩니다. 모든 병합 전략이 진행률보고를 지원하지는 않습니다.
기본적으로 git merge 명령은 공통 조상을 공유하지 않는 기록을 병합하는 것을 거부합니다. 이 옵션은 생명을 독립적으로 시작한 두 프로젝트의 기록을 병합 할 때이 안전을 무시하는 데 사용할 수 있습니다. 매우 드물기 때문에 기본적으로이를 활성화하는 구성 변수가 없으므로 추가되지 않습니다.
Commit 로그 메시지의 끝에 Committer에 의해 Signed-by-by 행을 추가하십시오. 사인의 의미는 프로젝트에 따라 다르지만 일반적으로 커미터가 동일한 라이선스로이 저작물을 제출할 권한이 있으며 개발자 원산지 증명서 (개발자 인증서 참조)에 동의한다는 것을 증명합니다.
병합 커밋에 사용될 커밋 메시지를 설정합니다 (생성 된 경우).
--log가 지정되면 병합중인 커밋의 짧은 로그가 지정된 메시지에 추가됩니다.
git fmt-merge-msg 명령은 자동화 된 git merge 호출에 좋은 기본값을 제공하는 데 사용할 수 있습니다. 자동화 된 메시지에는 분기 설명이 포함될 수 있습니다.
가능하다면 rerere 메커니즘이 자동 충돌 해결의 결과로 색인을 갱신하도록하십시오.
현재 충돌 해결 프로세스를 중단하고 병합 전 상태를 재구성하십시오.
병합이 시작될 때 커밋되지 않은 작업 트리 변경 사항이 있으면 git merge --abort가 경우에 따라 이러한 변경 사항을 재구성 할 수 없습니다. 따라서 git merge를 실행하기 전에 변경 사항을 항상 커밋하거나 숨겨 두는 것이 좋습니다.
git merge --abort는 MERGE_HEAD가있는 경우 git reset --merge와 같습니다.
git merge가 충돌로 멈춘 후에는 git merge --continue를 실행하여 병합을 마칠 수 있습니다 (아래의 "충돌 문제 해결 방법"참조).
우리 지점으로 합병하기 위해 대개 다른 지점장을 임명합니다. 두 개 이상의 커밋을 지정하면 두 개 이상의 부모와 병합이 생성됩니다 (옥토퍼 병합이라고도 함).
명령 줄에서 커밋을하지 않으면 현재 분기가 업스트림으로 사용하도록 구성된 원격 추적 분기를 병합합니다. 이 매뉴얼 페이지의 설정 부분을 참고하십시오.
FETCH_HEAD (및 다른 커밋 없음)가 지정되면 병합을 위해 git fetch를 이전에 호출하여. git / FETCH_HEAD 파일에 기록 된 분기가 현재 분기에 병합됩니다.
예비 병기 검사.
외부 변경 사항을 적용하기 전에 올바른 모양으로 작업하고 로컬로 커미트해야하므로 충돌이 발생해도 문제가 해결되지 않습니다. git-stash [1]를 참고하십시오. git pull 및 git merge는 로컬 uncommitted 변경이 git pull / git merge가 업데이트해야 할 수도있는 파일과 겹칠 때 아무 작업도하지 않고 중단됩니다.
헤더 커밋과 관련된 인덱스에 등록 된 변경 사항이 있으면 병합 커밋에서 관련이없는 변경 사항을 기록하지 않도록 git pull 및 git merge도 중단됩니다. (한 가지 예외는 변경된 색인 항목이 이미 병합 된 상태 일 때입니다.)
모든 명명 된 커밋이 이미 HEAD의 조상 인 경우 git 병합은 "Already up to date"메시지와 함께 일찍 종료됩니다.
신속한 병합.
종종 현재 브랜치 헤드는 명명 된 커밋의 조상입니다. 이것은 git pull에서 호출 할 때 가장 흔한 경우입니다. 업스트림 저장소를 추적하고 로컬 변경 사항을 커밋하지 않았으며 이제는 새로운 업스트림 리비전으로 업데이트하려고합니다. 이 경우, 새로운 커밋은 결합 된 히스토리를 저장하는 데 필요하지 않다; 대신, HEAD (색인과 함께)는 추가 병합 확약을 작성하지 않고 명명 된 확약을 가리 키도록 갱신됩니다.
이 동작은 --no-ff 옵션으로 생략 할 수 있습니다.
TRUE MERGE.
빨리 감기 병합 (위 참조)을 제외하고, 병합 할 브랜치는 양쪽 모두를 부모로 가지는 병합 커밋에 의해 묶여 야합니다.
병합 할 모든 분기의 변경 사항을 조정하는 병합 된 버전이 커밋되고 HEAD, 색인 및 작업 트리가 커밋됩니다. 겹치지 않는 한 작업 트리를 수정할 수 있습니다. 업데이 트가 그들을 보존합니다.
변경 사항을 조정하는 방법이 명확하지 않으면 다음이 발생합니다.
HEAD 포인터는 그대로 유지됩니다.
MERGE_HEAD ref는 다른 브랜치 헤드를 가리 키도록 설정됩니다.
깔끔하게 병합 된 경로는 인덱스 파일과 작업 트리에서 모두 업데이트됩니다.
충돌하는 경로의 경우 색인 파일은 최대 세 가지 버전을 기록합니다. 1 단계는 공통 조상의 버전, HEAD의 2 단계, MERGE_HEAD의 3 단계를 저장합니다 (git ls-files - u를 사용하여 스테이지를 검사 할 수 있음). 작업 트리 파일에는 "병합"프로그램의 결과가 포함됩니다. 3-way merge) 결과를 친숙한 갈등 마커 (& lt; === & gt; & gt; & gt; .
다른 변경 사항은 없습니다. 특히 병합을 시작하기 전에 가지고 있던 로컬 수정 사항은 동일하게 유지되고 색인 항목은 그대로, 즉 HEAD와 일치하게 유지됩니다.
복잡한 충돌을 일으키고 다시 시작하려는 병합을 시도한 경우 git merge --abort를 사용하여 복구 할 수 있습니다.
머기 태그.
주석이 달린 (그리고 아마도 서명 된) 태그를 병합 할 때 Git은 빨리 감기 병합이 가능하다하더라도 항상 병합 커밋을 생성하고, 커밋 메시지 템플릿은 태그 메시지와 함께 준비됩니다. 또한 태그가 서명 된 경우 서명 확인은 메시지 템플리트에서 주석으로보고됩니다. git-tag [1]를 참고하십시오.
태그가 붙은 커밋으로 이어지는 작업과 통합하려는 경우 (예 : 업스트림 릴리스 포인트와 동기화 할 때 불필요한 병합 완료를 원하지 않을 수 있습니다.
이 경우, git merge에 넘기 전에 태그를 "unwrap"할 수 있고, 스스로 작업하지 않았을 때만 - ff-pass를 전달할 수 있습니다. 예 :
충돌이 나타나기 시작합니다.
병합하는 동안 작업 트리 파일은 병합 결과를 반영하도록 업데이트됩니다. 공통 조상의 버전에 대한 변경 사항 중 중복되지 않는 항목 (즉, 파일의 영역을 변경하고 다른 영역은 그대로 남겨 두거나 그 반대의 경우도 마찬가지 임)은 최종 결과에 그대로 통합됩니다. 그러나 양측이 같은 영역을 변경하면 Git은 한쪽을 다른 쪽보다 무작위로 선택할 수 없으며 양측이 그 영역에 남긴 것을 남겨 두어 해결하도록 요청합니다.
기본적으로 Git은 RCS 제품군의 "병합"프로그램에서 사용하는 스타일과 동일한 스타일을 사용하여 다음과 같이 충돌하는 이러한 혼란을 표시합니다.
충돌하는 한 쌍의 변화가 발생한 영역은 & lt; & lt; & lt; & lt; & lt; & lt; & lt; , =======, & gt; & gt; & gt; & gt; & gt; & gt; & gt; . 그 부분은 전형적으로 당신 쪽이고, 그 부분은 전형적으로 그들 편입니다.
기본 서식에는 충돌 영역에서 원본이 말한 내용이 표시되지 않습니다. 얼마나 많은 라인이 삭제되어 바비의 발언으로 바뀌 었는지 말할 수 없습니다. 당신이 말할 수있는 유일한 것은 당신 측이 그것이 어렵다고 말하기를 원하고 당신이 쇼핑을 선호하는 반면, 다른 측은 그것이 쉽다는 것을 주장하기를 원한다는 것입니다.
"merge. conflictStyle"구성 변수를 "diff3"으로 설정하여 대체 스타일을 사용할 수 있습니다. "diff3"스타일에서는 위의 충돌이 다음과 같이 보일 수 있습니다.
또한, & lt; & lt; & lt; & lt; & lt; & lt; , =======, & gt; & gt; & gt; & gt; & gt; & gt; & gt; 다른 마커를 사용합니다. ||||||| 마커 다음에 원래 텍스트가옵니다. 당신은 원고가 사실을 진술했다고 말할 수 있으며, 당신 측은 그 진술에 단순히 포기하고 포기하고 다른 측은보다 긍정적 인 태도를 취하려고했습니다. 원본을보고 더 나은 해상도를 얻을 수도 있습니다.
분쟁을 해결하는 방법.
충돌을 본 후에는 다음 두 가지 작업을 수행 할 수 있습니다.
병합하지 않기로 결정하십시오. 필요한 정리 작업은 인덱스 파일을 HEAD 커밋으로 재설정하여 2를 되돌리고 작업 트리 변경 사항을 2와 3으로 정리하는 것입니다. git merge --abort를 사용하면됩니다.
갈등을 해결하십시오. Git은 작업 트리의 충돌을 표시합니다. 파일을 모양으로 편집하고 git을 사용하여 색인에 추가하십시오. git commit 또는 git merge --continue를 사용하여 거래를 봉인하십시오. 후자의 명령은 git commit을 호출하기 전에 (중단 된) 병합 진행 여부를 확인합니다.
다음과 같은 여러 도구를 사용하여 충돌 문제를 해결할 수 있습니다.
병합 도구를 사용하십시오. git mergetool을 사용하여 병합을 통해 작동하는 그래픽 mergetool을 시작하십시오.
차이점을보세요. git diff는 HEAD 및 MERGE_HEAD 버전의 변경 사항을 강조하는 3 방향 diff를 보여줍니다.
각 지점에서 diff를보십시오. git log --merge - p & lt; path & gt; 먼저 HEAD 버전과 MERGE_HEAD 버전의 diff가 표시됩니다.
원본을보십시오. git show : 1 : filename은 일반적인 조상을 보여줍니다. git show : 2 : filename은 HEAD 버전을 나타내며 git show : 3 : filename은 MERGE_HEAD 버전을 보여줍니다.
현재 브랜치 상단에 브랜치 수정 사항과 향상된 기능을 병합하여 문어 병합을 만듭니다.
우리의 병합 전략을 사용하여 현재 분기에 쓸모없는 분기를 병합하십시오.
현재의 브랜치에 브랜치 maint를 병합 시키지만, 새로운 커밋을 자동으로하지는 마십시오 :
병합에 대한 추가 변경 사항을 포함하거나 자체 병합 완료 메시지를 작성하려는 경우에 사용할 수 있습니다.
병합 커밋에 대한 실질적인 변경 사항을 몰래 사용하려면이 옵션을 악용하지 않아야합니다. bumping release / version name과 같은 작은 픽스 업도 허용됩니다.
병합 전략.
병합 메커니즘 (git merge 및 git pull 명령)을 사용하면 - s 옵션을 사용하여 백엔드 병합 전략을 선택할 수 있습니다. 일부 전략은 자체 옵션을 취할 수도 있습니다. 이 옵션은 - X & lt; option & gt; 자식 병합 및 / 또는 자식 끌어 인수.
이렇게하면 3 방향 병합 알고리즘을 사용하여 두 개의 헤드 (즉, 현재 브랜치와 다른 브랜치)를 해결할 수 있습니다. 그것은 십자가 병합 모호성을 신중하게 탐지하려고 시도하며 일반적으로 안전하고 빠른 것으로 간주됩니다.
이 방법은 3 방향 병합 알고리즘을 사용하는 두 개의 헤드 만 해결할 수 있습니다. 3 방향 병합에 사용할 수있는 공통 조상이 둘 이상이면 공통 조상의 병합 된 트리를 만들어이를 3 방향 병합을위한 참조 트리로 사용합니다. 이는 Linux 2.6 커널 개발 이력에서 가져온 실제 병합 커밋에 대한 테스트로 인해 불일치가 발생하지 않고 병합 충돌이 줄어들 었다고보고되었습니다. 또한 이름 변경과 관련된 병합을 감지하고 처리 할 수 있습니다. 하나의 분기를 가져 오거나 병합 할 때 기본 병합 전략입니다.
재귀 적 전략에는 다음과 같은 옵션이 있습니다.
이 옵션은 우리의 버전을 선호함으로써 충돌하는 덩어리를 자동으로 자동 해결하도록합니다. 우리 쪽과 충돌하지 않는 다른 트리의 변경 사항이 병합 결과에 반영됩니다. 이진 파일의 경우 전체 내용이 우리 측에서 가져옵니다.
이것은 우리의 머지 전략과 혼동되어서는 안됩니다. 이 전략은 다른 트리가 전혀 포함하지 않는 것을 보지 않습니다. 그것은 다른 나무가 한 모든 것을 버리고 우리의 역사에는 그 안에 일어났던 모든 것이 들어 있다고 선언합니다.
이것은 우리와 반대입니다. 우리와 달리, 이 병합 옵션을 혼란스럽게하는 병합을 병합하는 것은 없습니다.
이 옵션을 사용하면 병합 - 재귀 적으로 약간의 시간을 소비하여 중요하지 않은 일치 행 (예 : 별개의 기능에서 오는 중괄호)으로 인해 발생하는 불일치를 피할 수 있습니다. 병합 할 분기가 격렬하게 갈라 졌을 때 이것을 사용하십시오. git-diff [1] --patience를 참고하십시오.
병합 - 재귀 적으로 다른 diff 알고리즘을 사용하도록 지정합니다. 중요하지 않은 매칭 라인 (뚜렷한 기능의 중괄호)으로 인해 발생하는 불일치를 피할 수 있습니다. git-diff [1] --diff-algorithm도 참조하십시오.
ignore-space-change ignore-all-space ignore-space-at-eol.
3 방향 병합을 위해 표시된 공백 변경 유형의 행을 변경되지 않은 것으로 처리합니다. 행에 대한 다른 변경 사항과 혼합 된 공백 변경 사항은 무시되지 않습니다. git-diff [1] - b, - w 및 --ignore-space-at-eol도 참조하십시오.
그들의 버전이 라인에 공백 변경만을 도입한다면, 우리의 버전이 사용됩니다;
우리의 버전이 공백 변경을 도입했지만 그들의 버전이 상당한 변화를 포함한다면, 그들의 버전이 사용됩니다;
그렇지 않으면 병합은 일반적인 방법으로 진행됩니다.
3 방향 병합을 해결할 때 가상 체크 아웃을 실행하고 파일의 모든 3 단계를 체크인합니다. 이 옵션은 다른 깨끗한 필터 또는 줄 끝 정규화 규칙으로 분기를 병합 할 때 사용하기위한 것입니다. 자세한 내용은 gitattributes [5]의 "checkin / checkout 속성이 다른 분기를 병합"을 참조하십시오.
재 정규화 옵션을 비활성화합니다. 이것은 merge. renormalize 구성 변수를 겹쳐 씁니다.
이름 바꾸기 감지 기능을 해제하십시오. git-diff [1] --no-renames도 참조하십시오.
이름 바꾸기 감지 기능을 켜고 필요에 따라 유사도 임계 값을 설정합니다. 이것이 기본값입니다. git-diff [1] --find-renames를 참고하십시오.
find-renames = & lt; n & gt;에 대한 더 이상 사용되지 않는 동의어입니다. .
이 옵션은 병합 할 때 두 트리를 서로 맞춰야하는 방식을 추측하는 하위 트리 전략의 고급 형식입니다. 대신 지정된 경로가 두 개의 트리 모양을 일치시키기 위해 접두사로 사용됩니다 (또는 처음부터 제거됩니다).
이 경우 두 개 이상의 헤드가있는 경우는 해결되지만 수동으로 해결해야하는 복잡한 병합은 수행되지 않습니다. 주제 머리말을 함께 묶는 데 주로 사용됩니다. 둘 이상의 분기를 가져 오거나 병합 할 때 기본 병합 전략입니다.
이렇게하면 여러 개의 머리가 처리되지만 병합 된 결과 트리는 항상 현재 분기 헤드의 트리이므로 다른 모든 분기의 모든 변경 사항을 무시합니다. 그것은 사이드 브랜치의 오래된 개발 이력을 대체하기 위해 사용됩니다. 이것은 재귀 병합 전략에 대한 - Xours 옵션과 다릅니다.
이는 수정 된 재귀 적 전략입니다. 나무 A와 B를 병합 할 때 B가 A의 하위 트리에 해당하면 B는 먼저 같은 레벨의 나무를 읽지 않고 A의 트리 구조와 일치하도록 조정됩니다. 이 조정은 공통 조상 트리에서도 수행됩니다.
3- 방향 병합을 사용하는 전략 (기본값, 재귀 포함)을 사용하면 두 분기에서 변경이 이루어 지지만 나중에 분기 중 하나에서 되돌릴 경우 변경 내용이 병합 된 결과에 나타납니다. 어떤 사람들은이 행동이 혼란 스럽다는 것을 알게됩니다. 병합을 수행 할 때 헤드 및 병합베이스 만 고려되므로 개별 커밋이 고려되지 않기 때문에 발생합니다. 따라서 병합 알고리즘은 복귀 된 변경 사항을 전혀 변경되지 않은 것으로 간주하고 대신 변경된 버전으로 대체합니다.
구성.
병합시 충돌 트리가 작업 트리 파일에 쓰여지는 스타일을 지정하십시오. 기본값은 & lt; & lt; & lt; & lt; & lt; & lt; & lt; & lt; 충돌 마커, 한쪽면의 변경 사항, ======= 마커면, 다른 쪽면의 변경 사항, 그리고 & gt; & gt; & gt; & gt; & gt; & gt; 채점자. 다른 스타일 인 "diff3"은 |||||||을 추가합니다. 마커와 원래 텍스트 앞에 ======= 마커가 있습니다.
커밋 인수없이 merge가 호출되면 원격 브랜치 분기에 저장된 마지막 관찰 값을 사용하여 현재 분기에 대해 구성된 업스트림 브랜치를 병합합니다. & lt; branch & gt;.remote라는 브랜치의 이름을 브랜치 & lt; current branch & gt;.remote에 의해 명명 된 리모트에서 브랜치의 이름을 붙이고 & lt; remote & gt;.fetch 해당 원격 추적 브랜치를 추적하고 이러한 추적 분기의 팁을 병합합니다.
기본적으로 Git은 현재 커밋의 자손 인 커밋을 병합 할 때 추가 병합 커밋을 생성하지 않습니다. 대신 현재 분기의 끝이 빨리 전달됩니다. false로 설정하면, 이 변수는 Git에게 그러한 경우에 여분의 병합 커밋을 생성하게합니다 (커맨드 라인에서 --no-ff 옵션을주는 것과 같습니다). only로 설정하면, 그러한 빨리 감기 병합 만 허용됩니다 (명령 행에서 --ff-only 옵션을주는 것과 같습니다).
분기 이름 외에도 로그 메시지에 연관된 분기 설명 텍스트를 채 웁니다. 기본값은 false입니다.
분기 이름 외에도 병합중인 실제 커밋의 지정된 수의 한 줄 설명으로 로그 메시지를 채 웁니다. 기본값은 false이고 true는 20의 동의어입니다.
병합 중에 이름 바꾸기 검색을 수행 할 때 고려해야 할 파일 수. 지정하지 않으면 diff. renameLimit 값이 기본값으로 사용됩니다.
저장소에서 파일의 표준 표현이 시간이 지남에 따라 변경되었음을 Git에게 알려줍니다 (예 : 이전 커밋은 CRLF 행 끝으로 텍스트 파일을 기록하지만 최근에는 LF 행 끝을 사용함). 이러한 저장소에서 Git은 불필요한 충돌을 줄이기 위해 병합을 수행하기 전에 커밋에 기록 된 데이터를 표준 형식으로 변환 할 수 있습니다. 자세한 내용은 gitattributes [5]에서 "checkin / checkout 속성이 다른 분기를 병합"섹션을 참조하십시오.
병합 끝에서 ORIG_HEAD와 병합 결과 사이에 diffstat를 인쇄할지 여부. 기본값은 True입니다.
git-mergetool [1]이 병합 도구를 사용하는 방법을 제어합니다. 아래 목록은 유효한 내장 값을 보여줍니다. 다른 모든 값은 사용자 지정 병합 도구로 취급되며 해당하는 mergetool. & lt; tool & gt;.cmd 변수가 정의되어 있어야합니다.
재귀 적 병합 전략에 의해 표시되는 출력의 양을 제어합니다. 레벨 0은 충돌이 감지되면 최종 오류 메시지를 제외하고는 아무 것도 출력하지 않습니다. 레벨 1은 충돌 만 출력하고, 출력 충돌은 2 개, 파일 변경은 2 개입니다. 레벨 5 이상은 디버깅 정보를 출력합니다. 기본값은 레벨 2입니다. GIT_MERGE_VERBOSITY 환경 변수로 겹쳐 쓸 수 있습니다.
사용자 지정 저수준 병합 드라이버에 대한 사람이 읽을 수있는 이름을 정의합니다. 자세한 내용은 gitattributes [5]를 참조하십시오.
사용자 지정 저수준 병합 드라이버를 구현하는 명령을 정의합니다. 자세한 내용은 gitattributes [5]를 참조하십시오.
공통 조상간에 내부 병합을 수행 할 때 사용할 저수준 병합 드라이버를 명명합니다. 자세한 내용은 gitattributes [5]를 참조하십시오.
& lt; name & gt; 분기로 병합하기위한 기본 옵션을 설정합니다. 구문과 지원되는 옵션은 git merge의 옵션과 동일하지만 공백 문자가 포함 된 옵션 값은 현재 지원되지 않습니다.
힘내 병합 전략 옵션
git-rebase - 다른 기본 팁 위에 커밋을 다시 적용합니다.
기술.
& lt; branch & gt; git rebase가 자동 git checkout & lt; branch & gt;을 수행합니다. 다른 일을하기 전에. 그렇지 않으면 현재 분기에 남아 있습니다.
& lt; upstream & gt; & name. remote 및 branch. & lt; name & gt;.merge 옵션이 사용되며 (자세한 내용은 git-config [1] 참조) --fork-point 옵션이 가정됩니다 . 현재 어떤 지점에도 없거나 현재 분기에 업스트림이 구성되어 있지 않으면 rebase가 중단됩니다.
현재 브랜치에서 커밋에 의해 이루어진 모든 변경 사항은 & lt; 업스트림 & gt; 임시 영역에 저장됩니다. git log & lt; upstream & gt;이 보여줄 커밋과 동일한 커밋 세트입니다. HEAD; 또는 git log 'fork_point'. HEAD, --fork-point가 활성화 된 경우 (아래의 --fork-point에 대한 설명 참조); 또는 - root 옵션이 지정된 경우 git log HEAD 명령을 사용하십시오.
현재 브랜치는 & lt; upstream & gt; 또는 & lt; newbase & gt;로 리셋된다. --onto 옵션이 제공된 경우. 이것은 git reset - hard & lt; upstream & gt;와 똑같은 효과가 있습니다. (또는 & lt; newbase & gt;). ORIG_HEAD는 재설정 전에 분기의 끝을 가리 키도록 설정됩니다.
이전에 임시 영역에 저장된 커밋은 순서대로 현재 분기에 하나씩 다시 적용됩니다. HEAD의 커밋과 동일한 텍스트 변경을 도입하는 HEAD의 커밋은 & lt; upstream & gt; (즉, 다른 커밋 메시지 또는 타임 스탬프로 이미 업스트림에서 수용된 패치는 스킵 될 것이다).
병합 실패로 인해이 프로세스가 완전히 자동으로 수행되지 않을 수도 있습니다. 그런 병합 실패를 해결하고 git rebase --continue를 실행해야합니다. 또 다른 옵션은 병합 실패를 일으킨 커밋을 git rebase --skip으로 우회하는 것입니다. 원래 & lt; branch & gt;.git / rebase-apply 작업 파일을 제거하려면 대신 git rebase --abort 명령을 사용하십시오.
다음 기록이 존재하고 현재 분기가 "주제"라고 가정합니다.
이 시점에서 다음 명령 중 하나의 결과 :
참고 : 후자의 양식은 git checkout 주제의 짧은 손으로 git rebase 마스터가 뒤따른 것입니다. 리베이스 종료시 토픽은 체크 아웃 된 브랜치로 유지됩니다.
업스트림 브랜치에 이미 변경 사항이 포함 된 경우 (예 : 업스트림에 적용된 패치를 메일로 보냈기 때문에) 커밋을 건너 뜁니다. 예를 들어, 다음 기록에서 git rebase master를 실행합니다 (A '와 A는 동일한 변경 집합을 도입하지만 커미터 정보는 다릅니다).
한 브랜치를 기반으로 토픽 브랜치를 다른 브랜치에 이식하여 rebase --onto를 사용하여 후반 브랜치에서 토픽 브랜치를 포크 한 것처럼 가장하는 방법이 있습니다.
먼저 주제가 다음 분기를 기반으로한다고 가정 해 보겠습니다. 예를 들어, 주제에서 개발 된 기능은 다음에 나오는 일부 기능에 따라 다릅니다.
브랜치 마스터에서 토픽을 포크로 만들고 싶습니다. for example, because the functionality on which topic depends was merged into the more stable master branch. We want our tree to look like this:
We can get this using the following command:
Another example of --onto option is to rebase part of a branch. If we have the following situation:
then the command.
would result in:
This is useful when topicB does not depend on topicA.
A range of commits could also be removed with rebase. If we have the following situation:
then the command.
would result in the removal of commits F and G:
This is useful if F and G were flawed in some way, or should not be part of topicA. Note that the argument to --onto and the <upstream> parameter can be any valid commit-ish.
In case of conflict, git rebase will stop at the first problematic commit and leave conflict markers in the tree. You can use git diff to locate the markers (<<<<<<) and make edits to resolve the conflict. For each file you edit, you need to tell Git that the conflict has been resolved, typically this would be done with.
After resolving the conflict manually and updating the index with the desired resolution, you can continue the rebasing process with.
Alternatively, you can undo the git rebase with.
CONFIGURATION.
Whether to show a diffstat of what changed upstream since the last rebase. False by default.
If set to true enable --autosquash option by default.
If set to true enable --autostash option by default.
If set to "warn", print warnings about removed commits in interactive mode. If set to "error", print the warnings and stop the rebase. If set to "ignore", no checking is done. "ignore" by default.
Custom commit list format to use during an --interactive rebase.
Starting point at which to create the new commits. If the --onto option is not specified, the starting point is <upstream>. May be any valid commit, and not just an existing branch name.
As a special case, you may use "A. B" as a shortcut for the merge base of A and B if there is exactly one merge base. You can leave out at most one of A and B, in which case it defaults to HEAD.
Upstream branch to compare against. May be any valid commit, not just an existing branch name. Defaults to the configured upstream for the current branch.
Working branch; defaults to HEAD.
Restart the rebasing process after having resolved a merge conflict.
Abort the rebase operation and reset HEAD to the original branch. If <branch> was provided when the rebase operation was started, then HEAD will be reset to <branch>. Otherwise HEAD will be reset to where it was when the rebase operation was started.
Abort the rebase operation but HEAD is not reset back to the original branch. The index and working tree are also left unchanged as a result.
Keep the commits that do not change anything from its parents in the result.
Restart the rebasing process by skipping the current patch.
Edit the todo list during an interactive rebase.
Use merging strategies to rebase. When the recursive (default) merge strategy is used, this allows rebase to be aware of renames on the upstream side.
Note that a rebase merge works by replaying each commit from the working branch on top of the <upstream> branch. Because of this, when a merge conflict happens, the side reported as ours is the so-far rebased series, starting with <upstream>, and theirs is the working branch. In other words, the sides are swapped.
Use the given merge strategy. If there is no - s option git merge-recursive is used instead. This implies --merge.
Because git rebase replays each commit from the working branch on top of the <upstream> branch using the given strategy, using the ours strategy simply discards all patches from the <branch>, which makes little sense.
Pass the <strategy-option> through to the merge strategy. This implies --merge and, if no strategy has been specified, - s recursive . Note the reversal of ours and theirs as noted above for the - m option.
GPG-sign commits. The keyid argument is optional and defaults to the committer identity; if specified, it must be stuck to the option without a space.
Be quiet. Implies --no-stat.
Be verbose. Implies --stat.
Show a diffstat of what changed upstream since the last rebase. The diffstat is also controlled by the configuration option rebase. stat.
Do not show a diffstat as part of the rebase process.
This option bypasses the pre-rebase hook. See also githooks[5].
Allows the pre-rebase hook to run, which is the default. This option can be used to override --no-verify. See also githooks[5].
Ensure at least <n> lines of surrounding context match before and after each change. When fewer lines of surrounding context exist they all must match. By default no context is ever ignored.
Force a rebase even if the current branch is up to date and the command without --force would return without doing anything.
You may find this (or --no-ff with an interactive rebase) helpful after reverting a topic branch merge, as this option recreates the topic branch with fresh commits so it can be remerged successfully without needing to "revert the reversion" (see the revert-a-faulty-merge How-To for details).
Use reflog to find a better common ancestor between <upstream> and <branch> when calculating which commits have been introduced by <branch>.
When --fork-point is active, fork_point will be used instead of <upstream> to calculate the set of commits to rebase, where fork_point is the result of git merge-base --fork-point <upstream> <branch> command (see git-merge-base[1]). If fork_point ends up being empty, the <upstream> will be used as a fallback.
If either <upstream> or --root is given on the command line, then the default is --no-fork-point , otherwise the default is --fork-point .
These flag are passed to the git apply program (see git-apply[1]) that applies the patch. Incompatible with the --interactive option.
These flags are passed to git am to easily change the dates of the rebased commits (see git-am[1]). Incompatible with the --interactive option.
This flag is passed to git am to sign off all the rebased commits (see git-am[1]). Incompatible with the --interactive option.
Make a list of the commits which are about to be rebased. Let the user edit that list before rebasing. This mode can also be used to split commits (see SPLITTING COMMITS below).
The commit list format can be changed by setting the configuration option rebase. instructionFormat. A customized instruction format will automatically have the long commit hash prepended to the format.
Recreate merge commits instead of flattening the history by replaying commits a merge commit introduces. Merge conflict resolutions or manual amendments to merge commits are not preserved.
This uses the --interactive machinery internally, but combining it with the --interactive option explicitly is generally not a good idea unless you know what you are doing (see BUGS below).
Append "exec <cmd>" after each line creating a commit in the final history. <cmd> will be interpreted as one or more shell commands.
You may execute several commands by either using one instance of --exec with several commands:
or by giving more than one --exec :
If --autosquash is used, "exec" lines will not be appended for the intermediate commits, and will only appear at the end of each squash/fixup series.
This uses the --interactive machinery internally, but it can be run without an explicit --interactive .
Rebase all commits reachable from <branch>, instead of limiting them with an <upstream>. This allows you to rebase the root commit(s) on a branch. When used with --onto, it will skip changes already contained in <newbase> (instead of <upstream>) whereas without --onto it will operate on every change. When used together with both --onto and --preserve-merges, all root commits will be rewritten to have <newbase> as parent instead.
When the commit log message begins with "squash! …" (or "fixup! …"), and there is already a commit in the todo list that matches the same . , automatically modify the todo list of rebase - i so that the commit marked for squashing comes right after the commit to be modified, and change the action of the moved commit from pick to squash (or fixup ). A commit matches the . if the commit subject matches, or if the . refers to the commit’s hash. As a fall-back, partial matches of the commit subject work, too. The recommended way to create fixup/squash commits is by using the --fixup / --squash options of git-commit[1].
This option is only valid when the --interactive option is used.
If the --autosquash option is enabled by default using the configuration variable rebase. autoSquash , this option can be used to override and disable this setting.
Automatically create a temporary stash entry before the operation begins, and apply it after the operation ends. This means that you can run rebase on a dirty worktree. However, use with care: the final stash application after a successful rebase might result in non-trivial conflicts.
With --interactive, cherry-pick all rebased commits instead of fast-forwarding over the unchanged ones. This ensures that the entire history of the rebased branch is composed of new commits.
Without --interactive, this is a synonym for --force-rebase.
You may find this helpful after reverting a topic branch merge, as this option recreates the topic branch with fresh commits so it can be remerged successfully without needing to "revert the reversion" (see the revert-a-faulty-merge How-To for details).
MERGE STRATEGIES.
The merge mechanism ( git merge and git pull commands) allows the backend merge strategies to be chosen with - s option. Some strategies can also take their own options, which can be passed by giving - X<option> arguments to git merge and/or git pull .
This can only resolve two heads (i. e. the current branch and another branch you pulled from) using a 3-way merge algorithm. It tries to carefully detect criss-cross merge ambiguities and is considered generally safe and fast.
This can only resolve two heads using a 3-way merge algorithm. When there is more than one common ancestor that can be used for 3-way merge, it creates a merged tree of the common ancestors and uses that as the reference tree for the 3-way merge. This has been reported to result in fewer merge conflicts without causing mismerges by tests done on actual merge commits taken from Linux 2.6 kernel development history. Additionally this can detect and handle merges involving renames. This is the default merge strategy when pulling or merging one branch.
The recursive strategy can take the following options:
This option forces conflicting hunks to be auto-resolved cleanly by favoring our version. Changes from the other tree that do not conflict with our side are reflected to the merge result. For a binary file, the entire contents are taken from our side.
This should not be confused with the ours merge strategy, which does not even look at what the other tree contains at all. It discards everything the other tree did, declaring our history contains all that happened in it.
This is the opposite of ours ; note that, unlike ours , there is no theirs merge stragegy to confuse this merge option with.
With this option, merge-recursive spends a little extra time to avoid mismerges that sometimes occur due to unimportant matching lines (e. g., braces from distinct functions). Use this when the branches to be merged have diverged wildly. See also git-diff[1] --patience .
Tells merge-recursive to use a different diff algorithm, which can help avoid mismerges that occur due to unimportant matching lines (such as braces from distinct functions). See also git-diff[1] --diff-algorithm .
ignore-space-change ignore-all-space ignore-space-at-eol.
Treats lines with the indicated type of whitespace change as unchanged for the sake of a three-way merge. Whitespace changes mixed with other changes to a line are not ignored. See also git-diff[1] - b , - w , and --ignore-space-at-eol .
If their version only introduces whitespace changes to a line, our version is used;
If our version introduces whitespace changes but their version includes a substantial change, their version is used;
Otherwise, the merge proceeds in the usual way.
This runs a virtual check-out and check-in of all three stages of a file when resolving a three-way merge. This option is meant to be used when merging branches with different clean filters or end-of-line normalization rules. See "Merging branches with differing checkin/checkout attributes" in gitattributes[5] for details.
Disables the renormalize option. This overrides the merge. renormalize configuration variable.
Turn off rename detection. See also git-diff[1] --no-renames .
Turn on rename detection, optionally setting the similarity threshold. This is the default. See also git-diff[1] --find-renames .
Deprecated synonym for find-renames=<n> .
This option is a more advanced form of subtree strategy, where the strategy makes a guess on how two trees must be shifted to match with each other when merging. Instead, the specified path is prefixed (or stripped from the beginning) to make the shape of two trees to match.
This resolves cases with more than two heads, but refuses to do a complex merge that needs manual resolution. It is primarily meant to be used for bundling topic branch heads together. This is the default merge strategy when pulling or merging more than one branch.
This resolves any number of heads, but the resulting tree of the merge is always that of the current branch head, effectively ignoring all changes from all other branches. It is meant to be used to supersede old development history of side branches. Note that this is different from the - Xours option to the recursive merge strategy.
This is a modified recursive strategy. When merging trees A and B, if B corresponds to a subtree of A, B is first adjusted to match the tree structure of A, instead of reading the trees at the same level. This adjustment is also done to the common ancestor tree.
With the strategies that use 3-way merge (including the default, recursive ), if a change is made on both branches, but later reverted on one of the branches, that change will be present in the merged result; some people find this behavior confusing. It occurs because only the heads and the merge base are considered when performing a merge, not the individual commits. The merge algorithm therefore considers the reverted change as no change at all, and substitutes the changed version instead.
You should understand the implications of using git rebase on a repository that you share. See also RECOVERING FROM UPSTREAM REBASE below.
When the git-rebase command is run, it will first execute a "pre-rebase" hook if one exists. You can use this hook to do sanity checks and reject the rebase if it isn’t appropriate. Please see the template pre-rebase hook script for an example.
Upon completion, <branch> will be the current branch.
INTERACTIVE MODE.
Rebasing interactively means that you have a chance to edit the commits which are rebased. You can reorder the commits, and you can remove them (weeding out bad or otherwise unwanted patches).
The interactive mode is meant for this type of workflow:
have a wonderful idea.
hack on the code.
prepare a series for submission.
where point 2. consists of several instances of.
finish something worthy of a commit.
b) independent fixup.
realize that something does not work.
Sometimes the thing fixed in b.2. cannot be amended to the not-quite perfect commit it fixes, because that commit is buried deeply in a patch series. That is exactly what interactive rebase is for: use it after plenty of "a"s and "b"s, by rearranging and editing commits, and squashing multiple commits into one.
Start it with the last commit you want to retain as-is:
An editor will be fired up with all the commits in your current branch (ignoring merge commits), which come after the given commit. You can reorder the commits in this list to your heart’s content, and you can remove them. The list looks more or less like this:
The oneline descriptions are purely for your pleasure; git rebase will not look at them but at the commit names ("deadbee" and "fa1afe1" in this example), so do not delete or edit the names.
By replacing the command "pick" with the command "edit", you can tell git rebase to stop after applying that commit, so that you can edit the files and/or the commit message, amend the commit, and continue rebasing.
If you just want to edit the commit message for a commit, replace the command "pick" with the command "reword".
To drop a commit, replace the command "pick" with "drop", or just delete the matching line.
If you want to fold two or more commits into one, replace the command "pick" for the second and subsequent commits with "squash" or "fixup". If the commits had different authors, the folded commit will be attributed to the author of the first commit. The suggested commit message for the folded commit is the concatenation of the commit messages of the first commit and of those with the "squash" command, but omits the commit messages of commits with the "fixup" command.
git rebase will stop when "pick" has been replaced with "edit" or when a command fails due to merge errors. When you are done editing and/or resolving conflicts you can continue with git rebase --continue .
For example, if you want to reorder the last 5 commits, such that what was HEAD.
4 becomes the new HEAD. To achieve that, you would call git rebase like this:
And move the first patch to the end of the list.
You might want to preserve merges, if you have a history like this:
Suppose you want to rebase the side branch starting at "A" to "Q". Make sure that the current HEAD is "B", and call.
Reordering and editing commits usually creates untested intermediate steps. You may want to check that your history editing did not break anything by running a test, or at least recompiling at intermediate points in history by using the "exec" command (shortcut "x"). You may do so by creating a todo list like this one:
The interactive rebase will stop when a command fails (i. e. exits with non-0 status) to give you an opportunity to fix the problem. You can continue with git rebase --continue .
The "exec" command launches the command in a shell (the one specified in $SHELL , or the default shell if $SHELL is not set), so you can use shell features (like "cd", ">", ";" …). The command is run from the root of the working tree.
This command lets you check that intermediate commits are compilable. The todo list becomes like that:
SPLITTING COMMITS.
In interactive mode, you can mark commits with the action "edit". However, this does not necessarily mean that git rebase expects the result of this edit to be exactly one commit. Indeed, you can undo the commit, or you can add other commits. This can be used to split a commit into two:
Start an interactive rebase with git rebase - i <commit>^ , where <commit> is the commit you want to split. In fact, any commit range will do, as long as it contains that commit.
Mark the commit you want to split with the action "edit".
When it comes to editing that commit, execute git reset HEAD^ . The effect is that the HEAD is rewound by one, and the index follows suit. However, the working tree stays the same.
Now add the changes to the index that you want to have in the first commit. You can use git add (possibly interactively) or git gui (or both) to do that.
Commit the now-current index with whatever commit message is appropriate now.
Repeat the last two steps until your working tree is clean.
Continue the rebase with git rebase --continue .
If you are not absolutely sure that the intermediate revisions are consistent (they compile, pass the testsuite, etc.) you should use git stash to stash away the not-yet-committed changes after each commit, test, and amend the commit if fixes are necessary.
RECOVERING FROM UPSTREAM REBASE.
Rebasing (or any other form of rewriting) a branch that others have based work on is a bad idea: anyone downstream of it is forced to manually fix their history. This section explains how to do the fix from the downstream’s point of view. The real fix, however, would be to avoid rebasing the upstream in the first place.
To illustrate, suppose you are in a situation where someone develops a subsystem branch, and you are working on a topic that is dependent on this subsystem . You might end up with a history like the following:
If subsystem is rebased against master , the following happens:
If you now continue development as usual, and eventually merge topic to subsystem , the commits from subsystem will remain duplicated forever:
Such duplicates are generally frowned upon because they clutter up history, making it harder to follow. To clean things up, you need to transplant the commits on topic to the new subsystem tip, i. e., rebase topic . This becomes a ripple effect: anyone downstream from topic is forced to rebase too, and so on!
There are two kinds of fixes, discussed in the following subsections:
This happens if the subsystem rebase was a simple rebase and had no conflicts.
Hard case: The changes are not the same.
This happens if the subsystem rebase had conflicts, or used --interactive to omit, edit, squash, or fixup commits; or if the upstream used one of commit --amend , reset , or filter-branch .
The easy case.
Only works if the changes (patch IDs based on the diff contents) on subsystem are literally the same before and after the rebase subsystem did.
In that case, the fix is easy because git rebase knows to skip changes that are already present in the new upstream. So if you say (assuming you’re on topic )
you will end up with the fixed history.
The hard case.
Things get more complicated if the subsystem changes do not exactly correspond to the ones before the rebase.
The idea is to manually tell git rebase "where the old subsystem ended and your topic began", that is, what the old merge-base between them was. You will have to find a way to name the last commit of the old subsystem , for example:
With the subsystem reflog: after git fetch , the old tip of subsystem is at subsystem . Subsequent fetches will increase the number. (See git-reflog[1].)
Relative to the tip of topic : knowing that your topic has three commits, the old tip of subsystem must be topic.
You can then transplant the old subsystem..topic to the new tip by saying (for the reflog case, and assuming you are on topic already):
The ripple effect of a "hard case" recovery is especially bad: everyone downstream from topic will now have to perform a "hard case" recovery too!
The todo list presented by --preserve-merges --interactive does not represent the topology of the revision graph. Editing commits and rewording their commit messages should work fine, but attempts to reorder commits tend to produce counterintuitive results.
For example, an attempt to rearrange.
by moving the "pick 4" line will result in the following history:
git-rebase - 다른 기본 팁 위에 커밋을 다시 적용합니다.
기술.
& lt; branch & gt; git rebase가 자동 git checkout & lt; branch & gt;을 수행합니다. 다른 일을하기 전에. 그렇지 않으면 현재 분기에 남아 있습니다.
& lt; upstream & gt; & name. remote 및 branch. & lt; name & gt;.merge 옵션이 사용되며 (자세한 내용은 git-config [1] 참조) --fork-point 옵션이 가정됩니다 . 현재 어떤 지점에도 없거나 현재 분기에 업스트림이 구성되어 있지 않으면 rebase가 중단됩니다.
현재 브랜치에서 커밋에 의해 이루어진 모든 변경 사항은 & lt; 업스트림 & gt; 임시 영역에 저장됩니다. git log & lt; upstream & gt;이 보여줄 커밋과 동일한 커밋 세트입니다. HEAD; 또는 git log 'fork_point'. HEAD, --fork-point가 활성화 된 경우 (아래의 --fork-point에 대한 설명 참조); 또는 - root 옵션이 지정된 경우 git log HEAD 명령을 사용하십시오.
현재 브랜치는 & lt; upstream & gt; 또는 & lt; newbase & gt;로 리셋된다. --onto 옵션이 제공된 경우. 이것은 git reset - hard & lt; upstream & gt;와 똑같은 효과가 있습니다. (또는 & lt; newbase & gt;). ORIG_HEAD는 재설정 전에 분기의 끝을 가리 키도록 설정됩니다.
이전에 임시 영역에 저장된 커밋은 순서대로 현재 분기에 하나씩 다시 적용됩니다. HEAD의 커밋과 동일한 텍스트 변경을 도입하는 HEAD의 커밋은 & lt; upstream & gt; (즉, 다른 커밋 메시지 또는 타임 스탬프로 이미 업스트림에서 수용된 패치는 스킵 될 것이다).
병합 실패로 인해이 프로세스가 완전히 자동으로 수행되지 않을 수도 있습니다. 그런 병합 실패를 해결하고 git rebase --continue를 실행해야합니다. 또 다른 옵션은 병합 실패를 일으킨 커밋을 git rebase --skip으로 우회하는 것입니다. 원래 & lt; branch & gt;.git / rebase-apply 작업 파일을 제거하려면 대신 git rebase --abort 명령을 사용하십시오.
다음 기록이 존재하고 현재 분기가 "주제"라고 가정합니다.
이 시점에서 다음 명령 중 하나의 결과 :
참고 : 후자의 양식은 git checkout 주제의 짧은 손으로 git rebase 마스터가 뒤따른 것입니다. 리베이스 종료시 토픽은 체크 아웃 된 브랜치로 유지됩니다.
업스트림 브랜치에 이미 변경 사항이 포함 된 경우 (예 : 업스트림에 적용된 패치를 메일로 보냈기 때문에) 커밋을 건너 뜁니다. 예를 들어, 다음 기록에서 git rebase master를 실행합니다 (A '와 A는 동일한 변경 집합을 도입하지만 커미터 정보는 다릅니다).
한 브랜치를 기반으로 토픽 브랜치를 다른 브랜치에 이식하여 rebase --onto를 사용하여 후반 브랜치에서 토픽 브랜치를 포크 한 것처럼 가장하는 방법이 있습니다.
먼저 주제가 다음 분기를 기반으로한다고 가정 해 보겠습니다. 예를 들어, 주제에서 개발 된 기능은 다음에 나오는 일부 기능에 따라 다릅니다.
브랜치 마스터에서 토픽을 포크로 만들고 싶습니다. for example, because the functionality on which topic depends was merged into the more stable master branch. We want our tree to look like this:
We can get this using the following command:
Another example of --onto option is to rebase part of a branch. If we have the following situation:
then the command.
would result in:
This is useful when topicB does not depend on topicA.
A range of commits could also be removed with rebase. If we have the following situation:
then the command.
would result in the removal of commits F and G:
This is useful if F and G were flawed in some way, or should not be part of topicA. Note that the argument to --onto and the <upstream> parameter can be any valid commit-ish.
In case of conflict, git rebase will stop at the first problematic commit and leave conflict markers in the tree. You can use git diff to locate the markers (<<<<<<) and make edits to resolve the conflict. For each file you edit, you need to tell Git that the conflict has been resolved, typically this would be done with.
After resolving the conflict manually and updating the index with the desired resolution, you can continue the rebasing process with.
Alternatively, you can undo the git rebase with.
CONFIGURATION.
Whether to show a diffstat of what changed upstream since the last rebase. False by default.
If set to true enable --autosquash option by default.
If set to true enable --autostash option by default.
If set to "warn", print warnings about removed commits in interactive mode. If set to "error", print the warnings and stop the rebase. If set to "ignore", no checking is done. "ignore" by default.
Custom commit list format to use during an --interactive rebase.
Starting point at which to create the new commits. If the --onto option is not specified, the starting point is <upstream>. May be any valid commit, and not just an existing branch name.
As a special case, you may use "A. B" as a shortcut for the merge base of A and B if there is exactly one merge base. You can leave out at most one of A and B, in which case it defaults to HEAD.
Upstream branch to compare against. May be any valid commit, not just an existing branch name. Defaults to the configured upstream for the current branch.
Working branch; defaults to HEAD.
Restart the rebasing process after having resolved a merge conflict.
Abort the rebase operation and reset HEAD to the original branch. If <branch> was provided when the rebase operation was started, then HEAD will be reset to <branch>. Otherwise HEAD will be reset to where it was when the rebase operation was started.
Abort the rebase operation but HEAD is not reset back to the original branch. The index and working tree are also left unchanged as a result.
Keep the commits that do not change anything from its parents in the result.
Restart the rebasing process by skipping the current patch.
Edit the todo list during an interactive rebase.
Use merging strategies to rebase. When the recursive (default) merge strategy is used, this allows rebase to be aware of renames on the upstream side.
Note that a rebase merge works by replaying each commit from the working branch on top of the <upstream> branch. Because of this, when a merge conflict happens, the side reported as ours is the so-far rebased series, starting with <upstream>, and theirs is the working branch. In other words, the sides are swapped.
Use the given merge strategy. If there is no - s option git merge-recursive is used instead. This implies --merge.
Because git rebase replays each commit from the working branch on top of the <upstream> branch using the given strategy, using the ours strategy simply discards all patches from the <branch>, which makes little sense.
Pass the <strategy-option> through to the merge strategy. This implies --merge and, if no strategy has been specified, - s recursive . Note the reversal of ours and theirs as noted above for the - m option.
GPG-sign commits. The keyid argument is optional and defaults to the committer identity; if specified, it must be stuck to the option without a space.
Be quiet. Implies --no-stat.
Be verbose. Implies --stat.
Show a diffstat of what changed upstream since the last rebase. The diffstat is also controlled by the configuration option rebase. stat.
Do not show a diffstat as part of the rebase process.
This option bypasses the pre-rebase hook. See also githooks[5].
Allows the pre-rebase hook to run, which is the default. This option can be used to override --no-verify. See also githooks[5].
Ensure at least <n> lines of surrounding context match before and after each change. When fewer lines of surrounding context exist they all must match. By default no context is ever ignored.
Force a rebase even if the current branch is up to date and the command without --force would return without doing anything.
You may find this (or --no-ff with an interactive rebase) helpful after reverting a topic branch merge, as this option recreates the topic branch with fresh commits so it can be remerged successfully without needing to "revert the reversion" (see the revert-a-faulty-merge How-To for details).
Use reflog to find a better common ancestor between <upstream> and <branch> when calculating which commits have been introduced by <branch>.
When --fork-point is active, fork_point will be used instead of <upstream> to calculate the set of commits to rebase, where fork_point is the result of git merge-base --fork-point <upstream> <branch> command (see git-merge-base[1]). If fork_point ends up being empty, the <upstream> will be used as a fallback.
If either <upstream> or --root is given on the command line, then the default is --no-fork-point , otherwise the default is --fork-point .
These flag are passed to the git apply program (see git-apply[1]) that applies the patch. Incompatible with the --interactive option.
These flags are passed to git am to easily change the dates of the rebased commits (see git-am[1]). Incompatible with the --interactive option.
This flag is passed to git am to sign off all the rebased commits (see git-am[1]). Incompatible with the --interactive option.
Make a list of the commits which are about to be rebased. Let the user edit that list before rebasing. This mode can also be used to split commits (see SPLITTING COMMITS below).
The commit list format can be changed by setting the configuration option rebase. instructionFormat. A customized instruction format will automatically have the long commit hash prepended to the format.
Recreate merge commits instead of flattening the history by replaying commits a merge commit introduces. Merge conflict resolutions or manual amendments to merge commits are not preserved.
This uses the --interactive machinery internally, but combining it with the --interactive option explicitly is generally not a good idea unless you know what you are doing (see BUGS below).
Append "exec <cmd>" after each line creating a commit in the final history. <cmd> will be interpreted as one or more shell commands.
You may execute several commands by either using one instance of --exec with several commands:
or by giving more than one --exec :
If --autosquash is used, "exec" lines will not be appended for the intermediate commits, and will only appear at the end of each squash/fixup series.
This uses the --interactive machinery internally, but it can be run without an explicit --interactive .
Rebase all commits reachable from <branch>, instead of limiting them with an <upstream>. This allows you to rebase the root commit(s) on a branch. When used with --onto, it will skip changes already contained in <newbase> (instead of <upstream>) whereas without --onto it will operate on every change. When used together with both --onto and --preserve-merges, all root commits will be rewritten to have <newbase> as parent instead.
When the commit log message begins with "squash! …" (or "fixup! …"), and there is already a commit in the todo list that matches the same . , automatically modify the todo list of rebase - i so that the commit marked for squashing comes right after the commit to be modified, and change the action of the moved commit from pick to squash (or fixup ). A commit matches the . if the commit subject matches, or if the . refers to the commit’s hash. As a fall-back, partial matches of the commit subject work, too. The recommended way to create fixup/squash commits is by using the --fixup / --squash options of git-commit[1].
This option is only valid when the --interactive option is used.
If the --autosquash option is enabled by default using the configuration variable rebase. autoSquash , this option can be used to override and disable this setting.
Automatically create a temporary stash entry before the operation begins, and apply it after the operation ends. This means that you can run rebase on a dirty worktree. However, use with care: the final stash application after a successful rebase might result in non-trivial conflicts.
With --interactive, cherry-pick all rebased commits instead of fast-forwarding over the unchanged ones. This ensures that the entire history of the rebased branch is composed of new commits.
Without --interactive, this is a synonym for --force-rebase.
You may find this helpful after reverting a topic branch merge, as this option recreates the topic branch with fresh commits so it can be remerged successfully without needing to "revert the reversion" (see the revert-a-faulty-merge How-To for details).
MERGE STRATEGIES.
The merge mechanism ( git merge and git pull commands) allows the backend merge strategies to be chosen with - s option. Some strategies can also take their own options, which can be passed by giving - X<option> arguments to git merge and/or git pull .
This can only resolve two heads (i. e. the current branch and another branch you pulled from) using a 3-way merge algorithm. It tries to carefully detect criss-cross merge ambiguities and is considered generally safe and fast.
This can only resolve two heads using a 3-way merge algorithm. When there is more than one common ancestor that can be used for 3-way merge, it creates a merged tree of the common ancestors and uses that as the reference tree for the 3-way merge. This has been reported to result in fewer merge conflicts without causing mismerges by tests done on actual merge commits taken from Linux 2.6 kernel development history. Additionally this can detect and handle merges involving renames. This is the default merge strategy when pulling or merging one branch.
The recursive strategy can take the following options:
This option forces conflicting hunks to be auto-resolved cleanly by favoring our version. Changes from the other tree that do not conflict with our side are reflected to the merge result. For a binary file, the entire contents are taken from our side.
This should not be confused with the ours merge strategy, which does not even look at what the other tree contains at all. It discards everything the other tree did, declaring our history contains all that happened in it.
This is the opposite of ours ; note that, unlike ours , there is no theirs merge stragegy to confuse this merge option with.
With this option, merge-recursive spends a little extra time to avoid mismerges that sometimes occur due to unimportant matching lines (e. g., braces from distinct functions). Use this when the branches to be merged have diverged wildly. See also git-diff[1] --patience .
Tells merge-recursive to use a different diff algorithm, which can help avoid mismerges that occur due to unimportant matching lines (such as braces from distinct functions). See also git-diff[1] --diff-algorithm .
ignore-space-change ignore-all-space ignore-space-at-eol.
Treats lines with the indicated type of whitespace change as unchanged for the sake of a three-way merge. Whitespace changes mixed with other changes to a line are not ignored. See also git-diff[1] - b , - w , and --ignore-space-at-eol .
If their version only introduces whitespace changes to a line, our version is used;
If our version introduces whitespace changes but their version includes a substantial change, their version is used;
Otherwise, the merge proceeds in the usual way.
This runs a virtual check-out and check-in of all three stages of a file when resolving a three-way merge. This option is meant to be used when merging branches with different clean filters or end-of-line normalization rules. See "Merging branches with differing checkin/checkout attributes" in gitattributes[5] for details.
Disables the renormalize option. This overrides the merge. renormalize configuration variable.
Turn off rename detection. See also git-diff[1] --no-renames .
Turn on rename detection, optionally setting the similarity threshold. This is the default. See also git-diff[1] --find-renames .
Deprecated synonym for find-renames=<n> .
This option is a more advanced form of subtree strategy, where the strategy makes a guess on how two trees must be shifted to match with each other when merging. Instead, the specified path is prefixed (or stripped from the beginning) to make the shape of two trees to match.
This resolves cases with more than two heads, but refuses to do a complex merge that needs manual resolution. It is primarily meant to be used for bundling topic branch heads together. This is the default merge strategy when pulling or merging more than one branch.
This resolves any number of heads, but the resulting tree of the merge is always that of the current branch head, effectively ignoring all changes from all other branches. It is meant to be used to supersede old development history of side branches. Note that this is different from the - Xours option to the recursive merge strategy.
This is a modified recursive strategy. When merging trees A and B, if B corresponds to a subtree of A, B is first adjusted to match the tree structure of A, instead of reading the trees at the same level. This adjustment is also done to the common ancestor tree.
With the strategies that use 3-way merge (including the default, recursive ), if a change is made on both branches, but later reverted on one of the branches, that change will be present in the merged result; some people find this behavior confusing. It occurs because only the heads and the merge base are considered when performing a merge, not the individual commits. The merge algorithm therefore considers the reverted change as no change at all, and substitutes the changed version instead.
You should understand the implications of using git rebase on a repository that you share. See also RECOVERING FROM UPSTREAM REBASE below.
When the git-rebase command is run, it will first execute a "pre-rebase" hook if one exists. You can use this hook to do sanity checks and reject the rebase if it isn’t appropriate. Please see the template pre-rebase hook script for an example.
Upon completion, <branch> will be the current branch.
INTERACTIVE MODE.
Rebasing interactively means that you have a chance to edit the commits which are rebased. You can reorder the commits, and you can remove them (weeding out bad or otherwise unwanted patches).
The interactive mode is meant for this type of workflow:
have a wonderful idea.
hack on the code.
prepare a series for submission.
where point 2. consists of several instances of.
finish something worthy of a commit.
b) independent fixup.
realize that something does not work.
Sometimes the thing fixed in b.2. cannot be amended to the not-quite perfect commit it fixes, because that commit is buried deeply in a patch series. That is exactly what interactive rebase is for: use it after plenty of "a"s and "b"s, by rearranging and editing commits, and squashing multiple commits into one.
Start it with the last commit you want to retain as-is:
An editor will be fired up with all the commits in your current branch (ignoring merge commits), which come after the given commit. You can reorder the commits in this list to your heart’s content, and you can remove them. The list looks more or less like this:
The oneline descriptions are purely for your pleasure; git rebase will not look at them but at the commit names ("deadbee" and "fa1afe1" in this example), so do not delete or edit the names.
By replacing the command "pick" with the command "edit", you can tell git rebase to stop after applying that commit, so that you can edit the files and/or the commit message, amend the commit, and continue rebasing.
If you just want to edit the commit message for a commit, replace the command "pick" with the command "reword".
To drop a commit, replace the command "pick" with "drop", or just delete the matching line.
If you want to fold two or more commits into one, replace the command "pick" for the second and subsequent commits with "squash" or "fixup". If the commits had different authors, the folded commit will be attributed to the author of the first commit. The suggested commit message for the folded commit is the concatenation of the commit messages of the first commit and of those with the "squash" command, but omits the commit messages of commits with the "fixup" command.
git rebase will stop when "pick" has been replaced with "edit" or when a command fails due to merge errors. When you are done editing and/or resolving conflicts you can continue with git rebase --continue .
For example, if you want to reorder the last 5 commits, such that what was HEAD.
4 becomes the new HEAD. To achieve that, you would call git rebase like this:
And move the first patch to the end of the list.
You might want to preserve merges, if you have a history like this:
Suppose you want to rebase the side branch starting at "A" to "Q". Make sure that the current HEAD is "B", and call.
Reordering and editing commits usually creates untested intermediate steps. You may want to check that your history editing did not break anything by running a test, or at least recompiling at intermediate points in history by using the "exec" command (shortcut "x"). You may do so by creating a todo list like this one:
The interactive rebase will stop when a command fails (i. e. exits with non-0 status) to give you an opportunity to fix the problem. You can continue with git rebase --continue .
The "exec" command launches the command in a shell (the one specified in $SHELL , or the default shell if $SHELL is not set), so you can use shell features (like "cd", ">", ";" …). The command is run from the root of the working tree.
This command lets you check that intermediate commits are compilable. The todo list becomes like that:
SPLITTING COMMITS.
In interactive mode, you can mark commits with the action "edit". However, this does not necessarily mean that git rebase expects the result of this edit to be exactly one commit. Indeed, you can undo the commit, or you can add other commits. This can be used to split a commit into two:
Start an interactive rebase with git rebase - i <commit>^ , where <commit> is the commit you want to split. In fact, any commit range will do, as long as it contains that commit.
Mark the commit you want to split with the action "edit".
When it comes to editing that commit, execute git reset HEAD^ . The effect is that the HEAD is rewound by one, and the index follows suit. However, the working tree stays the same.
Now add the changes to the index that you want to have in the first commit. You can use git add (possibly interactively) or git gui (or both) to do that.
Commit the now-current index with whatever commit message is appropriate now.
Repeat the last two steps until your working tree is clean.
Continue the rebase with git rebase --continue .
If you are not absolutely sure that the intermediate revisions are consistent (they compile, pass the testsuite, etc.) you should use git stash to stash away the not-yet-committed changes after each commit, test, and amend the commit if fixes are necessary.
RECOVERING FROM UPSTREAM REBASE.
Rebasing (or any other form of rewriting) a branch that others have based work on is a bad idea: anyone downstream of it is forced to manually fix their history. This section explains how to do the fix from the downstream’s point of view. The real fix, however, would be to avoid rebasing the upstream in the first place.
To illustrate, suppose you are in a situation where someone develops a subsystem branch, and you are working on a topic that is dependent on this subsystem . You might end up with a history like the following:
If subsystem is rebased against master , the following happens:
If you now continue development as usual, and eventually merge topic to subsystem , the commits from subsystem will remain duplicated forever:
Such duplicates are generally frowned upon because they clutter up history, making it harder to follow. To clean things up, you need to transplant the commits on topic to the new subsystem tip, i. e., rebase topic . This becomes a ripple effect: anyone downstream from topic is forced to rebase too, and so on!
There are two kinds of fixes, discussed in the following subsections:
This happens if the subsystem rebase was a simple rebase and had no conflicts.
Hard case: The changes are not the same.
This happens if the subsystem rebase had conflicts, or used --interactive to omit, edit, squash, or fixup commits; or if the upstream used one of commit --amend , reset , or filter-branch .
The easy case.
Only works if the changes (patch IDs based on the diff contents) on subsystem are literally the same before and after the rebase subsystem did.
In that case, the fix is easy because git rebase knows to skip changes that are already present in the new upstream. So if you say (assuming you’re on topic )
you will end up with the fixed history.
The hard case.
Things get more complicated if the subsystem changes do not exactly correspond to the ones before the rebase.
The idea is to manually tell git rebase "where the old subsystem ended and your topic began", that is, what the old merge-base between them was. You will have to find a way to name the last commit of the old subsystem , for example:
With the subsystem reflog: after git fetch , the old tip of subsystem is at subsystem . Subsequent fetches will increase the number. (See git-reflog[1].)
Relative to the tip of topic : knowing that your topic has three commits, the old tip of subsystem must be topic.
You can then transplant the old subsystem..topic to the new tip by saying (for the reflog case, and assuming you are on topic already):
The ripple effect of a "hard case" recovery is especially bad: everyone downstream from topic will now have to perform a "hard case" recovery too!
The todo list presented by --preserve-merges --interactive does not represent the topology of the revision graph. Editing commits and rewording their commit messages should work fine, but attempts to reorder commits tend to produce counterintuitive results.
For example, an attempt to rearrange.
by moving the "pick 4" line will result in the following history:
No comments:
Post a Comment