블로그 이미지
윤영식
Full Stacker, Application Architecter, KnowHow Dispenser and Bike Rider

Publication

Category

Recent Post

2015. 10. 22. 10:41 AngularJS



본 서적은 자바스크립트와 앵귤러 프레임워크를 프로젝트에 도입해 보려는 개발자 또는 프로토타입을 해보고 싶은 개발자 또는 사용해 본 경험이 있는 개발자를 대상으로 한다. 앵귤러에 대해 처음 공부하는 분에게는 다소 어려울 수 있으므로 기초서적을 권장드린다. 책 제목처럼 3장이후 부터 실전 프로젝트 실습을 위한 상세 소스를 GitHub에서 제공한다. 1~2장은 개념 정리이므로 읽고 나중에 참조하는 장으로 사용한다. 참고로 2장은 실습이 없이 개념을 설명하는 장이기에 소스를 제공하지 않고 있다. (소스의 Git Branch는 장이 끝나는 시점에 언급하고 있다. 먼저 전체 소스를 보고 싶다면 GitHub 내용을 참조하자)








출판의 여정 


8개월의 원고작성, 3개월의 편집기간을 거쳐 드디어 책이 출간되었다. 책을 통해 개발자들과 공유하자는 의기투합은 2013년 겨울로 거슬러 올라간다. 이강훈님을 통해 알게된 이규원님, 김충섭님, 김대권님, 박유진님, 구교준님과 함께 MEAN 스택을 기획했었다. 그 당시 미국에 있었던 지라 구글 행아웃을 통해 주말마다 화상미팅을 하며 깃헙과 페이스북을 통해 서로의 의견과 결과물을 공유했다. 2014년 봄 귀국후 함께 오프라인에서 헤커톤도 하면서 책의 샘플을 만들며 진행했지만 각자의 일정으로 인해 MEAN 스택 집필을 흐지부지 되어갔다. 2014년 7월쯤 결단을 내리고 이렇게 진행하면 끝나지 않겠다 싶어서 다음 기회를 기약하였고, 홀로 책을 쓰기로 결심했다. 


