3-way merge 알고리즘에 대해

Git에서 두 브랜치를 머지할 때, 기본적으로 3-way merge 알고리즘을 사용하게 된다. 어떤 sequence A, B와 그 둘의 base인 sequence O가 있다고 하자. Git으로 치면 A, B는 머지할 브랜치, O는 base commit이 된다. sequence의 각 item은 소스코드의 한 줄이라고 생각하면 된다. 이렇게 A, O, B가 있을 때, A, O, B에 대해 [Longest common subsequence](이하 LCS) (( … 3-way merge 알고리즘에 대해 계속 읽기

git의 revision에 대해

git에서 revision이란 특정 Git object를 가리킬 수 있는 표현식을 의미한다. HEAD~2, master, a8dd808db6d87a1d809b1a223e08ab69602b2d3a, HEAD:test.txt 등이 모두 "revision"이다. 문법 ABNF 로 표현해보면 대략 다음과 같다. DIGIT = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" sha1 = 1*40HEXDIGIT refname = name / "refs" "/" (name … git의 revision에 대해 계속 읽기

git에서 특정 파일만 남기기 (git 기반 위키에서 특정 파일만 공개하기)

코드저장소에서 실수로 절대 넣어서는 안되는 파일을 넣어 버렸을 때, git의 filter-branch 명령을 사용하면 간단하게 특정 파일만 제외시키고 전체 히스토리를 재구축하는 것이 가능하다. 그러나 반대로 특정 파일만 남기는 것은 조금 까다롭다. filter-branch를 응용해서 남기고자 하는 파일 외에는 모두 삭제하면서 히스토리 전체를 재구축하는 방법이 있긴 한데, 속도도 느리고 잘 동작하게 만들기도 쉽지가 않다. 사실 일반적인 소프트웨어 개발 … git에서 특정 파일만 남기기 (git 기반 위키에서 특정 파일만 공개하기) 계속 읽기

Git의 blob은 어떻게 발음하는가.

Git 메일링 리스트에 문의해 본 결과, 일반명사 blob과 같이 블랍으로 발음하는 것이 맞다고 한다. 사실 이걸 어떻게 발음하는 것이 맞는가에 대해서는 어디에도 명시되어 있지 않다. gitglossary에도 없다. 일반적으로 database에서는 blob이 binary large object라는 의미로 쓰이고, 비랍(bee-lab)으로 발음하지만 Git에서는 그런 의미가 아닌지도 모르겠다. 단 두 명이 답을 주었을 뿐이긴 하지만, 이 메일링 리스트는 Git 개발자와 사용자가 … Git의 blob은 어떻게 발음하는가. 계속 읽기

디스크 공간 절약을 위해 파일을 Git 저장소에 보관하기

SSD를 쓰기 시작하면서 디스크 공간이 굉장히 소중해졌다. 그래서 잘 안 쓰는 파일들은 zip으로 압축해서 저장하곤 하지만 뭔가 파일 하나가 보고 싶을 때는 꺼내기가 좀 불편하다. 대안은 Git bare 저장소로 보관하는 것이다. 이 방법은 공간도 적게 사용하면서 필요할 때 gut 명령으로 간단히 파일을 꺼내 볼 수도 있다. 뿐만 아니라 Git 저장소는 굉장히 공간효율적이다. 때때로 gzip으로 압축했을 … 디스크 공간 절약을 위해 파일을 Git 저장소에 보관하기 계속 읽기

git bisect 응용 – 줄바꿈 문자 잘못 넣은 사람 찾기

나는 언제나 줄바꿈 문자를 '\n'로 통일한다. 내가 참여하는 모든 프로젝트에서도 그러하다. 그러나 윈도 사용자들은 기본적으로 '\r\n'을 사용하도록 되어있으므로, IDE나 편집기에서 혹은 Git에서 설정을 변경해주지 않는 이상 줄바꿈 문자가 '\r\n'이 된다. 이로 인해 다양한 OS를 사용하는 개발자들이 함께 같은 프로젝트에서 개발을 하다보면 내가 작성한 코드에 누군가 '\r\n'을 집어넣어 심란해지는 일이 종종 있다. 누가 집어넣었는지 찾아내고 싶지만 … git bisect 응용 – 줄바꿈 문자 잘못 넣은 사람 찾기 계속 읽기

git으로 버그의 원인 찾기

간만에 공용 저장소에서 커밋들을 pull 해왔을 때, 내 저장소의 코드가 제대로 동작하지 않기 시작하면 정말 난감하기 짝이 없다. 이 때 디버깅이 간단하지 않다면, 천천히 버그의 원인을 찾아보게 된다. 버그의 원인은, 현재 발생하고 있는 버그가 최초로 발생한 커밋에 있을 것이므로 그 커밋을 찾아낼 수 있다면 쉽게 원인도 파악할 수 있을 것이다. bisect로 찾기 bisect --run git … git으로 버그의 원인 찾기 계속 읽기

git으로 특정 기능이 언제 도입되었는지 찾기

답: 커뮤니티에 물어보거나 릴리즈 노트를 검색하면 된다. 하지만 다른 방법을 원한다면 다음을 읽도록 하자. 기술적인 문제에 대한 글을 쓰다 보면, 오픈소스 프로젝트에서 특정 기능이 언제 도입된 것인지 정확하게 알아야 할 때가 있다. 예를 들어, 내가 만든 소프트웨어가 운영 체제의 특정 기능 때문에 동작하지 않게 되었다면, 그 기능이 어떤 버전에 들어있는지 확인해서 고객들에게 그 버전은 사용하지 … git으로 특정 기능이 언제 도입되었는지 찾기 계속 읽기

깔끔하게 커밋하기

흔히 말하길, 좋은 커밋이란 단 한가지 고침만을 담고 있는(atomic한) 커밋이라고 한다. 그러나 코드를 작성하다 보면 여러가지 작업이 섞이는 것을 피하기 어렵다. 리팩토링을 하다가 오타를 발견하면 고치게 되고, 버그를 잡다가 잘못된 들여쓰기를 바로잡기도 한다. atomic한 커밋을 위해 눈 앞에 뻔히 보이는 잘못을 방치하는 것도 이상하지 않은가. 몇몇 (나처럼) 깔끔한 커밋에 집착하는 사람들은 이렇게 여러가지 종류의 수정이 … 깔끔하게 커밋하기 계속 읽기

git pull 할 때 인자 안줘도 알아서 되게 하기

요약 master 브랜치에서 작업중 git pull 명령을 실행했을 때 저장소와 브랜치를 명시하라는 에러를 만나면 .git/config에 다음과 같이 설정하라. [branch "master"] remote = origin merge = refs/heads/master 설명 git pull을 실행했을 때, 어떤 경우엔 군말없이 merge까지 잘 끝내지만, 어떤 경우엔 다음과 같은 메시지를 뱉으면서 실패하기도 한다. You asked me to pull without telling me which branch … git pull 할 때 인자 안줘도 알아서 되게 하기 계속 읽기