발생일: 2012.01.19

문제:
며칠 전 크로미엄 버전을 18.0.1010.1 dev-m 버전으로 업데이트 한 이후로,
잘 작동하던 몇몇 익스텐션이 제대로 작동하지 않는다.

어느 부분에서 오류가 나나 찾아봤더니,
익스텐션에서 document.documentElement 를 찾지 못한다.

뭐가 문젤까?


해결책:
크롬 dev 버전이 18.0.1010.1로 업데이트 되면서 발생한 버그로 추정된다.

검색해보니 같은 문제로 2012.01.11에 버그 리포팅 된 것이 있다.
https://groups.google.com/a/chromium.org/group/chromium-bugs/browse_thread/thread/0e668df511f0b381 

재현을 위해서는,
1. 익스텐션에서 아래와 같이 content script의 실행 시점을 document_start로 설정하고,
  content_scripts: [
    {
      ... (생략) ...
      run_at: "document_start"
    }
  ]


2. 스크립트 내에서 document.documentElement 를 접근하면 undefined가 뜨는 것을 확인할 수 있다.


아직 버그가 해결되지 않은 상태라 일단은,
임시 해결을 위해 스크립트 실행 시점을 기본값인 document_idle 로 변경하면 된다.



저작자 표시 비영리 변경 금지
Posted by ohgyun
발생일: 2012.01.16

문제:
담당하고 있는 서비스에서는 버전 관리 도구로 SVN을 사용하고 있다.
배포는 서버 개발팀에서 담당하고 있는데, 매 배포에 대한 버전 관리는 어떻게 관리하는 지 궁금해서 물어봤더니 각 릴리스에 대한 버전을 브랜치로 따서 관리한다고 한다.
예를 들어, v.1.0을 배포하고자 할 경우, Release Branch의 약어를 써서 RB-1.0 과 같은 이름의 브랜치를 따고, 해당 브랜치를 배포하는 식이다.

요새 Git으로 관리하고 있는 개인 프로젝트에서도 브랜치로 배포 버전을 따면 되겠구나~하고 생각하고 있었는데, 이것저것 알아보다 보니 실제로 브랜치보다는 태그(Tag)를 더 많이 사용하는 모양이다.

태그는 뭐고, Git에선 어떻게 사용하는 걸까?

해결책:

버전 관리 시스템에서 Tag란?
Tag는 특정 스냅샷에 대한 꼬리표(말 그대로 태그)다.
대부분의 버전 관리 도구에서 태그를 지원한다.

사실 지금까지는 습관적으로 trunk만 땡겨와 작업하고 있었는데, 이번 기회에 소스 리파지터리를 자세히 봐봤다.
이제서야 branches 영역과 tags 영역이 구분되어 있고, 개발팀에서는 브랜치를 굉장히 활발하게 활용하고 있다는 걸 알게 됐다.

SVN의 경우, 실제로 브랜치와 태그의 동작에는 차이가 없다고 한다.
두 가지 모두 동일하게 코드를 특정 영역으로 복사하는 것이며, 단지 의미 상의 차이만 있는 것이라 한다.
아마 그래서 서비스에서도 그냥 브랜치로 배포 버전을 관리하는 게 아닐까~~ 추측해본다.


Git에서 Tag 사용하기
Git에서도 태그를 지원하고 있다.

git tag 명령으로 간단하게 이미 만들어져 사용할 수 있는 태그를 조회할 수 있다.
특정 패턴을 가진 태그를 조회하고자 할 때엔 -l 옵션을 사용하면 된다.
예를 들어, git tag -l 'v.1.3.*' 을 실행하면, v.1.3의 태그들만 조회된다.

Git의 태그에는 Ligthweight Tag와 Annotated Tag 두 종류가 있다.
Lightweight Tag는 단순히 특정 커밋을 가리키는 포인터 역할을 하는 반면,
Annotated Tag는 태그를 만든 사람에 대한 정보, 태그 메세지, 서명 등을 추가할 수 있다.

Lightweight Tag는 간단하게 git tag <tagname> 과 같이 만들 수 있다.
예를 들어, git tag v1.3 를 실행하면, 현재 커밋에 v1.3이라는 태그를 붙인다.

