Ubisam-MergeTool/doc/history/2026-09-17-9차.md

9차 진행 기록 (2026-09-17 ~)

지시서: ../작업지시/9차.md

A-1. cherry-pick 마지막 저장 뒤 "내 쪽 대비" 라고 하지만 실제 기준은 이력에서 고른 커밋이다 (2026-09-17, 완료)

사용자 결정(2026-09-17): 작업 중 충돌을 다 풀면 두 칸의 기준을 HEAD 로 옮긴다. ("기준은 고른 커밋 그대로 두고 글을 맞춘다" 는 고르지 않음.)

고치기 전에 다시 났다 (길마다 저장소를 새로 만들어, 파일 비교 탭을 미리 열지 않고)

8차 E-1 순서 그대로 — 이력에서 커밋을 골라 시작 → 한 파일만 남기고 파일 단위 Accept Theirs → 남은 파일을 [3분할로 열기] → 충돌마다 Take Theirs → [Save].

	cherry-pick ([모든 브랜치] 켬)	revert ([모든 브랜치] 끔)
이력에서 고른 커밋	상대 쪽 작업	내 쪽 작업
마지막 Save 뒤 두 칸 기준(Selected Commit)	뒤이은 수정 — HEAD(내 쪽 작업)도 고른 커밋도 아닌 다른 브랜치 커밋	뒤이은 수정 = HEAD
BASE 제목	ace42e3 · Weld/Unit1.cs (꼬리 없음)	… · Motion/Unit0.cs · 되돌리기 전 내 쪽
요약	충돌 정리 끝 · [커밋] 으로 cherry-pick 을 끝냅니다 · 내 쪽 대비 가져온 변경 6줄	… · 내 쪽 대비 되돌린 변경 6줄

• 8차 E-1 에서 따로 잰 한 번은 기준이 고른 커밋이었다. 이번 cherry-pick 은 목록 맨 위(다른 브랜치 커밋), revert 는 HEAD. 같은 순서인데 기준이 셋 중 하나로 그때그때 달랐다 — N1 과 N1-덧(9차 A-2)은 뿌리가 같다.
• 파일 비교 탭 왼쪽 이력에서 선택된 줄이 맨 위 뒤이은 수정 이었다(스크린샷 d9-a1-pick-before-1).

원인

• 새로고침은 이력 목록(Commits)을 비웠다가 다시 채운다. 그때 Git 탭 이력 목록(SelectedItem 바인딩)이 선택을 놓치면 null 을 밀어 넣어 고른 커밋이 빈다. 놓치는지는 그때 화면 상태에 따라 달랐다.
• 비었으면 SelectedCommit = Commits[0] — 목록 맨 위로 채웠다. [모든 브랜치] 를 끄면 맨 위가 HEAD 라 티가 안 났고, 켜면 맨 위는 가장 최근의 다른 브랜치 커밋이다.
• 안 비었으면 이력에서 고른 커밋(cherry-pick 할 커밋)이 그대로 기준으로 남았다.
• 요약(OperationLabels.ResolvedSummary)은 기준이 HEAD 인지 보지 않고 "내 쪽 대비" 를 붙였다. BASE 제목은 HEAD 일 때만 작업 글을 붙여서 둘이 다른 말을 했다.

고친 것

• Services/CommitSelection.cs(새로) — 새로고침 뒤 고를 자리: 작업 중 충돌이 막 0 이 된 새로고침이면 HEAD, 아니면 새로고침 전에 고른 커밋을 해시로 되찾고, 없으면 맨 위가 아니라 HEAD(HEAD 도 목록에 없을 때만 맨 위). "막 0 이 된" 때만 옮긴다 — 그 상태에서 사람이 다른 커밋을 골라 보면 스테이징 · 새로고침마다 HEAD 로 끌어오지 않는다.
• GitWorkspace.ReadState — 목록을 갈아 끼우기 전에 고른 커밋의 해시를 적어 두고, 채운 뒤 CommitSelection.Choose 로 새 목록의 같은 커밋 객체를 고른다.
• OperationLabels.ResolvedSummary(…, baseIsHead) — 기준이 HEAD 가 아니면 작업 글을 쓰지 않는다(보통 요약). HomeViewModel 은 BASE 제목과 같은 조건(SelectedCommit.ShortSha == HeadSha)을 넘긴다.
• 하네스 MergeSaveTest 18건 추가(201건): 해시로 되찾기 · 순서가 바뀐 목록 · 비었을 때 HEAD · 사라졌을 때 HEAD · 막 0 이 되면 HEAD · 머무는 동안 안 끌어옴 · 기준이 HEAD 가 아니면 보통 요약.

