현실 세계에 시간 여행이 가능한 마법이 있다면 사람들은 전 재산을 걸어서라도 배우려고 할 것 입니다. 하지만 개발자라면 전 재산을 걸 필요가 없죠. git 을 알고 있다면 얼마든지 시간여행을 할 수 있습니다.

해당 포스트 에서는 git 사용간 알아두면 유용한 Git Commands Line 에 대해 다룹니다. 개인적으로 필요한 부분만 정리해 두었기 때문에 자세한 내용은 git-scm.com/book/ko/v2를 참조해 주세요.

용어정리

• HEAD : 현재 브랜치를 가르키는 포인터로, 현재 브랜치 마지막 커밋의 스냅샷 이라고 생각하시면 됩니다.
• 체크섬 : Git에서 체크섬은 SHA-1 해시를 사용하여 만들어진 40자 길이의 16진수 문자열(1f05a945f06e84c32232d4eb7305b9eecd22df4c)입니다. 파일의 내용이나 디렉토리 구조를 이용하여 체크섬을 구합니다.
• Fast Forward : Fast Forward는 Merge할 브랜치가 가리키는 commit이 현재의 (기준)브랜치보다 앞선(뭔가가 더 수정된) commit이기 때문에 현재 브랜치의 최신 커밋(HEAD)이 merge할 브랜치의 최신 커밋을 가르키는 merge를 말합니다.
• Non Fast Forward : master(기준)브랜치가 merge할 브랜치가 생성된 시점 이후로 새로운 commit이 발생하여 merge할 브랜치와 master브랜치와의 merge commit가 실행되어 master브랜치로 통합되는 것 fast forward가 가능한 경우라도 non fast forward옵션을 지정하여merge할 브랜치를 그대로 보존할 수 있습니다.

.gitignore

버전관리 대상에서 제외하고싶은 파일 및 폴더 관리
.gitignore 파일 생성 후 아래와 같이 추가하여 버전관리 대상에서 제외할 수 있습니다.

1
2

*.js # 해당 확장파일 모두 제외
tmp/ # 해당 폴더하위 모두 제외

git config

–global 옵션 없이 선언하면 설정값은 해당 저장소에만 유효합니다. 프로젝트마다 다른 name, email 을 사용하고 싶으면 --global 옵션 제거하고 설정합니다.

1
2
3
4
5

git config --global --list # 전체 설정값 확인
git config --global user.name "jaewon" # set user name
git config --global user.name # get user name
git config --global user.email "j@gamil.com" # set user email
git config --global user.email # get user email

remote

최초에 github과 같은 서비스에서 remote 저장소를 생성성(git init)하여 clone 받을 수 도 있지만, 로컬에서 저장소를 생성하여 리모트로 푸시하거나 로컬에서 리모트 저장소의 주소나 이름, 브랜치등 삭제등을 수행할 수 있습니다.

1
2
3
4
5
6
7
8
9
10
11
12

git remote add 저장소이름 https:// # 로컬에 리모트 저장소에대한 참조 추가
git remote rename 저장소이름 새저장소이름 # 로컬의 리모트 저장소 이름변경
git remote rm 저장소이름 # 로컬의 리모트저장소 삭제
git remote update origin –prune # 리모트 브랜치 기준 로컬브랜치 싱크 맞추기
git remote set-url remote저장소이름 리모트url # 리모트 저장소 변경
git push remote저장소이름 로컬브랜치
git push remote저장소이름 로컬브랜치:뉴브랜치이름 # 리모트 브랜치생성
git push origin –delete 리모트브랜치명 # 리모트 브랜치삭제
git pull ( fetch[저장소에서 변경사항 가져오기] + merge[가져와서 브랜치합치기] )
git clone 리모트 저장소경로 # 리모트 저장소 로컬에 받기
git checkout -t origin/리모트 브랜치 이름 # 리모트저장소의 브랜치 받기
git branch -r # 리모트 저장소 보기

diff

1
2
3
4

git diff // 워킹 디렉토리와 스테이지간 비교
git diff –-cached // 스테이지와 저장소에 커밋된 파일 비교
git diff HEAD~1 // HEAD 에서 이전 1개 커밋과의 diff 보기
git diff 체크섬1 체크섬2 // 두 체크섬간 diff 비교

log

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

git log -p fileName # fileName을 해당 path에 맞춰 사용하면 파일에대한 diff만 확인할 수 있다.
git log –since=yyyy-mm-dd –until=yyyy-mm-dd # 날짜사이의 로그 필터링
git log –since=<date>, –after=<date> # Show commits more recent than a specific date.
git log –until=<date>, –before=<date> # Show commits older than a specific date.
git log –grep="검색할 str"; # 대소문자구문
git log –grep="검색할 str" -i; # 대소문자구분없음 
git log –graph # 커맨드라인에서 그래프로 보여줌
git log –graph –all # 모든 branch의 그래프를 보여줌
git log –author ="jw9651″ #커미터 검색
git shortlog # 저장소에 참여한 모든 사용자가 만들어낸 커밋의 숫자를 알파벳 순서로 정렬하여 출력
git shortlog -n # 알파벳 순이아닌 커밋 횟수순
git shortlog -e # 작업자 이름옆에 이메일 메타데이터 출력
git shortlog -s # 스테이지/커밋 숫자들만 출력
ex)
git log –grep="SDU-5054″ -i –author="jw9651″
history | grep "push"
git reflog | grep merge | grep 5054

