'Tool/Git'에 해당하는 글 24건

git reset

Tool/Git 2017. 2. 8. 00:22

git 에는 3가지 로컬 트리가 있다.


1. 워킹 디렉토리(WD)는 버전 관리 중인(tracked) 디렉토리/파일들 이다. 흔히 버전관리 작업하는 로컬 디렉토리라고 생각하면 된다.

2. Index(staged) 는 바로 다음에 커밋될 자료들이다.

3. HEAD 는 현재 브랜치 마지막 커밋의 스냅샷(포인터)이다.


우리가 워킹 디렉토리에서 파일들을 생성하거나 수정하고 커밋을 하기 위해 add 명령으로 index 에 올린 후, 이 자료들은 commit 시 HEAD 가 된다.



위 3가지 로컬 트리를 이해했다면 reset 을 쉽게 이해할 수 있다.

reset 명령은 HEAD 를 이동시킬 수 있다.

HEAD 는 가장 마지막 커밋을 참조하는 포인터이지만 reset 명령으로 해당 브랜치의 다른 커밋으로 옮길 수가 있다. (아마도 대부분 이전으로 옮기겠지..)


reset 명령에는 3가지 옵션이 있다. (soft, mixed, hard)


$ git reset --soft HEAD~
cs


HEAD~ 는 HEAD 의 이전 커밋을 가리킨다. (HEAD~2... 등이나 체크섬 사용 가능)

이전 커밋으로 HEAD 를 옮기는데 --soft 하게.

로컬 트리의 HEAD 만 이전 커밋으로 변경하라는 명령이다.

그 후 새로 commit 을 실행하면 git commit --amend 명령과 동일한 결과가 된다.

amend 는 마지막 커밋을 수정하지만, reset 은 훨씬 이전의 커밋을 수정할 수 있다.


$ git reset --mixed HEAD~
cs


이전 커밋으로 HEAD 를 옮기는데 --mixed 하게. (mixed 가 default 이다.)

로컬 트리의 HEAD 와 index 를 이전 커밋으로 변경하라는 명령이다.


$ git reset --hard HEAD~
cs


이전 커밋으로 HEAD 를 옮기는데 --hard 하게.

로컬 트리의 HEAD 와 index, WD 모두를 이전 커밋으로 변경하라는 명령이다.



위 예제처럼 전체가 아닌 특정 파일(paths)들을 reset 할 수도 있다.

특정 파일 때문에 HEAD 포인터가 바뀌지는 않으므로 HEAD 는 상태 그대로 고정된다.

mixed 옵션으로 Index 나 WD 는 일부분 갱신할 수 있다.


$ git reset file.txt
cs


위 명령은 tree-ish(commit, tag ...) 와 옵션을 생략한 git reset --mixed HEAD file.txt 의 줄임이다.





* 롤백하기



위 그림처럼 C4 까지의 커밋이 있었다고 치자.

원격 저장소의 origin/master 가 C4 를 가리키고 있었다고 치자.

그런데 C3 과 C4 의 내용이 잘못되어 C2 로 롤백해야 하는 상황이 발생했다고 치자.

이 경우 다음의 명령으로 롤백을 시킬 수 있다.


$ git reset --hard C2
cs


그리고 모든 팀원이 C3 과 C4 를 날리고 C2 의 새로운 가지에서 다시 작할 수 있도록 push 를 해보자.

우선 간단한 변경 사항을 만들어 commit(C5) 명령 후에 push 를 날려보자.

원격의 origin/master 는 C4 를 가리키고 있으므로 pull 을 받고 push 하라는 non-fast-forward 경고가 발생한다.


 ! [rejected]        master -> master (non-fast-forward)
cs


이 때 pull 을 받아 버리면 다시 로컬 저장소는 C4 를 가리키게 되므로 pull 을 받으면 안된다.

강제 push 로 C3 과 C4 를 날려버리고 origin/master 가 C5 를 가리키도록 아래와 같이 명령한다.


$ git push --force origin master
...
 + eaa2322...5efad42 master -> master (forced update)
cs