확인한 것 (고친 앱, 같은 순서)

	cherry-pick ([모든 브랜치] 켬)	revert
마지막 Save 뒤 Selected Commit	내 쪽 작업 = HEAD	뒤이은 수정 = HEAD
BASE 제목	e039373 · Weld/Unit1.cs · 가져오기 전 내 쪽	6dde274 · Motion/Unit0.cs · 되돌리기 전 내 쪽
요약	충돌 정리 끝 · [커밋] 으로 cherry-pick 을 끝냅니다 · 내 쪽 대비 가져온 변경 6줄	… · 내 쪽 대비 되돌린 변경 6줄
git 과 대조	git diff -U0 HEAD -- Weld/Unit1.cs = 바뀐 줄 6 + 머지 주석 줄 6. 주석 줄은 규칙(무시: 머지 주석)대로 안 셈 → 6 이 맞다	같은 구성(+12 −6)

곁 확인(d9-a1-keep.ps1):

경우	결과
충돌을 다 푼 cherry-pick 저장소를 다시 열기	기준 HEAD · 요약 작업 글
그 상태에서 파일 비교 탭 이력으로 바탕 을 고름 → [새로고침] 세 번	세 번 모두 바탕 그대로(HEAD 로 안 끌려감) · 제목 꼬리 없음 · 요약 "차이 없음"("내 쪽 대비" 안 함)
작업 없음 · [모든 브랜치] 켬	맨 위 뒤이은 수정 이 아니라 HEAD 내 쪽 작업 그대로
Git 탭 이력에서 상대 쪽 작업 을 고름 → [새로고침] 세 번	세 번 모두 상대 쪽 작업 그대로
[모든 브랜치] 를 꺼 고른 커밋이 목록에서 빠짐	HEAD 로

• 하네스 22벌 1,112건 통과(+18) · 빌드 경고 0 · 오류 0.
• 병합 · pull · rebase 의 요약 · 제목은 기본값(baseIsHead 참)으로 8차 B-1 검사가 그대로 통과한다. 화면으로는 9차 D-1 에서 다시 본다.

알게 된 것 · 남긴 것

• Git 탭 이력에서 커밋을 고르면 파일 비교 탭의 Selected Commit 은 새로고침 전까지 따라오지 않는다(Git 탭은 _workspace.SelectedCommit 만 바꾸고, 파일 비교 탭은 새로고침 알림으로만 다시 읽는다). 이번에 바꾼 것이 아니라 전부터 그랬다. 고치지 않고 적어 둔다.
• A-2(한 번은 다른 브랜치 커밋이 기준)는 이번에 원인(목록 맨 위로 채움)이 드러나 함께 고쳐졌다. 지시서대로 A-2 에서 같은 순서를 다섯 번 넘게 되풀이해 확인한다.
• 자동 조작 쪽: 첫 확인 스크립트는 Git 탭에서 HEAD 를 골라 파일 비교 탭을 봤는데 위의 까닭으로 안 바뀌어, 파일 비교 탭 이력에서 고르게 고쳤다.

A-2. 한 번은 기준이 HEAD 도 가져온 커밋도 아닌 다른 브랜치 커밋이었다 (2026-09-17, 완료)

원인 (A-1 에서 드러남)