2014년 8월 이강훈님 회사인 스터디지피에서(https://bagle.io)의 서비스를 개발하면서 미국 플젝에서 얻은 AngularJS 경험과 개념정리가 덜 된 부분을 하나하나 집어가며 집필을 시작했다. 처음에는 한 페이지를 나가는데 하루의 시간이 걸리더니 조금씩 속도가 붙으면서 한달만에 100p 가량을 썼다. 하지만 다시 가을 미국 프로젝트로 2달간 집필 중단 후 한국에 돌아와 마음을 다잡고 12년전 내 책을 출판해 보자는 꿈을 다시한번 상기했다. 위키북스의 박찬규 대표님도 은근히 압력을 넣어주시며 언제쯤 나올까요 물어볼때마다 곧 나올겁니다 대답하곤 하루 1~2시간씩 짬을 내어 집필을 계속했다. 2015년 3월 집필을 완료하고 출판사에 전달했지만 피드백으로 날아온 것은 맞춤법과 문장 난해함에 대한 엄청난 지적질의 빨간줄이었다. 


한달간 주말마다 빨간 선생님과 싸움하며 "그래 글쓰는 것도 배우는 거다"라고 생각하고 나의 국어실력을 한탄하며 글을 풀어서 이야기식으로 고쳐나갔다. 사실 블로그를 쓰다보니 블릿(점, 점으로 요약한 내용)으로 내용을 요약해 표현하다 보니 책도 그렇게 썼드랬다. 블릿 내용을 다 풀어쓰는 것만도 한달. 다시 피드백받아 또 고치고 피드백받아 또 고치고, "아 무한루프의 피드백". 점점 스트레스와 화가 살짝 났다. 인생 목표 10가지중 1가지가 1년에 책한권씩 내자였던 것이 여지없이 깨지는 순간이었다. 이렇게 하다가는 2년에 한권내는 것도 힘들겠다 싶었다. 하지만 일에는 끝이 있는 법. 5월초 거의 마무리 피드백을 보내고, 책 추천사를 받고 인덱스를 보내고, 몇가지 피드백을 마무리하며 3개월의 수정작업은 6월 5일 마무리되었고, 예약 판매가 모든 온라인 서점에서 시작되었다. 그렇게 나온 것이 "실전 프로젝트로 배우는 AngularJS" 이다. 


본 서적은 AngularJS가 하도 유행이라 하여 한번쯤은 기초서적을 구매하거나 빌려서 본적이 있고, 온라인 튜토리얼을 통해 프로토타입핑을 해보았지만 당췌 AngularJS로 서비스를 어떻게 만들어야 할지 모르는 개발자를 위한 책이다. "나도 내가 원하는 서비스 뚝딱 만들어 보고 싶어 근데 어떻게 시작해야는 거야?"라고 생각하는 모든 개발자를 위한 책이다. AngularJS는 생태계를 가지고 있고 인식의 전환을 해야하는 새로운 용어들이 존재한다. 


처음 1장에서는 간단한 ToDo 서비스를 만들면서 주변의 생태계 도구와 개념을 이해하고 2장에서는 AngularJS의 장점들과 그중에 지시자(Directive)에 대해 좀 더 심도있게 설명을 했다. 3장, 4장에서 서비스를 바로 만들 줄 알았다면 오산이다. 이제 서비스를 만들 준비운동단계이다. 먼저 요건정의를 하고 이에 맞는 코딩 컨벤션 부터 AngularJS를 이용한 SPA 개발시 준비할 것들을 프론트앤드 아키텍처로 접근해 보았다. 5장에서 이제 좀 개발들어가려 했더니 그래도 요즘 많이 사용하는 NodeJS, MongoDB는 알고가자는 취지에서 개념과 실습코드를 넣었다. 1장~5장이 준비운동과 스타트 단계였다면 6장, 7장은 엄청난 스피도로 골인점을 향해가는 단계이다. 올초 2개월간 TossLab의 JANDI(http://www.jandi.com)에서 AngularJS에 대한 컨설팅 경험을 적용한 장이다. 





목차


▣ 01장: 단일 페이지 애플리케이션 개발 준비
1-1. 개발 도구 설치 
   - 깃 설치 
   - 노드 설치 
   - 요맨 설치 
   - 서브라임 텍스트 편집기 설치 

1-2. 단일 페이지 애플리케이션 생성 
   - yo generator 선택과 설치 
   - Yo를 이용한 ToDo 애플리케이션 생성 
1-3. 애플리케이션 컴포넌트 생성 
   - 앵귤러를 위한 index.html 설정 이해하기 
   - yo를 이용한 앵귤러 컨트롤러 추가 
   - bower를 이용한 앵귤러 지시자 추가 
1-4. 애플리케이션 테스트 및 빌드 
   - grunt를 이용한 테스트 
   - grunt를 이용한 배포 
정리 

▣ 02장: AngularJS 프레임워크 이해
2-1. MV* 프레임워크 
2-2. 양방향 데이터 바인딩 
   - 스코프 내부와 상속 관계  
   - MyToDo 애플리케이션에서 양방향 데이터 바인딩 
   - 스코프 생명 주기(Life Cycle) 
   - 그 외 $scope 객체 메서드 
2-3. 의존성 주입(DI, Dependency Injection) 
2-4. 클라이언트 템플릿 
2-5. 지시자(Directive) 
   - 지시자가 DOM에 적용되는 순서 
   - 지시자 정의 
   - 지시자의 스코프 객체의 범위 종류 
   - Template, TemplateUrl, TemplateCache, replace와 ng-template 사용 
   - compile, link의 $watch 등록을 이용한 양방향 데이터 바인딩 
   - controller, require와 link 네 번째 파라미터와의 관계 
   - transclude, ng-transclude 사용 
2-6. 테스트 프레임워크(단위, E2E) 
   - 카르마 기반 단위 테스트 
   - 프로트랙터 기반 E2E 테스트 
정리 

▣ 03장: 싱글 페이지 애플리케이션 기획및 생성
3-1. 애플리케이션 기획
   - 메인 페이지 
   - 그룹 정보 페이지 
   - 그룹 활동 페이지 
   - 설문 생성 페이지 
3-2. 애플리케이션 제너레이터 설계 
   - 애플리케이션의 폴더 구조 전략 
   - 애플리케이션 제너레이터 선정 
   - 앵귤러 코드 스타일 전략 
   - 스타일 가이드에 따른 제너레이터 템플릿 수정 방법 
   - IE8 지원을 위한 index.html 설정 
3-3. SPA 생성 
   - 애플리케이션의 모듈 구성 
   - 라우팅 설정 방식 
3-4. 단위 업무를 위한 앵귤러 컴포넌트 조합 
   - $resource를 통한 REST 모델 사용 
   - promise와 $q Async 호출에 대한 이해 
정리

▣ 04장: 애플리케이션을 위한 공통 프레임워크 개발
4-1. 공통 프레임워크 모듈 개발 
   - 다국어 처리 
   - 메시지 처리 
   - 팝업 메시지창 지시자 
   - HTTP 에러 처리 
   - 사용자 정의 Bower 컴포넌트 등록 
   - 로컬 저장소 서비스 
   - 유틸리티 지시자 
4-2. 로그인 화면 개발 
   - 트위터 부트스트랩 기반의 화면 디자인 및 폰트 사용 
   - 폼 유효성(Form Validation) 검사 
   - 인증을 위한 토큰과 쿠키 
4-3. OAuth를 이용한 인증 처리 
   - 백엔드에서 Passport 모듈을 이용한 인증 처리 
   - 페이스북 인증 처리 
   - 크롬 브라우저 개발자 도구를 이용한 클라이언트 디버깅 
   - 노드 인스팩터를 이용한 서버 디버깅 
정리

▣ 05장: 메인 페이지 개발
5-1. 백엔드 API 개발 
   - REST API 별 서버 모듈 조합 
   - 노드 모듈의 exports 이해 
   - 몽고디비와 몽구스 이해 
   - 서버 모델 개발 
   - 그룹 REST API 개발 
   - 포스트맨을 이용한 REST API 검증 
   - 백엔드 단위 테스트 수행 
5-2. 메인 화면 개발 
   - 공통 컴포넌트 재구성 
   - 메인 화면 레이아웃 개발 
   - 그룹 생성 
5-3. 그룹 목록 및 정보 표현 
정리 

▣ 06장: 그룹 페이지 개발
6-1. 그룹 정보 페이지 
   - 그룹 상세 정보 조회 
   - 그룹 프로필 이미지 변경 
   - 그룹 가입, 탈퇴 
6-2. 그룹 활동 페이지 
   - 그룹 활동 화면 레이아웃 개발 
   - 그룹 멤버 목록 표현 
6-3. 설문 카드 생성 
   - 설문 카드 생성 
   - 카드 지시자 개발 
6-4. 설문 종류별 카드 표현 
6-5. 설문 응답 및 결과 표현 
정리

▣ 07장: 실시간 반응 개발
7-1. Socket.IO 기반 실시간 연동 
   - 노드 기반 백엔드 Socket.IO 
   - AngularJS 기반 프런트엔드 Socket.IO 
   - 상단 알림 메뉴 추가 
7-2. 카드 목록 UX 개선 
   - 카드에 동영상 추가 
   - 무한 스크롤 적용 
   - 애니메이션 효과 적용 
7-3. AngularJS 성능 옵션 
   - 일회 바인딩 
   - ngModelOptions 지시자 
   - 디버깅 정보 비활성화 
   - $applyAsync 적용 

정리




구매


예스24 온라인 서점


알라딘 온라인 서점


인터파크 온라인 서점


교보문고 온라인 서점


G마켓 온라인 서점


현재는 예약 판매로 10% 싸게 구매 할 수 있다. 6월 17~19일간 배송을 시작한다. 당초 높은 가격이 책정되었지만 위키북스 대표님에게 가격이 높아 개발자에게 부담이 될 것 같다하였더니 파격적인(?) 가격에 판매를 시작해 주셨다. 지금까지 독자로 책을 사보면서 철자하나 틀리면 왠지 기분이 나쁘고 지적을 해주고 싶었는데 이제부터는 너그러이 용서해 줄것 같다. 정말 많은 공력과 시간이 투여되는 시간이었다. 하지만 새로운 경험을 하게 되었고 이렇게 해서 책 한권 한권이 출판된다는 생각을 하니 한권의 책을 사도 감사히 볼 마음가짐이 생긴다.  


이번달 중으로 출판사의 양해를 얻어 1장과 2장은 블로그에 공개하려 한다. 2장은 AngularJS v1.* 이 계속 사용되는 한 유용한 레퍼런스가 되리라 생각한다. 이렇게 생애 첫 책 출판을 자축하며... 내년에는 "Data Visualization using D3.js" 이고, 여기에 ReactJS 또는 AngularJS v2.* 와 Meteor를 접목한 경험을 출판할 계획이다. 글쓰기도 가끔은 중독이다. 자전거 처럼 잘 타지는 못하지만 타고 있는 동안은 자유다. 나를 표현하고 느낄 수 있는 시간이랄까~~~




소스 


책의 소스는 모두 깃헙에 있습니다. 책 챕터마도 브랜치에 대한 정보가 담겨 있습니다. 


책 소스를 위한 깃헙 그룹 : https://github.com/AngularJS-SPA-Development



posted by 윤영식
2013. 10. 28. 17:57 My Services/PlayHub

PlayHub는 Git Submodule을 사용하여 Main 밑으로 Frontend/Backend로 서브모듈단위로 나눌 것이다. 또한 아키텍쳐에 메세지 버스를 사용하므로 여러가지 모듈 분리가 필요할 것으로 예상된다 




아키텍쳐 

  - 구성 

    + 모바일 웹앱 : SPA(Single Page Application)으로 구성한다. AngularJS + BootFlat 사용예정 

    + 조회&푸쉬 서버 : Node.js를 이용하여 OAuth 로그인을 처리한다. Socket.io를 이용하여 Push를 한다 

    + 메세지 버스 : Redis를 사용하여 "조회&푸쉬 서버"와 "이슈정보 서버" 사이를 느슨하게 연결한다. PubSub 방식을 사용한다 

    + 이슈정보 서버 : Open API를 사용하여 Google Doc, DropBox, Trello, GitHub의 정보를 주기적으로 수집한다 

    + 스토어 서버 :  MongoDB 또는 MySql을 사용한다 

  - 장단점

    + 장점 : Backend의 Scale-out이 가능하고 다양한 언어를 통한 구현 및 Node.js를 통한 손쉬운 Push 구현이 가능하다 

    + 단점 : 관리 포인트가 늘어난다. 



Git 서브모듈 만들기 

  - git submodule <command> 를 사용한다 

  - 생성 순서 

    + GitHub에 Main 저장소를 만든다 

    + GitHub에 Submodule이 될 저장소를 만든다 

    + git clone <Main저장소 주소> playhub & cd playhub

    + git submodule add <Submodule 저장소 주소> <이름지정>

    + GitHub으로 git push 수행하기 

$ git clone https://github.com/ysyun/myplayhub.git

Cloning into 'myplayhub'...

remote: Counting objects: 3, done.

remote: Total 3 (delta 0), reused 0 (delta 0)

Unpacking objects: 100% (3/3), done.


$ cd myplayhub/

$ git submodule add https://github.com/ysyun/myplayhub-spa-webapp.git webapp

Cloning into 'webapp'...

remote: Counting objects: 3, done.

remote: Compressing objects: 100% (2/2), done.

remote: Total 3 (delta 0), reused 0 (delta 0)

Unpacking objects: 100% (3/3), done.

warning: LF will be replaced by CRLF in .gitmodules.

The file will have its original line endings in your working directory.


$ git status

# On branch master

# Changes to be committed:

#   (use "git reset HEAD <file>..." to unstage)

#

# new file:   .gitmodules

# new file:   webapp

#

$ git branch

* master


$ git commit -a -m "add submodule webapp"

[master 2fdaa1b] add submodule webapp

warning: LF will be replaced by CRLF in .gitmodules.

The file will have its original line endings in your working directory.

 2 files changed, 4 insertions(+)

 create mode 100644 .gitmodules

 create mode 160000 webapp


$ cat .gitmodules

[submodule "webapp"]

path = webapp

url = https://github.com/ysyun/myplayhub-spa-webapp.git


$ git push

Counting objects: 4, done.

Delta compression using up to 4 threads.

Compressing objects: 100% (3/3), done.

Writing objects: 100% (3/3), 404 bytes | 0 bytes/s, done.

Total 3 (delta 0), reused 0 (delta 0)

To https://github.com/ysyun/myplayhub.git

   0871412..2fdaa1b  master -> master



  - 전체 소스 받아오기 

    + git clone 으로 Main 저장소 받아오기 

    + git submodule init 명령으로 submodule 등록

    + git submodule update로 서브모듈에 대한 clone 작업 수행 

$ git clone https://github.com/ysyun/myplayhub.git

Cloning into 'myplayhub'...

remote: Counting objects: 6, done.

remote: Compressing objects: 100% (4/4), done.

remote: Total 6 (delta 0), reused 3 (delta 0)

Unpacking objects: 100% (6/6), done.


$ cd myplayhub/

$ git status

# On branch master

nothing to commit, working directory clean


$ git submodule init

Submodule 'webapp' (https://github.com/ysyun/myplayhub-spa-webapp.git) registered for path 'webapp'


$ git submodule update

Cloning into 'webapp'...

remote: Counting objects: 3, done.

remote: Compressing objects: 100% (2/2), done.

remote: Total 3 (delta 0), reused 0 (delta 0)

Unpacking objects: 100% (3/3), done.

Submodule path 'webapp': checked out '1bfbcac347a7d6ce4620900b8dad991a638f2763'


$ cd webapp/


~/myplayhub/webapp on  (detached from 1bfbcac)

$ ls

README.md

$ git status

# HEAD detached at 1bfbcac

nothing to commit, working directory clean


// 서브모듈이 현재 존재하지 않는 브랜치가 되었다

~/myplayhub/webapp on  (detached from 1bfbcac)

$ git branch

* (detached from 1bfbcac)

  master


// 해결을 위하여 branch swith를 해야하는데 "git checkout master"를 하면 된다 

$ git checkout master

Switched to branch 'master'


// 해결이 되었다 

~/myplayhub/webapp on  master

$ git branch

* master


// 이후 업데이트 할 내역이 있으면 

$ git pull 


  - 서브모듈 삭제

    + git submodule rm <submodule 디렉토리> 명령 없어졌음 

    + git rm <submodule 디렉토리> 명령으로 제거

    + .gitmodules 의 submodule관련 설정 3줄 제거 

$ git rm webapp

rm 'webapp'


$ vi .gitmodules

webapp submodule 삭제 


$ git status

# On branch master

# Changes to be committed:

#   (use "git reset HEAD <file>..." to unstage)

#

# deleted:    webapp

#

# Changes not staged for commit:

#   (use "git add <file>..." to update what will be committed)

#   (use "git checkout -- <file>..." to discard changes in working directory)

#

# modified:   .gitmodules


$ git commit -a -m "delete webapp submodule"

[master 8305c3c] delete webapp submodule

 2 files changed, 4 deletions(-)

 delete mode 160000 webapp


$ git status

# On branch master

# Your branch is ahead of 'origin/master' by 1 commit.

#   (use "git push" to publish your local commits)

#

nothing to commit, working directory clean


$ git push




Git 브랜치 전략

  - 브랜치 전략에 대하여 숙지한다

  - master 브랜치에 어느 정도 환경설정이 끝났다면 협업을 위하여 develop 브랜치를 만든다. 

    + master와 develop은 절대 삭제되지 않고 계속 유지 되는 브랜치로 둔다 

  - 기능을 구현하기 시작하면 develop브랜치에서 feature 브랜치를 만든다 

    + Story 단위로 만들어서 관리한다 

    + master에서 따오지 않고 develop에서 브랜치하고, remote origin에 push하지 않는다 

    + 필요없을시 삭제한다 

  - develop 브랜치에서 어느 정도 되었다 싶으면 release 브랜치를 만든다

    + release 번호를 달고 수정이 필요한 부분을 보완하고 tag를 단다 

    + master로 merge를 한다 

  - master에 문제가 발견되었을 때 hotfix 브랜치를 만든다 

    + hotfix는 develop과 master 양쪽에 반영을 한다 


   Master + Develop 브랜치 : 영원한 브랜치 

   Feature + Release + Hotfix 브랜치 : 보조 브랜치 (삭제가능)



<참조>

  - Git 서브모듈 명령어 설명

  - Git Submodule 관리 팁

  - GitHub SSH 만들기 

posted by 윤영식
2013. 4. 23. 22:08 Git, GitHub

Dogfeet 이분이 Git 전문가라는 생각이 든다. 번역본도 충실하며 끊임없이 노력하는 모습이 마음에 든다. 본받고 싶은분~~~



Git의 성공적인 Branching 전략

  - 성공적인 브랜칭 전략 한글 번역본 읽자

  - 일하는 flow (Workflow) 형태를 이해하고 싶다면 정리한  보자 (Pro Git 한글 번역본중 일부를 정리한 것임)



GitFlow 설치하여 Branching 전략에 맞는 Branch 생성하여 작업하기 

  - 설치 : 다양한 OS 설치 가이드

< 1단계 > 

$ git clone --recursive git://github.com/nvie/gitflow.git

$ sudo make install  (mac 경우 /usr/local/bin 에 설치된다)


 만일 /opt/local/bin에 설치를 원하면 하기와 같이 수행

$ sudo make prefix=/opt/local install


< 2단계 >

$ sudo chmod 755 /usr/local/bin/gitflow* (git-flow*)  

  또는 /opt/local/bin에 설치되었다면 

$ sudo chmod 755 /opt/local/bin/gitflow* (git-flow*)  


< 3단계 > 

/bin/sh^M 오류시 dos2unix 수행 (명령어 없으면 설치)

$ dos2unix /usr/local/bin/gitflow* 


  - 사용법 : 설명 원문

< 1단계 > 

최초 git flow 방식의 branch 전략을 사용할 계획인 git repository로 이동하여 한번만 셋업하기 


$ git flow init

No branches exist yet. Base branches must be created now.

Branch name for production releases: [master]

Branch name for "next release" development: [develop]


How to name your supporting branch prefixes?

Feature branches? [feature/]

Release branches? [release/]

Hotfix branches? [hotfix/]

Support branches? [support/]

Version tag prefix? []   <= 요건 주지 말자. 주게되면 git tag 시에 명칭의 앞에 항상 따라 붙는다. 


< 2단계 > 

feature 디렉토리 밑으로 login 브랜치 생성 

$ git flow feature start login


login commit 하고 develop 브랜치에 merge 하고 login 브랜치 삭제하고 develop 브랜치로 돌아옴 

$ git flow feature finish login


release v0.1.0 브랜치 생성 

$ git flow release start v0.1.0


release v0.1.0 브랜치를 태깅하고 master를 develop에 merge 해준다. 따라서 git checkout develop으로 이동해서 작업가능하다 

$ git flow release finish v0.1.0

  

  - 그래픽컬한 설명 (강추)



그림 보면서 Git 이해하기

  - 비쥬얼 Git 레퍼런스 한글 : 자주 사용하는 명령을 그림과 함께 설명

  - 왜 Git을 사용하는가? : 이제 Git으로 소스, 문서작업을 하자 



Dogfeet 님의 블로그 포스팅 참조

  - http://dogfeet.github.io/ : Git 과 GitHub 그리고 JavaScript, Node.js 에 대한 다양한 주제를 다루고 있다





<참조>

  - GitFlow 적용하기 

posted by 윤영식
2013. 4. 1. 19:41 Git, GitHub/GitHub

낚시성 제목이지만 한번쯤 링크를 걸어 놓고 궁금한 사항 발생시 첫번째로 확인해 볼 레퍼런스 사이트를 정리해 본다 



Git 메뉴얼

  - git-scm.com 의 한글 번역 메뉴얼

 




명령어 레퍼런스

  - gitref.org : 명령어에 대한 예와 다이어그램이 잘 나와있음






Merge 와 Diff Tool 바꾸기 

  - git의 기본적인 merge, diff 툴을 좀 더 괜찮은 넘으로 바꾸어 사용하기

  - p4merge 툴로 바꾸기 : 다운로드 받아서 설치한다

  - extMerge 파일 생성

/Users/nulpulum> cd /usr/local/bin

/usr/local/bin> cat extMerge

#!/bin/sh

/Applications/p4merge.app/Contents/MacOS/p4merge $*


  - extDiff 파일 생성

/usr/local/bin> cat extDiff

#!/bin/sh

[ $# -eq 7 ] && /usr/local/bin/extMerge "$2" "$5"


  - 환경설정 명령 : git config --global <옵션>

// 옵션들 

merge.tool=extMerge

mergetool.extMerge.cmd=extMerge "$BASE" "$LOCAL" "$REMOTE" "$MERGED"

mergetool.extMerge.trustexitcode=false

diff.external=extDiff


  - ~/.gitconfig 내역 변경

[merge]

tool = extMerge

[mergetool "extMerge"]

cmd = extMerge \"$BASE\" \"$LOCAL\" \"$REMOTE\" \"$MERGED\"

[mergetool] <-- 제거

trustExitCode = false

[diff]

external = extDiff


  - 사용법은 p4merge 툴로 바꾸기 참조하시라





기초 문법 다시 보자 





Git 원리 이해하기 


posted by 윤영식
2013. 2. 28. 11:29 Git, GitHub/Git Lec02

rebase를(참조) 통하여 다른 브랜치의 전체 commit 내역을 복사해오지 않고 특정 commit 내역만을 가져오고 싶을 경우 cherry-pick을 사용한다


1) 언제 사용

  - 토픽이나 패치 브랜치에서 개발된 특정 commit만을 가져오고 싶을 경우 

  - 즉, 하나의 commit만 rebase 하는 것이다 



2) 실습

  - cherry-pick을 하기전 상태

  

  [5.26 master브랜치와 별도의 토픽브랜치 ruby_client로 두개의 커밋이 존재]


/////////////////////////////////////////

// ruby_cleint별도 브랜치 만들어진 이후

// master 브랜치 커밋내역

git log --pretty=oneline -since="2 hours"

fatal: unrecognized argument: -since=2 hours

[nulpulum:~/git-repositories/pro_git]git log --pretty=oneline --since="2 hours"

514281f305bd001776ca41efebccf8276a6bfd98 modify dowon.js


/////////////////////////////////////////

// ruby_client 브랜치로 이동

$ git checkout ruby_client

Switched to branch 'ruby_client'

$ git log --pretty=oneline --since="2 hours"

0f79ccda8c4086d57a4b9ed53c87ecaf11e52ba5 modify topci.txt

40396ae5ab8a964704e0ab84809bb499f9c996b2 add topic.txt


  - check-pick 수행하기 

    + 그림에서 e43a6에 해당하는 "40396"에 대해서 master 브랜치에서 check-pick 한다

/////////////////////////////////////////

// master 브랜치로 토픽브랜치의 특정

// commit 내역만을 rebase = cherry-pick

$ git checkout master

Switched to branch 'master'

Your branch is ahead of 'origin/master' by 1 commit.

  (use "git push" to publish your local commits)

[nulpulum:~/git-repositories/pro_git]git branch

* master

  ruby_client


$ git cherry-pick 40396ae5ab8a964704e0ab84809bb499f9c996b2

[master 4963fef] add topic.txt

 1 file changed, 1 insertion(+)

 create mode 100644 topic.txt


/////////////////////////////////////////

// ruby_client의 커밋이 master 브랜치로 

// 새로운 commit을 제일 앞에 놓았다 

$ git log --pretty=oneline --since="2 hours"

4963fef54f1d6760ec4e5ff15c9684e0f5e6ad4e add topic.txt

514281f305bd001776ca41efebccf8276a6bfd98 modify dowon.js

[nulpulum:~/git-repositories/pro_git]git branch

* master

  ruby_client


  

  [5.27 e43a6 커밋내역 하나만 master의 제일 앞으로 새로운 commit이 생성]



<참조>

  - Pro Git : p127

posted by 윤영식
2012. 12. 21. 11:31 Git, GitHub/Git Lec01

Git 내부 저장소를 최적화 해주는 작업과 zip/tar로 묶는 방법에 대해 알아보자 


  • git gc : 저장소의 크기 압축 및 최적화 (지저분한 내용을 정리)
  • git gc --aggressive : 변경 사항 델타(delta)단위로 저장한다. 저장단위를 처음부터 최적화 한다 
$ git gc
Counting objects: 201, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (123/123), done.
Writing objects: 100% (201/201), done.
Total 201 (delta 57), reused 193 (delta 54)

$ git gc --aggressive
Counting objects: 201, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (177/177), done.
Writing objects: 100% (201/201), done.
Total 201 (delta 61), reused 140 (delta 0)



  • git archive --format=zip --prefix=aa/ HEAD > bb.zip : zip 포멧으로 aa/ 디렉토리 밑으로 모든 파일을 넣어서 HEAD에서 압축 생성하여 bb.zip파일을 만든다 
  • git archive --format=tar --prefix=aa/ HEAD | gzip > bb.tar.gz : 상동. 단, gz에 대하여 gzip 압축 추가 함 
// zip 압축하기 
$ git archive --format=zip --prefix=mqtt_java_client/ HEAD > mqtt_java.zip

// 확인
$ ls
README.md                   jmqtt_client-1.0.jar  mqtt_java.zip  src
eclipse_feature.properties  license.properties    pom.xml

// tar 압축하기 
$ git archive --format=tar --prefix=mqtt_java_client/ HEAD > mqtt_java.tar.gz

$ ls
README.md                   jmqtt_client-1.0.jar  mqtt_java.tar.gz  src
eclipse_feature.properties  license.properties    pom.xml


* 참조 : Git 선화

'Git, GitHub > Git Lec01' 카테고리의 다른 글

[Git] Release 브랜치 다루기  (0) 2012.12.20
[Git] tag 다루기  (0) 2012.12.20
[Git] Remote 저장소 연결 및 관리  (0) 2012.12.17
[Git] History 이용 및 관리하기  (0) 2012.12.13
[Git] Merge 종류와 충돌 해결하기  (0) 2012.12.12
posted by 윤영식
2012. 12. 20. 16:42 Git, GitHub/Git Lec01

git은 브랜치로 코드를 다룬다. 릴리즈 브랜치는 릴리즈할 코드를 분리할 목적에서 사용한다.


  • 구현하기로 한 기능 구현이 끝나면 릴리즈할 코드를 분리할 목적으로 브랜치를 생성한다. (완전히 검토된 상태는 아님)
  • 최소한의 변경은 발생하며, 버그나 로직 수정에만 집중한다 (기능추가 없음)
  • 이름은 RB_ 로 접두어를 붙이면 좋다
  • 릴리즈 브랜치는 마지막 테스트까지만 존재한다
  • 릴리즈 준비가 끝나면 태그(Tag)를 붙이고 해당 브랜치를 삭제한다 
  • 해당 릴리즈의 수정은 태그에서 브랜칭하여 수정 처리한다 

// 현재 태그 
$ git tag
1.0

// 태그에서 새로운 릴리즈 브랜치 만들기 (특정 브랜치에서 수정을 하고자 할 때)
$ git branch RB_1.0.1 1.0

// 브랜치 이동
$ git checkout RB_1.0.1
Switched to branch 'RB_1.0.1'

// 현재 브랜치 명
$ git branch
* RB_1.0.1
  another-from-1.0
  from-1.0
  master

// RB_1.0.1 수정이 완료되면 RB_1.0.1 에 대한 tag 1.0.1 을 만듦 
$ git tag 1.0.1

// 태그 목록 보기 
$ git tag
1.0
1.0.1

// 생성했던 브랜치는 삭제하고 태그 1.0.1 만 남김 
$ git checkout master
Switched to branch 'master'

$ git branch -D RB_1.0.1
Deleted branch RB_1.0.1 (was f5844d4).

$ git branch
  another-from-1.0
  from-1.0
* master


* 참조 : Git 선화

posted by 윤영식
2012. 12. 20. 16:01 Git, GitHub/Git Lec01

Git의 tag는 코드의 책깔피와 같아서 릴리즈된 코드에 tag를 달아두면 언제나 해당 태그로 이동할 수 있다. 즉, Freezing Code Release 정도로 보면 되겠다. Tag 는 브랜치처럼 다루어 지지만 읽기만 가능하다. 따라서 변경을 하고 태그로 부터 별도 브랜치를 생성하여 진행하면 된다. 


// 현재 상태 

$ git branch

* master


// 태그 생성

$ git tag 1.0


// 태그 목록 

$ git tag

1.0


// 태그로 이동 : 태그로 이동하면 마치 주인없는 땅으로 이동한 것과 같다 

$ git checkout 1.0

Note: checking out '1.0'.


You are in 'detached HEAD' state. You can look around, make experimental

changes and commit them, and you can discard any commits you make in this

state without impacting any branches by performing another checkout.


If you want to create a new branch to retain commits you create, you may

do so (now or later) by using -b with the checkout command again. Example:


  git checkout -b new_branch_name


HEAD is now at f5844d4... add license.properties


// no branch라고 나온다 

$ git branch

* (no branch)

  master


// 태그에서 별도의 브랜치를 생성하여 write 작업을 할 수 있다 

$ git checkout -b from-1.0

Switched to a new branch 'from-1.0'


// 전체 브랜치 목록

$ git branch

* from-1.0

  master


// 태그 1.0 에서 또 다른 브랜치 생성

$ git checkout -b another-from-1.0 1.0

Switched to a new branch 'another-from-1.0'


// 전체 브랜치 목록

$ git branch

* another-from-1.0

  from-1.0

  master


릴리즈 버전에 대하여 코드 freezing 시에 사용하자 

posted by 윤영식
2012. 12. 17. 11:12 Git, GitHub/Git Lec01

Git은 분산 버전 관리 시스템이므로 원격의 공유 저장소가 있다. Private 하게 원격 저장소를 구축할 수도 있고, 요즘은 GitHub을 SaaS 형태로 사용하면 된다. GitHub에선 Public과 Private이 있는데, Public 은 공짜, Private은 subscription 모델로 월단위로 과금을 한다. 



▶ remote 저장소 주소들 (GitHub기준)

  • SSH (Secure Shell) : git@github.com:<아이디>/<프로젝트>.git   (주로 write 권한을 주고자 할 때 사용 - push)
    예) git@github.com:ysyun/jmqtt_client.git
  • GIT 프로토콜 :  git://github.com/<아이디>/<프로젝트>.git  (주로 read 권한을 주고자 할 때 사용. 9418포트 사용 - pull)
    예) git://github.com/ysyun/jmqtt_client.git
  • HTTP, HTTPS : https://github.com/<아이디>/<프로젝트>.git  (속도 제일 느리지만 방화벽 오픈 필요없음)
    예) https://github.com/ysyun/jmqtt_client.git



