변경을 검토하기 전에 커밋과 브랜치 비교
단일 커밋, 직접 비교 및 브랜치 분기 이후 중 방식을 고르고 방향을 확인하여 고정된 커밋을 검토하세요.
검토를 시작하기 전에 질문을 정하세요. ‘이 커밋이 무엇을 바꿨나요?’와 ‘분기 이후 이 브랜치가 무엇을 바꿨나요?’는 같은 브랜치 이름이라도 다른 Diff를 만들 수 있습니다.
커밋된 변경을 읽을 Mac 앱을 찾는다면 먼저 Yenpo Git Diff 뷰어의 사용 과정과 제한을 확인하세요.
비교 열기
feature 브랜치를 main과 비교하려면 다음 예시 이름을 자신의 브랜치로 바꾸어 진행하세요.
- 로컬 Git 저장소를 열고 사이드바의 **버전 비교…**를 누르세요.
- 커밋에서 비교로 전환하세요.
- 기준에서 로컬 브랜치의
main을, 대상에서 로컬 브랜치의feature를 선택하세요. 각 열에 별도의 브랜치 소스와 검색란이 있습니다. feature의 작업을 보려면 브랜치 분기 이후, 두 끝을 비교하려면 직접 비교를 선택하세요. 차이는 다음 절에서 설명합니다.- 요약의 브랜치 이름과 짧은 커밋 ID를 확인하세요. 방향이 반대라면 기준과 대상에서 브랜치를 다시 선택한 뒤 변경 사항 보기를 누르세요.
- 변경된 파일 트리에서 파일을 선택해 인라인 Diff를 읽으세요.
origin/main을 쓰려면 기준 열에서 원격 브랜치를 선택하세요. 이는 서버의 실시간 상태가 아니라 로컬 저장소에 저장된 원격 추적 참조입니다. 최신 원격 커밋이 필요하면 평소 쓰는 Git 클라이언트로 갱신한 뒤 비교 선택기를 다시 여세요.
Yenpo는 비교를 특정 커밋에 고정합니다. 이후 브랜치가 이동해도 선택한 커밋을 유지합니다. 새 끝을 검토하려면 새 비교를 여세요.
방식 선택
| 질문 | 방식 | 비교 범위 |
|---|---|---|
| 커밋 하나가 무엇을 바꿨나요? | 커밋 | 첫 번째 부모 → 해당 커밋. 최초 커밋은 빈 트리와 비교 |
| 두 브랜치 끝이 현재 어떻게 다른가요? | 직접 비교 | 기준 끝 → 대상 끝 |
| 분기 이후 대상이 무엇을 바꿨나요? | 브랜치 분기 이후 | Merge base → 대상 끝 |
다음 기록을 보세요.
M1──M2 main
/
O───X
\
F1──F2 feature
main → feature 직접 비교는 M2와 F2를 비교하므로 양쪽의 작업을 포함합니다. 브랜치 분기 이후는 X와 F2를 비교하며 ‘feature가 무엇을 추가했는가’에 보통 적합합니다. 최종 병합을 시뮬레이션하거나 충돌 여부를 알려주지는 않습니다.
병합 커밋의 커밋 모드는 첫 번째 부모만 비교합니다. 각 부모에 대한 Diff가 아니라 병합을 보는 한 관점이므로 질문에 맞는지 확인하세요.
정확한 리비전 쌍 확인
변경된 파일 트리 위의 리비전 줄에 포인터를 올리면 전체 커밋 ID를 볼 수 있습니다. 직접 비교에서는 선택한 기준과 대상 커밋입니다. 브랜치 분기 이후에서는 기준이 merge-base(...)로 표시되며 기준 브랜치 끝이 아닌 공통 조상의 ID입니다.
Git에서 같은 버전을 확인하려면 저장소에서 다음 읽기 전용 명령을 실행하세요. BASE_COMMIT_OID와 HEAD_COMMIT_OID를 Yenpo에 표시된 전체 ID로 바꾸세요.
git show --no-patch --format='%h %s' BASE_COMMIT_OID HEAD_COMMIT_OID
git diff --stat BASE_COMMIT_OID HEAD_COMMIT_OID --
첫 명령은 두 커밋을 식별하고 두 번째는 커밋된 트리의 차이를 요약합니다. 커밋하지 않은 파일은 포함되지 않습니다. 이전 검토를 확인할 때는 기록한 ID를 사용하세요. 브랜치 이름이 새 커밋을 가리킬 수 있습니다.
주변 코드와 함께 Diff 읽기
변경된 파일 트리는 읽기 전용 인라인 Diff를 엽니다. 비교 파일과 현재 파일을 나란히 열 수 있으므로 호출자나 테스트를 판단하기 전에 각 탭의 버전을 확인하세요. 작업 트리에는 선택한 대상에 없는 변경이 이미 있을 수 있습니다.
동작에 영향을 주는 변경마다 수정된 줄 너머도 읽으세요.
- 새 코드에 도달하는 호출자를 찾으세요.
- 실행을 유발하는 입력이나 상태를 확인하세요.
- 반환값, 오류 또는 부수 효과를 호출자까지 따라가세요.
- 기존 테스트가 실제로 그 상태에 들어가는지 확인하세요.
‘동시 읽기 처리’라는 테스트가 단순히 두 호출을 순서대로 실행할 수도 있습니다. 이름보다 준비 과정과 단언문을 읽으세요. Promise 캐시 검토에서 실제 예제를 볼 수 있습니다.
AI Reader에 검토 요청
비교 헤더의 AI에 이 비교 검토 요청 버튼은 선택한 비교를 첨부한 초안을 만듭니다. 아직 요청을 보내지 않습니다. 비교 칩을 확인하고 검토할 내용을 초안에 적은 뒤 보내세요. 모델을 연결하지 않았다면 먼저 모델 제공업체 연결을 따르세요.
예를 들면 다음과 같습니다.
이 변경의 취소와 오류 처리 회귀를 검토해 주세요. 각 문제의 변경 위치, 발생 상태, 사용자에게 보이는 결과 및 근거 코드를 제시해 주세요. 기준 버전에 이미 있던 문제는 별도로 나열해 주세요.
제안된 조건이 선택한 커밋에서 실제로 발생할 수 있는지 확인하세요. 코드만으로 순서가 불명확하면 재현이나 관련 테스트를 요청하고 직접 실행하세요. 답변에 있는 테스트는 실행된 것이 아닙니다.
수정하고 싶을 때
Git 비교 대화는 항상 읽기 전용입니다. 수정하려면 현재 작업 트리에서 일반 대화를 시작하고 편집 허용을 켜세요. 비교는 참고용으로 열어 두세요.
그다음 작업 트리 Diff를 읽고 프로젝트 검사를 직접 실행하세요. 실행을 중지해도 이미 쓴 파일은 되돌려지지 않습니다. 원래 다른 변경이 있었다면 수정과 구분한 뒤 커밋할 내용을 결정하세요.