AI Convergence

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을 운영하는데는 비공개팀과 약간의 차이가 있다. 공개팀 운영시에는 모든 사람이 공유 저장소에 대해서 쓰기 권한이 없기 때문이다. 프로젝트 관리자는  Fork를 지원하는 Git 호스팅에서 -GitHub- 기여하는 방법에 대해 가이드 해야 한다. GitHub을 예로 Pull Request는 어떤 절차로 이루어 질까?

1) 갑순이 Fork 질 하기 

  - 갑순이 중앙 저장소(예, ysyun)의 GitHub에서 Fork질 하여 자신의 원격 저장소(예, nulpulum)를 하나 만든다  

    + GitHub의 갑순이 계정으로 로그인한다 

    + GitHub의 중앙 저장소(ysyun)로 이동하여 "Fork" 버튼을 클릭하면 갑순이 계정으로 중앙 저장소(nulpulum)가 clone된다 

     [GitHub Fork 클릭]

  - 갑순이 원격 저장소(nulpulum)를 자신의 PC 로컬 저장소로 clone 한다 : git clone <갑순이 원격저장소>

  - 갑순이의 원격 저장소 이름을 origin에서 myfork로 바꾼다

    + git remote -v : default 설정된 origin 명칭 확인 

    + git rename origin myfork : origin을 myfork라는 이름으로 변경 

2) 갑순이 별도 브랜치 만들고 push 질 하기 

  - 갑순이 별도의 featureA 브랜치를 만들고 두번의 commit 질 한다 

    + git checkout -b featureA : featureA 만들기 

  - 간혹 commit  실수 한것은 날려 버리고 싶다 : git reset --hard HEAD^ (참조)

  - 갑순이의 원격 저장소(nulpulum)인 myfork에 featureA를 push 한다 (참조)

    + GitHub 의 commit 내역은 "Commit" 탭에서 확인가능하다 

  [GitHub Commit]

 [갑순이 GitHub 저장소(nulpulum)의 featureA 브랜치]

3) 갑순이 Pull Request 질 하기 

  - 갑순이는 수정한 사항에 대하여 중앙 저장소(ysyun)의 관리자에게 Pull Request를 요청하여 자신이 수정한 것을 가져가라 알린다

    + 갑순이 GitHub 계정으로 들어가서 상단의 "Pull Request"를 클릭한다 

 [갑순이 GitHub 저장소(nulpulum)의 Pull Request 버튼 클릭]

    + Pull Request 원하는 브랜치를 선택한다 

    + 갑순이 원격 저장소(nulpulum)에서 featureA를 선택하고 중앙 저장소(ysyun)에게 Pull Request를 보낸다

    + featureA에 commit 두번 한것과 파일 수정 정보등이 보인다 -Commits (2) Files Chagned (1)-

  [Pull Request 요청 내역 입력한후 "Send pull request" 보내기]

    + 중앙 저장소 (ysyun)에서 Pull Request온 내역을 볼 수 있다 

 [중앙 저장소(ysyun)의 Pull Request 내역 보기]

  - 가급적 Pull Request를 할때는 별도의 토픽 브랜치(갑순이가 만든 featureA)와 같이 만들어서 관리자에게 요청한다 

    + master 브랜치와 구분하고 수정 내용을 거부할 때 쉽게 버릴 수 있다

  - 갑순이 다른 브랜치를 만들어서 작업할 때는 featureA에서 하지 말고 origin/master에서 한다 

    + git checkout -b featureB origin/master

<참조> 

  - Pro Git (p. 110)

  - 2개 아이디의 Public repository를 만들어서 테스트 해보았다.

비공개 대규모 팀을 운영할 때는 Git Workflow에서 Integration-Manager 방식을 선택한다. 이는 팀별로 별도의 Master를 두고 Integration Manager가 중앙 Master로 push할 수 있는 권한을 갖도록 한다. 즉, 중간 단계의 master가 하나 더 있는 구조이다. 

1) 가정

  - 갑순이는 두 팀에 속한다 

  - 1팀 갑순이 + 갑돌이

  - 2팀 갑순이 + 갑복이 

