애플리케이션에 코드를 기여할 때는 보통 Git의 기능(feature) 브랜치에서 커밋을 작성하게 됩니다. 이 가이드에서는 프로젝트의 커밋을 최신 상태로 동기화하는 방법을 살펴보고, Git과 GitHub가 무엇인지도 함께 알아보겠습니다.
Git과 GitHub란?
Git은 코드에 대한 모든 변경 사항을 추적하는 명령줄 도구입니다. 변경 사항을 저장할 때 자주 사용하는 명령으로는 git add, git commit, git push가 있으며, 이러한 방식을 버전 관리(version control)라고 부릅니다.
이 명령어들로 파일 변경 사항을 저장한 후, git push 명령을 실행하면 파일이 GitHub 같은 코드 호스팅 플랫폼에 저장됩니다. GitHub는 파일을 저장소(repository)에 보관하며, 사용자들이 코드를 손쉽게 공유할 수 있도록 지원합니다.
GitHub와 같은 코드 호스팅 플랫폼은 원격 환경에서 함께 프로젝트를 진행할 수 있게 해줍니다. 기술 분야 일자리가 원격 근무로 빠르게 전환되고 있는 만큼, 이러한 협업 도구의 중요성은 그 어느 때보다 커지고 있습니다.
git merge를 사용해야 하는 시점
회사에서 다른 개발자들과 함께 일하든, 취미로 오픈 소스 프로젝트에 기여하든 git merge 명령어를 반드시 사용하게 됩니다. 여기서 중요한 것은 회사나 해당 오픈 소스 프로젝트가 커밋을 수락하는 방식을 정확히 파악하는 것입니다. 프로젝트에 본격적으로 참여하기 전에 주변에 물어보고 기여 가이드라인(contributing guidelines)을 꼼꼼히 읽어보세요.
일반적으로 개발자는 앱의 특정 기능을 구현하는 업무를 맡게 되며, 그에 따라 기능 브랜치에서 코드 변경 사항을 커밋합니다. 기능 브랜치는 마스터(master) 브랜치에서 '분기'되어 나온 브랜치로, 마스터 브랜치에는 최종 배포용 코드가 위치합니다.
개발 단계에서 기능 브랜치에서 코딩을 진행하면, 개발 과정에서 발생할 수 있는 버그로부터 마스터 브랜치를 깨끗하게 유지할 수 있습니다. 기능 브랜치의 이름은 구현하는 기능을 나타내는 이름으로 짓는 것이 좋습니다. 이 시점에서 여러분은 마스터 브랜치에서 분기되어 연결된 기능 브랜치에서 작업하고 있는 것입니다.
다음 다이어그램은 브랜치가 동작하는 방식을 시각적으로 잘 보여줍니다.
여기에는 topic과 master 두 개의 브랜치가 있습니다. topic 브랜치가 바로 기능 브랜치입니다. A, B, C는 시간 순서대로 발생한 커밋이며, C는 기능 브랜치의 가장 최근 커밋입니다. G는 마스터 브랜치의 가장 최근 커밋입니다.
이런 상황은 다른 팀이 코드 리뷰를 통과한 후 마스터 브랜치에 커밋했을 때 발생합니다. 마스터 브랜치의 최신 버전이 내 로컬 머신에 있는 마스터 브랜치 버전(git pull 기준)과 달라지면서 버전 관리 문제가 생기고, 이로 인해 병합 충돌(merge conflict)이 발생할 수 있습니다.
기능 브랜치에서 git merge master 명령을 실행하면 마스터 브랜치를 기능 브랜치로 병합할 수 있습니다. 이렇게 하면 로컬의 마스터 브랜치가 최신 상태로 갱신되며, 이후 코드가 코드 리뷰를 통과하면 git push origin master 명령으로 변경 사항을 마스터 브랜치에 푸시할 수 있습니다.
다시 강조하지만, 프로젝트 기여 가이드라인을 모두 충족하기 전에는 마스터 브랜치에 푸시해서는 안 됩니다. 검증되지 않은 코드로 인한 버그나 문제를 예방하기 위해, 마스터 브랜치에 직접 푸시하지 않는 것이 모범적인 실천 방법(best practice)입니다.
결론
Git 명령어를 능숙하게 사용하는 것은 모든 개발자에게 필수 역량입니다. 특정 명령어를 언제 어떻게 사용해야 하는지 제대로 알고 있으면, 항상 최신 버전의 코드를 안전하게 저장하고 다른 브랜치와의 병합 문제를 예방할 수 있습니다.
회사 코드베이스나 오픈 소스 프로젝트에 기여하면서 Git을 사용할 때는 해당 프로젝트의 가이드라인을 반드시 따라야 합니다. 프로젝트마다 코드 리뷰 방식이 다르기 때문에, 특히 git merge master를 사용할 때는 가이드라인을 준수하는 것이 필수적입니다.