Git 자유자재로 활용하기
git reset을 하고 나서 돌아오려면?
이때까지 한 커밋들은 사라지는 것일까? 아니다. git reset을 해도 그 이후의 커밋들이 삭제되는 건 아니다. 제일 최근 커밋으로 git reset --hard [커밋ID] 커맨드를 입력하면 다시 확인할 수 있다.
$ git reflog만약 전에 커밋 히스토리를 하지 않았을 때, HEAD가 이때까지 가리킨 커밋들을 기록한 정보를 보여준다. 커밋을 확인하고 q를 눌러 나갈 수 있다.
커밋 히스토리를 보는 다양한 방법
$ git log --pretty=oneline --all현재있는 브랜치뿐만 아니라 다른 브랜치 히스토리도 확인할 때 사용할 수 있다.
$ git log --pretty=oneline --all --graph--all 옵션만 주었을 때는 브랜치 별로 확인하기 어려울 수 있다. 이때 --graph 옵션을 주면 커밋 히스토리가 각 브랜치와의 관계가 잘 드러나도록 그래프 형식으로 출력한다. 출력 화면에 *는 커밋을 뜻하고, |들은 브랜치를 의미한다.
깔끔한 커밋 히스토리를 원할 때 git merge 대신 git rebase
$ git rebase [브랜치이름] # merge할 브랜치
$ git add .
$ git rebase --continuegit rebase --continue는 conflict가 발생해서 제대로 진행되지 못한 리베이스를 계속 진행한다. git commit 커맨드를 사용하는게 아니다.
rebase와 merge의 차이는 rebase는 새로운 커밋을 만들지 않고, rebase로 만들어진 커밋 히스토리는 merge로 만들어진 커밋 히스토리보다 더 깔끔하다.
작업 내용 임시 저장하기
$ git stash
# git stash list # 보관한 내용들 확인git stash를 하면 최근 커밋 이후로 작업했던 내용이 모두 스택(stack)에 옮겨지고, working directory 내부는 다시 최근 커밋의 상태로 초기화가 된다.
$ git stash apply스택에 담겨져 있던 내용을 다시 working directory로 불러올 때 사용된다.
적용한 작업 내용은 스택에서 없애기
$ git stash # 작업 내용 저장
$ git stash list # 작업 내용 조회(=스택 살펴보기)
$ git stash apply [ID] # 작업 내용 적용
$ git stash drop [ID] # 작업 내용 제거apply와 drop은 뒤에 ID를 지정해 주지 않으면,가장 최근 작업 내용을 적용하고 삭제한다. 또한 작업 내용이 너무 많이 쌓이면 보기 힘드므로, 이미 적용한 작업 내용은 지워주는게 좋다. 그런데 작업 내용을 적용하면서 동시에 스택에서 제거도 해주는 커맨드가 있다.
$ git stash pop [ID]이 커맨드를 쓰면 특정 작업 내용을 적용함과 동시에 그것을 스택에서 제거할 수 있다. git pop도 마찬가지로 ID를 인자로 주지 않으면, 가장 최근에 한 작업 내용을 적용하면서 스택에서 제거하게 된다.
앞으로 스택에 저장된 작업 내용을 working directory에 적용할 때, 그 작업 내용을 나중에 또 쓸 필요가 있다면 git stash apply를 사용하고 나중에 또 쓸 필요가 없다면 git stash pop을 사용하면 된다. 일반적으로는 후자의 경우를 더 많이 사용한다.
필요한 커밋만 가져오는 git cherry-pick
$ git cherry-pick [ID]cherry-pick은 자신이 원하는 작업이 들어있는 커밋들만 가져와서 현재 브랜치에 추가하는 기능이다. 이때에도 conflict 오류가 발생하는데 이제까지 배운 방식대로 해결하면 문제가 없을 것이다.
.gitignore 파일 살펴보기
Github에 레포지토리를 만들 때, 왼쪽 하단에 Add .gitignore: None이라는 설정 탭을 확인할 수 있다. 이 말은 .gitignore 파일을 만들지 않겠다는 것이다. 그렇다면 .gitignore 파일은 무엇일까?
.gitignore 파일은 working directory 내에 존재하는 파일들 중에서 마치 존재하지 않는 것처럼 Git이 인식해야할 파일들의 목록이 적힌 파일이다. 말그대로 Git이 무시하는 파일들의 이름이 적혀있는 파일이다. Add .gitignore: None 설정 탭을 눌러보면 알파벳 A부터 순서대로 그 알파벳으로 시작하는 단어들이 등장한다. 이 단어들은 모두 프로그램이 실행되는 플랫폼이나 프로그래밍 언어들을 말한다. 이들 중 하나를 선택하면 그 플랫폼에서 실행될 프로그램을 만들거나, 해당 프로그래밍 언어로 코드를 작성할 때 (보통 자동으로) 생성되는 파일들 중에서 굳이 Git에 의해 버전 관리가 필요가 없는, 불필요한 파일들의 이름이 정리된 .gitignore 파일을 자동으로 생성해 준다.
예를 들어 Python을 선택하고 .gitignore 파일을 확인하면 여러 파일 이름 또는 디렉터리 이름이 보일 것이다.
*.py[cod]
*$py.class
*.so*는 그냥 길이 0개 이상의 아무 단어라고 생각하면 된다. 그리고 대괄호[]는 그 안의 알파벳 중에 하나라고 생각하면 된다.
| 단어 | 의미 |
| *.py[cod] | .pyc 또는 .pyo 또는 .pyd로 끝나는 파일명 |
| *$py.class | $py.class로 끝나는 파일명 |
| *.so | .so로 끝나는 파일명 |
여기에 해당하는 파일들은 모두 Git이 무시해 버린다. 또 build/, develop-eggs/처럼 이름 맨 뒤에 슬래시(/)가 붙은 것은 디렉터리를 말한다. 이 2가지는 build 디렉터리에 있는 모든 파일과, develop-eggs 디렉터리에 있는 모든 파일들도 Git이 무시한다는 것이다.
즉, 이런 것들은 버전 관리를 할 정도의 가치가 없고 오히려 버전 관리를 하면 용량만 더 차지할 뿐더러 나중에 각 버전을 살펴볼 때 가독성을 떨어뜨리기만 하기 때문에 Git이 무시하도록 설정한 것이다.
그 밖에 알아야 할 사실
git commit이라고만 쓰고 실행하면 커밋 메시지를 입력할 수 있는 텍스트 에디터 창이 뜬다. 거기서 커밋 메시지를 입력하고 저장하고 나면 커밋이 이루어진다.git push와git pull은 그 작업 단위가 브랜치이다. 예를 들어, master 브랜치에서git push를 하면 master 브랜치의 내용만 remote respository의 master 브랜치로 전송되지, premium 브랜치의 내용이 전송되는 것은 아니다. (git push에--all이라는 옵션을 주면 모든 브랜치의 내용을 전송할 수 있기는 하다.)