2) 1팀 갑순이 featureA만들어 갑돌이와 작업

  - 갑순이는 저장소를 clone하고 featureA 브랜치를 만들고 수정후 커밋한다 

    + feautreA 브랜치 생성 : git checkout -b featureA

    + 커밋 : git commit -am "add function"

  - 갑순이가 해당 브랜치를 갑돌이와 공유하려 한다. 

    + 여기서 갑순이는 Integration Manager가 아니다

    + 갑순이는 운격 저장소에 featureA로 push 하고 갑돌이에게 해당 사실을 알린다 

3) 2팀 갑순이 featureB 브랜치 만들어 갑복이와 작업

  - 갑순이는 갑복이와 원격 저장소의 master 브랜치를 기반으로 featureB작업을 계속 수행하기로 한다

    + 원격저장소에서 로컬 저장소로 fetch 하기 : git fetch origin

    + git checkout -b featureB origin/master

  - 갑순이가 몇가지 작업을 하고 featureB에 커밋을 한다 

    + git fetch origin

    + git checkout -b featureB origin/master

    + 2번의 커밋객체 생성 : git commit -am "modified some function" (e5b0f) -> git commit -am "add new function" (85127)

   [그림 5.12] 갑순이 현재 로컬 저장소 커밋 그래프

  - 갑순이 featureB를 push 하려는데 갑복이로부터 이미 featureBee 브랜치로 한번 push 했다고 연락을 받는다

    + 갑복이 내역을 merge 하기위해 fetch 한다 : git fetch origin

    + 갑복이 브랜치를 merge 한다 : git merge origin/featureBee

  - 갑순이 이제 featureB를 원겨 저장소로 push 하려는데 갑복이 featureBee 와 이름이 틀리다

    + 로컬 featureB를 원격 featureBee로 push 한다 : git push origin featureB:featureBee (cd685)

4) 1팀 갑돌이 featureA 작업

  - 갑돌이 featureA 작업후에 push 했고 갑순이에게 확인요청한다 

  - 갑순이는 내역확인을 위하여 원격저장소에서 fetch 한다 : git fetch origin 

  - 갑순이는  featureA 브랜치에 어떤 것이 업데이트 되었는지 확인한다 (갑돌이 커밋시 메시지 잘 입력했다 가정함)

    + 변경내역 확인 : git log origin/featureA ^featureA 

    + 확인후 로컬 featureA 브랜치로 이동 : git checkout featureA

    + 원격 featureA를 로컬 featureA에 merge 수행 : git merge origin/featureA

  - 갑순이 다시 일부 수정하여 featureA 브랜치를 원격 저장소로 push 한다 

    + git commit -am "small tweak"

    + git push origin featureA (774b3)

    + 갑순이의 저장소를 보자 

  [그림 5.13] featureB도 원격으로 push하고 featureA도 원격 저장소로 push한 갑순이 로컬 저장소 

5) 갑순이 메인 브랜치로 merge 요청작업 

  - Integration-Manager는 두 브랜치를 merge 하고 메인 브랜치의 커밋 (5399e) fetch해 온다 

  - 다음과 같은 구조가 될 것이다 

  [그림 5.14] integration manager는 774b3 과 ce685 커밋을 merge하여 5399e를 원격저장소에 커밋한 후 갑순이가 fetch 함!

<참조>

  - Pro Git 5장 108p

소규모 팀으로 일을 할때 어떤 절차에 의해서 소스를 Merge하고 원격저장소로 Push 할 수 있는지 알아보자. 팀원간 Git 기본 workflow로써 가장 기본적으로 숙지해야할 사항이라 판단된다. 

1) 가정 

  - 3~5명이 하나의 원격 Git - 예, GitHub Private Repository - 에 원본을 합친다 

  - 각자가 local repositor로 내려 받아서 작업을 한다 

2) 갑순이 push 작업

  - 갑순이가 GitHub에서 저장소를 복제한다 : git clone <git address>

  - 갑순이가 하나의 파일에 대해서 수정하고 commit 한다 : git commit -am "modified files"

  - GitHub에 변경된 파일을 push 한다 : git push origin master