▶ remote 저장소에 대한 별칭 관리

  • git remote add <별칭> <원격지 주소> : 예) git remote add origin https://github.com/ysyun/jmqtt_client.git
  • origin : 원격 저장소를 가르키는 일반적인 별칭으로 사용한다. 
  • git remote -v : 별칭한 내역을 볼 수 있다
  • git branch -r : 별칭에 대한 remote repository의 branch를 볼 수 있다 
  • git remote rm <별칭> : 별칭을 제거한다 
$ git clone https://github.com/ysyun/jmqtt_client.git
Cloning into 'jmqtt_client'...
remote: Counting objects: 195, done.
remote: Compressing objects: 100% (140/140), done.
Rremote: Total 195 (delta 54), reused 161 (delta 32)eceiving objects:  65% (127/
Receiving object
Receiving objects: 100% (195/195), 238.32 KiB | 184 KiB/s, done.
Resolving deltas: 100% (54/54), done.

$ cd jmqtt_client/

$ git branch
* master

$ git branch -r
  origin/HEAD -> origin/master
  origin/master

$ git remote -v
origin  https://github.com/ysyun/jmqtt_client.git (fetch)
origin  https://github.com/ysyun/jmqtt_client.git (push)



▶ remote 저장소 Pulling 
  • github의 경우는 머전 github에서 프로젝트의 remote repository를 생성한다
  • git clone <remote address>를 통하여 local PC의 local repository로 복제를 한다 (위 예제 참조)
  • git fetch <remote> <refspec> : 지역 저장소의 원격 브랜치가 갱신됨 (지역 브랜치에 변경사항을 합치진 않음)
  • git pull : default origin 원격 저장소에서 현재 브랜치로 merge 함 
  • git pull <remote> <refspec> : 원격 장소에서 가져온 소스를 현재 지역 브랜치에 merge 함
  • <remote> : 원격 저장소의 별칭 origin을 입력하면 된다. 별칭이 없다면 전체 주소를 넣어야 한다.
$ git pull
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 3 (delta 2), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From https://github.com/ysyun/jmqtt_client
   e13af6f..bf80359  master     -> origin/master
Updating e13af6f..bf80359
Fast-forward
 README.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)