• 8차 E-1 N1-덧의 f310f49(다른 브랜치의 뒤이은 수정)는 목록 맨 위였다. 새로고침이 이력 목록을 갈아 끼울 때 Git 탭 목록이 선택을 놓치면 고른 커밋이 비고, 비면 Commits[0] 으로 채웠다. [모든 브랜치] 를 켜면 맨 위는 가장 최근의 다른 브랜치 커밋이다.
• 놓치는지는 그때 화면 상태에 따라 달라 "같은 순서로 다시 재니 안 났다". 9차 A-1 의 고치기 전 확인에서 다시 났다(기준 ace42e3 "뒤이은 수정").
• A-1 에서 해시로 되찾고 없으면 HEAD 로 채우게 고쳤다(CommitSelection).

고치며 새로 걸린 것 → 함께 고침

• A-1 대로 해시만 지키자 cherry-pick [커밋] 뒤에도 선택이 옛 HEAD(내 쪽 작업)에 남아 파일 비교가 방금 커밋한 줄을 "남은 차이 6줄" 이라고 했다 (되풀이 확인 첫 회차에서 남). 예전에는 선택을 놓치면 맨 위(새 커밋)로 가서 우연히 "차이 없음" 이었다.
• CommitSelection.Choose(…, previousHeadSha) — HEAD 를 보고 있다가 HEAD 가 움직이면(커밋 · 체크아웃) 새 HEAD 를 따라간다. 다른 커밋을 보고 있었으면 그대로 둔다. GitWorkspace 가 지난 새로고침의 HEAD(_lastHeadSha)를 들고 있다.
• 하네스 MergeSaveTest 5건 추가(206건): HEAD 를 보다 커밋하면 새 HEAD · 다른 커밋을 보고 있었으면 그대로 · HEAD 가 안 움직이면 그대로 · 처음 열기 · 새 HEAD 가 목록에 없음.

확인한 것 — 8차 E-1 순서를 여섯 번 (d9-a2.ps1)

회차마다 저장소를 새로 만들고, 파일 비교 탭을 미리 열지 않고, [모든 브랜치] 를 켜고 이력에서 상대 쪽 작업 → [Cherry-pick] → Weld/Unit1.cs 만 남기고 파일 단위 Accept Theirs → [3분할로 열기] · Take Theirs · [Save] → 충돌 탭 [커밋]. 새로고침이 일어나는 곳마다 Git 탭 이력의 선택 줄과 파일 비교 탭 Selected Commit 을 적었다.

지점	기대(규칙)	6회 결과
[Cherry-pick] 뒤(충돌 24)	고른 커밋 상대 쪽 작업	6/6
파일 단위 Accept 뒤(충돌 1)	고른 커밋	6/6
마지막 [Save] 뒤(충돌 0)	HEAD 내 쪽 작업 · 제목 "가져오기 전 내 쪽" · 요약 "내 쪽 대비 가져온 변경 6줄"	6/6 (Git 탭 · 파일 비교 탭 둘 다)
[커밋] 뒤	새 HEAD(cherry-pick 커밋) · "차이 없음" · Working Tree Clean	6/6 (첫 회차는 고친 뒤 되풀이 스크립트의 1회)

• 다른 브랜치 커밋(뒤이은 수정)이 기준으로 잡힌 회차 0.
• 하네스 22벌 1,117건 통과(+5) · 빌드 경고 0 · 오류 0.

남긴 것

• 자동 조작 쪽: 되풀이 스크립트가 처음에 한 회차만 돌았다. PowerShell 변수 이름은 대소문자를 가리지 않아 안쪽 반복 횟수 $rounds 가 회차 수 $Rounds 를 덮었다. 이름을 바꿔 다시 돌렸다.
• Git 탭에서 고른 커밋을 파일 비교 탭이 새로고침 전까지 안 따라오는 것(A-1 에 적음)은 그대로다.

B-1. MERGED 칸에서 반영하며 넣은 주석 줄이 다시 정렬하면 "무시" 색이 된다 (2026-09-17, 완료)

사용자 결정(2026-09-17): 처음부터 "무시" 색. ("머지 반영함" 색으로 계속 · 그대로 둔다는 고르지 않음.)

고치기 전에 다시 났다 (새로 만든 저장소, MergeHub 로 병합 → Weld/Unit1.cs 를 [3분할로 열기])