3) 갑돌이 push 작업

  - 갑돌이도 GitHub에서 저장소를 복제한다 

  - 값돌이도 다른 파일 하나를 수정하고 commit 한다 

  - GitHub에 변경된 파일을 push 한다 => 오류가 발생하여 파일 push를 하지 못한다 

4) 갑돌이 push 오류 해결하기 

  - 갑돌이는 Push 하기전 원격저장소의 갑순이 commit 내역을 로컬 저장소에 merge 해야 한다 

  - 갑돌이는 먼저 원격 저장소의 내용을 fetch 한다 : git fetch origin

   [그림 5.4] origin에서 fetch를 하면 origin/master가 된다(fbff5) 로컬의 master (738ee)와 merge는 안된 상태

  - 로컬 master와 원격 origin/master를 merge 한다 : git merge origin/master

  - 갑돌이는 merge를 완료하고 push를 재시도 한다 : git push origin master  (origin master 생략가능)

  [그림 5.5] merge를 했을 때 새로운 commit object가 생성된다 (72bbc)

  [그림 5.6] push를 하게되면 origin/master의 위치도 최신 commit object를 가르키게 된다 (72bbc)

5) 갑순이 branch 생성후 push 추가작업

  - 갑순이는 이슈해결을 위하여 별도 issue54 브랜치를 만들었다

  - issue54 브랜치에 대해서 3개의 commit을 수행하였다. 

  - 원격으로 push 하기 위하여 먼저 원격의 갑돌이 push 내역을 fetch 한다 : git fetch origin

  [그림 5.8] fetch하여 원격의 origin/master를 가져온다 (72bbc)

  - fetch 해온 origin/master 와 merge할 내용을 확인한다 : git log --no-mergs origin/master ^issue54

  - merge를 위하여 master 브랜치로 checkout 한다 : git checkout master

  - 먼저 issue54 부터 merge 한다 : git  merge issue54

    origin/master 와 issue54 브랜치는 모두 master 보다 fast-forward 된 브랜치 이기 때문에 순서에 상관없이 merge해도 된다

  - 다음 origin/master 를 merge 한다 : git merge origin/master

  [그림 5.9] local의 issue54를 merge하고, origin/master와 merge를 하면 새로운 commit object가 생성된다 (8059c)

  - 로컬 저장소에 모드 merge 되었으므로 원격 저장소로 push 한다 : git push origin master 

  [그림 5.10] push를 하게되면 origin/master가 가르키는 commit object는 최신 8059c 가 된다. 

6) 최종 Workflow 모습

  - 갑순이 == Jessica

  - 갑돌이 == John

  [그림 5.11] push -> fetch -> merge -> push 작업이 이루어진다     

<참조>

  - Pro Git : 5장 page 104

Git commit 할 때 가이드 라인을 잘 지켜서 원격 저장소에 소스가 꼬이지 않도록 하고, 커밋된 내역을 잘 이해할 수 있도록 메세지 작성 정책에 대해 알아보자

  - 공백 문자를 깨끗이 제거 한다 : 확인)  git diff --check (공백 문자 오류확인가능, 잘 못 사용한 공백은 X 문자로 바꿈)

  - 최대한 수정사하을 하나의 주제로 요약한다

    + 여러 가지 이슈에 대한 수정사항을 하나의 커밋에 담지 말아라

    + 적절한 메세지를 작성한다 : 반드시 좋으 커밋 메세지를 담는다

  - 같은 파일의 다른부분을 수정하는 경우에는 git add -patch 명령을 이용한다 

    + 한 부분씩 나누어 Stage 영역에 저장해야 한다 

  - 메세지 작성

    + 첫줄엔 50자내로 간략히 요약

    + 두번째줄 비우고 세번째줄에 자세히 설명글 :개발동기, 구현 상황, 제약조건/상황

    + 글은 현재형을 사용한다 

    + 추가 내용은 한줄 띄우고 시작한다 

    + 잘쓰여진 커밋 메세지는 git log --no-merges 명령으로 꼭 살펴본다 

   예)

