접기가 풀려는 문제를 차이 이동·미니맵·다음 파일이 이미 대부분 풀고 있다. 반면 목록을 둘로 나누는 일은 122군데를 건드리고 틀리면 저장이 깨진다. WinMerge 확인 결과와 다시 꺼낼 조건을 지시서에 적었다.
253 lines
19 KiB
Markdown
253 lines
19 KiB
Markdown
# 작업 지시 — MergeHub 4차 (로컬 머지툴 사용성)
|
|
|
|
대상: `D:\Sorce\MergeTool\MergeHub` (플러그인) · `D:\Sorce\MergeTool\UbisamPlatform` (셸)
|
|
전제: 1~3차 지시서는 모두 끝났다([../진행상황.md](../진행상황.md)). 이 지시서는 **기능을 늘리는 것이 아니라
|
|
매일 쓰는 사람의 걸림돌을 없애는 것**이 목적이다. 이 도구는 사내 로컬 환경에서 쓰는
|
|
머지툴이 우선이므로, 서버·협업 기능보다 "혼자 앉아서 파일 두 개 견주는 일"이 빨라지는 쪽을 먼저 본다.
|
|
|
|
---
|
|
|
|
## 공통 규칙
|
|
|
|
- **D → A → B → C 순서로 진행한다.**
|
|
- D(변경 이력 폴더)가 먼저다. 기록하는 자리를 바꾸는 일이라, 나중에 하면 A~C 의 기록을 옛 자리에 쌓았다가 다시 옮기게 된다.
|
|
- 그 다음이 A 다. 작업한 것이 사라지는 문제이기 때문이다.
|
|
- C(화면 구성)는 서로 얽히지 않아 순서를 바꿔도 되지만, 기능이 자리를 잡은 뒤에 손대는 편이 손이 덜 간다.
|
|
- **항목 하나를 끝낼 때마다** 빌드하고 실제로 실행해 화면을 확인한 뒤 보고한다. 전부 끝내고 한 번에 보고하지 않는다.
|
|
- **항목 하나가 끝나면 기록을 세 군데에 남기고 로컬 커밋한다** (D-1 로 자리가 바뀌었다).
|
|
1. **상세**는 `doc/history/YYYY-MM-DD-주제.md` 에 적는다 — 무엇이 원인이었는지, 어떤 판단을 했는지, 확인한 결과.
|
|
2. [../진행상황.md](../진행상황.md) 은 **대기 → 완료로 상태만** 고친다. 여기에 상세를 적지 않는다.
|
|
3. [../history/changelog.md](../history/changelog.md) 에 한 줄을 더한다 — 날짜 · 무엇을 왜 · 커밋 해시.
|
|
- 커밋 메시지는 한국어 한 줄.
|
|
- **왜 나누나** — 진행상황이 721줄까지 불어나 "그때 무슨 판단을 했더라" 를 스크롤로 뒤져야 했다.
|
|
상세가 갈 자리가 따로 있으면 진행상황은 한 화면에 머문다.
|
|
- **푸쉬하지 않는다.** 원격 저장소가 생기기 전까지 `.git` 에만 쌓아 둔다.
|
|
- 기존 검사 하네스 16벌(514건)은 계속 통과해야 한다. 로직을 건드리면 **테스트를 먼저 늘린다.**
|
|
- 빌드 경고 0 · 오류 0 을 유지한다. 앱이 실행 중이면 파일 잠금으로 빌드가 실패하므로 `UbisamBase.Shell` 을 먼저 종료한다.
|
|
- 플랫폼을 고치면 **다른 소비 프로그램에 미치는 영향**을 함께 적고 `UbisamPlatform/doc/history/changelog.md` 에 남긴다.
|
|
MergeHub 쪽 changelog 와 헷갈리지 않게 한다 — 둘은 기준이 다르다(D-1 참고).
|
|
- 아래 넷은 지금 코드에 **아예 없다**(2026-09-09 확인). 있는 것을 고치는 게 아니라 새로 만드는 일이다 -
|
|
최근 목록 · 같은 줄 접기 · 다음 파일 이동 · 외부 편집기 호출.
|
|
|
|
---
|
|
|
|
## A. 먼저 — 작업한 것이 사라지는 문제
|
|
|
|
### A-1. 저장하지 않은 편집이 말없이 사라진다
|
|
|
|
- 증상: 파일 비교에서 LOCAL 을 고친 뒤 **저장하지 않은 채** 다른 파일을 열면 고치던 내용이 그대로 없어진다.
|
|
묻지도 않고 알리지도 않는다. 머지툴에서 이건 기능 부족이 아니라 결함에 가깝다.
|
|
- **먼저 어느 길로 들어와야 사라지는지 전부 찾아 목록으로 보고한 뒤** 고친다. 최소한 이 길들을 본다.
|
|
`HomeViewModel.OnPlainCompareRequested` · `PickLeftFile` / `PickRightFile` · 폴더 비교에서 더블클릭
|
|
(`FolderViewModel.OpenInDiffCore`) · 끌어다 놓기(`DropFile` · `RouteDroppedPaths`) · 폴더 검색 결과 열기
|
|
(`OpenHitCore`) · Git 탭에서 다른 파일 고르기 · 데모 전환 · 3-Way 켜고 끄기.
|
|
- **비교 규칙을 바꾸는 길은 건드리지 않는다.** `ReloadLinesFrom` 은 편집을 지키도록 이미 만들어져 있다.
|
|
지금 안전한 길까지 확인 창을 붙이면 규칙 하나 바꿀 때마다 창이 떠서 못 쓴다. **어느 쪽인지 먼저 확인하고 손댄다.**
|
|
- 묻는 창은 세 갈래다 — `저장` · `저장하지 않고 계속` · `취소`. 확인 창은 플랫폼 것(`MessageUtil`)을 쓴다.
|
|
- 고친 것이 없으면(`HasChanges == false`) 묻지 않는다. 저장 없이 넘어가도 되는 경우까지 묻는 것이 더 나쁘다.
|
|
- **판정 기준**: LOCAL 을 한 줄 고친 뒤 위에 적은 모든 길로 다른 파일을 열면 창이 뜬다.
|
|
`취소` 를 누르면 고치던 내용과 화면이 그대로 남는다. 고친 것이 없으면 창이 뜨지 않는다.
|
|
|
|
### A-2. 내보낸 보고서에 만든 사람이 없다
|
|
|
|
- 증상: `결과 내보내기` 로 뽑은 파일 머리글에 `만든 때` 는 있는데 **누가 뽑았는지가 없다**(`CompareReport.Head`).
|
|
남에게 보내라고 만든 기능이라 작성자가 없으면 결재나 메일에 붙였을 때 되묻게 된다.
|
|
- 이름은 **머지 주석과 같은 자리**에서 가져온다. 설정 `MergeCommentAuthor` → 비었으면 git config `user.name` →
|
|
그것도 없으면 윈도우 계정. 지금 `MergeNote.Build` 가 하는 판단과 **같은 함수를 쓴다** -
|
|
같은 사람이 같은 화면에서 뽑았는데 주석과 보고서에 다른 이름이 찍히면 그 자체가 버그다.
|
|
- 파일 비교 · 폴더 비교 두 보고서 모두 해당된다.
|
|
- **판정 기준**: 뽑은 파일 머리글에 만든 사람이 나오고, 그 이름이 반영한 줄 주석에 찍히는 이름과 같다.
|
|
|
|
---
|
|
|
|
## B. 매일 쓰는 마찰 줄이기
|
|
|
|
### B-1. 최근 비교 목록
|
|
|
|
- 왜 필요한가 - **같은 짝을 반복해서 연다.** 경로를 매번 다시 고르는 것이 지금 제일 잦은 마찰이다.
|
|
- 파일 짝(왼쪽·오른쪽)과 폴더 짝을 **따로** 기억한다. 최근 것이 위. 상한은 10~20개.
|
|
- 파일 비교 · 폴더 비교 화면 위쪽에서 목록을 펼쳐 고르면 그 짝으로 바로 연다.
|
|
- 저장 자리는 플랫폼 설정 폴더(`D:\UbisamConfig`) 쪽이다. **설정 화면을 어지럽히지 않는다** -
|
|
사람이 손으로 고칠 값이 아니다. `MergeHubSettings` 에 넣을지 파일을 따로 둘지는 구현자가 정하되 그 까닭을 적는다.
|
|
- **없는 경로를 목록에서 자동으로 지우지 않는다.** 네트워크 드라이브나 USB 는 잠깐 안 보일 뿐인데
|
|
지워 버리면 다시 찾아 들어가야 한다. 흐리게 보여 주고, 열려고 할 때 없다고 알린다.
|
|
- **판정 기준**: 프로그램을 껐다 켜도 최근 짝이 남아 있고, 목록에서 하나를 고르면 두 칸이 채워지며 비교가 열린다.
|
|
|
|
### B-2. 같은 줄 접기 — **취소** (2026-09-10)
|
|
|
|
사용자 판단으로 뺀다. 번호는 그대로 둔다.
|
|
|
|
**왜 뺐나** - 접기가 풀려는 문제("차이 사이를 지나가야 한다")는 **이미 있는 기능이 대부분 풀고 있다.**
|
|
차이 이동(`Alt+↑↓` · 처음/마지막) · 미니맵 · 상태바의 `차이 3 / 15` · B-3 다음 파일.
|
|
접기가 여기에 더 얹는 것은 **차이 여러 개를 한 화면에 동시에 놓고 보는 것** 하나뿐이고, 매일 하는 일이 아니다.
|
|
|
|
반대편 값은 크다. 화면에 뿌리는 목록과 저장에 쓰는 목록이 같은 것이라, 접으려면 둘로 나눠야 한다.
|
|
그 이름이 `HomeViewModel` 한 파일에서 **122군데** 쓰이고, **틀리면 저장할 때 줄이 조용히 사라지는 쪽으로 틀린다.**
|
|
4차에서 한 것 중 가장 위험한 작업인데 얻는 것이 이미 있는 기능과 겹친다.
|
|
|
|
**참고 - WinMerge 는 이 기능이 있다**(2026-09-10 설치본 2.16.52 에서 직접 확인).
|
|
`보기 → 문맥 차이` 에 모든 줄 / 0 / 1 / 3 / 5 / 7 / 9 줄, `Ctrl+D` 로 전체와 축약 전환, 반전도 있다.
|
|
다만 **구간마다 접고 펴는 것이 아니라 파일 전체에 거는 거르기**다. 숨긴 자리에 표시가 없고 그냥 사라진다.
|
|
지시서에 적었던 "같은 줄 128개, 누르면 펼침" 과는 다른 물건이다.
|
|
|
|
**다시 꺼낼 조건** - 실제로 쓰다가 **차이 이동만으로 부족하다고 느끼는 순간**이 오면 그때 값이 분명해진다.
|
|
그때는 WinMerge 방식(전체에 거는 문맥 줄 수)이 일이 절반이므로 그쪽부터 본다.
|
|
곁들여 묶어 두었던 **3-Way 원본 세 칸 접기**도 함께 미룬다.
|
|
|
|
---
|
|
### B-3. 폴더 비교에서 다음 다른 파일로 바로 넘어가기
|
|
|
|
- 왜 필요한가 - 지금은 파일 하나를 보고 **폴더 탭으로 돌아갔다가** 다음 파일을 다시 열어야 한다.
|
|
다른 파일이 스무 개면 이 왕복을 스무 번 한다.
|
|
- 파일 비교 화면에 `이전 파일` · `다음 파일` 을 둔다. 단축키도 함께 준다(`Ctrl+PageUp` · `Ctrl+PageDown` 을 먼저 검토).
|
|
- 폴더 비교에서 열었을 때만 켜진다. 그냥 파일 두 개를 연 경우에는 넘어갈 목록이 없으므로 꺼져 있어야 한다.
|
|
- **지금 화면에 보이는 목록 순서**를 그대로 따른다. 필터로 "코드가 다른 것만" 을 걸어 뒀으면 그 안에서만 움직인다.
|
|
- 몇 번째인지 보여 준다(예: `3 / 27`).
|
|
- 저장하지 않은 편집이 있으면 **A-1 규칙을 그대로 탄다.**
|
|
- **판정 기준**: 폴더 비교에서 파일 하나를 열고, 폴더 탭으로 돌아가지 않고 다른 파일 전부를 차례로 훑을 수 있다.
|
|
|
|
### B-4. 외부 편집기로 열기 — **취소** (2026-09-10)
|
|
|
|
사용자 판단으로 뺀다. 번호는 그대로 둔다 — 뒤 번호를 밀면 앞서 오간 이야기와 어긋난다(3차 D-4 와 같은 처리).
|
|
|
|
**왜 뺐나** - 무엇이 열릴지 정하는 값이 두 개(편집기 경로 · 인자 틀) 필요한데,
|
|
그 값을 채워 넣는 수고가 얻는 것보다 크다고 봤다. 지금도 경로를 복사해 직접 열 수 있고,
|
|
비주얼스튜디오는 줄 번호로 바로 가는 간단한 인자가 없어 반쪽짜리가 된다.
|
|
---
|
|
|
|
## C. 화면 구성 정리
|
|
|
|
기능을 더하는 것이 아니라 **자리를 되찾는** 일이다. 코드를 나란히 읽는 도구에서
|
|
가로·세로 한 줄은 그대로 읽을 수 있는 코드 양이다.
|
|
|
|
C 묶음은 서로 얽히지 않으므로 **어느 것부터 해도 된다.** 값이 큰 순서로 적었다.
|
|
|
|
### C-1. 같은 경로가 세 군데 나온다 (파일 비교)
|
|
|
|
- 지금: ① 위 툴바에 `기준 파일...` · `내 파일...` 옆의 **잘린** 경로 ② 패널 머리글의 `BASE · 파일이름.cs`
|
|
③ 그 아래 `경로` 상자의 전체 경로. 셋이 같은 것을 말한다.
|
|
- ③ 경로 상자가 패널마다 세로 40px 남짓을 먹는다. 3-Way 는 칸이 넷이라 그만큼 곱해진다.
|
|
- 머리글 한 줄로 합치고 **전체 경로는 툴팁**으로 옮긴다. 위 툴바의 잘린 경로는 읽을 수 없으므로 뺀다.
|
|
- **경로를 드래그해서 복사할 수 있는 것은 지킨다.** 지금 읽기전용 `TextBox` 를 쓰는 까닭이 그것이다
|
|
(`HomeView.xaml` 의 경로 줄 주석 참고). 복사 방법이 사라지면 안 된다 - 대안(우클릭 복사 등)을 함께 낸다.
|
|
- **행 잠금을 깨지 않는다.** 지금 경로 줄은 BASE·LOCAL 의 높이를 맞추려고 자리를 맞춰 둔 것이다.
|
|
줄을 없애거나 합칠 때 두(네) 칸의 01행이 여전히 같은 높이여야 한다.
|
|
- **판정 기준**: 2-Way·3-Way 모두에서 코드가 두 줄 이상 더 보이고, 각 칸의 01행이 같은 높이에 있다.
|
|
경로 전체는 어딘가에서 여전히 읽고 복사할 수 있다.
|
|
|
|
### C-2. 아래쪽 정보가 세 군데로 흩어져 있다
|
|
|
|
- 지금: 왼쪽 아래 `Diff 요약 총 43 라인 · 차이 10 라인` / 가운데 `1행 1열 | 차이 - / 5 | UTF-8 · LF · C#` /
|
|
그 아래 `편집 0건 · 되돌리기 0건 · 남은 차이 10 라인 | 코드 검사 이상 없음`.
|
|
- 비슷한 숫자가 세 군데 있다 - `차이 10 라인` · `차이 - / 5` · `남은 차이 10 라인`. 어느 것을 봐야 할지 헷갈린다.
|
|
- 한 줄로 합친다. 자리 규칙을 정해 둔다 - **왼쪽은 지금 위치**(행·열), **가운데는 진행**(차이 3/5 · 남은 10줄 · 편집 2건),
|
|
**오른쪽은 파일 정보**(UTF-8 · LF · C# · 코드 검사).
|
|
- 줄이 하나 줄어드는 만큼 코드가 그만큼 더 보인다.
|
|
- **판정 기준**: 아래쪽이 한 줄이 되고, 같은 뜻의 숫자가 두 번 나오지 않는다.
|
|
|
|
### C-3. Git 탭에서 지금 못 쓰는 것이 위쪽 4분의 1을 차지한다
|
|
|
|
- 지금: `저장소 연결` 블록에 원격 URL · 이름 · 클론 · 원격 추가 · 원격 삭제 · Gitea 계정 · 토큰 ·
|
|
Fetch · Pull · Push 가 있다. **원격 저장소가 없어 전부 비활성**이다(`GitView.xaml`).
|
|
- 이 프로젝트는 로컬 머지툴이 우선이고 푸시도 하지 않는다. 그런데 화면에서는 원격이 제일 넓다.
|
|
- **지우지 않는다. 접는다.** 사내 Gitea 가 생기면 다시 필요하다. 펼침 상태를 기억한다.
|
|
- 접었을 때 남는 것은 `로컬 경로` · `폴더...` · `열기` 한 줄이다.
|
|
- **판정 기준**: 접으면 세로 100px 이상이 브랜치 목록·이력으로 가고, 펼치면 지금과 똑같다.
|
|
껐다 켜도 접힌 상태가 그대로다.
|
|
|
|
### C-4. 색 구분 범례를 읽는 것에서 쓰는 것으로
|
|
|
|
- 지금: `색 구분 | BASE와 다름 5 | 머지 반영함 0 | 직접 수정 0 | 추가 5 | 삭제 0 | 무시 0 | 자리 옮김 0 | 줄 안에서 바뀐 부분`
|
|
이 늘 한 줄을 차지한다. 0건인 것도 그대로 자리를 잡는다.
|
|
- 두 가지를 한다.
|
|
- 0건인 갈래는 흐리게 한다. 있는 것과 없는 것이 한눈에 갈린다.
|
|
- **개수를 누르면 그 갈래로 이동한다.** `추가 5` 를 누르면 추가된 줄만 차례로 훑는다.
|
|
이러면 범례가 설명이 아니라 도구가 되고, 색 이름을 외울 필요가 없어진다.
|
|
- 이동은 이미 있는 차이 이동(`Alt+↑↓`)과 **같은 방식으로 움직인다.** 새 이동 규칙을 만들지 않는다.
|
|
- **판정 기준**: 0건 갈래가 눈에 띄게 흐리다. `추가 N` 을 누르면 첫 추가 줄로 가고, 다시 누르면 다음 추가 줄로 간다.
|
|
|
|
### C-5. ACTIONS 칸이 매번 쓰는 것과 한 번 정하는 것을 섞어 놨다
|
|
|
|
- 매번 쓰는 것: `Accept` · `이 덩어리 반영` · `Undo`/`Redo` · 차이 이동 · `저장`.
|
|
- 한 번 정하면 그대로인 것: `저장 형식` 두 칸 · `비교 규칙` 네 개(공백 비교 · Aa 구분 · 필터 끔 · 줄바꿈 끔) · `편집 잠금`.
|
|
- 뒤쪽을 접는다(예: `▸ 비교 규칙`). 접힌 상태를 기억한다. 오른쪽 칸 폭을 그만큼 코드에 돌려준다.
|
|
- **차이 이동 버튼의 자리를 다시 본다.** 가장 자주 누르는데 손이 가장 먼 오른쪽 끝에 있고,
|
|
정작 `차이 3 / 5` 표시는 아래쪽 상태바에 있다. **개수와 이동 단추를 같은 자리에 둔다** -
|
|
C-2 와 함께 하면 자연스럽다.
|
|
- 규칙을 바꾸면 화면을 다시 그리므로 **반영·편집 표시가 유지되는지 확인한다**(3차 E-5 에서 한 번 깨졌던 자리다).
|
|
- **판정 기준**: 접으면 코드 폭이 눈에 띄게 넓어지고, 펼치면 지금과 같다. 차이 이동을 누르는 손이 짧아진다.
|
|
규칙을 바꿔도 반영한 줄 색이 그대로다.
|
|
|
|
---
|
|
|
|
## D. 변경 이력을 전용 폴더로
|
|
|
|
**이 항목만 순서를 앞당겨도 된다.** 먼저 해 두면 A~C 의 기록이 처음부터 새 자리에 쌓인다.
|
|
나중에 하면 옛 자리에 쌓아 뒀다가 다시 옮기게 된다.
|
|
|
|
### D-1. `doc/history/` 를 만들고 진행상황을 나눈다
|
|
|
|
- 지금 [../진행상황.md](../진행상황.md) 는 **690줄**이고 계속 늘어난다. 한 파일에 다섯 가지가 섞여 있다 -
|
|
주차 목표 · 차수별 상태 표 · 항목별 상세 설명 · 미룬 것 · 완료 기록.
|
|
"3차 D-3 에서 무슨 판단을 했더라" 를 찾으려면 스크롤로 뒤져야 한다. 5차·6차가 쌓이면 더 나빠진다.
|
|
- 플랫폼은 이미 나눠 두었다(`UbisamPlatform/doc/history/` 에 `changelog.md` + 날짜별 파일).
|
|
**MergeHub 만 한 파일에 쌓고 있다.** 같은 방식으로 맞춘다.
|
|
- 이렇게 나눈다.
|
|
|
|
```
|
|
doc/
|
|
진행상황.md 지금 무엇이 대기·진행·완료인지 (표와 링크만)
|
|
작업지시/
|
|
3차.md · 4차.md · 머지툴보강.md · 사용성보강.md
|
|
history/
|
|
changelog.md 한 줄 요약 표 (날짜 · 무엇을 왜 · 커밋)
|
|
2026-09-08-2주차.md
|
|
2026-09-09-3차.md
|
|
```
|
|
|
|
- `진행상황.md` 에는 **지금 상태만** 남긴다. 끝난 차수의 상세 설명은 날짜별 파일로 옮기고 링크만 건다.
|
|
- `changelog.md` 는 한 줄 요약 표다. **플랫폼 것과 성격이 다르다** - 플랫폼 changelog 의 핵심은
|
|
"다른 소비 프로그램에 미치는 영향"인데, MergeHub 는 소비 프로그램이라 그럴 대상이 없다.
|
|
여기서는 **무엇을 왜 바꿨는지**가 중심이다. 형식만 빌리고 내용 기준은 따로 잡는다.
|
|
- 파일 이름은 플랫폼과 같게 `YYYY-MM-DD-주제.md`.
|
|
- **링크를 깨뜨리지 않는다.** 지시서를 `doc/작업지시/` 로 옮기면 `진행상황.md` 와 다른 지시서 안의
|
|
경로가 전부 바뀐다. 옮긴 뒤 문서 안의 링크를 모두 고치고, 고친 것을 보고에 적는다.
|
|
옮기는 값이 링크 고치는 값보다 작다고 판단되면 **지시서는 그대로 두고 history 만 만들어도 된다** -
|
|
그때는 그렇게 판단한 까닭을 적는다.
|
|
- 옮길 때 **내용을 고쳐 쓰지 않는다.** 자리만 옮긴다. 다시 쓰면 그때 무슨 판단을 했는지가 흐려진다.
|
|
줄바꿈 형식이 바뀌어 파일 전체가 바뀐 것처럼 보이지 않게 주의한다(4차 C 묶음 커밋에서 실제로 그랬다).
|
|
- 코드를 건드리지 않으므로 빌드·검사에 영향이 없다. 그래도 **커밋 뒤 앱을 한 번 띄워 본다** -
|
|
문서만 고쳤다고 생각했는데 아닌 경우가 있다.
|
|
- **판정 기준**: `진행상황.md` 가 200줄 아래로 줄고 지금 대기·진행 중인 것이 한 화면에 들어온다.
|
|
끝난 차수의 상세는 `changelog.md` 한 줄에서 링크 한 번으로 간다. 문서 안의 링크가 하나도 깨지지 않는다.
|
|
|
|
### D-2. 앞으로의 기록 규칙을 정한다
|
|
|
|
- D-1 을 하고 나면 **공통 규칙의 "진행상황.md 를 갱신한다" 가 뜻이 달라진다.** 새 규칙을 지시서 맨 앞에 적는다.
|
|
- 항목을 끝내면 **상세는 그 날짜 파일**(`doc/history/YYYY-MM-DD-주제.md`)에 적는다.
|
|
- `진행상황.md` 는 **대기 → 완료로 상태만** 고친다.
|
|
- `changelog.md` 에 한 줄을 더한다 - 날짜 · 무엇을 왜 · 커밋 해시.
|
|
- 지금까지 상세를 진행상황에 몰아 적은 것은 파일이 하나뿐이어서였다. 자리가 생기면 나눌 이유가 생긴다.
|
|
- **판정 기준**: 4차 A~C 를 진행하는 동안 이 규칙대로 기록이 쌓이고, 진행상황이 다시 길어지지 않는다.
|
|
|
|
---
|
|
|
|
## 이번 지시서에서 하지 않는 것
|
|
|
|
번호를 붙여 두는 이유는 나중에 "왜 안 했나" 를 다시 묻지 않기 위해서다.
|
|
|
|
- 로그인·권한 — 로컬 도구가 우선이라 뒤로 미룬다.
|
|
- 대용량 파일 성능(수만 줄) — 실제 사내 소스 크기를 확인한 뒤 판단한다.
|
|
- 비교 창 여러 개(3차 D-4) — 사용자 판단으로 뺀 항목이다. 되살리지 않는다.
|
|
|
|
---
|
|
|
|
## 보고 형식
|
|
|
|
항목마다 이렇게 적는다.
|
|
|
|
- 무엇이 원인이었는지 한두 줄 (새로 만드는 항목이면 어떤 판단을 했는지)
|
|
- 어떤 파일을 어떻게 고쳤는지
|
|
- 실제로 실행해 확인한 결과
|
|
- 커밋 해시
|