▶ remote 저장소 Pushing

  • git push : default origin 저장소를 & 현재 브랜치를 원격의 같은 브랜치로 푸싱한다 
  • git push <remote> <branch> :현재 브랜치를 원격의 신규 또는 존재하는 branch로 푸싱한다
  • git push <remote> <branch1>:<branch2> : 지역 branch1을 원격의 신규 또는 존해하는 branch2로 푸싱한다 
  • git push --dry-run <매개변수>: 푸싱된 변경 사항을 확인
  • <remote> : 원격 저장소의 별칭 origin을 입력하면 된다. 별칭이 없다면 전체 주소를 넣어야 한다.
yuwonsystem01@YSYUN91005152 /d/git-repositories/jmqtt_client (master)
$ touch license.properties
$ vi license.properties

// 파일하나 로컬 저장소에 추가하기
$ git add license.properties
$ git commit -a -m "add license.properties"
[master f5844d4] add license.properties
 1 file changed, 1 insertion(+)
 create mode 100644 license.properties

// 원격 origin 서버로 현재 master 브랜치내용 push 하기 (id & pwd 물어봄)
$ git push origin master  (또는 git push)
Username for 'https://github.com': ysyun@yuwin.co.kr
Password for 'https://ysyun@yuwin.co.kr@github.com':
Counting objects: 4, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 297 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
To https://github.com/ysyun/jmqtt_client.git
   bf80359..f5844d4  master -> master