Git은 분산 버전관리 시스템이다. 서로 각자의 저장소를 가지고서 어떻게 충돌없이 잘 사용할 수 있을지 알아보자. (5장)

1) 중앙집중식 Workflow

  - 예전의 Subversion에 익숙한 사용자들의 방식

  - 예로 2명이 작업, 한명이 서버로 update코드 push하면 다른한명이 서버에서 update코드를 pull하여 merge 수행

  - 모든 사용자에게 서버에 push 권한을 부여해야 함

  - 그러나 중앙 서버 저장소로 a코드가 다른이에 의해 push 되었고, 다른사람이 a코드를 수정하여 push해도 Git은 이것을 방지해 준다. 즉, 다시 로컬로 fetch 또는 pull 하지 않으면 중앙 서버로 push 할 수 없게 막아준다

2) 통합관리(Integration-Manager) Workflow

  - 여러 리모트 저장소를 두고 한개는 R/W 가능, 다른 한개는 R만 가능하게 설정가능 하다

  - 이것은 GitHub의 운영방식이다. Pull Request 수행하면 통합관리자가 이것을 보고 기여자의 저장소에서 원본 저장소로 pull하여 merge 하게 된다

3) 독재자 보조관(Dictator and Lieutenants) Workflow

  - 2)번 형태의 확장판

  - Linux Kernel과 같은 큰 프로젝트에서 사용한다 

* 다양한 변종의 Workflow가 존재함 

<참조>

  - 성공적인 Git Branch 전략 (한글번역본 - dogfeet)

    + feature : 기능 만들기 

    + develop : 개발진행

    + release : 릴리즈 

    + hotfixes : 긴급 패치 

    + master : 원본 

Git 에서 한 브랜치에서 다른 브랜치로 합치는 방법은 Merge와 Rebase가 있다. Rebase 사용시 좋은 점과 사용하지 말아야 할 때에 대해서 알아보자 (ch 3.6)

1) Rebase 기초 

  - 일반적으로 3 way merge로 브랜치 합치기를 함    

  - Rebase는 한 브랜치에서 변경된 사항을 다른 브랜치에 적용한다 

    + Rebase할 브랜치를(B) checkout한 브랜치가 가르키는 커밋까지 diff하여 다른 내용을 임시로 저장해 놓음 (temp)

    + temp에 저장한 변경사항을 차례로 적용하여 Rebse될 브랜치(A)에 새로운 commit을 만든다 

    + Rebase될 브랜치(A)는 가장 최신 commit 개체가 되고 브랜치의 포인터는 fast-forward 된다 

    + 즉, Rebase는 기존 commit을 사용하는 것이 아니라 새로운 commit을 만들어 합치는 것이다

  -  Rebase가 merge 보다 좀 더 깔끔한 히스토리를 만든다. 일이 병렬로 하다 rebase 하면 선형적으로 된다 

  - 보통 리모트 브랜치에 커밋을 깔끔하게 적용하고 싶을 때 사용한다 (메인 프로젝트에 패치를 보낼 때)

  - Rebase=브랜치의 변경사항을 순서대로 다른 브랜치에 적용하면서 합치고, Merge는 두 브랜치의 최종결과만 합친다

2) Rebase 위험성 

  - 이미 공개 저장소에 Push 한 커밋을 Rebase 하지 마라 : 동료와 협업시 commit 객체 내용이 삭제되어 버린다 (p. 78)

  - 즉, 로컬에서 작업진행한 내 commit 개체만 Rebase하고 리모트에 있는 commit 개체의 rebase는 불허!!!

  - Push 하기 전에 정리하려고 Rebase하는 것은 괜찮다 

<사용법>

  - http://mobicon.tistory.com/165  : 리모트 저장소에서 pull하고 conflict 날 경우

  - http://mobicon.tistory.com/164  : 로컬 저장소에서 conflict 날 경우 

Git은 Branch를 자유자래로 사용함으로써 그 진가를 실감할 수 있다. 복잡한 애플리케이션이나 프로젝트일 수도록 더욱 힘을 발휘한다. Branch에 대하여 알아보자. 