첫 충돌(101행 Power100)에서 Take Theirs → 규칙 [Aa 구분] 을 눌러 다시 정렬 → 한 번 더 눌러 되돌림.

때	범례	101행 주석 줄	LOCAL(Mine) 칸
연 뒤	무시 0 · 추가 0 · Conflict 6 · 총 3787줄	-	-
Take Theirs 직후	머지 반영함 1 · 추가 1 · 무시 0 · Conflict 5 · 총 3788줄	추가(파랑)	번호 없이 주석 글이 보임(내 파일에 없는 줄)
다시 정렬 뒤	머지 반영함 1 · 추가 0 · 무시 1 · Conflict 5	무시(회색)	빈 자리

• 6차 기록의 "처음 넣었을 때 색" 은 "머지 반영함" 이 아니라 "추가" 였다. 지시서도 그 말을 옮겨 적었다.
• 요약 · 차이 수 · 총 줄 수 · 저장된 파일(주석 1줄 · 3788줄)은 다시 정렬 전후가 같았다 — 색과 범례만 달랐다.

원인

• 주석 줄을 넣을 때(InsertNoteAbove) IsApplied = true 로 만들지만, 곧바로 반영 표시를 다시 계산하는 RefreshAppliedFlags 가 되돌리기 스택에 없는 그 줄을 반영 아님으로 되돌린다. BASE 에 없는 줄이라 "추가" 가 된다. 무시 규칙은 정렬할 때만 매겨서 넣는 순간에는 빠져 있었다.
• 다시 정렬하면 줄을 새로 만들며 규칙 "머지 주석 무시" 에 걸려 IsIgnored → "무시"(색은 무시가 먼저). 파일에 원래 있던 주석 줄과 같은 모양이다.
• 네 칸에서는 SetRemote(null, null) 이 MINE 칸에 LocalText(주석)를 넣어 LOCAL(Mine) 칸에 글이 보였다. 다시 정렬한 행은 MINE 이 빈 자리다.

고친 것

• HomeViewModel.InsertNoteAbove — 넣는 줄을 다시 정렬했을 때와 같은 모양으로 만든다. IsIgnored = Rules.IsFiltered(주석)(규칙이 꺼져 있으면 지금처럼 추가), 네 칸이면 SetThreeWay(null, null, null, null)(MINE · REMOTE 빈 자리).
• 하네스 NoteTest 5건 추가(69건): 주석 줄이 끼어든 MERGED 를 다시 정렬하면 주석 행 하나가 서고 BASE · MINE · REMOTE 가 비며, 규칙이 켜져 있으면 무시 줄 · 끄면 아님 — 넣는 순간 모양의 기준.

확인한 것 (같은 순서로 다시, d9-b1.ps1 · d9-b1-extra.ps1)

때	범례	101행 주석 줄	LOCAL(Mine) 칸
Take Theirs 직후	머지 반영함 1 · 추가 0 · 무시 1 · Conflict 5 · 총 3788줄	무시(회색)	빈 자리
[Aa] 한 번 · 두 번 다시 정렬	같음	같음	같음
[Undo]	머지 반영함 0 · 무시 0 · Conflict 6 · 총 3787줄	걷어냄	-
[Redo]	머지 반영함 1 · 무시 1 · Conflict 5 · 총 3788줄	다시 무시	빈 자리
Save 뒤	git M · 주석 1줄 · 3788줄 (고치기 전과 같음)
규칙 "머지 주석 무시" 끔 · Take Theirs 직후	머지 반영함 1 · 추가 1 · 무시 0 (지금처럼)	추가

• 하네스 22벌 1,122건 통과(+5) · 빌드 경고 0 · 오류 0. 설정은 시험마다 백업 → 되돌림(해시 같음).

알게 된 것 · 남긴 것 (고치지 않음)