* 참조 : 선화의 Git

'Git, GitHub > Git Lec01' 카테고리의 다른 글

[Git] Release 브랜치 다루기  (0) 2012.12.20
[Git] tag 다루기  (0) 2012.12.20
[Git] History 이용 및 관리하기  (0) 2012.12.13
[Git] Merge 종류와 충돌 해결하기  (0) 2012.12.12
[Git] Reset 사용하기  (0) 2012.12.11
posted by 윤영식
2012. 12. 13. 14:00 Git, GitHub/Git Lec01

Git의 local repository의 commit 히스토리를 보고, 관리하는 방법에 대해서 알아보자. 참조 블로그 내용을 명령어 위주로 정리함.



▶ 리비전 로그와 범위 알아보기 

  • git log : 지금까지 수행한 내역이 전부 보인다. 끝낼 땐 :q 차례로 입력한다
  • git log <hash id 7자리> : 특정 커밋내역만 출력 (출력 형식 : 커밋명, 작성자, 날짜, 로그메세지)
  • git log --since="5 hours" : 5시간 동안 현재까지 (minute 또는 2012-10.01 날짜 형식가능)
  • git log --before="5 hours" : 현재부터 5시간을 제외하고 5시간 전의 모든 커밋내역 보기 
  • git log 184dfa1..HEAD : 해쉬아이디부터 현재(HEAD)까지 로그 내역 (HEAD 생략가능)
  • ^ : 캐럿문자 -1 취급 (12819fe^ = 12819fe와 일치하는 리비전 바로 이전 리비전으로 해석), 여러 캐럿 사용가능 예) 34fa3rt^^ 
  • ~N : 커밋명에 N만큼 뺌 (12819fe~1 = 12819fe 바로 이전 리비전을 나타냄)
  • git log -1 HEAD^~2 = git log -l HEAD~1^^  같은 의미의 리비전 필터링임