1) 분산 버전 관리 시스템

  - 클라이언트가 파일의 마지막 Snapshot을 Checkout 하지 않는다. 그냥 저장소를 전부 복제한다

  - 서버에 문제 생겨도 다시 작업시작 가능하다

  - DVCS 한경에서는 리모트 저장소가 존재하고 여러개 문제없다. 동시 다양한 그룹과 다양한 방법으로 협업이 가능하다. 

2)  Git 철학

  - 2005년 BitKeeper 사용하지 않으며 리누스 토발즈가 개발 

  - 빠른 속도

  - 단순한 구조

  - 비선형적인 개발 (수천 개의 동시 다발적인 브랜치)

  - 완벽한 분산

  - 리눅스 커널같은 대형 프로젝트에도 유용할 것 (속도나 데이터 크기면에서)

3) Git 데이터 저장 방식

  - Git 은 데이터를 일련의 Snapshot으로 기록한다 

  - Staging Area에서 Local Git 저장소에 파일 저장(=Blob). 해당 파일의 Checksum을(SHA-1) 저장한다.

  - Commit을 하면 Local Git 저장소에 

    + 하위 디렉토리의 "트리 개체" 생성

    + 트리 개체 밑으로 "커밋 개체" 생성 : 메타데이터(저자,메시지)와 트리 개체 포인터, 이전 트리 개체 포인터 정보 저장

  - 즉, Git 저장소에 Commit > Tree > Blob 이 생성된다 

4) 브랜치(Branch) 

  - Git 기본 master 브랜치를 만든다. master 브랜치는 자동으로 마지막 Commit 개체를 가르킨다 

   + 즉, 브랜치는 Git 저장소의 Commit 개체를 가르키는 것이다. 

  - 브랜치는 SHA-1 40자의 체크섬 파일에 불과하다. 즉 41바이트(줄바꿈포함) 크기

  - Git은 특수한 HEAD 라는 포인터가 존재 = 지금 작업 중인 브랜치를 가르킴 

    + 즉, Head > Master(브랜치) > Commit 포인터를 가르킨다 

  - 브랜치를 나누고 각각의 브랜치가 commit 이후 merge 방법 = 3 way merge

   + Merge시에 Merge에 대한 정보가 들어있는 커밋을 하나 만든다 

5) 충돌(Conflict) 

  - 3 way merge 시에 같은 파일의 한 부분을 각각의 브랜치가 수정하였을 때 발생

  - git status 명령으로 conflict 상황 체크 

  - 충돌부분을 직접 수정후 git add -> git commit 함 

  - Merge 브랜치 필터링 명령

    + git branch --merged : merge한 브랜치 목록 확인 (* 가 없는 브랜치는 이미 다른 브랜치와 merge 한 것임)

    + git branch --no-merged : 현재 ckeckout한 브랜치에 merge 하지 않은 브랜치를 보여줌 

6) 브랜치 접근 in Local

  - master 브랜치 : 배포/안정화 브랜치

  - develop 브랜치 : 개발 브랜치, develop 밑으로 topic 브랜치 (각 브랜치를 하나의 실험실로 생각한다)

  - topic 브랜치 : 어떤 한 가지 주제나 작업의 짧은 호흡의 브랜치이다 예) hotfix 브랜치

    + master merge후에 삭제

    + 내용별 검토, 테스트가 용이하다

7) 리모트 브랜치 

  - 리모트 브랜치란 리모트 저장소에 있는 브랜치이다. 

  - 명칭 = (remote)/(branch) 형식 예) 리모트 저장소가 origin 이고 master 브랜치이면 origin/master 로 표현함 

  - git clone으로 local에 내려 받으면 origin/master가 생기고 마음대로 조종할 수 없다. 

  -  git fetch origin을 할때 자동으로 리모트 저장소의 최신 master 브랜치로 local의 origin/master가 갱신된다

    + 누군가 리모트에 push를 하여 origin의 master commit을 갱신함 

    + 나는 옛날 origin/master를 가지고 있고 그동안 local에서 commit도 했음, pull로 최신으로 update 할 경우 

    + git fetch origin/hotfix01 로 브랜치 지정하여 로컬로 받으면 저장소에 브랜치가 생성되지 않고 포인터만 생성됨

      = git merge origin/hotfix01 로 새로받은 브랜치 내용을 merge 한다

      = 또는 merge 하지 않고 새로운 브랜치로 만들려면 git checkout -b hotfix01 origin/hotfix01  수행 

  - git push [remote] [branch] : 리모트에 쓰기 권한이 있어야 한다. 예) git push origin hotfix01

    + git push [remote] [local branch]:[remote branch] 로 로컬/리모트 브랜치 명이 틀릴 때 사용한다 

