Git 미드레벨 테스트·코드품질 기술면접
새 면접Q. Pull Request를 리뷰할 때 커밋 히스토리의 품질도 중요한 검토 요소입니다. 좋은 커밋 히스토리의 특징을 설명하고, git log를 활용해 코드 리뷰 시 커밋 품질을 평가하는 기준과 방법을 제시해주세요. 특히 atomic commit의 개념과 이것이 코드 리뷰 및 향후 유지보수에 미치는 영향을 설명해주세요.
각 커밋이 독립적이고 완결된 변경 단위를 가져야 하는 이유와, 이를 검증하는 git 명령어를 생각해보세요.
좋은 커밋 히스토리는 atomic commit 원칙을 따르며, 각 커밋은 하나의 논리적 변경 사항만 포함해야 합니다. git log --oneline --graph로 커밋 구조를 확인하고, git show [commit-hash]로 각 커밋의 변경 범위를 검토합니다. git log -p를 통해 커밋별 diff를 확인하여 관련 없는 변경이 섞여있는지 점검할 수 있습니다. Atomic commit은 각 커밋이 독립적으로 빌드 및 테스트 가능해야 하며, git revert로 안전하게 되돌릴 수 있어야 합니다. 이는 git bisect를 통한 버그 추적을 용이하게 하고, 특정 기능만 선택적으로 cherry-pick하거나 revert할 수 있게 합니다. 코드 리뷰 시 커밋 메시지가 'why'를 설명하는지, 변경 범위가 적절한지, 테스트 코드가 함께 포함되었는지 확인해야 합니다.
- • Atomic commit 원칙: 각 커밋은 하나의 논리적 변경 단위
- • git log, git show를 활용한 커밋 품질 검증
- • 독립적 빌드/테스트 가능성과 안전한 revert 가능성
- • git bisect, cherry-pick 등 향후 유지보수 작업의 용이성
레거시 버그를 추적할 때 커밋 히스토리가 잘 정리되어 있으면 git blame과 git log로 변경 의도를 빠르게 파악할 수 있습니다.
팀에서 WIP(Work In Progress) 커밋을 많이 만들고 나중에 squash하는 개발자와, 처음부터 atomic commit을 만들려고 노력하는 개발자가 있습니다. 각 접근 방식의 장단점과 팀 차원에서 권장할 만한 방식은 무엇인가요?
Q. TDD(Test-Driven Development)를 실천하는 팀에서 Git 커밋 전략을 수립하려고 합니다. Red-Green-Refactor 사이클에서 각 단계별로 커밋을 어떻게 구성해야 하는지 설명하고, 실패하는 테스트 코드를 커밋하는 것의 장단점을 논의해주세요. 또한 git stash를 활용해 TDD 워크플로우를 관리하는 방법도 제시해주세요.
TDD의 각 단계(테스트 작성, 구현, 리팩토링)가 커밋 히스토리에 어떻게 반영되어야 개발 과정을 추적하기 좋을지 생각해보세요.
TDD에서 커밋 전략은 크게 두 가지 접근이 있습니다. 첫째는 각 단계별로 커밋하는 방식으로, Red 단계에서 실패하는 테스트를 커밋하고, Green 단계에서 최소 구현을 커밋한 후, Refactor 단계에서 개선된 코드를 커밋합니다. 이는 개발 과정을 상세히 기록하지만 히스토리가 길어지는 단점이 있습니다. 둘째는 Refactor 완료 후 하나의 atomic commit으로 squash하는 방식으로, 깔끔한 히스토리를 유지하지만 중간 과정이 사라집니다. 실무에서는 git stash를 활용해 Red 단계의 테스트를 임시 저장하고, 긴급한 다른 작업을 처리한 후 git stash pop으로 복귀할 수 있습니다. 실패하는 테스트를 커밋하면 CI/CD가 실패하므로, --no-verify 옵션이나 [WIP] 태그를 사용하거나, feature 브랜치에서만 허용하는 정책이 필요합니다. 최종적으로는 git rebase -i로 의미 있는 커밋 단위로 정리하는 것을 권장합니다.
- • Red-Green-Refactor 각 단계별 커밋 vs 완료 후 squash 전략
- • 실패하는 테스트 커밋 시 CI/CD 파이프라인 고려사항
- • git stash를 활용한 작업 컨텍스트 전환 관리
- • git rebase -i로 최종 히스토리 정리
TDD로 개발할 때 중간에 긴급 버그 수정 요청이 들어오면 git stash로 현재 작업을 저장하고 hotfix 브랜치로 전환한 후 다시 복귀할 수 있습니다.
Pair Programming과 TDD를 함께 실천하는 팀에서, 두 개발자의 기여를 Git 커밋에 어떻게 반영하시겠습니까? Co-authored-by 태그의 활용과 커밋 전략을 설명해주세요.
Q. 대규모 리팩토링 작업을 진행할 때, 기능 변경 없이 코드 구조만 개선하는 커밋들을 어떻게 관리하고 리뷰받아야 할까요? git blame의 유용성을 해치지 않으면서 대규모 파일 이동, 이름 변경, 코드 재구성을 추적 가능하게 유지하는 전략을 제시해주세요. 특히 git mv, git log --follow, git blame -C, -M 옵션의 활용법과 리팩토링 커밋을 분리하는 best practice를 설명해주세요.
리팩토링과 기능 변경을 별도 커밋으로 분리하고, Git의 이동/복사 감지 기능을 활용하는 방법을 고려해보세요.
대규모 리팩토링은 반드시 기능 변경과 분리된 별도 커밋으로 관리해야 합니다. 파일 이동 시 git mv를 사용하면 Git이 자동으로 rename을 감지하며, git log --follow [file]로 이름이 바뀐 파일의 전체 히스토리를 추적할 수 있습니다. git blame -M 옵션은 같은 파일 내에서 이동한 코드를 감지하고, -C 옵션은 다른 파일에서 복사된 코드까지 추적합니다. 리팩토링 전략은 1) 파일 이동만 하는 커밋, 2) 이름 변경만 하는 커밋, 3) 내부 구조 개선 커밋으로 단계를 나누는 것이 좋습니다. 각 커밋은 테스트가 통과해야 하며, 커밋 메시지에 'refactor:'를 명시해 기능 변경이 없음을 표시합니다. .git-blame-ignore-revs 파일에 포맷팅이나 대규모 리팩토링 커밋을 등록하면 git blame 시 해당 커밋을 건너뛸 수 있습니다. PR 리뷰 시 리팩토링 커밋과 기능 변경 커밋을 분리해서 리뷰하면 검토가 용이합니다.
- • 리팩토링과 기능 변경을 별도 커밋으로 엄격히 분리
- • git mv, git log --follow로 파일 이동 추적
- • git blame -M, -C 옵션으로 코드 이동/복사 감지
- • .git-blame-ignore-revs로 대규모 변경 커밋 필터링
코드 소유권을 파악하거나 버그의 원인을 찾을 때 git blame을 사용하는데, 리팩토링 커밋이 적절히 관리되지 않으면 실제 로직 변경을 찾기 어려워집니다.
레거시 코드베이스에서 수천 개의 파일에 걸친 패키지 구조 재편성을 진행해야 합니다. 한 번에 모든 변경을 하는 것과 점진적으로 마이그레이션하는 것 중 어떤 접근을 선택하시겠으며, Git 전략은 어떻게 수립하시겠습니까?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!