[카테고리:] Git

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

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

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

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

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

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

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