• 규칙 "머지 주석 무시" 를 끈 채 다시 정렬하면 반영 색이 옆 줄로 옮겨 간다. 주석 줄이 BASE 의 코드 줄(Power93)과 한 행으로 짝지어져, 초록(머지 반영함)이 주석 줄에 · 보라(직접 수정)가 반영한 코드 줄(Power100 => 0.9)에 붙는다. 반영 표시가 BASE 줄 번호로 붙들려 있어서다. 이번에 바꾼 것이 아니고 기본값(켬)에서는 나지 않는다. 범례 수 · 저장 내용은 같다.

B-2. 폴더 비교 뒤 화면 트리를 세우는 데 1초 남짓 (2026-09-17, 완료 · 고치지 않음)

재 보니 트리는 1초가 아니었다. 트리를 만들고 첫 화면을 그리기까지 0.13~0.24초이고, 기다림의 대부분은 비교 자체였다. 줄일 자리가 없어 고치지 않았다. 제품 코드는 바꾸지 않았다.

무엇으로 쟀나

• 5차 B-2 의 시험 묶음(FolderPerf/Corpus.cs, 씨앗 고정) — 4,500개 · 같음 4,063 · 다름 359(주석만 294) · 왼쪽만 40 · 오른쪽만 38. 실제 소스는 열지 않았다.
• 앱에 임시 측정 로그를 넣어 단계를 나눴다(커밋하지 않고 잰 뒤 git checkout 으로 되돌리고 다시 빌드). ① 백그라운드 비교(FolderComparer.Compare) ② 트리 노드 만들기(Rebuild — 노드 생성 · 필터 · 가지치기 · 목록에 넣기) ③ 첫 화면(Rebuild 시작부터 WPF 가 그리기를 마치고 한가해질 때 ApplicationIdle 까지).
• 조작은 사람 길 그대로(d9-b2.ps1): 폴더 비교 탭에 두 경로 → [비교] 세 번 → 필터를 전체 · 같은 것만 · 다른 것만 · 전체로.

잰 값 (ms)

경우	비교	트리 만들기	첫 화면까지	트리 노드 · 펼쳐 보이는 것
[비교] 1회 · 캐시 찬 상태 아님(그날 첫 비교)	9,170	5	135	544 · 59
[비교] 데운 뒤 5회	682 · 796 · 703 · 683 · 711	5~17	126~167	544 · 59
필터 → 전체 (다시 훑지 않음)	-	16 · 17	240 · 229	4,608 · 275
필터 → 같은 것만	-	16	38	4,171 · 5
필터 → 다른 것만	-	6	196	544 · 59

• 기본 필터(다른 것만)에서 사람이 기다리는 시간 ≈ 비교 0.7초 + 첫 화면 0.13초 ≈ 0.85초. 트리 몫은 15% 쯤이다.
• 트리가 가장 무거운 "전체" 에서도 0.24초. 노드 만들기는 17ms 이고 나머지는 WPF 가 펼친 줄(275개)을 그리는 값이다. 트리는 이미 가상화(VirtualizingPanel Recycling)를 쓴다.

왜 5차는 "1초 남짓" 이라고 적었나

• 5차는 자동 조작으로 [비교] 를 누른 때부터 요약 글이 뜰 때까지를 쟀다(1,086ms). 이번에도 같은 방식으로는 1,084~1,428ms 가 나왔다. 그런데 누르는 도구가 누른 뒤 0.6초를 쉬고(Click 의 대기), 요약 글을 찾으려 화면 요소를 수천 개 훑는 값이 더해진다. 앱 안에서 잰 비교 + 첫 화면(0.84초)과의 차이가 그만큼이다.
• 그 차이를 "트리를 세우는 값" 으로 읽은 것이 틀렸다. 이번에는 앱 안에서 단계를 나눠 잰 값을 기준으로 삼는다.

정한 것

• 고치지 않는다. 트리 몫이 0.13~0.24초라 줄여도 사람이 느낄 차이가 없고, 트리 동작(펼침 · 선택 · 필터 · 끌어 놓기)을 건드릴 까닭이 없다. 지시서의 "트리 세우기가 대부분이면" 에 해당하지 않는다.
• "더 줄일 자리" 로 적어 둔 5차 기록은 이 측정으로 닫는다.

새로 본 것 (고치지 않음)

