Git stashstash는 우리말로 안전한 곳에 보관하다, 넣어두다 라는 뜻을 가지고 있으며여기서는 워킹 디렉토리에서 작업하던 내용을 깃이 따로 보관을 해주는 역할을 해준다.이때 보관하는 장소를 'stack 스택' 이라고 하는데이 스택의 의미는 어떤 데이터를 저장하는 구조를 말한다. ▲ 그림을 보면 먼저 놓은 자료일 수록 다시 꺼낼 때 가장 나중에 꺼내지는 구조를 stack 이라고 한다. ▲ git stash를 하면 가장 먼저 저장했던 작업 내용이 가장 아래에 저장 되는 구조이며 다시 꺼낼 때 가장 나중에 꺼내진다.이런 자료 구조를 stack 이라고 한다. 한번 git stash를 실행해보자 git stash Saved working directory and index state WIP on premi..

커밋 히스토리를 보는 방법은 git log --pretty=oneline 을 사용한다 커밋 히스토리는 현재 위치해있는 브랜치의 히스토리를 보여주는데만약 다른 브랜치를 보려면 checked 커맨드 사용하면서 왔다갔다 했었다. 여기서 --all이라는 옵션을 붙여주면 --allgit log --pretty=oneline --all 이렇게 두 개의 브랜치가 한번에 다나오면서 각각의 모든 히스토리를 보여준다.그런데 이렇게 보면 햇갈릴수 밖에없다. 커밋 메시지마다 어떤 브랜치였는지 기억도 잘안나는 데다가섞여있는 느낌이 있다보니 더 햇갈린다. 이런 문제를 해결해주는 커맨드가 있다. --graph 이 옵션을 쓰면 커밋 히스토리가 각 브랜치와의 관게가 잘 드러나도록 그래프 형식으로 출력된다.git log --pretty..

간단하게 reset 에서 다시 되돌리는 방법을 설명하고자한다예를들어 premium 브랜치에서 LayoutStudy README.md 여기 커밋으로 reset을 해보겠다. git reset --hard bc92 실행하면 워킹 디렉토리에 있는 내용도 다 초기화 될 것이다.히스토리를 열어보면 맨 처음 파일 업로드 커밋을 제외한 README파일을 첫 커밋 했을때 내용만 들어가있다.즉 리셋이 잘 실행 되었다는 것을 알 수있다.  그럼 이때까지 작업했던 커밋들은 다 삭제가 돼버린걸까?그렇지는 않다. 리셋을 해도 리셋한 커밋 이후의 커밋들이 삭제 되는 것은 아니다.삭제 된것이 아니라는걸 보여주자면맨 위 사진에 보면 리셋 하기전 히스토리인데 ' 1caf ' 맨 위 커밋을 다시 리셋을 해보겠다 git reset --ha..

main 브랜치로 이동해서 README에 문구하나 작성해주자 git checked main '작심삼일' 이라는 문구를 넣어서 저장해주고 터미널에서 커밋해준다.이 커밋을 리모트 레포지토리의 main 브랜치에 반영하기위해 push 해준다. 자 상황 예시는 끝났다.지금 이미 main 브랜치의 리모트 래포지토리에 커밋이 올라가있는 상태인데이미 push 해버렸고 .. 취소하려면 어떻게 하면 될까? 저 문구를 지우고 그냥 다시 커밋을 하면 될것 같지만 이러한 동작을 한번에 해주는 커맨드가 존재한다.커밋 히스토리를 보자면.. 여기서 이 최신 커밋에서 한 작업을 되돌리고 다시 커밋을 해주는 커맨드가 있다.  Git revertrevert는 되돌리다, 복귀하다 라는 뜻을 가지고있으며 말 그대로 최신 커밋에서 한 작업을 ..

깃을 쓰다보면 하나의 파일이 이때까지 어떻게 변해 온건지를 파악해야할 때가있다. 예를 들어 지금 본인의 프로젝트에 있는 README파일도 모든 내용을 한번에 다 쓰고 커밋한게 아니다지금 README파일은 여러번의 커밋을 해온 결과가 지금의 모습이다. 한 가지 파일이 완성되기까지 어떤 커밋들이 있어왔는지를 볼수있는 커맨드가 있다, git blameblame은 비난하다, ~의 탓으로 돌리다 이런 뜻인데표현이 조금 그렇지만 여기서는 어떤 파일의 특정 코드를 누가 작성했는지 찾아내기 위해 사용된다.아마 커맨드 개발자가 누군가 실수할 때 작성자를 갈구고 탓을 돌리기 위해 작명을 blame으로 작성했던것 같다(?) git blame [파일명] 실행하면 파일의 각 부분이 어떤 커밋으로 인해 탄생했는지 한눈에 볼 수있..

