Bread's Blog

이런 구닥다리 같은 글이 아직 있다니.. https://github.com/amix/vimrc 이런거 쓰자.  - 2016. 3. 설치할 플러그인  - pathogen.vim (vim 플러그인 path 관리)  - NERDTree (vim에서 파일시스템을 tree 구조로 볼수 있게 해준다.)  - sensible.vim (.vimrc가 누더기가 되는게 싫다면 이걸 설치한다. vim을 사용하면 기본적으로 설정해야 하는것들.)  - AutoComplPop (자동완성) 묻지도 따지지도 말고 실행 ~/.vimrc 를 열고 아래 코드를 붙혀 넣는다.

'Vincent Driessen ' 이라는 사람의 브랜칭 모델 을 기반으로 한 git extension. 설치방법: https://github.com/nvie/gitflow/wiki/Installation Homebrew를 사용한다면 아래처럼 brew install git-flow 간략한 설명 (복잡한 설명은 원문 참조) Vincent Driessen's branching model에는 다섯개의 브랜치를 사용한다. 그 중에서 메인 브랜치는 master 와 develop - master origin/master 브랜치의 HEAD는 항상 production-ready상태이어야 한다. - develop origin/develop 브랜치(integration branch라고도 부름)의 HEAD는 다음 릴리즈 버전을 위한 가장 최근의 변경사항을 반영하고 있어야 한다. 다음 릴리즈를 위한 개발이 완료되었다면 master로 merge된다. 그리고 태그를 붙힌다. master로 merge가 되었다는것은 새로운 릴리즈가 완성되었다는 의미이다. master에 merge하는 이벤트가 발생하면 git hook을 사용해서 곧바로 production 서버로 올릴수도 있다. 이 밖의 추가적인 브랜치 - Feature branches(Topic branches) develop 브랜치로부터 생성되고, develop 브랜치에 merge 되어야 한다. feature branch는 바로 다음 릴리즈에 merge될수도 있고 나중에 merge될수도 있다. feature branch는 origin repo가 아닌 개발자 repo에 있어야 한다. merge 할때는 --no-ff 옵션을 추가한다.(나머지 브랜치 merge도 마찬가지) - Release branches develop 브랜치로부터 생성되고, develop 또는 master 브랜치로 merge 된다. 새로운 production을 위해 준비중인 브랜치라고 보면 된

"Red, Green, Refactor." 0. Think 1. Red : 아주 짧은 코드(5줄 이하)로 이루어진 test를 만든다. 그리고 test는 실패한다. 2. Green : 일단 test를 통과하게 만든다. 디자인, 성능 등에는 신경쓰지 말고, 하드코딩이 들어가도 상관없으니 일단 통과만 하게 한다. 3. Refactor : 이제 가다듬을 차례이다. 중복된 코드를 제거하고, 소프트웨어의 디자인을 개선한다. test는 통과해야 한다. 4. Repeat Red/Green/Refactor 싸이클의 주기는 짧은 속도로 반복되어야 한다.