진행 중인 작업을 바꾸지 않고 기준 브랜치와 충돌할지 미리 보고 싶을 때 git merge-tree --write-tree HEAD origin/develop를 사용했습니다. 작업 트리와 인덱스를 그대로 두고 두 커밋을 병합한 결과를 확인할 수 있습니다. 한 브랜치에서는 기준 브랜치에 새 커밋이 23개 들어왔을 때 검사에 충돌이 없었습니다. 이후 다른 변경이 먼저 병합되자 다시 실행한 검사에서 문서 충돌이 나타났고, 기준 브랜치를 실제로 합쳐 그 파일을 정리했습니다. 미리 본 결과는 그때 비교한 두 커밋에 대한 것이었습니다.

새 DB 제약에 걸린 테스트 데이터

연습 시간 통계 작업에서는 기준 브랜치를 합칠 때 Git이 멈추지 않았지만, DB 검사에서 FAILED 상태의 연습 세션을 만들던 픽스처가 실패했습니다. 기준 브랜치의 마이그레이션이 실패 상태에 실패 사유가 있어야 한다는 제약을 추가했기 때문입니다. 스키마와 통계 테스트가 서로 다른 파일에 있어서 Git은 두 변경을 그대로 합칠 수 있었습니다.

통계가 실패한 세션을 제외하는지 확인하려면 FAILED 행은 필요했습니다. 그래서 픽스처에 NO_SOUND를 넣어 새 스키마를 만족하면서도 같은 통계 조건을 검사하도록 고쳤습니다. 새 임시 MySQL에서 다시 실행한 기록에는 기본 테스트 133개와 DB 테스트 30개가 통과한 것으로 남았습니다.

병합본에서 기존 이벤트 확인

녹음 업로드와 분석 작업을 연결할 때, 인계 설명에는 같은 이름을 인터페이스로 정의하는 방안이 남아 있었습니다. 병합된 코드를 대조하니 같은 이름의 데이터 클래스와 커밋 후에 실행되는 리스너가 있었습니다. 업로드 쪽은 콜백을 없애고, 상태를 갱신하는 트랜잭션 안에서 그 이벤트를 발행하도록 맞췄습니다.

같은 패키지의 두 파일에 이름이 같은 타입을 선언하면 줄 단위 병합에는 충돌이 없어도 Kotlin에서 중복 선언이 됩니다. 이번에는 병합된 선언과 실제 발행 지점을 확인해 두 정의가 함께 들어가는 상황을 피했습니다.

이때 미리 본 병합 결과는 충돌 파일을 찾는 데 쓰고, 통계 동작이 새 스키마에서도 유지되는지는 실제 마이그레이션을 적용한 DB로 확인했습니다. 같은 확인이 필요한지 판단하려면 충돌의 유무에 더해 합쳐진 변경의 범위를 읽어야 했습니다.

기준 브랜치가 77개 커밋 앞섰던 사례

별도의 연습 세션 생성 작업에서는 Push 직전 기준 브랜치에만 있는 커밋이 77개였습니다. 녹음 업로드 쪽에서 녹음 상태 갱신과 분석 시작 이벤트를 같은 트랜잭션으로 묶은 변경이 들어와, 세션 생성과 함께 쓰는 매퍼와 설정에서 충돌했습니다. 세션 생성과 업로드에 필요한 매퍼를 둘 다 남기고, 분석 제한 시간과 공통 오류 코드의 정의를 맞췄습니다.

양쪽이 같은 위치에 파일을 새로 만든 add/add 충돌도 있었습니다. 세션을 만드는 POST와 분석 상태를 읽는 GET이 같은 컨트롤러에 남도록 합쳤습니다. 생성자에는 두 요청의 유스케이스를 함께 연결하고, 이름이 겹친 생성 응답 타입과 테스트를 정리했습니다. 이때 검증할 것은 충돌 표시가 없어졌는지와 두 요청이 계속 동작하는지였습니다. 새로 만든 빈 MySQL에서 clean build databaseTest를 실행했고, 당시 기록에는 일반 테스트 251개와 DB 통합 테스트 55개가 통과했습니다.

마지막 두 커밋에서 검증 범위를 다시 정하기

Push 직전 원격 기준을 한 번 더 읽으니 커밋 두 개가 추가됐습니다. 로컬과 원격의 커밋 수뿐 아니라 바뀐 파일을 비교하니 분석 명세 Markdown 하나만 바뀌어 있었습니다. 이때는 문서를 통합하고 변경 내용을 검토했습니다. 앞서 77개 커밋을 합쳤을 때의 테스트 결과와 이번 문서 검토 결과는 별도로 남겼습니다.

공유하기 전에 확인할 두 곳

코드와 문서가 맞아도, 공유하려는 커밋의 메시지와 문서 링크가 실제 작업을 가리키는지 따로 봤습니다.

마지막 커밋의 작업 키

분석 실패 처리 작업의 마지막 커밋에 다른 작업 키가 섞인 것을 Push 전에 발견했습니다. git commit --amend --only로 메시지를 다시 작성하면 스테이징한 별도 변경을 포함하지 않고 마지막 커밋을 바꿀 수 있습니다. git log -1로 새 커밋의 메시지를 다시 읽어 이번 작업의 키만 남았는지 확인했습니다. Git commit 문서

공유 문서의 실제 버전

쉼표를 빼고 실제 음표만 0부터 세는 제안이 아직 로컬에만 있는 것을 확인했습니다. 같은 이름의 문서가 원격에 있어도 해당 문단은 들어 있지 않았습니다. 제안을 병합한 뒤 원격 버전의 해당 문서와 절을 연결했습니다. 검토가 필요한 제안은 MR로, 병합된 규칙은 그 문단이 들어 있는 문서로 연결합니다. git show의 리비전:파일경로 표기로 공유할 버전의 본문을 직접 읽을 수 있습니다. Git 리비전 문서