기본 콘텐츠로 건너뛰기

[git] stash명령을 통해 쓸데없는 커밋 방지하기

git에서는 특정 브랜치를에서 작업 중 갑자기 타 브랜치로 옮겨야 하는 경우가 종종 있다(자주 있는거 같기도 하다)
이럴 때 stash를 사용하지 않는다면 커밋을 하고 타 브랜치로 옮겨야 한다. 
이때 만약 커밋을 할 타이밍이 아니라면 쓸데없이 커밋 로그가 한줄 쌓일 것이다.
이러한 것이 쌓이다보면 커밋을 보기가 싫어진다.

이럴때 stash를 이용하면 쓸데없는 커밋을 남기지 않고도 타 브랜치를 움직일 수 있다.
$ git checkout -b test  # test branch 생성

$ vim test.py     # test.py파일 생성

'''코드수정'''
:wq

$ git status
On branch test
Changes not staged for commit:
  (use "git add ..." to update what will be committed)
  (use "git checkout -- ..." to discard changes in working directory)

        modified:   test

Untracked files:
  (use "git add ..." to include in what will be committed)

        test.py

no changes added to commit (use "git add" and/or "git commit -a")
(/Users/bagjeongtae/anaconda) bagjeongtaeui-MacBook-Pro:git_test bagjeongtae$ 


파일을 추가를 하거나 수정을 하고나서 status 명령을 통해 어떤 파일이 생성, 갱신, 삭제가 되었느지 알 수 있다.

문제는 이러한 상태에서는 checkout, pull을 수행 할 수가 없게된다.
위와같은 상태에서 commit이나 pull을 시도할 경우 아래와 같은 현상이 일어날 것이다.
$ git checkout master
error: Your local changes to the following files would be overwritten by checkout:
              test.py
Please commit your changes or stash them before you switch branches.
Aborting

로컬에서 파일이 바뀌어 덮어 씌우게 된다. 커밋을 하고 브랜치를 교체하라는 에러를 띄운다.
그럼 여기서 커밋을 해주어야 하는데 이때 stash를 쓰게되면 꼭 커밋을 할 필요가 없다.

필자같은 경우는 이때 commit을 했다가 타 브랜치로 이동을 해서 작업을 하고 다시 원래 브랜치로 돌아와서 reset을 써서 커밋을 지웠었는데
stash를 쓰면 저렇게 할 필요가 없다.
$ git stash
Saved working directory and index state WIP on test: 2fc8bdc test
HEAD is now at 2fc8bdc test
$ git stash list
stash@{0}: WIP on test: 2fc8bdc test
저장이 되면서 해당 브랜치의 HEAD는 clean상태가 된다. clean상태란 가장 최근 커밋 상태를 가리키는 것이다. 그리고 현재의 상태를 stash저장소에 저장을 하게 된다.

$ git checkout master
타 브랜치로 checkout을 하면 정상적으로 checkout이 가능하게 된다.

바꾼 브랜치에서 작업을 하고 다시 test브랜치로 돌아온 후 stash로 저장 한 코드를 다시 불러오자 방법은 몇가지가 있는데
첫번째로 git stash pop을 이용하는 것이다
$ git stash pop
$ git stash show list
pop을 이용 할 경우 stash리스트에서 뺴오면서 해당 데이터를 지워준다.
이건 스택의 push, pop이랑 원리가 같다.

두번째 방법은 apply를 이용하는 것이다.
$ git stash apply
$ git stash show list
stash@{0}: WIP on test: 2fc8bdc test
apply를 사용 할 경우 list에서 해당 정보를 지우지 않는다. 해당 정보를 계속 남기고 싶다면 pop이 아니라 apply를 사용하도록 하자

댓글

이 블로그의 인기 게시물

[git] git log 확인하기

