Ubisam-MergeTool/doc/작업지시/9차.md

작업 지시 — MergeHub 9차 (두 칸이 무엇과 견주는지 사실대로 · 8차에서 남긴 것)

대상: D:\Sorce\MergeTool\MergeHub (플러그인) · D:\Sorce\MergeTool\UbisamPlatform (셸) 전제: 1~8차 지시서는 모두 끝났다(../진행상황.md).

이번 지시서가 나온 곳 — 8차 E-1 에서 시험 저장소를 길마다 새로 만들어 병합 · pull · rebase · cherry-pick · revert 를 파일 비교 탭을 미리 열지 않고 MergeHub 만으로 끝까지 했다. 다섯 길 모두 커밋까지 갔고 줄끝 · BOM 바뀐 파일 · 충돌 표식 · class 이름 다른 파일이 모두 0 이었다. 새로 걸린 것은 하나(N1)와 그 곁가지 하나다. 파일을 망가뜨리지는 않지만, 화면이 줄 수를 무엇과 견줬는지 틀리게 말한다. 근거와 수치는 ../history/2026-09-16-8차.md 의 E-1 에 있다.

8차 E-1 에서 잰 것	병합	pull	rebase	cherry-pick	revert
끝낸 커밋	부모 둘	부모 둘	rebase 완료 1/1	부모 하나 · 원래 메시지 · 작성자 박지훈	Revert "내 쪽 작업"
줄끝 · BOM 바뀐 파일	0 / 33	0 / 33	0 / 31	0 / 33	0 / 36
충돌 표식 · class 이름 다른 파일	0 · 0	0 · 0	0 · 0	0 · 0	0 · 0
마지막 Save 뒤 두 칸의 기준(BASE)	HEAD	HEAD	HEAD	이력에서 고른 커밋	(마지막 파일은 파일 단위라 안 봄)
커밋 본문 해결 내역(8차 F-1)	26개	26개	해당 없음	해당 없음	해당 없음

---

공통 규칙

• A → B → C → D 순서로 진행한다. A 는 화면이 사실과 다르게 말하는 것이라 먼저다.
• 항목 하나를 끝낼 때마다 빌드하고 실제로 실행해 화면을 확인한 뒤 보고한다.
• 항목 하나가 끝나면 기록을 세 군데에 남기고 로컬 커밋한다(4차 D-2 규칙).
  1. 상세는 doc/history/YYYY-MM-DD-9차.md — 원인 · 판단 · 확인한 결과
  2. ../진행상황.md 은 대기 → 완료로 상태만
  3. ../history/changelog.md 에 한 줄 — 날짜 · 무엇을 왜 · 커밋
• 푸쉬하지 않는다.
• 실제 소스를 열지 않는다(2026-09-11 결정). 시험 재료는 C1Repo 로 만든 저장소로 한다. 씨앗이 고정돼 몇 번을 만들어도 내용은 같다 (커밋 해시는 만든 시각에 따라 달라진다 — 기록에는 해시보다 커밋 제목을 적는다). 고치기 전에 문제가 다시 나는 것부터 보이고, 고친 뒤 안 나는 것을 보인다.
• 기존 검사 하네스(22벌 1,094건)는 계속 통과해야 한다. 로직을 건드리면 테스트를 먼저 늘린다.
• 빌드 경고 0 · 오류 0 을 유지한다. 앱이 실행 중이면 UbisamBase.Shell 을 먼저 종료한다.
• 사용자 설정 파일(D:\UbisamConfig\Settings\MergeHubSettings.json)은 시험 전에 백업하고, 끝나면 바이트 그대로 되돌린다. 창 기억(ShellWindowPlacement.json)은 시험 뒤 "기억 없음" 으로 둔다.
• 자동 조작으로 확인할 때는 사람이 갈 수 있는 길만 쓴다. 켤 때 뜨는 이름 창은 [저장] 으로 닫고, 접힌 원격 영역은 [펴기] 로 연다. 파일 비교 탭은 미리 열지 않는다(D7_NO_PREOPEN=1).
• 문서 글을 PowerShell 로 넣을 때는 작은따옴표 문자열만 쓴다(8차에서 배움 — 큰따옴표 안의 백틱이 이스케이프로 먹혀 changelog 줄이 깨졌다).
• 결과 확인은 줄끝만 보지 않는다. 충돌 표식과 UnitN.cs 안의 class 이름도 본다.
• 플랫폼을 고치면 다른 소비 프로그램에 미치는 영향을 함께 적고 UbisamPlatform/doc/history/changelog.md 에 남긴다. 배포는 사용자 확인 뒤.