8) 브랜치 추적(Tracking)

  - Git은 리모트 저장소에서 Clone시에 master 브랜치를 origin/master 브랜치로 추적 브랜치를 만든다

  - checkout 할 때도 자동으로 추적 브랜치가 만들어 져서 git pull/push 할 때 별도의 옵션을 주지 않고 해당 리모트 브랜치로 수행

  - git checkout -b [branch] [remotename/branch] : 추적 브랜치 만듦 

9) 리모트 브랜치 삭제 

  - git push [remotename] [local branch] :[remote branch] 협업때 사용했던 서브 브랜치를 이제 삭제 하고 싶을 경우 

  - 예) git push origin :hotfix01  [local branch]를 비워두면 "로컬에서 빈 내용을 리모트의 [remote branch]인 hotfix01에 채워 넣어라" 라는 뜻이 된다   

Git의 열거형 명령을 하나의 Alias로 지정할 수 있다. 설정 방법을 알아보자 

1) Alias 설정하기 : git config --global alias.[Alias명] '[명령]'

  - Ustage상태로 변경 : git config --global alias.unstage 'reset HEAD --' 로 설정하면 하기 명령은 동일하다 

    $ git unstage fileA

    $ git reset HEAD fileA 

  - last 명령 : git config --global alias.last 'log -l HEAD'

2) 많이 사용하는 git alias : 참조사이트 

* 현 브랜치의 히스토리를 short SHA값, author 정보, 커밋 트리 그리고 히스토리에서 특정 커밋을 가르키는 refs(브랜치, 태그)보기

  $ git config --global alias.lg "log --name-status --color --abbrev-commit --date=relative --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset'"

  $ git lg 결과를 색깔별로 보여줌 

* 브랜치를 중심으로 히스토리를 보고 싶을 경우

  $ git config --global alias.tree "log --graph --decorate --pretty=oneline --abbrev-commit --all"

  또는 $ git config --global alias.lol 'log --oneline --graph --decorate'

  $ git tree 또는 git lol 수행 결과

* Visual 윈도우에서 변경 내역 보기 

  $ git config --global alias.visual '!gitk'

  $ git visual 을 수행하면 하기 화면이 뜬다 

<참조>

  - dogfeet alias 설정

  - 개발자 하루 alais 설정

  - 자료 : 민트기술

   Git-Guide-r1.pdf

SVN의 Tag처럼 Git에도 Tag가 있다. 어떻게 사용하는지 보자 

1) Tag 조회하기 : git tag 

  - 특정 버전 조회시 git tag -l 'v1.4.2.*' 식으로 조회한다

2) Annotated Tag 붙이기 : git tag -a [버전] -m '[메시지]'

  - Tag를 만든 사람의 이름, 이메일, 날짜, 메시지를 저장함. 단순 Tag일때는 Lightweight Tag를 사용함 

  - Tag 정보와 커밋 정보 보기 : git show [버전]

3) Lightweight Tag : git tag [버전]

  - 브랜치처럼 가리키는 지점을 최신 커밋으로 이동시키지 않는다. 단순 특정 커밋에 대한 포인터일 뿐임 (체크섬만을 저장할 뿐)

  - -a, -s, -m 등의 옵션을 사용하지 않는다 

4) Tag 검증하기 : git tag -v [버전]

  - GPG 서명을 검증하는 것으로 공개키가 필요하다

  - 서명 메시지가 없으면 하기와 같은 error 메시지가 나옴 (다음 기회에 다시 알아보자)