이전 글 되풀이 요약을 하자면 git으로 다른 개발자와 협업을 하는 상황에서git push를 하기 전에 git pull을 해야할 떄가 많다고 했었다.그리고 git pull은 리모트 레포지토리에 있는 branch를 가져와서현재 brancgh에 자동으로 merge하는 커맨드라고 했었다.(이때 branch를 가져온 다는 것은 그 branch가 가리키고 있는 커밋 이전에 이루어진 모든 커밋을 가져온다는 뜻) 그런데 merge는 하지 않고 딱 가져오는 단계까지만 해주는 커맨드도 있다.Git fetchfetch는 우리말로 가져오다 라는 뜻을 가지고있으며여기서 fetch를 실행하면 가져오기만하고 자동으로 merge는 되지 않는다. git pull읋 하면 자동으로 merge 까지 해주니까 편할 것 같은데 왜 굳이 fe..

이전 파트에서 git push와 git pull 커맨드를 배웠다.(기억안난다면 커멘드 클릭해서 되풀이하기) 이번에는 git push를 쓸 때 자주 만나게 되는 상황을 설명해보겠다. 우선 premium 브랜치에서 시작해보자 (git checkout premium) premium 브랜치에서 내용을 좀 더 추가해보자면 다음프로젝트 일정에 관한 내용을 추가하고 저장 한다음 git add 하고 커밋을 해줬다. 이렇게 로컬 레포지토리의 premium 브랜치에서 커밋을 해줬다.이제 리모트 레포지토리의 premium 브랜치로 이동하기위해 깃허브 페이지의 premium 브랜치에 접속해보자 깃허브의 premium 브랜치에서도 README파일을 수정해보자  이렇게 로컬 레포지토리와 다른 내용을 넣었다. 상황을 정리해보자면...

각 커맨드를 클릭하면 해당 관련된 글로 이동합니다.git branch [새 브랜치 이름]: 새로운 브랜치를 생성 git checkout -b [새 브랜치 이름]: 새로운 브랜치를 생성하고 그 브랜치로 바로 이동 git branch -d [기존 브랜치 이름]: 브랜치 삭제 git checkout [기존 브랜치 이름]: 그 브랜치로 이동 git merge [기존 브랜치 이름]: 현재 브랜치에 다른 브랜치를 머지git merge --abort: 머지를 하다가 conflict가 발생했을 때, 일단은 머지 작업을 취소하고 이전 상태로 돌아감

merge를 하면 새로운 커밋이 생긴다고 했었다.그리고 머지를 통해서 생겨난 커밋을 머지 커밋(merge commit)이라고 부른다고 했었다. 그림을 보면 지금 main 브랜치에서 premium 브랜치를 merge 해서 머지 커밋이 생긴 것을 알 수있다.하지만 머지를 한다고해서 항상 새로운 커밋이 생기는 것은 아니다. 예를 들어 main 브랜치에 있는 상태에서 'merge premium'을 실행한다면? premium 브랜치가 가리키던 커밋을, main 커밋도 똑같이 가리키게 된다. 커밋수도 그대로인 것을 짐작할수있는데이렇게 새로운 커밋이 생기는 게 아니라 단지 브랜치가 이동하게 되는 머지를 Fast-forward 머지라고 한다.Fast-forward는 어떤 영상이나 소리를 빨리감기(앞으로 감기)한다는 뜻..

전 글에서 브랜치(branch)는 커밋을 가리키는 존재(포인터)이고,HEAD는 이런 브랜치를 통해 커밋을 간접적으로 가리키는 존재(포인터) 라고 했다. 그렇다면 이전에 배운 'git reset' 커맨드의 동작 원리를 더욱 정확하게 알 수 있을 것이다.git reset을 할 때 HEAD의 변화는?  이 상태에서 git reset [--hard 또는 --soft 또는 --mixed] 9033 을 실행한다면 HEAD가 9033.. 커밋을 가리키게 된다. git reset 커맨드를 사용하면 HEAD는 여전히 같은 브랜치를 가리키고, HEAD가 가리키는 브랜치가 다른 특정 커밋을 가리키게 되고, 이 때문에 결국 HEAD가 간접적으로 가리키던 커밋도 바뀌게 되는 것이다.  이러면 git reset을 했을 때 HEA..