Annotated Tag는 태그를 달 때, -a 또는 -s 옵션을 사용하면 된다.
옵션의 자세한 내용은 git tag --help 로 확인~~

적용한 내용의 태그를 조회하고자 할 때엔 git show <tagname> 을 실행~!
이 명령으로 각 태그의 커밋 정보를 조회할 수 있다.


실제로 jquey의 github을 보니 태그를 사용해 릴리스 버전 관리를 하고 있는 걸 볼 수 있었다.
https://github.com/jquery/jquery/tags


Git의 Tag, 잘 사용해보자~~ 


# 참고:
- SVN의 Branching/Tagging: http://wiki.kldp.org/wiki.php/SubversionBook/BranchingAndMerging


저작자 표시 비영리 변경 금지
Posted by ohgyun
발생일: 2012.01.15

문제:
git에서 커밋할 때엔 항상 git add . 명령어로 커밋할 대상을 골라놓은 후,
git commit -m [message] 명령으로 커밋했다.

git add 가 정확히 어떤 것인지 모르고 습관적으로 실행했었는데,
이번에 책을 읽다가 알게된 내용을 메모해둔다.


해결책:

Git 프로젝트의 세 가지 단계
가장 먼저 Git 프로젝트의 세 가지 단계에 대해 이해해야 한다.

Git 프로젝트에는 Git Directory, Working Directory, Stating Area 세 가지 단계가 있다.
Git Directory는 Git이 프로젝트의 모든 정보를 저장하는 곳이다.
Git의 핵심이라 할 수 있고, Git을 새로 구축하거나 다른 저장소에서 Clone할 때 Git Directory가 만들어진다.

Working Directory는 프로젝트의 특정 버전을 Git Directory로부터 체크아웃 상태이다.
Staging Area는 곧 Commit 할 파일에 대한 정보를 저장한다. 단순한 파일이고 실제로 Git Directory 내에 존재한다.

Git으로 하는 일은 기본적으로 다음과 같다.
- Working Directory에서 파일을 수정한다.
- Staging Area에 파일을 Stage 해서 Commit 할 Snapshot을 만든다.
- Staging Area에 있는 파일들을 Commit 해서 Git Directory에 영구적인 Snapshot으로 저장한다.


Working Directory의 파일 상태
작업 디렉토리의 모든 파일은 크게 Tracked와 Untracked로 나뉜다.

Tracked는 Git의 관리 대상 파일임을 의미하고 반대로 Untracked는 관리 대상이 아닌 파일을 의미한다.

Tracked 파일들은 또 Unmodified(또는 Commited)와 Modified, Staged 상태로 나뉜다.
Unmodified는 수정되지 않은 파일을, Modified는 수정된 파일, Staged는 커밋 대상인 파일을 의미한다.

예를 들어, 새로운 파일을 만들고 Staging Area에 추가하지 않았다면 그 파일은 Untracked에 포함된 파일이다.
만약, Git의 관리 대상인 파일(Tracked)을 수정했지만 아직 Staging Area에 추가하지 않았다면, 그 파일은 Modified 이다.
파일을 수정하고 Staging Area에 추가했다면 그 파일은 Staged 가 되고,
Commit 했다면 Commited 또는 Unmodified 가 된다.


Staging Area에 추가하기
작업한 파일을 Git Directory로 커밋하려면 반드시 Stating Area에 추가해야 한다.
git add [file] 명령으로 작업한 파일을 Staging Area에 추가할 수 있다.

습관적으로 작성하고 있었던 git add . 는 변경된 모든 파일(정확하게는 Modified와 Untracked인 파일)을 Staged 로 변경하겠다는 의미였다.

git status 명령을 실행해보면,
각 파일을 상태별로 구분해 리스팅 해 줄 뿐만 아니라, 파일의 상태를 변경할 수 있는 팁도 전해준다.
지금까지는 무심코 지나쳤었는데, 이제 자세히 살펴보자.




저작자 표시 비영리 변경 금지
Posted by ohgyun