깃의 명령어를 소개하는 글이 아닌, 개인적으로 자주 쓰지만 자꾸 잊어버리는 명령어만 모아두는 글이다. 전체 명령어를 훑어보고 싶다면 깃의 공식 도서를 참고하자. 특정 텍스트가 포함된 commit 검색 >git log -S<텍스트> 특정 텍스트가 추가되거나, 삭제된 commit을 검색해 준다. 머지 >git merge –no-ff -Xtheirs <브랜치 이름> merge 시, FF가 가능하더라도 merge commit을명시적으로 만든다. merge 할때, 타겟 브랜치의 파일에 […]
인터넷에는 깃(Git)의 장점에 대한 많은 글이 있다. 먼저 많이 회자되는 장점들을 무작위로 열거 해보자. 미친듯이 속도가 빠르다. 오프라인 작업이 가능하다. 저장공간을 적게 차지한다. 실수를 쉽게 복구할 수 있다. 항상 대안이 있어 염려할 필요가 없다. 커밋이 쉽다. 커밋의 관리가 쉽다. 특정 파일을 무시할 수 있다. 브랜치를 만들 수 있다. 내 상태를 확인할 수 있다. 브랜치에서
게릿(Gerrit)은 문서화가 잘되어 있는 프로젝트다. 여기서는, 내게 필요한 내용만 골라 예제와 함께 모아둔다. Code-Review와 Verified의 차이는 무엇인가? Code-Review는 코드를 보고 주는 점수이고, Verified는 빌드에 이상이 없는 것을 확인하는 점수다. Verified는 젠킨스와 같은 CI 툴을 통해 자동으로 줄 수 있도록 하자. 왜 Gerrit의 계정을 사용하나? 깃은 계정 관리 기능이 없다. 그래서, 게릿을 통해 우회적으로 계정 관리를
깃은 이미 잘 설명된 글이 많으므로, 여기서는 내게 필요한 부분만 예제와 함께 모아 둔다. commit에 변경사항이 빠진다? git add는 커밋을 위해 스테이징 영역에 파일을 추가한다. 하지만, 추가할 때 파일 이름이 추가되는 것이 아니라, 현재까지의 변경사항이 추가되는 것이다. 그러므로, A 라는 파일을 git add 명령어로 스테이징 영역에 파일을 추가한 후 수정하면, 나중에 수정한 내용은 커밋에 포함되지
Detached HEAD란? 보통 브랜치(branch)는 특정 커밋(commit)의 revision number를 가리키고 HEAD가 이 브랜치를 가리킨다. 이렇게 HEAD -> 브랜치 -> 특정 커밋 순서로 commit을 가리키는 상태를 ‘attached HEAD’ 상태(state)라고 한다. 그리고, Detached HEAD란 HEAD가 브랜치를 통해 간접적으로 commit을 가리키지 않고, 직접 커밋을 가리키는 것을 말한다. 깃에서 HEAD는 1개 뿐이고, 이 HEAD는 현재 체크아웃(checkout)한 커밋을 가리킨다. 추가적인 작업을