Git 주니어 테스트·코드품질 기술면접
새 면접Q. 팀에서 코드 리뷰를 위해 Pull Request를 올렸는데, 리뷰어가 '커밋이 너무 많고 변경사항이 뒤섞여 있어서 리뷰하기 어렵다'는 피드백을 주었습니다. 이미 push한 여러 커밋들을 논리적인 단위로 재구성하여 리뷰하기 쉽게 만들려면 어떤 Git 명령어와 전략을 사용해야 하나요?
이미 push한 커밋의 히스토리를 수정하는 대화형 명령어를 생각해보세요.
git rebase -i (interactive rebase)를 사용하여 커밋을 재구성할 수 있습니다. git rebase -i HEAD~n 명령으로 최근 n개의 커밋을 편집 모드로 열고, squash로 관련된 커밋들을 합치거나, reword로 커밋 메시지를 수정하거나, reorder로 순서를 변경할 수 있습니다. 작업이 완료되면 git push --force-with-lease로 원격 브랜치에 반영해야 합니다. 단, 이미 다른 사람이 해당 브랜치를 사용 중이라면 히스토리 변경을 피해야 하며, 팀 내 rebase 정책을 확인해야 합니다. 각 커밋은 하나의 논리적 변경사항만 포함하도록 구성하여 리뷰어가 변경 의도를 쉽게 파악할 수 있게 합니다.
- • git rebase -i를 사용한 커밋 재구성
- • squash, reword, reorder 등의 interactive rebase 옵션 활용
- • git push --force-with-lease로 안전하게 강제 푸시
- • 각 커밋을 논리적 단위로 구성하여 리뷰 가능성 향상
코드 리뷰 전 커밋을 정리하여 리뷰어의 이해를 돕고 리뷰 품질을 높이는 상황에서 사용됩니다.
git push --force와 git push --force-with-lease의 차이점은 무엇이며, 왜 후자가 더 안전한가요?
Q. 팀에서 Git hook을 활용하여 커밋이나 푸시 전에 자동으로 테스트를 실행하는 품질 검증 시스템을 구축하려고 합니다. pre-commit과 pre-push hook의 차이점을 설명하고, 각각 어떤 종류의 테스트를 실행하는 것이 적합한지 설명해주세요.
각 hook이 실행되는 시점과 실행 시간이 개발 흐름에 미치는 영향을 고려해보세요.
pre-commit hook은 git commit 실행 직전에 트리거되며, pre-push hook은 git push 실행 직전에 트리거됩니다. pre-commit에서는 빠른 피드백이 중요하므로 린터 검사, 코드 포맷팅 검증, 수정된 파일만 대상으로 하는 빠른 단위 테스트를 실행하는 것이 적합합니다. pre-push에서는 좀 더 시간이 걸리더라도 전체 단위 테스트 스위트나 통합 테스트를 실행하여 원격 저장소로 보내기 전 최종 검증을 수행합니다. 실무에서는 husky나 pre-commit 같은 도구를 사용하여 hook을 팀원 간에 공유하고, 너무 느린 테스트는 CI/CD 파이프라인으로 분리하여 개발 속도를 유지합니다.
- • pre-commit은 커밋 전, pre-push는 푸시 전에 실행
- • pre-commit에는 빠른 검증(린터, 포맷터, 일부 단위 테스트)
- • pre-push에는 전체 테스트 스위트 및 통합 테스트
- • husky 등의 도구로 hook 관리 및 팀 공유
로컬에서 코드 품질을 자동으로 검증하여 불량 코드가 원격 저장소에 올라가는 것을 사전에 방지하는 상황에서 사용됩니다.
Git hook을 우회하여 커밋이나 푸시를 강제로 실행할 수 있는 방법이 있나요? 그렇다면 이를 어떻게 방지할 수 있나요?
Q. 코드 리뷰 과정에서 리뷰어가 특정 파일의 변경 이력을 추적하고 싶어합니다. 해당 파일이 언제, 누가, 왜 수정했는지 확인하여 코드 변경의 맥락을 이해하려고 할 때 사용할 수 있는 Git 명령어들과 그 활용 방법을 설명해주세요.
파일의 각 라인별 변경 이력을 추적하는 명령어와 특정 코드 블록의 변경 히스토리를 찾는 방법을 생각해보세요.
git blame 명령어를 사용하면 파일의 각 라인이 어떤 커밋에서 누구에 의해 마지막으로 수정되었는지 확인할 수 있습니다. git log -p 파일명을 사용하면 해당 파일의 전체 변경 히스토리와 diff를 볼 수 있으며, git log -L 시작라인,끝라인:파일명 명령으로 특정 함수나 코드 블록의 변경 이력만 추적할 수 있습니다. 또한 git log --follow 파일명을 사용하면 파일 이름이 변경된 경우에도 이력을 추적할 수 있습니다. 이러한 명령어들을 통해 코드 리뷰 시 변경의 의도와 맥락을 파악하여 더 효과적인 피드백을 제공할 수 있습니다.
- • git blame으로 라인별 변경 이력 및 작성자 확인
- • git log -p로 파일의 전체 변경 히스토리 조회
- • git log -L로 특정 코드 블록의 변경 이력 추적
- • git log --follow로 파일명 변경 시에도 이력 추적
코드 리뷰나 버그 수정 시 특정 코드가 왜 그렇게 작성되었는지 히스토리를 추적하여 맥락을 이해하는 상황에서 사용됩니다.
git blame의 결과에서 특정 커밋이 대량 리팩토링으로 인한 것이라 실제 로직 작성자를 찾기 어렵다면 어떻게 해야 하나요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!