(24) Git - stash / 깃 작업 내용 임시 저장하기

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

• format_list_bulleted Git
• · 2024. 9. 11.
• textsms

(24) Git - log all과 graph / 커밋 히스토리 보는 여러가지 방법

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

• format_list_bulleted Git
• · 2024. 9. 11.
• textsms

(23) Git - reflog / reset 되돌리는 방법

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

• format_list_bulleted Git
• · 2024. 9. 11.
• textsms

(실무_4) Git Part2 - git revert / 리모트 레포지토리에 올라간 커밋 취소하기

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

• format_list_bulleted Git
• · 2024. 9. 11.
• textsms

(실무_3) Git Part2 - git blame / 코드 작성자 찾기

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

• format_list_bulleted Git
• · 2024. 9. 10.
• textsms

(실무_2) Git Part2 - git pull 와 git fetch

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

• format_list_bulleted Git
• · 2024. 9. 10.
• textsms