• 그날 첫 비교는 9.2초였다(데운 뒤 0.7초의 13배). 4,500개 파일을 디스크에서 처음 읽는 값으로 보인다(디스크 캐시 · 백신 검사). 한 번 잰 값이고 원인은 가려 보지 않았다. 사람이 처음 비교할 때 겪는 시간은 이쪽이다.

C-1. 웹 문서를 8차 끝 · 9차에 맞게 (2026-09-17, 완료)

doc\web\index.html 은 8차 D-1(E-1 · F-1 전)에서 멈춰 있었고, "지금까지 만든 것" 쪽은 6차에서 멈춰 있었다. 지난 기록 쪽(6차 표 · 발표 슬라이드)은 그때 이름 그대로 두었다.

고친 것

자리	고친 것
머리글 · 개요	"2026-09-17 기준" · 하네스 22벌 · 1,122건(1,073건에서) · "8차 끝 · 9차 진행 · 다섯 길 줄끝 바뀐 파일 0" · 로컬 커밋 104(94에서, 이 기록 커밋 포함) · 출처 작업지시/9차.md
매뉴얼 · 병합 충돌 푸는 순서	병합 커밋 본문이 저절로 붙는다는 말 · 마지막 저장 뒤 두 칸 기준이 HEAD 로 옮겨지고 작업별 요약(병합 · rebase · cherry-pick · revert) · 다른 커밋을 고르면 보통 요약 · 커밋하면 새 HEAD 로
매뉴얼 · 새 절 "충돌을 어떻게 풀었는지 어디에 남나"	소스(머지 주석) · 병합 커밋 본문(8차 F-1) · Git 탭 로그 표, 본문 예시(E-1 병합의 갈래별 건수 26개), cherry-pick · revert · rebase 는 본문 없음 · 30개 넘으면 줄임. 목차에 "해결 기록이 남는 곳"
매뉴얼 · Git 탭 이력 · 머지 주석	모든 브랜치에서 목록 순서가 바뀌어도 고른 커밋 그대로(9차 A-2) · 반영하며 넣은 주석 줄도 처음부터 무시 색 · Mine 칸 빈 자리(9차 B-1)
매뉴얼 · 알아 둘 한계	더함: 본문 해결 내역은 MergeHub 에서 푼 충돌만 · 그날 첫 큰 폴더 비교 9.2초(9차 B-2) · Git 탭에서 고른 커밋을 파일 비교 탭이 새로고침 전까지 안 따라옴(9차 A-1) · 머지 주석 무시를 끈 채 다시 정렬하면 반영 색이 옆 줄로(9차 B-1)
남은 일	머리말 "8차까지 끝 · 9차 A · B 끝" · 8차 표에 D-1 · F-1 · E-1 · 새 표 "9차에서 고친 것"(A-1 · A-2 · B-1 · B-2) · "8차에 남은 것" → "9차에 남은 것"(D-1) + "정해서 두지 않는 것"(빈 cherry-pick 커밋 · 스타일 맞춤 선택지 · 반쪽 스냅 · 1px 테두리)
지금까지 만든 것	머리말 · 숫자(커밋 104 · 1,122건) · 차수별 기록에 7차 · 8차 · 9차 · 하네스 막대에 8차 1,094 · 9차 진행 1,122(7차는 따로 적지 않아 뺐다, 막대 폭 다시 계산) · 기능 목록 Git 에 병합 커밋 본문
비교 표(WinMerge)	"22벌 1,073건" → 1,122건

확인한 것