---

A. 두 칸이 무엇과 견주는지 사실대로

A-1. cherry-pick 마지막 저장 뒤 "내 쪽 대비" 라고 하지만 실제 기준은 이력에서 고른 커밋이다 (8차 E-1 N1) — 먼저 정한다

• 다시 내는 순서(8차 E-1 에서 따로 재 봄):
  1. 새 저장소를 열고 이력 탭 [모든 브랜치] 를 켠 뒤 상대 쪽 작업 커밋을 골라 [Cherry-pick].
  2. 충돌 탭에서 Weld/Unit1.cs 만 남기고 나머지를 파일 단위 Accept Theirs.
  3. Weld/Unit1.cs 를 [3분할로 열기] → 충돌마다 Take Theirs → [Save].
  4. 파일 비교 탭이 두 칸으로 떨어진다. 제목은 (가져온 커밋 짧은해시) · Weld/Unit1.cs, 요약은 "충돌 정리 끝 · [커밋] 으로 cherry-pick 을 끝냅니다 · 내 쪽 대비 가져온 변경 N줄". HEAD 는 다른 커밋이다.
• 제목은 사실(고른 커밋)을 말하는데 요약은 HEAD 와 견준 것처럼 말한다. 두 글이 서로 다른 기준을 말한다. 8차 B-1 기록의 "cherry-pick 제목에 꼬리가 없는 것은 맞다" 는 제목만 본 판단이었다.
• 짚이는 곳(코드를 읽어 짚은 것 — 원인부터 확인할 것):
  • HomeViewModel.cs 의 BASE 제목은 commit.ShortSha == _workspace.HeadSha 일 때만 작업 글("가져오기 전 내 쪽")을 쓰고, 아니면 짧은해시 · 경로 다.
  • 같은 파일의 요약(UpdateSummaries)은 OperationLabels.ResolvedSummary 를 선택 커밋이 HEAD 인지 보지 않고 쓴다. 그래서 "내 쪽 대비" 가 붙는다.
  • 선택 커밋은 이력 탭과 함께 쓰는 _workspace.SelectedCommit 이다(GitViewModel.cs 에서 이력 선택이 넣음). 새로고침 뒤에는 비어 있을 때만 Commits[0] 으로 채운다(GitWorkspace.cs). 병합 · rebase 는 이력에서 커밋을 고르지 않아 HEAD 로 남고, cherry-pick · revert 는 이력에서 커밋을 골라 시작하므로 그 커밋이 남는다.
  • revert 도 같은 길일 것이다. 8차 C-1 · E-1 의 revert 는 마지막 파일을 파일 단위로 풀어 두 칸을 보지 않았다.
• 고치기 전에 사용자에게 두 가지를 보이고 정한다(스크린샷과 함께).
  1. 작업 중 충돌을 다 풀고 두 칸으로 돌아갈 때 기준을 HEAD 로 옮긴다 — 병합 · rebase 와 같아지고 "내 쪽 대비 가져온 변경 N줄" 이 사실이 된다. 대신 이력 탭의 선택도 HEAD 로 움직인다(같은 선택을 쓰므로). 이력 선택을 두고 파일 비교 쪽만 HEAD 로 볼 수 있는지도 함께 본다.
  2. 기준은 고른 커밋 그대로 두고 글을 맞춘다 — 요약은 기준이 HEAD 일 때만 작업 글, 아니면 "충돌 정리 끝 · [커밋] 으로 cherry-pick 을 끝냅니다 · 짧은해시 대비 N줄".
• 판정 기준:
  • 정한 대로 cherry-pick · revert 마지막 [Save] 뒤 제목과 요약이 같은 기준을 말한다. 줄 수가 그 기준과 실제로 견준 수와 같다(git 으로 같은 두 쪽을 diff 해 대조).
  • 병합 · pull · rebase 의 요약 · 제목은 8차 B-1 그대로(하네스로 확인).
  • 작업이 없을 때 이력에서 커밋을 골라 보는 보통 비교는 지금 그대로.

A-2. 한 번은 기준이 HEAD 도 가져온 커밋도 아닌 다른 브랜치 커밋이었다 (8차 E-1 N1-덧) — 원인부터