5) 나중에 Tag 하기 : git tag -a v1.2 [해쉬값 앞 7자리] -m '[메시지]'

  - 과거 특정 커밋에 대해서 Tag를 달 수 있다. 커밋 내역 확인하기 : git log --pretty=oneline

6) Tag 공유하기 : git push origin [버전]

  - 서버로 Branch를 push 하는 것과 동일하다 

  - 한번에 여러 개의 tag를 push 하기 : git push origin --tags

GitHub에 만들어 놓은 저장소 관리를 알아보자. 

1) 리모트 저장소 확인하기 

2) 리모트 저장소 추가하기 : git remote add [단축이름] [url] 

3) 리모트 저장소를 Pull, Fetch 하기 : git fetch [remote-name] 

   - fetch : clone 이후 변경된 데이터를 모두 로컬로 가져온다. 그러나 자동 Merge는 하지 않는다. 수동 Merge해야 함

   - pull : 리모트 저장소 브랜치에서 데이터를 가져와서 현재 작업하는 로컬 브랜치와 Merge 한다. 

4) 리모트 저장소에 Push 하기 : git push [리모트 저장소 이름] [브랜치 이름]

5) 리모트 저장소 살펴보기 : git remote show [리모트 저장소 이름]

Git 저장소를 만들고 Working Directory, Staging Area, Git Directory를 오가는 명령을 알아보자.

> Git 저장소 만들기 

• 프로젝트 디렉토리를 만든다
• 프로젝트 디렉토리로 이동한다
• git init 명령을 수행하면 .git 디렉토리가 생긴다 (git 뼈대)
• 버전관리를 시작할려면 git add -> git commit 을 하여 파일을 저장소에 추가해야 시작된다.

> Git 복제 

• git clone <url>

> 파일 수정하고 저장소에 저장하기 

• Tracked(관리대상)와 Untracked(비관리대상) 으로 나뉜다. 즉 한번이라도 commit 되면 관리대상이 된다.
• Tracked는 Unmodified(수정하지 않음)와 Modified(수정함) 그리고 Staged(커밋전) 상태 중 하나이다.
• Clone을 하게 되면 모든 파일은 Tracked이면서 Unmodified 상태이다. 또한 자동으로 자동 Checkout도 한다.

untracked <-> unmodified <-> modified <-> staged <-> commited

• git status : 파일 상태의 확인 tracked와 modified 상태파일이 없거나, Untracked 파일이 있는지 보여준다

• git add <파일명 또는 디렉토리경로명> : Tracked 상태로 만들면서 Staged 상태가 된다 

• Modified 상태의 파일을 Stage 하기 

• Stage 된 파일을 다시 Modified 하였을 경우 

• .gitignore : Untracked 파일을 git 목록에서 제거하기 (로그파일, 빌드환경파일, 프로젝트파일등 무시하고자 하는 것을 명시한다)
• 아무것도 없는 줄이나 # 시작하는 줄 무시
• 표준 Glob 패턴 사용 (Glob패턴은 정규표현식을 단순하게 만든 것으로 보통 쉘에서 사용)
• * : 문자가 하나도 없거나 하나 이상을 의미 
• [abc] : 중괄호 안에 있는 문자중 하나를 의미
• ? : 문자 하나를 의미
• [0-9] : 하이픈을 사용하면 그 캐릭터 사이의 문자 하나를 의미
• 디렉토리는 슬래쉬(/)를 끝에 사용
• 느낌표(!)로 시작하는 패턴은 해당 패턴의 파일 무시

• git diff : Staged와 Unstaged 상태의 변경 내용을 보기 (git status 는 단순 상태 정보만을 보여주지만 git diff는 변경 내용을 볼 수 있다)

• git commit <fileName option> -m <message> : Staging Area 파일을 정일한다. 즉, Staged 파일만 해당 된다. git add 하지 않은 파일은 Modified 상태로 남음.

• git commit -a -m <메세지> : Staging Area 생략하고 commit 하기. 