git log를 통해서 커밋 이력과 해당 커밋에서 어떤 작업이 있었는지에 대해 조회를 할 수 있다. 우선 git에서의 주요 명령어부터 알아보겠다. $ git push [branch name] $ git pull [branch name] 여기서 branch name은 로컬일 경우 해당 브런치 이름만 적으면 되지만 깃허브 원격 저장소로 연결을 원할 경우는 해당 브런치 이름 앞에 꼭 origin을 붙이도록 한다. $ git brnch [branch name] $ git checkout [branch name] branch일경우 해당 브런치를 생성을 한다. 여기서 현재의 브런치를 기준으로 브런치를 따는것이다. checkout은 브런치를 바꾸는 것이다.(HEAD~[숫자]를 이용하면 해당 커밋으로 움직일수 있다.. 아니면 해당 커밋 번호를 통해 직접 옮기는것도 가능하다.) -> 해당 커밋으로 옮기는 것일뿐 실질적으로 바뀌는 것은 없다. 해당 커밋으로 완전히 되돌리려면 reset이라는 명령어를 써야한다. 처음 checkout을 쓰면 매우 신기하게 느껴진다. 막 폴더가 생겼다가 지워졌다가 ㅋㅋㅋㅋㅋ  master 브런치에서는 ht.html파일이 존재하지만 a브런치에서는 존재하지않는다. checkout 으로 변경을 하면 D 로 명시를 해준다.  $ git log 해당 브런치의 커밋 내역을 보여준다. a 브런치의 커밋 내역들이다. (머지 테스트를 하느라 커밋 내용이 거의 비슷하다 ㅋㅋ) master 브런치의 커밋 내역들이다. 커밋 번호, 사용자, 날짜, 내용순으로 등장을 한다. 이건 단순히 지금까지의 내역을 훑어보기 좋다. 좀더 세밀한 내용을 봐보자. $ git log --stat --stat을 붙이면 기존의 로그에서 간략하게 어떤 파일에서

[git] pull을 하여 최신코드를 내려받자

보면 먼가 로고가 다르게 뜨는것을 확인을 할 수가있다. C:\Users\mung\Desktop\etc\study\python-gene>git checkout remotes/origin/master Note: checking out 'remotes/origin/master'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example:   git checkout -b HEAD is now at 29e282a... fetch test C:\Users\mung\Desktop\etc\study\python-gene>git branch * (HEAD detached at origin/master)   master   test1   test2 깃이 잘 쓰면 참 좋은놈인데 어지간히 쓰기가 까다롭다. 처음에 깃을 푸시 성공하는데만 한달정도 걸렸던걸로 기억이 난다.. ㅋㅋㅋ 여담으로  깃 프로필을 가면 아래사진 처럼 보인다. 기여도에 따라서 초록색으로 작은 박스가 채워지는데 저걸 잔디라고 표현을 한다고 합니다 ㅎ 저 사진은 제 깃 기여도 사진입니당 ㅋㅋㅋㅋ 다시 본론으로 돌아와서 ㅋㅋ pull을 하면 깃에 최신 소

[kali linux] sqlmap - post요청 injection 시도

아래 내용은 직접 테스트 서버를 구축하여 테스트 함을 알립니다.  실 서버에 사용하여 얻는 불이익에는 책임을 지지 않음을 알립니다. sqlmap을 이용하여 get요청이 아닌 post요청에 대해서 injection공격을 시도하자. 뚀한 다양한 플래그를 이용하여 DB 취약점 테스트를 진행을 해보려고 한다. 서버  OS : windows 7 64bit Web server : X Server engine : node.js Framework : expresss Use modules : mysql Address : 172.30.1.30 Open port : 6000번 공격자 OS : kali linux 64bit use tools : sqlmap Address : 172.30.1.57 우선 서버측 부터  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 var  express  =  require( 'express' ); var  app  =  express(); var  mysql  =  require( 'mysql' ); var  ccc  =  mysql.createConnection({     host: '127.0.0.1' ,     user: 'root' ,     post: '3306' ,     password: '*********' ,     database: 'test' }) app.post(