Git은 Team Foundation 버전 제어, Perforce 또는 Subversion과 같은 CVCS(중앙 집중식 버전 제어 시스템)와는 근본적으로 다른 방식으로 기록을 나타냅니다. 중앙 집중식 시스템은 리포지토리의 각 파일에 대해 별도의 기록을 저장합니다. Git은 기록을 전체 리포지토리의 스냅샷 그래프로 저장합니다. Git에서 커밋 이라고 하는 이러한 스냅샷에는 여러 부모가 있을 수 있으며 직선 대신 그래프처럼 보이는 기록을 만들 수 있습니다. 이러한 역사의 차이는 매우 중요하며 CVCS에 익숙한 사용자가 Git을 혼란스럽게 하는 주된 이유입니다.
커밋 기록 기본 사항
간단한 기록 예제로 시작합니다. 세 개의 선형 커밋이 있는 리포지토리입니다.
커밋 A는 커밋 B의 부모이며 커밋 B는 커밋 C의 부모입니다. 이 기록은 CVCS와 매우 유사합니다. C 커밋을 가리키는 화살표는 분기입니다. 분기는 특정 커밋에 대한 포인터이므로 Git에서 분기가 매우 가볍고 쉽습니다.
CVCS와 Git의 주요 차이점은 개발자가 리포지토리의 전체 복사본을 가지고 있다는 것입니다. 원격 리포지토리에서 최신 커밋을 가져오면 로컬 리포지토리를 원격 리포지토리와 동기화 상태로 유지해야 합니다. 이렇게 하려면 다음 명령을 사용하여 메인 브랜치를 가져온다.
git pull origin main
이렇게 하면 원격 리포지토리의 주 분기에서 모든 변경 사항이 병합되며, 기본적으로 Git에서 origin이라고 이름이 지정됩니다. 이 끌어오기는 하나의 새 커밋을 가져왔고 로컬 리포지토리의 주 분기는 해당 커밋으로 이동합니다.
분기 히스토리 이해하기
이제 코드를 변경해야 합니다. 여러 기능을 병렬로 작업할 때 여러 활성 분기가 있는 것이 일반적입니다. 이는 새 분기가 무겁고 거의 생성되지 않는 CVCS와는 극명한 대조를 이룹니다. 첫 번째 단계는 다음 명령을 사용하여 새 브랜치로 이동하는 것입니다.
git checkout -b cool-new-feature
두 명령을 결합한 바로 가기입니다.
-
git branch cool-new-feature분기를 만들려면 -
git checkout cool-new-feature분기에서 작업을 시작하려면
추가됨
이제 두 분기가 동일한 커밋을 가리킵니다. 두 개의 새 커밋인 E 및 F에서 cool-new-feature 분기에 몇 가지 변경 사항이 있다고 가정합니다.
커밋은 해당 분기에 커밋되었기 때문에 cool-new-feature 분기에서 접근 가능합니다.
이제 기능이 완료되었으므로 메인 브랜치에 병합해야 합니다. 이렇게 하려면 다음 명령을 사용합니다.
git merge cool-new-feature main
병합이 있을 때 기록의 그래프 구조가 표시됩니다. Git은 분기가 다른 분기에 병합될 때 새 커밋을 만듭니다. 병합 커밋입니다. 충돌이 없으므로 이 병합 커밋에 포함된 변경 내용은 없습니다. 충돌이 있는 경우 병합 커밋에는 충돌을 해결하는 데 필요한 변경 내용이 포함됩니다.
실제 세계의 역사
다음은 팀의 활성 개발 코드와 더 유사한 Git 기록의 예입니다.
대략 같은 시기에 자신의 브랜치에서 main 브랜치로 커밋을 병합하는 사람은 세 명입니다.
다음 단계
GitHub 및 Azure Repos 그리고 Git 로그 기록 간소화에서 Git 기록 작업에 대해 자세히 알아보세요.