! [remote rejected] master -> master (TF401027: Your account lacks the permission(s) required for the operation you are attempting. 
You need to have 'For error: failed to push some refs to ...
cs


권한이 없다는 오류가 발생한다면, git 서버에 접속하여 다음 config 를 추가하면 된다.


$ git config receive.denyNonFastforwards false
cs


서버 관리자에게 권한 거부 당한다면 ㅈ망 ^^


이상!


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

,

tracking to untracking

Tool/Git 2017. 2. 7. 22:56

.gitignore 파일은 버전관리 하지 않는(untracked) 파일을 버전관리 하지 않도록 무시할 수 있다.

하지만 깜빡하고 이미 버전관리(tracked) 에 포함이 됐거나 뒤늦게 .gitignore 파일에 추가했다면 tracked 파일은 무시되지 않는다.

이럴 때는 해당 파일을 삭제하고 커밋하는 방법도 있지만, 파일을 삭제하지 않고 tracked 파일을 untracked 파일로 변경하는 방법이 있다.


$ git rm --cached filename
cs


filename 에는 \* 같은 파일명 확장 기능을 사용할 수도 있다.

다음 명령은 log 디렉토리의 모든 log 확장자 파일들을 untracked 로 변경한다.


$ git rm --cached log/\*.log
cs


디렉토리와 디렉토리 내의 모든 파일은 간단하게.


$ git rm -r --cached log
cs





WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

,

git stash

Tool/Git 2017. 2. 6. 01:02

merge 를 하거나 branch 를 변경할 때 기존 작업물을 commit 하거나 stash 하라는 메시지를 볼 수 있다.

주로 임시적인 commit 을 행하곤 하는데, stash 라는 기능도 매우 유용하다.

요점만 말하자면 현재 수정된 tracked 파일들을 잠시 특정 공간(stack)으로 옮겨주는 역할을 한다.

그리고 나서 나중에 다시 되돌리면 끝이다.


$ git stash <- 수정된 tracked 파일을 잠시 옮김
 
$ git checkout other_branch <- 딴짓
$ git commit -m 'anything' <- 딴짓
$ git checkout ori_branch <- 딴짓
 
$ git stash apply <- 수정된 tracked 파일을 다시 가져옴
cs



재미진 기능이다.

아래의 명령으로 stash 된 리스트를 확인할 수 있다.


$ git stash list
stash@{0}: WIP on master: 049d078 added the index file
stash@{1}: WIP on master: c264051 Revert "added file_size"
stash@{2}: WIP on master: 21d80a5 added number to log
cs


특정 stash 리스트를 삭제할 수도 있다.


$ git stash drop stash@{0}
cs


apply 대신 아래의 명령을 사용하면 stash apply 후 바로 스택에서 제거하여 리스트에 남지 않는다.


$ git stash pop
cs




WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

,

git amend

Tool/Git 2017. 2. 5. 00:44

마지막 커밋을 수정할 수 있는 방법이 있다. 바로 commit 명령의 amend 옵션을 사용하는 것이다.

'기능 추가 완료' 라고 당당하게 커밋 메시지를 추가했는데, 파일 몇개가 빠졌다면, 

혹은 '깅ㅡㄴ 추가 완료!' 이런식으로 메시지가 잘못됐을 때 사용할 수 있다.


$ git commit --amend -m '기능 추가 완료'
cs


라고 명령하면 현재 index(staged) 작업물들이 추가로 커밋되며 이전 커밋에 더해진다.


중요한 것은 commit 시 생성되는 체크섬(cabcbb5b1ac4e7593749e1853f21405ddacc7f88 같은...) 이 수정되므로,

이미 push 된 커밋이라면 수정하지 않는 것이 좋다.

이미 push 된 커밋을 부모(parent)로 하는 자식들이 있을 경우, 체크섬이 바뀌면서 부모 잃은 자식을 만들 수 있다.




WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

,

git conflict 해결

Tool/Git 2017. 2. 4. 22:30

merge 시 주로 발생하는 충돌, conflict 는 길게 말할 것도 없다.


<<<<<<<<< HEAD:index.html
<div id="footer">contact : email.support@github.com</div>
=======
<div id="footer">
please contact us at support@github.com
</div>
>>>>>>> iss53:index.html
cs


1. 일반적으로 위와 흡사한 형태의 충돌인데, 일단 동일한 부분을 함께 작업한 팀원과 상의하여 코드를 수정한다.

2. <<<<<<<<<, =======, >>>>>>> 라인 역시 삭제한다.

3. 수정이 끝났다면, 다른 기존 파일들과 마찬가지로, add 명령으로 index(staged) 상태로 변경하고, commit 하고 push 한다.



끝이다.


주로 2번 까지만 진행하고 3번을 생략한 채 계속해서 push 를 하려고 해서 '충돌이 해결되지 않았다'는 메시지를 보게된다.

아주 간단하다는...


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

,