▶ 버전간의 차이점 
  • git diff --stat 1.0 : 릴리스 사이의 통계를 보여줌
  • git blame <fileName> : 누구의 책임인지 보여줌 
  • git commit -C HEAD -a --amend : 커밋 수정하기 -> 커밋된 것을 다시 스테이징으로 옮겨줄 때 --amend를 사용한다 
  • git revert -n HEAD : 기존 커밋을 다시 돌려 놓을때 사용 -> 이전 커밋상태로 돌아감 
  • git reset --hard HEAD : 저장소 재설정임. 이전 커밋의 오류를 수정하려는 경우 사용 (--soft는 스테이징으로 옮김, --hard는 저장소와 작업트리에서 커밋을 완전 제거해 버림)
  • git rebase : 커밋 순서를 대화형으로 재배치 하는 것이다 (vi식으로 커밋 순서를 재배치 하는 것이다)
    • git rebase -i HEAD~3 : vi로 위치조정 -> 저장하면 rebase 작업을 수행한다
    • git log --pretty=format="%h %s" HEAD^3 : 변경 내역 확인

* 참조 : 선화의 Git


'Git, GitHub > Git Lec01' 카테고리의 다른 글

[Git] tag 다루기  (0) 2012.12.20
[Git] Remote 저장소 연결 및 관리  (0) 2012.12.17
[Git] Merge 종류와 충돌 해결하기  (0) 2012.12.12
[Git] Reset 사용하기  (0) 2012.12.11
[Git] Hash Object 정보보기  (0) 2012.12.11
posted by 윤영식
2012. 12. 12. 15:00 Git, GitHub/Git Lec01