• git rm <파일> : 삭제된 파일은 Staging 상태가 된다. 다시 commit을 하면 삭제가 된다. (삭제확인을 위한 장치). 만일 Staging Area에서 포함되지 않게 제거하는 것은 git rm --cached를 사용한다.

• git mv <from파일> <to파일> : 파일 이름 변경하기를 하면 Staging Area에 Renamed 상태로 된다.

• git log : 커밋 히스토리 보기. 가장 최근 커밋이 가장 먼저 나온다. -p 옵션은 커밋의 diff 결과를 보여준다. -2 는 두개의 결과만 보여준다. -p 옵션은 diff이기 때문에 동료의 변경 내용을 빠르게 확인 할 수 있다. --stat 각 커밋의 통계 정보를 보여줌. --pretty는 사용자 정의가능 (oneline, short, full, fuller, format 옵션 예, --pretty=oneline). --graph는 브랜치 그래프를 보여줌

* git log 옵션들

Git 설치에 대해 간단히 알아보고, 설정하는 방법에 대하여 알아보자 

> Git 설치

• Git은 curl, zlib, openssl, expat, libiconv를 필요로 한다 

// 윈도우 설치
http://code.google.com/p/msysgit  다운로드하여 설치한다

• http://git-scm.com/download 에서 최신 snapshot을 받아서 컴파일하고 설치한다

$ cd git-1.7.2.2
$ make prefix=/usr/local all
$ sudo make prefix=/usr/local install

• Git이 이미 설치되었다면 최신버전 소스를 다음과 같이 받을 수 있다. 

> Git 환경파일

• /etc/gitconfig : 시스템의 모든 사용자와 모든 저장소에 적용되는 설정. git config --system 옵션으로 RW 가능.
• ~/.gitconfig : 특정 사용자에게만 적용(윈도우는 USER 밑에 존재) git config --global 옵션으로 RW 가능.
• .git/config : Git Directory(Local Repsoitory)의 현재 작업중인 프로젝트에만 적용. 우선순위 가장 높음.

Pro Git에 대한 번역본을 보면서 공부한 내용을 정리한다. 

> 버전 관리 형태 

• VCS : 초창기 로컬 버전 컨트롤 시스템으로 시작
• CVCS : 중앙 버전 컨트롤 시스템 (단점 : 중앙 저장소 장애시 모든 개발자 접속 불가. 예: SVN, CVS)
• DVCS : 분산 버전 컨트롤 시스템 (장점 : CVCS 단점 극복, 중앙 저장소를 그대로 로컬에 복제하여 사용함. 예:  Git)

> Git 역사

• 리눅스 초창기 개발에서 쓰던 BitKeeper DVCS가 상용화 요구하면서 개발됨
• 빠른 속도, 단순한 구조, 동시 다발적 브랜치(비선형적 개발), 완벽한 분산, 대형 프로젝트에도 적함(속도, 크기면에서도) 요건 충족토록 개발시작
• 2005년 탄생

> Git 특성

• Git 데이터는 파일 시스템의 SnapShot 으로 크기가 작다. 파일 변경이 없으면 버져닝시 이전 파일의 링크만 저장한다.
• 거의 모든 명령은 로컬에서 수행된다. (CVCS는 네트워크 속도에 영향을 받는다) 오프라인 상태에서도 작업이 가능하다.
• 데이터 무결성을 위해 모든 데이터 저장전 체크섬(Checksum 또는 Hash)을 구하여 관리한다. SHA01 Hash를 사용하여 체크섬을 만든다. (길이 40자 16진수 문자열)
• 로컬에 3 단계로 나뉜다 : Working Directory (Modified) - Staging Area (Staged) - Git Directory(Local Repository, Commited)
• Working Directory : 특정 버전을 Checkout 한 것이다. Git Directory에 압축된 데이터베이스 파일을 가져와 만든다
• Staging Area : Git Directory에 있고, 단순 파일이고 곧 Commit 할 파일에 대한 정보이다. 종종 인덱스라고 불림.
• Git Directory : 프로젝트의 메타데이터와 객체 데이터베이스를 저장하는 곳이다. Git의 핵심이다.