• 8차 E-1 cherry-pick 에서 마지막 [Save] 뒤 제목이 f310f49 · Weld/Unit1.cs 였다. HEAD(b7ac29b)도 가져온 커밋(68fe17f)도 아니었고, 요약의 줄 수(3줄)로 보면 [모든 브랜치] 목록의 다른 브랜치 커밋(뒤이은 수정)으로 보인다. 같은 순서로 따로 다시 재니 나지 않았다.
• 짚이는 곳: 새로고침 때 커밋 목록을 갈아 끼우면(Replace(Commits, …)) 이력 목록이 고른 줄을 위치(순번)로 다시 잡을 수 있다. [모든 브랜치] 를 켜면 cherry-pick 뒤 목록 순서가 바뀐다. 선택 커밋이 목록에 없는 옛 객체로 남는 경우도 본다.
• 방향:
  1. 원인부터 — 새로고침 전후로 선택 커밋 · 목록 순번 · 이력 탭 선택 줄을 로그로 남겨 cherry-pick 길(8차 E-1 순서 그대로)을 다섯 번 이상 되풀이한다. 작업 순서(파일 단위 Accept 여러 번 · [3분할로 열기] · 저장 뒤 저절로 다음 파일 열기)가 새로고침을 겹치게 하는지 본다.
  2. 다시 나면 원인을 적고 고친다 — 새로고침 뒤에도 선택은 같은 해시의 커밋으로 돌아가야 한다.
  3. 다섯 번 넘게 해도 안 나면, 코드로 짚은 만큼과 되풀이한 횟수를 적고 사용자에게 보고한 뒤 닫는다(짐작으로 고치지 않는다).
• 판정 기준: 새로고침(작업 시작 · 충돌 해결 · 커밋) 뒤 선택 커밋의 해시가 새로고침 전과 같다. 목록 순서가 바뀌는 [모든 브랜치] 에서도. 하네스로 "목록 순서가 바뀐 새로고침 뒤 선택 복원" 을 만든다.

---

B. 전에 남겨 둔 작은 것

B-1. MERGED 칸에서 반영하며 넣은 주석 줄이 다시 정렬하면 "무시" 색이 된다 (6차 기록) — 먼저 정한다

• 6차 기록(../history/2026-09-14-6차.md): 네 칸에서 줄을 가져오며 들어간 머지 주석 줄이, 다시 정렬하면(타이핑 멈춤 · 규칙 변경) "무시" 색으로 바뀐다. 차이 수에는 원래도 세지 않던 줄이다.
• 8차 B-3 에서 MERGED 번호를 결과 파일 번호로 바꿨다. 주석 줄은 결과에 들어가는 줄이라 번호가 붙는다 — 색과 번호가 서로 다른 말을 하는지 본다.
• 방향: 만든 저장소에서 다시 내 스크린샷으로 보이고 사용자와 정한다. ① 주석 줄은 처음 넣었을 때 색 그대로 ② 지금처럼 "무시" 색(비교에서 무시하는 줄이라는 뜻). 정한 뒤 고친다면 차이 수 · 번호 · [다음 충돌] 이동은 그대로여야 한다.
• 판정 기준: 정한 대로 색이 다시 정렬해도 바뀌지 않는다(또는 그대로 두기로 한 까닭을 적는다). 차이 수 · MERGED 번호 · 저장된 파일은 8차 결과 그대로.

B-2. 폴더 비교 뒤 화면 트리를 세우는 데 1초 남짓 (5차 B-2 기록) — 재고 정한다

• 5차 기록(../history/2026-09-11-5차.md): "지금도 1초 남짓이고, 건드리면 트리 동작이 바뀔 위험이 있다. 더 줄일 자리로 적어 둔다."
• 방향: 만든 폴더 두 벌(파일 수를 정해 적는다)로 비교 · 트리 세우기 · 첫 화면까지를 나눠 잰다. 트리 세우기가 대부분이면 줄일 방법과 위험을 적어 사용자에게 보이고 정한다. 트리 동작(펼침 · 선택 · 필터 · 끌어 놓기)이 바뀌는 방법이면 하지 않는다.
• 판정 기준: 잰 값(세 번 평균)을 적는다. 고쳤다면 같은 폴더로 전후를 견주고 트리 동작 확인 목록이 모두 그대로다. 안 고치기로 했다면 까닭을 적고 "미룬 것" 으로 옮긴다.

---

C. 문서

