저장소 분리1. 저장소를 분리할 수 있도록 새로운 브랜치를 생성한다. 2. 깃허브에서 위 저장소와 동기화할 새로운 원격 저장소를 생성하고 로컬 저장소에 등록한다. 3. 생성한 브랜치를 원격 저장소로 푸시한다. 이때 로컬 저장소의 브랜치는 분리 기준이 되는 worked 브랜치이다. 그리고 원격 저장소로 전송되는 브랜치는 main 브랜치이다.  이제 원격 저장소는 커밋 3개만 main 브랜치에 가지고 있다. 4. 저장소를 분리하기 위해 commit-tree 명령어로 가상의 임시 객체를 생성한다. 이 객체는 아직 다른 어떤 객체와도 연결되지 않고 떨어져 있는 객체이다. 5. 생성된 임시 객체를 다른 커밋 객체와 리베이스하여 병합한다. 결과로 이전에 있던 커밋들과 연결 고리가 끊어져 분리되었으며 로그 기록에는 ..

여러 개발자와 협업하다 보면 잘못된 코드를 찾는 것은 쉽지 않다. 모든 커밋 이력을 살펴본다면 시간이 오래 걸리므로 깃은 이러한 코드를 쉽게 찾을 수 있도록 파일의 수정 이력을 분석한다. blame 명령어blame 기능은 커밋의 메타 정보를 코드 라인 별로 같이 결합하여 출력한다. 코드를 수정한 사람이 누구인지, 언제 수정한지를 쉽게 판별할 수 있으며, 메타 정보를 바탕으로 문제를 좀 더 쉽게 파악할 수 있다. blame 명령어는 개별 파일에서만 동작하며, 명령어 인자 값으로 개별 파일을 전달한다.$ git blame  blame 옵션소스 코드의 용량이 클 때는 이력 정보도 많이 출력된다. 이때는 L 옵션을 사용하여 파일의 특정 영역만 지정할 수 있다.$ git blame -L ,  추가 옵션-e: 사..

참조 기록 확인reflog깃은 안정적인 작업을 유지하기 위해 참조된 모든 refs를 기록한다. 그리고 내부적으로 작업한 모든 HEAD와 브랜치 포인터를 기록한다. 이때 사용된 포인터들의 기록을 reflog라고 하며, reflog 기록은 reflog 명령어를 사용하여 확인할 수 있다.$ git reflog log -glog 명령어의 g 옵션으로도 refs 로그를 확인할 수 있다.$ git log -g 기록 확인reflog 기록들은 HEAD@{숫자} 형태이다. 각 숫자는 작업을 수행한 해시 값을 가리킨다. 따라서, reflog에 기록된 HEAD@{숫자} 포인터를 이용하여 커밋 정보를 확인할 수 있다.$ git show HEAD@{0} 기간 확인커밋의 로그 기록이 많은 경우 필터링할 수 있다. 필터링은 특정한..

해시 값 확인생성된 모든 해시 값은 show 명령어로 확인할 수 있다.$ git show  역 조회show 명령과는 반대로 rev-parse 명령어로 포인터의 해시 값을 알 수 있다. 예를 들어, 브랜치는 커밋 해시 값을 가리키는 포인터이므로 브랜치 이름을 사용하여 참조하는 해시 값을 조회할 수 있다.$ git rev-parse main 참조 목록깃에서는 생성된 해시 값을 쉽게 참조할 수 있도록 refs 목록을 생성한다. 깃의 모든 refs 목록은 저장소의 숨긴 영역인 .git/refs 폴더 안에 저장된다. 처음 저장소를 생성하면 .git/refs 폴더에는 heads와 tags 폴더만 있다. 새로운 feature 브랜치를 만들고 .git/refs 폴더를 확인하면 feature 브랜치의 refs가 생성되었..

저장소 분리규모가 큰 프로젝트를 효과적으로 관리하기 위해, 프로젝트를 작은 단위로 분리하여 관리하는 방식이 많이 사용된다. 이를 위해 Git은 서브모듈(Submodule) 이라는 개념을 제공한다.서브모듈은 하나의 Git 저장소가 다른 Git 저장소를 포함하는 형태로, 대형 프로젝트를 모듈화하여 독립적으로 관리할 수 있도록 도와준다. 각각의 기능을 독립된 저장소로 분리하여 관리하며, 독립적으로 관리된 저장소들은 다시 메인 저장소(Main Repository) 와 결합하여 재사용된다. 이러한 방식은 프로젝트의 유지 보수성과 확장성을 크게 향상시킨다. 서브 모듈 추가부모 저장소와 자식 저장소를 생성하고 각각 원격 저장소에 연결해준 상황이다.submodule 명령어의 add 옵션은 부모 저장소에 자식 저장소를 ..

