사용자 결정(2026-09-18): 새 폴더를 만든다 · 쓰다 막히면 먼저 보고 시작한다.
- Services/ExportPlan.cs (새 파일): 폴더 이름(변경분_범위_날짜) · 같은 이름이면 _2 _3 · 쓸 수 있는지 먼저 보기 · 보일 글
- GitService.ExportChangedFiles: 쓰기 전에 막힌 파일을 먼저 보고, 하나라도 있으면 폴더도 만들지 않고 멈춘다
- GitViewModel: 고른 폴더 아래 새 폴더에 뽑고 안내는 그 옆에. 알림에 폴더 이름
- 하네스 ReportTest +12 (45 → 57), 22벌 1,185건 통과, 빌드 경고 0 오류 0
- 화면 확인: 같은 폴더에 두 번 뽑아 _2 가 생기고 기존 파일(메모 · 옛 폴더)은 그대로
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
사용자 결정(2026-09-18): 안내는 폴더 밖(옆)에 · 지울 파일은 목록으로만.
- Services/ExportReport.cs (새 파일): 머리글(만든 때 · 사람 · 저장소 · 뽑은 곳 · 범위 두 줄) · 뽑은 파일 목록(추가 · 수정 · 이름 바뀜은 옛 이름 병기) · 장비에서 지워야 할 파일 목록. PathFor 가 폴더 옆 이름을 정함
- GitService.ExportChangedFiles 가 무엇을 어떻게 했는지 목록까지 돌려줌 (IGitService 같이)
- GitViewModel: 뽑은 뒤 안내를 폴더 옆에 쓰고 경로를 로그에. 안내를 못 써도 추출은 성공으로 둔다
- 하네스 ReportTest +14 (31 → 45), 22벌 1,173건 통과, 빌드 경고 0 오류 0
- 화면 확인: 범위 4eb9ece→cbcad8a 안내가 git diff -M 과 같음(뽑은 3 · 지울 2), 병합 커밋은 '(고른 커밋의 부모)' 표시
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
충돌 탭 파일 단위 Accept 는 소스에 주석이 안 남고, 병합 커밋 본문은 비어 있었고,
Git 탭 로그는 끄면 사라져 누가 어느 파일을 어떻게 풀었는지 남는 곳이 없었다(사용자 요청).
- MergeResolutionLog: 기록 파일(첫 줄 MERGE_HEAD) 읽기 · 쓰기, 본문 만들기, 메시지에 붙이기
- GitService: 병합 중일 때만 .git/MERGEHUB_RESOLUTIONS 에 적고, CommitMerge 가 본문을 붙인다.
병합 커밋 · 작업 취소 · 새로고침 때 쓸모없는 기록을 치운다
- 충돌 탭 Accept Mine/Theirs/Both · [Save] · Save & Commit · 파일 남기기/지우기 · 머지 주석 자동이 적는다
- Git 탭 메시지 칸에 본문을 미리 채우고, 풀 때마다 새로 채운다(사람이 고치면 두고 커밋 때 붙임)
- 하네스 MergeSaveTest 183건(21건 추가), 22벌 1,094건 통과
확인: 병합 "충돌 해결 26개 · 김승준"(줄 단위 7 · Theirs 15 · 남기기 1 · 지우기 1 · 주석 자동 2),
pull 26개, Accept Mine 기록 뒤 [작업 취소] 로 기록 파일 없음. 줄끝 · BOM 0/33, 회귀 없음.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
이미 들어 있는 커밋을 cherry-pick 하면 [커밋] 이 켜졌고, 누르면 로그에
"[cherry-pick 커밋] 실패: No changes; nothing to commit." 만 남았다. 진행 줄도 그대로였다.
- GitService.HasStagedChanges() 를 두고 적용 로그 · 커밋 앞 막음에 쓴다
- GitWorkspace.PendingHasChanges 를 상태로 들고, 진행 줄이 그 값을 본다
- CanFinishOperation 은 cherry-pick · revert 에서 커밋할 것이 있어야 켜진다
- 병합 커밋은 트리가 같아도 정상이라 걸지 않는다
- 하네스 MergeSaveTest 155건(진행 줄 7건), 18벌 921건 통과
확인: HEAD 커밋을 다시 cherry-pick → [커밋] 꺼짐 · "가져올 변경이 없습니다 - [작업 취소] 로 끝냅니다" ·
[작업 취소] 로 빠져나옴. 충돌 24건짜리 보통 cherry-pick 은 그대로 커밋까지(원래 메시지).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
화면이 모든 충돌을 "병합" 으로 불렀다 - rebase REMOTE 가 "THEIRS", cherry-pick 에 "병합 진행 중",
다 풀면 cherry-pick 을 끝낼 단추가 없고, 로그에 RebaseContinue() · Commit(), 다른 브랜치 커밋은 고를 수 없었다.
GitOperationState 로 칸 제목(올릴 자리 · 다시 올리는 내 커밋 · 가져오는 커밋) · 머리 글 · 진행 표시 ·
끝내기 단추(병합 커밋 · 계속 · 커밋)를 정한다. cherry-pick · revert 는 원래 메시지 · 작성자로 커밋.
머지 주석 자동 풀기 · 알림도 같은 뒷일. 이력 탭 [모든 브랜치].
rebase · cherry-pick 모두 줄끝 바뀐 파일 0, MergeSaveTest 125건 통과.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
병합 때 적는 처음 충돌 목록이 병합 커밋 · 작업 취소 · 터미널에서 끝낸 병합 뒤에도 남았다.
MERGE_HEAD 가 없거나 다른 병합의 것이면 병합 커밋 · 작업 취소 직후와 상태를 다시 읽을 때마다 지운다.
병합 중에는 그대로라 "푼 것 M개 (M/전체)" 는 이어진다. 세 경우 화면에서 확인, MergeSaveTest 88건 통과.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
양쪽이 같은 이름으로 새로 만든 파일에 Accept Both 를 누르면 묻지 않고
두 blob 을 바이트째 이어 붙였다. 결과 파일 한가운데에 BOM 이 하나 더
들어갔고 같은 class 가 두 번 나와 빌드가 안 됐다.
- BothJoin: 두 벌을 각자 제 인코딩으로 글로 풀어 이어 붙인 뒤 내 쪽
형식(인코딩, BOM, 줄끝)으로 다시 쓴다. 규칙은 A-1 의 TextFile.Encode
- ResolveConflict(Both): 바이트 이어 붙이기 대신 BothJoin
- Git 탭 Accept Both: 먼저 묻는다(무엇이 일어나는지, 줄 단위로 둘 다
넣으려면 3분할에서). 단추 도움말
Both 는 없애지 않았다. 이어 붙이는 게 맞는 파일도 있다.
화면 확인 14건 통과(묻기, 아니오면 그대로, 예면 BOM 1개와 CRLF 한
가지, 보통 충돌도 같음). EncTest 10건 추가. 21벌 785건 통과
(새로 빌드한 실행 파일). 경고 0, 오류 0. A 묶음 끝.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
병합 중에 충돌 파일을 고르면 BASE 와 내 것 두 칸뿐이었다. 읽기는
충돌 갈래(세 벌)로 했지만 켠 것은 지역 변수 threeWay 뿐이고, 화면
틀을 정하는 IsThreeWay 는 콤보에서 브랜치를 골랐을 때만 참이었다.
상대가 무엇을 바꿨는지 안 보인 채 풀게 됐다.
- IsThreeWay: 콤보로 고른 3-Way 이거나 충돌 파일이라 켠 3분할이면 참.
충돌 쪽은 따로 둔 깃발이라 콤보 값은 건드리지 않는다
- LoadFileAsync: 행을 싣기 전에 틀부터 바꾸고, 읽기 갈래는 콤보로
고른 3-Way 만 본다(앞 파일의 3분할이 다음 파일로 새지 않게)
- GetMergeTheirsName: MERGE_HEAD 를 가리키는 브랜치 이름, 없으면
병합 메시지의 이름, 그것도 없으면 짧은 해시
- MergeNames: 병합 메시지에서 이름 꺼내기(저장소 없이 검사)
- REMOTE 제목에 상대 브랜치 이름
화면 확인 18건 통과(충돌 파일 네 칸, 제목 REMOTE · feature/theirs,
콤보 없이 해결로 저장, 병합이 끝나면 두 칸, 콤보 3-Way 는 예전과 같음).
MergeSaveTest 14건 추가. 21벌 759건 통과(새로 빌드한 실행 파일).
경고 0, 오류 0.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
3분할로 푼 파일을 저장하면 줄끝이 전부 LF 가 됐다. 3,363줄 CRLF
파일에서 충돌 6개를 풀었는데 git 에는 파일 전체가 바뀐 것으로 나왔다.
원인은 둘이었다.
- ResolveConflictWithContent 가 인코딩만 맞추고 줄끝을 안 봤다.
편집기 글은 줄마다 \n 이라 늘 LF 로 써졌다.
- 원본으로 워킹트리 파일을 읽었다. 충돌 중에는 git 이 LF 로 충돌
표시를 넣어 두어 원본이 아니다.
- TextFile.Encode: 저장 바이트 규칙을 한 곳으로. "원본 유지" 는
넘겨받은 원본 바이트를 따르고, 줄끝은 가장 많은 것, BOM 은 한 번
- TextFile.Write: 디스크 파일을 원본으로 Encode 를 쓴다
- ResolveConflictWithContent: 원본을 ours blob 으로(없으면 theirs,
base). 고른 저장 형식을 받는다
- HomeViewModel 세 자리가 저장 형식을 넘긴다
Io/Unit12.cs +399 줄 -> +2 -1, CRLF 유지
Motion/Unit0.cs +3367 -3363 -> +8 -4
한글설명.cs CP949 와 CRLF 유지
LineEnding.cs 상대가 LF 로 바꿔도 내 쪽 CRLF
줄바꿈 LF 를 고르면 LF
검사 모음이 빌드 실패를 삼키고 옛 실행 파일을 돌리던 것을 찾았다.
LangTest(5차 B-1 의 CarryOver 변경), ReportTest(파일 누락),
TokenTest(Program.cs 없음, 새로 씀)를 고쳤다. 이제 모두 다시 빌드한
새 실행 파일만 센다. 21벌 745건 통과. 경고 0, 오류 0.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
실제 저장소 2091개를 MergeHub 로 읽어 봤다. CP949 67개 포함해 깨짐 0, 저장 왕복 어긋남 0.
판별 코드가 TextFile 과 GitService 두 군데에 복사돼 있던 것을 한 곳으로 모았다.
상태바가 KS_C_5601-1987, 목록이 CP949 로 같은 것을 다르게 부르던 것도 맞췄다.
기획안 4p 의 "Git 조작" 항목 중 화면에 없던 것들을 채웠다. 다섯 중 넷은
GitService 에 이미 구현돼 있었고 버튼만 없던 것이라, 서비스를 새로 만든 것은
변경분 추출 하나뿐이다.
- 커밋 수정(amend): 오타 난 메시지나 빠뜨린 파일을 새 커밋을 쌓지 않고 바로잡는다.
고쳐 쓸 메시지를 처음부터 다시 치지 않게 "마지막 메시지" 버튼을 곁들였다.
- stash 목록: 저장/적용만 있어 "맨 위 것"에만 손이 닿았다. 골라서 적용·삭제한다.
하나 꺼내면 번호가 한 칸씩 당겨지므로, 목록이 바뀌면 고른 항목을 다시 잡는다 -
안 그러면 다음 삭제가 엉뚱한 것을 지운다.
- 두 커밋 사이 비교: "여기부터" 로 시작점을 잡으면 그 뒤 고르는 커밋이 끝점이 된다.
안 잡으면 지금까지처럼 부모와 비교한다(기존 동작 유지).
- blame: 머지 중에 "이 줄 왜 이렇게 됐지"를 묻게 되는데, 이력을 뒤지는 것보다 빠르다.
- 변경분 파일 추출: 장비에 소스를 통째로 넣지 못하는 현장에서 바뀐 것만 들고 갈 때 쓴다.
텍스트로 다시 쓰면 줄바꿈과 인코딩이 바뀌므로 바이트 그대로 옮긴다.
곁들여 고친 것: 상태 배지 줄의 ItemHeight 가 24 로 묶여 있어 "mergetool 등록"
버튼이 반쯤 잘려 보였다. 줄 높이는 내용이 정하게 두었다.
실행 확인(데모 저장소): 메시지 수정으로 sha 가 바뀜 · stash 저장→목록→적용으로
워킹트리 복구 · 헤더가 "2766bc5 → 6e6bb78 (2개 파일)" · blame 31줄 전부 표시 ·
변경분 2개 파일 추출.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
UbisamBase 플랫폼 위에서 도는 플러그인. 지금까지 만든 것을 그대로 담는다.
- 폴더 비교 / 파일 비교(부분 수용·워드랩·찾기) / 3-Way 병합 / Git 조작
- 비교 엔진: histogram 정렬 · 이동 블록 감지 · 무시 규칙 · 13개 언어 토크나이저
- doc/ 에 작업 지시서와 진행 기록
빌드 산출물(bin/obj)은 추적하지 않는다 - 플랫폼 런타임이 빌드 때마다
D:\UbisamPlatform\bin 에서 복사되어 들어오므로 저장소에 담을 이유가 없다.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
