박세헌

자기소개

안녕하세요. 박세헌입니다. 이번 프로젝트에서 팀 협업의 효율과 코드 안정성을 높이기 위해 알아두어야 할 심화 Git 및 GitHub 활용 전략을 학습하고 정리했습니다.

안전한 협업을 위해서는 단순히 브랜치를 나누는 것을 넘어, 원격 저장소 레벨에서의 통제가 필수적입니다.

Branch Protection Rules 설정: main 브랜치와 같은 핵심 브랜치에 직접 코드가 들어오는 것을 방지하기 위해 규칙을 설정합니다.
병합(Merge) 전 반드시 Pull Request 거치기
최소 1명 이상의 코드 리뷰 승인(Approve) 필수
해결되지 않은 리뷰 대화(Unresolved Conversations)가 있을 경우 병합 차단
관리자(Admin)에게도 예외 없이 규칙 적용 (우회 방지)

GitHub에서 PR을 병합할 때 선택하는 방식에 따라 main 브랜치의 커밋 히스토리가 완전히 달라집니다. 팀의 컨벤션에 맞춰 적절한 방식을 선택해야 합니다.

Merge Commit: feature 브랜치의 모든 커밋 이력이 그대로 유지되며, 병합된 시점에 새로운 Merge 커밋이 생성됩니다. 전체 작업 흐름의 맥락을 상세히 파악할 수 있습니다.
Squash and Merge: feature 브랜치의 수많은 개발 커밋들을 하나로 압축(Squash)하여 main 브랜치에 단 하나의 깔끔한 커밋으로 기록합니다. 히스토리가 단순해지지만 개별 커밋의 세부 내역은 사라집니다.
Rebase and Merge: 커밋의 병합 지점 없이, main 브랜치 최신 상태 위에 feature 브랜치의 커밋들을 일렬로 재배치하여 이어 붙입니다. 선형적인 히스토리를 유지할 수 있습니다.

잘못된 커밋이나 변경 사항을 다룰 때는 원격 저장소 공유 여부에 따라 올바른 명령어를 선택해야 혼선을 막을 수 있습니다.

git commit --amend (공유 전): 가장 최근 커밋의 메시지나 누락된 파일을 추가할 때 사용합니다. 새로운 해시값의 커밋으로 교체되므로, 아직 원격에 푸시하지 않은 로컬 커밋에만 사용해야 안전합니다.
git reset --soft HEAD~1 (공유 전): 최근 커밋을 취소하되, 작업 중이던 변경 사항(Changes)은 스테이징 영역에 그대로 보존합니다. 커밋 단위를 다시 쪼개고 싶을 때 유용합니다.
git revert <commit-hash> (공유 후 안전): 이미 원격에 공유된 커밋의 변경 사항을 반대로 되돌리는 새로운 커밋을 생성합니다. 기존 히스토리를 삭제하지 않고 안전하게 과거 상태로 롤백할 수 있습니다.
git stash / git stash pop: 현재 작업 중이던 미완료 내용을 임시로 서랍에 넣어두듯 보관하고, 다른 브랜치로 이동했다가 돌아와 다시 불러올 때 사용합니다.

충돌은 단순한 마커 (<<<<<<<, =======, >>>>>>>) 지우기가 아닙니다.

양쪽 브랜치의 변경 의도를 모두 파악한 뒤, 관련 팀원과의 충분한 협의를 거쳐 최종 코드를 확정해야 합니다.
충돌 해결 후에는 반드시 로컬에서 빌드 및 테스트 검증을 마친 뒤 git add와 커밋을 수행하고 원격에 푸시해야 합니다.

이번 프로젝트에서는 위와 같은 체계적인 규칙과 도구 활용법을 바탕으로, 코드의 품질과 팀 간의 소통 기록을 모두 지키는 협업 방식을 연습하고 있습니다.