• 화면 문구와 대조(앱 소스 grep): "충돌 정리 끝" · "병합 커밋을 할 수 있습니다" · "으로 rebase 를 이어 갑니다" · "올릴 자리 대비 올린 변경" · "내 쪽 대비 가져온 / 되돌린 / 받은 변경" · 본문 갈래 이름 7가지(MergeResolutionLog.Label) · "새로고침" · "3분할로 열기" · "Selected Commit" 모두 소스에 있다.
• 옛 숫자 · 옛말이 남지 않았다: "1,073" · "7차 끝 · 8차 진행" · "8차에 남은 것" 0건.
• 태그 짝: section 26/26 · div 195/195 · table 28/28 · ul 36/36 · ol 11/11 · li 200/200 · tr 223/223 · td 538/538 · pre 11/11 · code 71/71 · h2 37/37 · h3 26/26. 제어 문자 0.
• 발행: 같은 주소의 아티팩트를 버전 9 로 갱신했다(먼저 발행본을 읽어 저장소의 직전 파일과 같은지 대조 — 게시용 겉틀만 달랐다 — 뒤 버전 8 로 올리고, 머리글 날짜를 고쳐 9). 저장소의 doc/web/index.html 과 같은 파일이다.
• 로컬 파일은 브라우저 창에서 스크립트로 넘길 수 없어 미리 보기는 하지 않았다.

제품 코드는 바꾸지 않았다.

D-1. cherry-pick · revert 를 마지막 파일까지 네 칸으로 끝까지 (+ 병합 · rebase 회귀) (2026-09-17, 완료)

지시서대로 고치지 않고 적기만 했다. 제품 코드는 바꾸지 않았다(웹 문서의 "9차 진행" 표시만 "9차 끝" 으로 맞춰 아티팩트 버전 10).

무엇으로 했나

• 길마다 C1Repo 로 저장소를 새로 만들고 파일 비교 탭을 미리 열지 않았다(D7_NO_PREOPEN=1). 이름 창은 [저장], 설정 CSharpBraceStyle 은 길마다 백업 → 끔 → 되돌림(네 번 모두 해시 같음).
• 병합 · rebase · cherry-pick 은 8차 E-1 과 같은 순서(같은 줄 충돌 15개 파일 단위 Accept Theirs → NewPanel Accept Both [아니오] → [3분할로 열기] 뒤 저절로 열리는 파일마다 Theirs · Mine 번갈아 [Save] · 띠 [파일 지우기] · [파일 남기기]). 마지막 파일 Weld/Unit1.cs 는 네 칸 [Save].
• cherry-pick 은 [모든 브랜치] 를 켜고 이력에서 상대 쪽 작업 을 골랐다. revert 도 [모든 브랜치] 를 켜고 feature/revert 에서 내 쪽 작업 을 골라, 15개는 파일 단위 Accept Theirs · 마지막 Motion/Unit0.cs 는 네 칸에서 Take Theirs 6 → [Save] (8차 E-1 revert 는 마지막을 파일 단위로 풀었다).
• 새로 넣은 확인 — 기준 대조: 마지막 [Save] 뒤 HEAD · 제목의 해시 · Selected Commit · 요약의 N줄을 git diff -U0 HEAD(머지 주석 줄 뺀 +/− 줄 수)와 견줌. 커밋 뒤 보기: [병합 커밋] · [계속] · [커밋] 뒤 파일 비교 탭의 Selected Commit 이 새 HEAD 인지.

네 길의 결과

