AI Convergence

본 서적은 자바스크립트와 앵귤러 프레임워크를 프로젝트에 도입해 보려는 개발자 또는 프로토타입을 해보고 싶은 개발자 또는 사용해 본 경험이 있는 개발자를 대상으로 한다. 앵귤러에 대해 처음 공부하는 분에게는 다소 어려울 수 있으므로 기초서적을 권장드린다. 책 제목처럼 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

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 으로 Main 저장소 받아오기 

    + git submodule init 명령으로 submodule 등록

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

  - 서브모듈 삭제

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

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

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

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 만들기 

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

Git의 성공적인 Branching 전략

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

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

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

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

  - 사용법 : 설명 원문

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

그림 보면서 Git 이해하기

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

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

Dogfeet 님의 블로그 포스팅 참조

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

<참조>

  - GitFlow 적용하기 

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

Git 메뉴얼

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

명령어 레퍼런스

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

Merge 와 Diff Tool 바꾸기 

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

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

  - extMerge 파일 생성

  - extDiff 파일 생성

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

  - ~/.gitconfig 내역 변경

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

기초 문법 다시 보자 

Git 원리 이해하기 

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

1) 언제 사용

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

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

2) 실습

  - cherry-pick을 하기전 상태

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

  - check-pick 수행하기 

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

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

<참조>

  - Pro Git : p127

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

• git gc : 저장소의 크기 압축 및 최적화 (지저분한 내용을 정리)
• git gc --aggressive : 변경 사항 델타(delta)단위로 저장한다. 저장단위를 처음부터 최적화 한다 

• 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 압축 추가 함 

* 참조 : Git 선화

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

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

* 참조 : Git 선화

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

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

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 <별칭> : 별칭을 제거한다 

• 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을 입력하면 된다. 별칭이 없다면 전체 주소를 넣어야 한다.

▶ remote 저장소 Pushing

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

* 참조 : 선화의 Git

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은 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 옵션은 강제 삭제)

• 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 (최종 커밋함)

• 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 값 확인하고 도구로 합치기 시도함 (도구 사용법은 다시 상세히 봐야겠음)

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

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

• 해쉬명 앞 6자리를 통하여 변경 내역이 무엇인지 파악하기 : git cat-file -p <해쉬명 앞 6자리>

• 전체 해쉬에 대한 파일명 맵핑 목록 보기 : git ls-files -s  ( .git/index 파일 내역을 참조함 )

▶ Git의 4가지 객체

> Blob Object

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

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

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

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

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