태그깃은 정리된 커밋을 배포할 수 있도록 특수한 포인터를 제공하며, 특정 커밋을 가리키는 포인터로 버전을 관리한다. 이 포인터를 태그라고 한다. 즉, 태그는 특정 커밋의 해시 값을 가리키는 꼬리표를 의미 한다.최종 사용자는 개발자가 부여한 태그를 사용하여 코드 버전을 구별한다. 또한, 태그 포인터로 최종 배포판의 커밋을 구별한다. 태그는 커밋 해시 값을 기준으로 생성되며 특정 커밋 해시 값을 가리키는 것 뿐만 아니라, 꼬리표 이름과 정보도 포함하고 있다. 태그는 추가 정보를 보유하는지 여부에 따라 두 가지로 구분한다.Annotated: 태그 이름 + 정보 포함Lightweight: 태그 이름만 포함 태그 목록단순히 태그 목록을 확인하고 싶다면 tag 명령을 단독으로 실행하거나 l 옵션을 사용하여 모든 태..

reset 명령어리셋 명령어를 사용하면 지정된 커밋 코드로 되돌아가고 특정 커밋의 해시 값 상태로 모든 코드를 복구한다. $ git reset 옵션 커밋ID mixed리셋 명령어의 기본 옵션이다.$ git reset --mixed 커밋ID$ git reset 커밋ID 리셋한 후 스테이지 상태까지 복원하지는 않기 때문에 수정 사항이 Unstaged 상태로 남게 된다. 따라서, 커밋하려면 add 명령을 먼저 실행한다. softsoft 옵션은 가장 낮은 단계의 리셋 동작이다. 지정한 커밋 위치로 복귀하면서 스테이지 영역의 상태도 같이 복구시킨다. 즉, 해당 옵션은 파일을 수정하고, add 명령어로 스테이지 영역에 올려 커밋을 실행하기 직전의 단계로 되돌린다.soft 옵션은 단순히 HEAD 위치만 이동하는 역할..

브랜치를 합치는 방법은 병합 외에도 리베이스가 있다. 리베이스는 커밋의 트리 구조를 재배열하는 것으로 파생된 브랜치의 기준이 되는 베이스 커밋을 변경하는 것이다. 브랜치가 많아지면 단계별로 커밋을 따라가면서 코드를 확인해야하는 불편함이 있으므로 베이스의 분기점을 변경하여 진행 사항을 파악하기 쉽게 한다. 리베이스 vs 병합병합은 두 브랜치의 공통 조상 커밋을 찾아 서로 다른 커밋을 3-way 방식으로 병합할 수 있다. 병합하는 두 브랜치는 순차적으로 커밋을 비교하면서 마지막 최종 커밋을 생성한다.반면 리베이스는 두 브랜치를 서로 비교하지 않고 순차적으로 커밋 병합을 시도한다. 따라서 리베이스는 단순히 변경 사항을 새로운 베이스 브랜치의 최신 커밋 뒤로 하나씩 적용하는 방식으로 진행된다. 이 과정에서 두 ..

여러 사람과 개발 작업을 하다 보면 충돌이 자주 발생한다. 대부분의 충돌 원인은 같은 위치의 코드를 동시에 수정했을 때 두 수정 중 어떤 것이 맞는지 깃에서 자동으로 알 수 없기 때문에 발생한다. 보통 3-way 병합이 실패한 경우이다. 충돌 상황을 만들기 위하여 main 브랜치에서 footer 브랜치를 생성하고 임의의 파일을 수정한 다음 커밋한다. 다시 main 브랜치로 체크아웃하고 충돌이 발생하도록 같은 파일의 같은 위치를 수정한 후 커밋한다. 서로 다르게 분기된 브랜치이기 때문에 3-way 병합을 시도한다면 자동으로 병합되지 못하고 충돌이 발생하게 된다. 이어서 git status로 작업 상태를 확인해보면 커밋되지 않은 변경 사항이 추가가 되어있음을 알 수 있다. 수동으로 충돌 해결깃은 충돌이 발생..

Fast-Forward 병합순차적 커밋에 맞추어 병합을 처리하는 방법을 Fast-Forward 병합이라고 한다. 해당 방식은 일반적으로 혼자 개발할 때 사용한다.브랜치를 병합하려면 기준이 되는 브랜치로 이동해야 한다. 현재 feature 브랜치로 분기하여 작업했으므로 main 브랜치로 체크아웃한다. 커밋 작업은 분기된 feature 브랜치에서 모두 수행하였으므로 두 브랜치를 병합하면 된다. Fast-Forward 병합은 작업한 브랜치를 원본 브랜치에 병합할 때 작업한 브랜치의 시작 커밋을 원본 브랜치 이후의 커밋으로 가리킨다. 단순히 커밋 위치를 최신으로 옮기는 것과 비슷하다. 결과적으로 main 브랜치의 마지막 커밋 위치와 feature 브랜치의 마지막 커밋 위치가 같아졌고 동일한 HEAD 포인터를 가..