확인	① 병합	③ rebase	④ cherry-pick ([모든 브랜치])	⑤ revert ([모든 브랜치])
줄 고른 로그	18줄 · "3-Way 안 씀" 0	18줄 · 0	18줄 · 0 (다시 한 회차)	6줄 · 0
마지막 [Save] 한 파일	Weld/Unit1.cs (네 칸)	Weld/Unit1.cs	Weld/Unit1.cs	Motion/Unit0.cs (네 칸)
마지막 Save 뒤 제목	53493f7 · Weld/Unit1.cs · 병합 전 내 쪽	285f078 · … · 올릴 자리	09273c6 · … · 가져오기 전 내 쪽	81b33fa · Motion/Unit0.cs · 되돌리기 전 내 쪽
마지막 Save 뒤 요약	충돌 정리 끝 · 병합 커밋을 할 수 있습니다 · 내 쪽 대비 받은 변경 3줄	… · [계속] 으로 rebase 를 이어 갑니다 · 올릴 자리 대비 올린 변경 3줄	… · [커밋] 으로 cherry-pick 을 끝냅니다 · 내 쪽 대비 가져온 변경 3줄	… · [커밋] 으로 revert 를 끝냅니다 · 내 쪽 대비 되돌린 변경 6줄
기준 대조 (HEAD = 제목 = Selected Commit, N = git)	같음 · git +3 −3 (주석 3 뺌)	같음 · +3 −3	같음 · +3 −3	같음 · +6 −6 (주석 6 뺌)
끝낸 커밋	29c83ee 부모 둘 · 본문 충돌 해결 26개 · 김승준	83f1d7a 부모 하나(올릴 자리 위)	52ba0dd 부모 하나 · 작성자 박지훈 · 커밋한 사람 시험	aab2f8d Revert "내 쪽 작업" · REVERT_HEAD 없음
커밋 뒤 파일 비교 탭 기준	새 HEAD 29c83ee	새 HEAD 83f1d7a	새 HEAD 52ba0dd	새 HEAD aab2f8d
줄끝 · BOM · 인코딩 바뀐 파일	0 / 33	0 / 31	0 / 33	0 / 36
충돌 표식 · class 이름 다른 Unit	0 · 0	0 · 0	0 · 0	0 · 0
빈 cherry-pick (방금 만든 HEAD 를 다시)	-	-	[커밋] 꺼짐 · 로그 "cherry-pick 했지만 가져올 변경이 없습니다 - [작업 취소] 로 끝냅니다" · [작업 취소] 로 나옴	-

판정 기준

기준	결과
네 길 모두 MergeHub 만으로 끝까지	됐다 (cherry-pick 은 두 번째 회차 — 아래)
줄끝 · BOM 바뀐 파일 0 · 충돌 표식 0 · class 이름 다른 Unit 파일 0	네 길 모두 0
마지막 [Save] 뒤 제목 · 요약 · 실제 기준이 서로 같다	네 길 모두 같음 — 요약의 N 도 git diff 와 같음
8차 A-1 · B-1 · B-2 · F-1 다시 안 남	안 남 — [3분할로 열기] 로 처음 열어도 고른 파일(class 검사 0), rebase "올릴 자리", 빈 cherry-pick [커밋] 꺼짐, 병합 본문 26개
(9차 A-2) 커밋 뒤 기준	네 길 모두 새 HEAD

새로 걸린 것 (고치지 않음)

#	무엇	근거
N1	cherry-pick 첫 회차에서 Motion/Unit0.cs 충돌 6개를 차례로 고른 뒤 요약이 "남은 충돌 1개" 로 남아 [Save] 가 꺼졌고, 흐름이 거기서 멈췄다(충돌 5개 남은 채 끝).	줄 고른 로그가 병합 · rebase 는 18줄인데 그 회차는 10줄 — Unit0 에서 고르기 한 번이 로그에 남지 않았다. 새 저장소로 같은 순서를 다시 하니 18줄 · 끝까지 갔다. 누름 한 번이 앱에 닿지 않은 자동 조작 쪽 문제로 보이지만(7차 C-2 · 8차 C-1 의 목록 선택이 안 닿던 것과 같은 모양) 원인을 가려 보지는 않았다. 사람이 겪는다면 "남은 충돌 1개" 와 [다음 충돌] 이 남은 곳을 알려 주므로 막히지는 않는다.

시험 도구 쪽 (제품 결함 아님)

• 결과 확인 스크립트가 부모 하나인 커밋(rebase · cherry-pick · revert)에서 merge-base 사용법 오류를 찍지만, 줄끝 판정은 첫 부모와 제대로 한다(8차 E-1 과 같음).
• 빈 cherry-pick 뒤 진행 줄 읽기가 빈 글로 나온 것은 스크립트가 "남은 충돌 · 충돌 정리 끝" 으로 시작하는 줄만 읽어서다. 안내 글은 로그와 [커밋] 꺼짐으로 확인했다.
• pull 은 지시서 범위(병합 · rebase 회귀)가 아니라 이번에 돌리지 않았다.

코드는 바꾸지 않았으므로 검사는 그대로(하네스 22벌 1,122건) · 빌드 경고 0 · 오류 0. 설정 · 창 기억은 되돌림, 앱 꺼짐.