merge

일반적인 master의 HEAD 포인터를(컨플릭트시 병합하여) 가장 앞의 커밋으로 옮기는 fast-forward 방식의 merge 입니다. 변경 이력을 모두 확인할 수 있습니다.

reset

1
2
3
4
5
6
7
8

git reset 파일명 // stage -> unstage로변경, add취소
git reset –hard하면 이전으로만 돌아감

git reset –soft 식별id: # add 는 된상태로 
git reset –mixed 식별id: # add하기 전 untracted 로 
git reset –hard 식별id: # 해당 커밋 로그 untracted 파일 까지 삭제
git reset --hard origin/master # 
git reset a.txt // a.txt 파일만 스테이지에서 워킹디렉토리로( tracked -> untracted )

commit

1
2

git commit -m "commit message here"
git commit –amend // 커밋했는데 빠진 파일이나 수정한파일이 있거나, 커밋 메시지 수정하고 싶을 때 사용, 커밋 이력은 추가되지 않는다.

branch

1
2
3
4
5
6

git branch // 사용가능한 브랜치 목록
git branch 브랜치명 // 브랜치생성 헤더는 기존 브랜치에 유지
git checkout -b 브랜치명 // git branch 브랜치명 + git checkout 브랜치명 과동일
git checkout 브랜치명 // 해당 브랜치로 이동
git checkout 체크섬 // 치면 해당 커밋시점으로 돌아감
git branch -d 브랜치명 //브랜치삭제

stash

워킹 디렉토리에 unstaged 파일들을 백업하고 워킹디렉토리를 깨끗한 상태 즉 HEAD의 상태로 만듭니다.

1
2
3
4
5
6

git stash // unstaged파일 백업, 워킹디렉토리 head 상태
git stash list // stash 리스트 보기
git stash apply // stash 꺼내서 적용
git stash drop stash@{0} // stash삭제
git stash pop // 스태시 적용하고 적용한 스태시 삭제
git stash clear // 전체 stash list를 삭제

revert

remote 저장소에 원치 않는 커밋이 푸시되었을 경우 가장 확실하게 복구할 수 있는 거의 유일한 방법입니다.

1
2

git revert 체크섬 # 해당 커밋에 대한 revert만 수행
git revert 체크섬.. # 체크섬 바로 이전 커밋까지 revert 커밋로그 남기며 revert 수행

revert를 사용하게 되는 경우 크게 아래 두가지 형상이 있을 수 있습니다.

1. remote 저장소의 head~ revert 하고싶은 커밋 사이에 나의 이력만 있는 경우
2. remote 저장소의 head~ revert 하고싶은 커밋 사이에 나의 이력과 다른 작업자의 이력이 함께 남아있는 경우

두 경우 모두 revert 커밋 로그를 revert 마다 하나씩 남기는 git revert 체크섬.. 방법을 추천합니다. 각 커밋에 대한 revert 이력을 남길 수 있어 저장소의 히스토리를 놓치지 않고 파악할 수 있습니다. 그리고 컨플릭을 해소할 경우에도 한번에 많은 해소 보다는 각 revert 시 발생하는 컨플릭에 대해서만 해소해 주면 되기 때문에 revert 후 혹 문제가 생겼을 경우 수습할 범위도 줄어들게 됩니다.

아무튼 작업자가 여러명인 저장소의 경우는 매우 골치아픈 상황이 발생할 수 있기 때문에 원격 저장소에 푸시시 신중하도록 하며, 혹시 모를 상황에 대비하여 로컬 저장소에서 rebase 사용하여 원격 저장소의 이력을 깔끔하게 관리할 수 있게 하는게 좋은 것 같습니다.

cherry-pick

다른 브랜치의 원하는 커밋만 뽑아서 현재 브랜치에 merge 시킬 수 있는 아주 유용한 기능입니다.

1

git cherry-pick 체크섬 

alias

.config 파일의 alias 를 수정합니다. .config 는 .git/ 디렉토리에 있으며 프로젝트, 저장소의 정의 설정파일입니다.
여기서 자주 사용하는 명령에 대한 alias 를 생성할 수 있습니다.

1
2

git config --local alias.ad add
git config --gloabl alias.st status

위와 같이 각각 로컬, 글로벌에 add -> ad, status -> st 로 alias를 선언해 주었습니다.
.config 파일을 열어보면 아래와 같이 추가되어 있는 것을 확인하실 수 있습니다.

1
2
3

[alias]
    ad = add
    st = status

delete file

tracking 대상인 파일 삭제시 그냥 지우면(rm -rf) Change but not updated 라고 계속 뜹니다.
git rm a.txt 를 사용하여 파일을 삭제하면 working directory 에서 삭제되고 삭제된 파일은 git 의 deleted 목록에 있습니다. 이 상태에서 commit 하면 tracted 목록에서 삭제됩니다.
이미 파일을 stage에 추가했다면 다음과 같은 애러가 출력됩니다. error: the following file has changes staged in the index: 이럴경우 -f 옵션을 주어( git rm -f a.txt ) 강제로 삭제할 수 있습니다.