git은 branch를 만들어 "테스트할 기능", "새로운 기능", "버그 픽스"등에 대하여 만들고, master에 다시 merge를 할 수 있다. branch를 만들고, merge하는 방법을 알아보자 



Git 제어

  • git branch new : 새로운 branch 를 만든다. 아무런 내역이 없다.
  • git checkout new : 새로 만든 new 브랜치로 이동한다 
  • git checkout -b alternate master : master를 복제하여 브랜치를 만들고 alternate로 checkout 이동한다 
  • git branch -m alternate alternative : 브랜치의 명칭을 alternative로 변경한다 (-M 기존 같은 명칭 브랜치 있어도 덮어씀)
  • git brranch -d alternative : alternative 브랜치를 삭제한다 (-D 옵션은 강제 삭제)


▶ Merge 전략 
  • Straight Merge (바로 합치기) : 브랜치 변경 이력 전체를 합치는 방법
  • Squashed Commit (커밋 합치기) : 한 브랜치 이력 압축하여 다른 브랜치의 최신 커밋으로 하나 만드는 방법
  • Cherry-picking (선택하여 합치기) : 다른 브랜치의 하나의 커밋을 현재 브랜치에 적용하는 방법

각 합치기에 대해서 위->아래 명령순으로 살펴보자 

> 바로 합치기 
  • git checkout -b alternate master
  • git add about.html (내용 넣음) -> git commit -m "add about"
  • git checkout master 
  • git merge alternate : master 브랜치에 alternate 브랜치를 합친다 (즉, about.html 파일이 신규로 합쳐짐)

> 커밋 합치기 
  • git checkout -b contact master
  • git add contact.html (주소 내역 추가) -> git commit -m "add contact address"
  • contact.html (email 내역 추가) -> git commit -a -m "add contact email" (즉, commit object 두개가 된다)
  • git checkout master
  • git merge --squash contact : contact의 커밋 두개를 하나로 만들어 master의 staging에 추가함 (git status 확인)
  • git commit -m "add contact address" -m "add contact email"  (master 브랜치에 contact.html 을 커밋한다)

> 선택하여 합치기
  • git checkout contact
  • git commit -a -m "add contact sns id" (contact.html안에 twitter 계정추가 commit object Hash 코드를 34abcd 로 가정함)
  • git checkout master
  • git cherry-pick 34abcd  ( contact 브랜치의 34abcd 커밋을 master 브랜치에 커밋한다)
  • git reset --hard HEAD 마지막 커밋을 master 브랜치에서 제거
  • git cherry-pick -n 34abcd ( -n 옵션 사용하면 master 브랜치의 staging에 넣음, 커밋안함. git status 로 확인)
  • git commit (최종 커밋함)


▶ Merge시 충돌 해소하기 

두개의 브랜치를 합치기하다 같은 파일의 내용이 동시에 변경되었을 경우 해결방법을 알아보자. 
  • git checkout -b about master : about 브랜치 생성 후 checkout
  • git add about.html (about 내역 입력) -> git commit -m "add about"
  • git branch about2 abut : about 브랜치를 기반하여 about2 브랜치를 생성
  • git commit -a -m "add XXX" : about 브랜치의 about.html 파일에 XXX 입력
  • git checkout about2 
  • git commit -a -m "add YYY" : about2 브랜치의 about.html 파일에 YYY 입력 (이제 about 브랜치의 about.html과 about2 브랜치의 about.html 파일에 XXX 와 YYY 충돌이 발생함)
  • git checkout about
  • git merge about2 : about2 브랜치를 about 브랜치로 바로 합치기
  • about.html 안에 conflict 내역이 표시됨 : 내역을 직접 수정하거나, git mergetool 명령으로 merge.tool 값 확인하고 도구로 합치기 시도함 (도구 사용법은 다시 상세히 봐야겠음)
<<<<<<<< HEAD : 밑으로 현재 브랜치 코드 나옴
>>>>>>>> about2 : 합치려는 다른 브랜치 코드 나옴
======= : 구분자

예) about.html 파일안의 conflict 내역
<<<<<<<< HEAD
XXX
=======
YYY
>>>>>>>> about2


'Git, GitHub > Git Lec01' 카테고리의 다른 글

[Git] tag 다루기  (0) 2012.12.20
[Git] Remote 저장소 연결 및 관리  (0) 2012.12.17
[Git] History 이용 및 관리하기  (0) 2012.12.13
[Git] Reset 사용하기  (0) 2012.12.11
[Git] Hash Object 정보보기  (0) 2012.12.11
posted by 윤영식
2012. 12. 11. 11:02 Git, GitHub/Git Lec01