C-1. 웹 문서를 8차 끝 · 9차에 맞게

• doc\web\index.html 은 8차 D-1(E-1 · F-1 전)에서 멈춰 있다.
  • 개요 숫자가 "7차 끝 · 8차 진행" · "22벌 · 1,073건" 이다(지금 1,094건).
  • 8차 F-1(병합 커밋 본문에 해결 내역)이 매뉴얼에 없다(본문 0건). 파일 단위 Accept 의 기록이 어디 남는지 알려 줄 곳이다.
  • 남은 일의 "8차에 남은 것" 에 끝난 E-1 이 남아 있다.
• A · B 를 고친 뒤 한 번에 맞춘다. 지난 기록(history)은 그때 이름 그대로 둔다.
• 판정 기준: 문서의 단추 이름 · 요약 글이 지금 화면과 같다(화면 문구를 grep 으로 대조). F-1 이 매뉴얼에 있다(본문 예시 포함). "알아 둘 한계" · 남은 일이 9차 끝 기준이다. 태그 짝이 맞는다. 발행된 아티팩트도 같은 내용으로 갱신.

---

D. 확인

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

• A · B 를 고친 뒤 저장소를 새로 만들어 한다. 파일 비교 탭은 미리 열지 않는다.
• cherry-pick · revert 는 마지막 파일을 네 칸 [Save] 로 푼다 — 8차 E-1 revert 는 마지막을 파일 단위로 풀어 두 칸의 기준을 보지 못했다. 둘 다 [모든 브랜치] 를 켠 채로 한다(A-2 를 밟는 순서).
• 병합 · rebase 는 마지막 [Save] 뒤 요약 · 제목만 다시 본다(8차 B-1 회귀).
• 8차 E-1 과 같은 표로 적는다. 새로 걸린 것은 고치지 말고 적는다 — 그 목록이 10차가 된다.
• 판정 기준: 네 길 모두 MergeHub 만으로 끝까지. 줄끝 · BOM 바뀐 파일 0 · 충돌 표식 0 · class 이름 다른 Unit 파일 0. 마지막 [Save] 뒤 제목 · 요약 · 실제 기준이 서로 같다. 8차 A-1 · B-1 · B-2 · F-1 이 다시 나지 않는다.

---

이번 지시서에서 하지 않는 것

• 실제 소스로 병합해 보기 — 실제 소스는 열지 않는다(2026-09-11 결정).
• 빈 cherry-pick 을 커밋으로 남기는 길(--allow-empty) — 두지 않기로 했다(2026-09-16 사용자 결정).
• 비교할 때만 C# 스타일을 맞추고 저장은 원래대로 하는 선택지 — 만들지 않기로 했다(2026-09-17 사용자 결정).
• MergeHub 밖(터미널)에서 푼 충돌을 병합 본문에 적기 — 알 길이 없다. 본문 건수가 처음 충돌 수보다 적으면 그만큼은 밖에서 푼 것이다(8차 F-1).
• 셸 창 스냅이 화면 반쪽이 안 되는 것 — 최소 크기(1280×720 DIP)가 반쪽보다 크다. 최소 크기를 줄이지 않는 한 그대로(8차 C-3). 왼쪽 스냅에서 Win+→ 가 가끔 복원되지 않는 것은 Windows 쪽 동작이라 두고 본다. 1px 테두리는 그대로(사용자 결정).
• 화면 잠금 확인 창의 가운데 맞춤을 자동으로 재기 — 잠그면 사람이 풀어야 해서 확인이 멈춘다. 이름 창과 같은 길(OwnerCentering)이라 함께 맞는다(8차 C-3).
• 빠른 비교(크기 · 수정일)가 내용만 바뀐 파일을 놓치는 것 — 폴더 비교의 알려진 한계로 둔다.
• 같은 줄 접기(4차 B-2) · 외부 편집기(4차 B-4) · 로그인·권한 · Gitea PR — 미룬 그대로 둔다.

---

보고 형식

항목마다 이렇게 적는다.

• 고치기 전에 문제가 다시 나는 것을 어떻게 보였는지 (만든 저장소의 어느 파일로)
• 무엇이 원인이었는지 한두 줄
• 어떤 파일을 어떻게 고쳤는지
• 실제로 실행해 확인한 결과 (줄 수 · 해시 · 줄끝 · 충돌 수 · class 이름처럼 눈이 아닌 값으로)
• 커밋 해시