발생일: 2015.11.06 키워드: git checkout, git double dash, --, git dash dash, 깃 더블 대시, 대시 대시, bash, command flags 문제: 깃에서 특정 파일의 변경을 취소할 때 아래와 같은 커맨드를 실행한다. git checkout -- path/to/file.txt 그러고보니 아무 생각 없이 습관적으로 사용하고 있었는데, 더블 대시가 의미하는 게 뭘까? 해결책: 기본적으로 더블 대시는 배시에서 커맨드 옵션의 끝을 의미하는 용도로 쓰인다. 예를 들어, grep 명령으로 옵션 -v 가 아닌 문자열 -v 를 검색하고 싶다면, 아래와 같이 `--` 로 옵션이 종료되었음을 명시할 수 있다. $ grep -- -v file 문제에서 예로 들었던 깃 커맨드..
발생일: 2015.11.06 키워드: git merge conflict with binary files, git checkout, 바이너리 파일 머지 충돌, 바이너리 머지 깨짐 문제: 바이너리 파일의 머지가 깨진 경우, HEAD나 머지한 브랜치의 것 중 하나를 선택하려고 한다. 해결책: git checkout 커맨드에서 --ours 와 --theirs 옵션을 제공한다. --ours: 현재 브랜치의 것을 선택 --theirs: 다른 브랜치의 것을 선택 $ git checkout --ours -- path/to/file # 현재 브랜치의 것을 선택 $ git checkout --theirs -- path/to/file # 머지한 브랜치의 것을 선택 참고: http://stackoverflow.com/ques..
발생일: 2015.07.06 키워드: github, 깃헙, 깃허브, PR, Pull Request 문제: 우리 프로젝트에서는 모든 피처를 `feature/XXX` 브랜치로 작업하고, 작업이 완료되면 develop에 머지하는 Pull Request 를 올려 리뷰 후 머지하는 프로세스를 갖고 있다. 기존엔 모든 멤버가 리뷰하고 동의해야 PR을 머지하는 방식이었는데, 멤버가 많아지면서부턴 몇몇의 동의로도 머지되곤 한다. 게다가 최근엔 배포 주기가 빨라져서, 놓치는 PR이 더 많아지게 됐다. 이럴 땐 Pull Request 페이지에서, Closed & Merge 된 이슈를 조회하곤 하는데, PR 페이지의 기본 정렬이 생성일 순이어서 매번 업데이트 순으로 변경해 정렬하곤 했다. 나도 모르게 동일한 걸 반복하고 있..
발생일: 2015.04.28 키워드: Git, branch, tag, 깃 태그, git tag 문제: 우리 프로젝트에서는 매 배포마다, 배포 버전을 깃 태그로 할당하고 있다. 배포 도구는 쉘로 만들었고 배포할 때 버전을 입력하면 깃 태그로 추가하도록 해두었는데, 배포할 때 가장 최근 배포 버전 정보가 있으면 더 편리할 것 같다. 모든 브랜치에서 가장 최근의 태그를 가져오고 싶다. 예를 들면, 아래처럼 나오게 말이다. - 배포 버전을 입력하세요 (최근 버전 v2.1.0): 해결책: $ git describe --tags $(git rev-list --tags --max-count=1)
발생일: 2014.12.11 키워드: Travis CI, 깃헙, Git Hook, 깃훅, 깃헙 웹훅, Github Web Hook, Github Pull Request Builder, 젠킨스, Jenkins 문제: 회사에서는 깃헙 엔터프라이즈 버전을 쓰고 있고, (당연한 이야기지만) 우리 프로젝트에서는 작업한 코드가 반영되려면 모든 테스트를 통과해야 한다. 테스트는 주요 브랜치에 커밋이 발생할 때, (예: 피처 브랜치를 디벨롭이나 마스터에 머지하는 경우) 깃헙 웹훅을 받아 빌드 서버에서 수행하고 있다. 초반에는 담당자가 개발 완료 후에 테스트를 돌려보고 확인한 후에 푸시하는 방식이었는데, 종종 테스트를 확인하지 않는 경우가 있어서 주요 브랜치에 머지가 된 후에야 테스트가 깨진 것을 확인할 때가 있었다. ..
발생일: 2014.11.20 키워드: git, rebase 문제: 작업하던 내용을 작은 단위로 쪼개 커밋했다가, 의미있는 단위로 모아서 서버에 푸시하려고 한다. git rebase 로 커밋을 정리할 수 있는 걸로 알고 있고, 여러 번 해보긴 했는데 이건 늘 할 때마다 헷갈린다. 해결책: `git rebase`에 대한 자세한 설명은 아래 참고 문서에서 확인할 수 있다. 여기선 'rebase 인터랙션 도구로 여러 커밋을 한 개의 커밋으로 정리’하는 과정을 기술하는 것으로 설명하려 한다. 1. 먼저, 지금까지의 커밋 로그를 확인한다. $ git log 8fde911 - Sixth commit 9f3e2b8 - Fifth commit 1d02857 - Fourth commit 7ee8f67 - Third com..
발생일: 2014.08.08 키워드: git, 파일명, 대소문자, capitalization 문제: 대부분의 프로젝트는 작업은 맥에서 하지만 운영은 CentOS에서 하고 있다. 작업할 때 가끔 실수로 파일명의 대소문자가 틀릴 때가 있는데, 맥에서는 대소문자를 구분하지 않기 때문에 오류가 나지 않아서 배포 후에야 대소문자를 구분하는 CentOS 환경에서 발견하곤 한다. 맥에선 대소문자를 변경해 커밋해도 같은 파일로 인식하기 때문에, 늘 다른 이름으로 변경했다가 커밋하고, 다시 대소문자를 변경한 후에 커밋하는 방법으로 해결하고 있었다. 번거롭다. 더 간단한 방법은 없을까? 해결책: `git mv`에 `--force` 옵션을 사용하면 한 번에 처리할 수 있다! 예) `git mv --force myfile M..
발생일: 2013.07.24 문제: Git에서 원하는 파일 변경이나 커밋만 가져오려면 어떻게 해야할까? 해결책: 두 가지 방법이 있다. git cherry-pick 커밋 커밋 대상에 내가 원하는 변경만 있다면 - 해당 커밋의 변경만 가져온다. 이전 변경 내용이 있었다면, 이건 적용되지 않는다. 이게 머지툴이 있으면 BASE 파일 (적용하려는 커밋의 바로 조상 커밋)을 가져와서 하는 거라 해결 가능하지만, 이 때는 파일 diff 만으론 처리할 수 없다. - 커밋되지 않게 하려면 -n 옵션을 쓴다. git checkout 커밋 파일명 원하는 파일만 가져오는 거 이건 파일을 덮어써서 바로 stage 상태로 보낸다. 바로 덮어써지는 게 싫으면 --patch 옵션을 쓰면 된다. http://stackoverflo..
발생일: 2013.07.02 문제: `origin`으로 추가한 리모트에 있는 브랜치가 삭제되었을 때,로컬에서도 해당 정보를 업데이트 받아서 리모트에서 삭제한 브랜치가 자동으로 삭제되도록 하고 싶다. 어떻게 하면 될까~? 해결책: 아래 두 명령 중의 하나로 처리할 수 있다. $ git remote prune origin $ git remote update --prune http://stackoverflow.com/questions/3184555/cleaning-up-old-remote-git-branches