commit을 하여 Blob format으로 되어 있는 binary 파일에 대한 명칭은 SHA-1 해쉬알고리즘으로 해쉬명을 가지고 있다. 파일명과 해쉬명을 오가면 확인하는 방법을 알아보자 


  • 파일명 통하여 해쉬명 알아내기 : git hash-object <fileName>
$ git hash-object license.properties
b2ece065fd82ac65e5871a602166586fe691e3e7


  • 해쉬명 앞 6자리를 통하여 변경 내역이 무엇인지 파악하기 : git cat-file -p <해쉬명 앞 6자리>
$ git cat-file -p b2ece0
mqtt client for java version 1.0
written by ysyun, 2012


  • 전체 해쉬에 대한 파일명 맵핑 목록 보기 : git ls-files -s  ( .git/index 파일 내역을 참조함 )
$ git ls-files -s
100644 63bc96b980e4f36e5679312d4437908eb3add614 0       .classpath
100644 c349675aef6a30ee914d585a741bd742aad8b027 0       .project
100644 8e4055a6fa840c0bb4179360cee8a6e10352309f 0       .settings/org.eclipse.jdt.core.prefs
100644 8a6d87a1e842e58d1ea6bb707510c62f5eacc3d0 0       .settings/org.eclipse.m2e.core.prefs
100644 3ae4edb1acf2899b42b8ee6b9fd1c1ccb07cdd48 0       README.md
100644 026d2feeef3eccda9bbaae9db1ad251b9a436203 0       eclipse_feature.properties
100644 5ada071fd63361c553a5a1f7e9b816025e992c13 0       jmqtt_client-1.0.jar
100644 b2ece065fd82ac65e5871a602166586fe691e3e7 0       license.properties
100644 5f6e56a8381891e9ad64b61f58716ec7925ec5bb 0       pom.xml
100644 1fdcc8c6237579974f662d902f28d13f4c592580 0       src/main/java/MqttService.java




▶ Git의 4가지 객체


> Blob Object

  • Header + Content 
  • zlib으로 압축되어 있음
  • .git/objects/ 아래 있음 

> Tree Object
  • blob + 다른 tree 객체
  • 폴더와 같은 개념
  • .git/objects/ 아래 있음 

> Commit Object
  • blobs + trees + author + date + message
  • .git/objects/ 아래 있음

> Tag Object 
  • pointer to commit object
  • .git/refs/tags/ 아래 있음 


* 참고 : 개발자를 위한 고급 Git 활용 (p50부터)

'Git, GitHub > Git Lec01' 카테고리의 다른 글

[Git] tag 다루기  (0) 2012.12.20
[Git] Remote 저장소 연결 및 관리  (0) 2012.12.17
[Git] History 이용 및 관리하기  (0) 2012.12.13
[Git] Merge 종류와 충돌 해결하기  (0) 2012.12.12
[Git] Reset 사용하기  (0) 2012.12.11
posted by 윤영식
2012. 11. 14. 16:55 Git, GitHub

AWS에 Ubuntu 12버전 이미지를 설치하고 개발환경 구성을 하고 있다. 개발소스의 버전관리는 Git을 사용할 것이고, Git 설치하는 과정을 정리한다

 

<Ubuntu 설치하기>

  • ci 계정을 하나 만든다 : prompt> useradd ci
  • sudo 권한이 없다면 : root 권한에서 prompt> sudo useradd –m ci –G admin
  • 기본 라이브러리들 설치 : prompt> sudo apt-get install expat curl zlib1g-dev libssl-dev openssl make
  • git을 설치 한다 (현재 1.7.9.5-1 버전) : prompt> sudo apt-get install git-core 
  • git 버전 확인 : prompt> git –version
  • binary 위치 : /usr/bin/git

 

<Git 환경설정>

ci@ip-10-146-81-140:~$ which git
/usr/bin/git
ci@ip-10-146-81-140:~/git_repositories$ git config --global user.name "dowon"
ci@ip-10-146-81-140:~/git_repositories$ git config --global user.email nulpulum@gmail.com
ci@ip-10-146-81-140:~/git_repositories$ git config --global --list
user.name=dowon
user.email=nulpulum@gmail.com

* gDoc Link

* 전체 설정 정보 : http://www.kernel.org/pub/software/scm/git/docs/git-config.html#_variables

'Git, GitHub' 카테고리의 다른 글

[Git] commit 사용하기  (0) 2012.11.26
[Git] diff 사용하기  (0) 2012.11.22
[Git] Branch 전략  (1) 2012.11.14
SVN에 대하여 이해하기  (0) 2012.09.20
[Git] 레퍼런스 모음  (0) 2012.09.10
posted by 윤영식
2012. 11. 14. 08:50 Git, GitHub

Git을 가장 효율적으로 사용할 수 있는 방법에 대하여 번역해 놓은 글을 읽었다. 가장 합리적이면서 다양한 경우의 수에 대비한 적용 방식이  아닐까 하는 생각이 든다

원문 : Git Branch 전략

  • origin/master <-> origin/develop 영원히 가져가는 핵심 브랜치
    • master –>(create) develop –>(merge) master
    • 이름 : develop-*, master-*
    • master : production ready 코드
    • develop : integration 코드 (통합) – daily CI build
    • master 로 merge 할 때 배포 버전 태그 달음 : master commit 시 자동 빌드 수행
    • develop –> master로 가기 전 release 브랜치를 반드시 거친다
  • feature / release / hotfix 보조 브랜치
    • feature 브랜치
      • 조만간 배포할 기능을 개발 (배포할 수도 안 할 수도 있는 기능)
      • 이름 : feature-*
      • develop –>(create) feature –>(merge) develop
      • 맘에 안드는 기능이면 delete 한다.
      • feature는 개발자 저장소에 commit 하고,  origin에 push하지 않는다
    • release 브랜치
      • 제품 배포를 준비하는 브랜치
      • 이름 : release-*
      • 버전 번호를 부여함
      • develop->(create) release –>(merge) develop, master
      • 발견된 버그가 있다면  release에서 해결하고 develop에 merge
      • 진짜 배포할 상태가 되었을 때 master로 merge 하고 tag를 단다 (명령어들은 원문 참조)
    • hotfix 브랜치
      • 이미 배포한 운영버전에 문제를 해결하기 위해 만듦
      • 이름 : hotfix-*
      • master –> (create) hotfix –> (merge) develop, master
      • 치명적 버그의 발견 즉시 해결하기 위해 master 브랜치의 tag에서 create 한다

 

각 브랜치 정책에 따라 개발을 해보자 

'Git, GitHub' 카테고리의 다른 글

[Git] commit 사용하기  (0) 2012.11.26
[Git] diff 사용하기  (0) 2012.11.22
[Git] Ubuntu 에 설치하기  (0) 2012.11.14
SVN에 대하여 이해하기  (0) 2012.09.20
[Git] 레퍼런스 모음  (0) 2012.09.10
posted by 윤영식
prev 1 next