Git

이 시리즈에서 정리하고자 하는 내용은 다음과 같습니다.git을 사용하면서 생기는 문제상황과 그에 대한 해결법.git을 사용하면서 문제가 생기지 않도록 주의하는 법. git 명령어에 대한 옵션과 팁.git의 내부구조와 개념 일부.이 시리즈는 독자가 clone, fetch

삭제한 파일 복구하기 작업 중에 파일을 삭제했는데 나중에 그 파일이 필요해지는 경우가 있습니다. 다행히 파일을 삭제하고나서 commit했든 안했든, git은 삭제한 파일의 이름을 확인하고 복구할 수 있습니다. > !주의: git mv 명령을 사용하지 않고 파일을

나는 파일을 삭제하지 않았는데 git은 삭제했다고 받아들일 때가 있습니다. 예를 들어 작업 중 파일을 다른 디렉토리로 옮겨야 하는 상황이 있을 겁니다. 이 때 마우스로 드래그&드롭 하거나 mv 명령을 통해 파일을 이동시켰다면, 파일이 외부에서 조작된 것이기 때문에 gi

이제 막 clone을 마친 상태라면 git branch --all명령을 입력하더라도 main(혹은 master) 위의 그림처럼 브랜치와 원격 저장소에 존재하는 브랜치를 가리키는 포인터 몇 개밖에 보이지 않을겁니다.생각해보면 이런 과정을 거쳐야 할 것 같습니다.HEAD를

Pro Git을 읽다보면 index와 stage라는 용어를 자주 만나게 됩니다. 두 개념을 자주 혼동했던 기억이 있어 따로 정리하게 되었습니다. 본문 내용은 일부를 발췌하여 정리한 내용입니다. 보다 자세히 알고 싶다면 아래 항목을 참고해주세요.2.2 Git의 기초 -

merge는 가장 자주 사용하는 명령 중 하나입니다. 그런데 똑같은 merge명령을 내리더라도 깃은 기존의 히스토리에 따라 다른 방식으로 병합을 진행합니다. 병합하려는 두 브랜치 모두에 변경사항이 있다면 깃은 3-way merge를 진행합니다. 둘 중 한 곳에만 변경사

한 파일의 여러 곳을 수정했는데 그 중 변경사항의 일부만 커밋에 반영하고 싶은 상황이라 가정해봅시다. 직접 파일을 수정한 뒤 커밋해도 괜찮지만 그런 상황에서 유용한 명령어가 있습니다.이 명령어를 실행하면 코드를 일정한 덩어리(hunk)로 쪼개고, 각 덩어리마다 반영여부

무심코 다른 브랜치에서 작업하고 있다가 뒤늦게 발견하는 경우가 있습니다.

분명 파일을 복사해서 붙여넣었고, 필요한 부분만 수정했습니다. 그런데 문제가 없어야 할 부분에서 오류가 나고 있습니다.git diff는 일반적으로 브랜치와 브랜치, 혹은 현재의 Working Directory와 commit을 비교하는 명령이지만, --no-index옵션

개요 어느정도 깃에 익숙해졌다 하더라도 깃헙과 같은 원격저장소(remote repository)를 통해 처음으로 협업을 경험하면 혹시나 남들에게 피해를 줄까봐 겁을 먹게 됩니다. 그렇지만 사실 원격 저장소의 히스토리를 망가뜨리지 않기 위해 고려해야 할 점은 단 한 문

문제가 발생한 커밋을 찾아야 하는데 막상 커밋이 수백개라 엄두가 안 나는 상황이 있을 수 있습니다. 깃은 그럴 때 활용할 이진 탐색 명령어를 제공합니다. 기본적인 용례 활용에 앞서 세 가지 사항을 가정하겠습니다. 현재 HEAD위치는 496dca8 rebase

두 상황은 아주 다르지만 모두 worktree명령어로 해결할 수 있습니다. git worktree는 말 그대로 브랜치가 아니라 새로운 '작업 트리'를 만들고 관리하는 명령입니다. 기존의 트리와 새 트리는 HEAD, index를 별도로 사용하기 때문에 파일의 변경상황에

github, gitlab과 같은 원격저장소에서는 머지가 끝난 브랜치를 자동으로 삭제하도록 설정하기도 합니다. 그러나 로컬에서 ref로 참조하고 있는 포인터들은 원격저장소의 그것과는 별도이기 때문에 사라지지 않습니다. 시험삼아 github의 rebase브랜치를 삭제해보

!주의: 해당 옵션을 이용하려면 먼저 원격 저장소를 망가뜨리는 상황을 피하기 위해 주의해야 할 점을 확인해주세요\--interactive는 많은 명령에서 공유하고 있는 옵션입니다. add, reset, rebase 등등에서 이용할 수 있으며, 사실 다른 주제에서 다루었