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

Publication

Category

Recent Post

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 윤영식
2013. 1. 30. 15:36 Git, GitHub/Git Lec02

공개팀으로 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]


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

// 로컬 저장소에 새로운 브랜치 만들기 

dowon /d/git-nulpulum/jmqtt_client (master)

$ git checkout -b featureA

Switched to a new branch 'featureA'


dowon /d/git-nulpulum/jmqtt_client (featureA)

$ vi license.properties


dowon /d/git-nulpulum/jmqtt_client (featureA)

$ git commit -am "modified license 1"

[featureA 9e5ce9b] modified license 1

 1 file changed, 1 insertion(+)


dowon /d/git-nulpulum/jmqtt_client (featureA)

$ vi licene.properties


dowon /d/git-nulpulum/jmqtt_client (featureA)

$ git commit -am "modified license 2"

[featureA b3787b8] modified license 2

 1 file changed, 1 insertion(+), 1 deletion(-)


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

// 원격 저장소에 새로운 브랜치 만들기 

dowon /d/git-nulpulum/jmqtt_client (featureA)

$ git push myfork featureA

Username for 'https://github.com': nulpulum@gmail.com

Password for 'https://nulpulum@gmail.com@github.com':

Counting objects: 8, done.

Delta compression using up to 2 threads.

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

Writing objects: 100% (6/6), 562 bytes, done.

Total 6 (delta 2), reused 0 (delta 0)

To https://github.com/nulpulum/jmqtt_client.git

 * [new branch]      featureA -> featureA


  

 [갑순이 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를 만들어서 테스트 해보았다.

posted by 윤영식
2013. 1. 28. 10:12 Git, GitHub/Git Lec02

비공개 대규모 팀을 운영할 때는 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

posted by 윤영식
2013. 1. 28. 09:50 Git, GitHub/Git Lec02

소규모 팀으로 일을 할때 어떤 절차에 의해서 소스를 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

posted by 윤영식
2013. 1. 25. 09:05 Git, GitHub/Git Lec02

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


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

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

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

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


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

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


  - 메세지 작성

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

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

    + 글은 현재형을 사용한다 

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

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

   예)

   

posted by 윤영식
2013. 1. 25. 08:44 Git, GitHub/Git Lec02

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 : 원본 



posted by 윤영식
2013. 1. 16. 10:53 Git, GitHub/Git Lec02

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, GitHub > Git Lec02' 카테고리의 다른 글

[Pro Git] 커밋 가이드라인  (0) 2013.01.25
[Pro Git] 협업 Workflow  (0) 2013.01.25
[Pro Git] Branch 사용하기  (0) 2013.01.16
[Pro Git] Git Alias 사용하기  (0) 2013.01.08
[Pro Git] Tag 사용하기  (0) 2013.01.08
posted by 윤영식
2013. 1. 16. 10:20 Git, GitHub/Git Lec02

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에 채워 넣어라" 라는 뜻이 된다   

posted by 윤영식
2013. 1. 8. 20:42 Git, GitHub/Git Lec02

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'

$ git config --global alias.last 'log -l HEAD'


$ git last

commit 329db048ff7af2d417588e28da50a6c53fb1bd84

Author: Yun DoWon <ysyun@yuwin.co.kr>

Date:   Thu Dec 27 11:07:26 2012 +0900


    add content in build.gradle


commit f856853c5b0ac53483f9d14fe1b3ec6ef0fdbca7

Author: 윤도원 (영식) <ysyun@yuwin.co.kr>

Date:   Thu Dec 27 11:01:23 2012 +0900


    Update build.gradle


commit 03ca40a6026b9144f15cc8988ad6539049d36486

Author: 윤도원 (영식) <ysyun@yuwin.co.kr>

Date:   Wed Dec 26 17:55:01 2012 -0800


    Create build.gradle


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

[alias]

git config --global alias.st status

git config --global alias.co checkout

git config --global alias.ci commit

git config --global alias.br branch

git config --global alias.unstage 'reset HEAD --'

git config --global alias.cs "commit -s"

git config --global alias.last 'log -1 HEAD'

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


* 현 브랜치의 히스토리를 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

posted by 윤영식
2013. 1. 8. 20:12 Git, GitHub/Git Lec02

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 [버전]

$ git tag -a v1.1 -m 'pro git version 1.1'


$ git tag

v1.1


$ git show v1.1

tag v1.1

Tagger: Yun DoWon <ysyun@yuwin.co.kr>

Date:   Tue Jan 8 19:40:20 2013 +0900


pro git version 1.1


commit 329db048ff7af2d417588e28da50a6c53fb1bd84

Author: Yun DoWon <ysyun@yuwin.co.kr>

Date:   Thu Dec 27 11:07:26 2012 +0900


    add content in build.gradle


3) Lightweight Tag : git tag [버전]

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

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

$ git tag v1.1w


$ git tag

v1.1

v1.1w


// 단순히 커밋 정보만 보여준다

$ git show

commit 329db048ff7af2d417588e28da50a6c53fb1bd84

Author: Yun DoWon <ysyun@yuwin.co.kr>

Date:   Thu Dec 27 11:07:26 2012 +0900


    add content in build.gradle


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

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

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

 $ git tag -v v1.1

object 329db048ff7af2d417588e28da50a6c53fb1bd84

type commit

tag v1.1

tagger Yun DoWon <ysyun@yuwin.co.kr> 1357641620 +0900


pro git version 1.1

error: no signature found

error: could not verify the tag 'v1.1'


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

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

$ git log --pretty=oneline

329db048ff7af2d417588e28da50a6c53fb1bd84 add content in build.gradle

f856853c5b0ac53483f9d14fe1b3ec6ef0fdbca7 Update build.gradle

03ca40a6026b9144f15cc8988ad6539049d36486 Create build.gradle

49c657f59b787b0ee8409782cd1d5ff16b78033d Initial commit


// 메시지를 -m을 넣지 않으면 하기와 같이 오류 발생함

$ git tag -a v1.2 03ca40a

fatal: no tag message?


$ git tag -a v1.0.1 03ca40a -m 'v1.0.1'


$ git tag

v1.0.1

v1.1

v1.1w


$ git show v1.0.1

tag v1.0.1

Tagger: Yun DoWon <ysyun@yuwin.co.kr>

Date:   Tue Jan 8 19:57:06 2013 +0900


v1.0.1


commit 03ca40a6026b9144f15cc8988ad6539049d36486

Author: 윤도원 (영식) <ysyun@yuwin.co.kr>

Date:   Wed Dec 26 17:55:01 2012 -0800


    Create build.gradle


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

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

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

$ git push origin v1.1

Username for 'https://github.com':

Password for 'https://ysyun@yuwin.co.kr@github.com':

Counting objects: 1, done.

Writing objects: 100% (1/1), 169 bytes, done.

Total 1 (delta 0), reused 0 (delta 0)

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

 * [new tag]         v1.1 -> v1.1


$ git push origin --tags

Username for 'https://github.com':

Password for 'https://ysyun@yuwin.co.kr@github.com':

Counting objects: 1, done.

Writing objects: 100% (1/1), 159 bytes, done.

Total 1 (delta 0), reused 0 (delta 0)

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

 * [new tag]         v1.0.1 -> v1.0.1

 * [new tag]         v1.1w -> v1.1w


posted by 윤영식
2012. 12. 27. 11:18 Git, GitHub/Git Lec02

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


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

// 프로젝트 복제 

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

Cloning into 'pro_git'...

remote: Counting objects: 3, done.

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

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


$ cd pro_git


$ git remote

origin


// 같은 프로젝트에 대해서 여러 기여자가 있을 수 있다. 

$ git remote -v  

origin  https://github.com/ysyun/pro_git.git (fetch)

origin  https://github.com/ysyun/pro_git.git (push)


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

$ git remote -v

dowon   $ (fetch)

dowon   $ (push)

origin  https://github.com/ysyun/pro_git.git (fetch)

origin  https://github.com/ysyun/pro_git.git (push)


// 기존 잘 못 설정된 내역 삭제

$ git remote rm dowon


$ git remote -v

origin  https://github.com/ysyun/pro_git.git (fetch)

origin  https://github.com/ysyun/pro_git.git (push)


// 새로운 remote alias 추가 

$ git remote add dowon  https://github.com/ysyun/pro_git.git


// 확인

$ git remote -v

dowon   https://github.com/ysyun/pro_git.git (fetch)

dowon   https://github.com/ysyun/pro_git.git (push)

origin  https://github.com/ysyun/pro_git.git (fetch)

origin  https://github.com/ysyun/pro_git.git (push)


// 리모트 저장소 이름 변경 

$ git remote rename dowon young


// 확인

$ git remote -v

origin  https://github.com/ysyun/pro_git.git (fetch)

origin  https://github.com/ysyun/pro_git.git (push)

young   https://github.com/ysyun/pro_git.git (fetch)

young   https://github.com/ysyun/pro_git.git (push)


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

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

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

// fetch로 새로 추가한 build.gradle 파일 가져오기 fetch 수행

$ git fetch origin

From https://github.com/ysyun/pro_git

   49c657f..03ca40a  master     -> origin/master


// 못가져옴 

$ ls

README.md


// pull로 새로 추가한 build.gradle 파일 가져오기 fetch 수행

$ git pull origin

Updating 49c657f..03ca40a

Fast-forward

 build.gradle | 3 +++

 1 file changed, 3 insertions(+)

 create mode 100644 build.gradle


// 가져옴 

$ ls -alrt

total 5

drwxr-xr-x   13 yuwonsys Administ     4096 Dec 27 10:45 ..

-rw-r--r--    1 yuwonsys Administ       38 Dec 27 10:45 README.md

-rw-r--r--    1 yuwonsys Administ       37 Dec 27 10:58 build.gradle

drwxr-xr-x   14 yuwonsys Administ     4096 Dec 27 10:58 .git

drwxr-xr-x    5 yuwonsys Administ        0 Dec 27 10:58 .


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

// 내용확인

$ cat build.gradle

task gzip << {

  println "gzip"

}


// remote에서 build.gradle 내역 수정함 -> fetch로 가져오기 시도 

$ git fetch origin

remote: Counting objects: 5, done.

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

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

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

From https://github.com/ysyun/pro_git

   03ca40a..f856853  master     -> origin/master


// 변경 내역 파일 fetch 못함 

$ cat build.gradle

task gzip << {

  println "gzip"

}

// remote에서 build.gradle 내역 수정함 -> pull로 가져오기 시도 

$ git pull origin

Updating 03ca40a..f856853

Fast-forward

 build.gradle | 1 +

 1 file changed, 1 insertion(+)


// 변경 내역 파일 pull하여 가져왔음 

$ cat build.gradle

task gzip << {

  println "gzip"

  println "ok"

}


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

// 맨 하단 내역을 로컬에서 추가한다 

$ cat build.gradle

task gzip << {

  println "gzip"

  println "ok"

  println "are you sure?"

}


// 상태를 확인해 보면 modified 상태이므로 Staging Area -> Git Directory로 이동해야 한다 

$ git status

# On branch master

# 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:   build.gradle

#

no changes added to commit (use "git add" and/or "git commit -a")


// -a 옵션으로 Git Directory로 바로 commit 한다

$ git commit -a -m "add content in build.gradle"

[master 329db04] add content in build.gradle

 1 file changed, 1 insertion(+)


// commit 완료 확인

$ git status

# On branch master

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

#

nothing to commit, working directory clean


// 변경 내역을 리모트의 master 브랜치로 push 한다 (github 사용시 ID/PWD 입력함)

$ git push origin master

Username for 'https://github.com': ysyun@yuwin.co.kr

Password for 'https://ysyun@yuwin.co.kr@github.com':

Counting objects: 5, done.

Delta compression using up to 2 threads.

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

Writing objects: 100% (3/3), 345 bytes, done.

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

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

   f856853..329db04  master -> master


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

$ git remote show origin

* remote origin

  Fetch URL: https://github.com/ysyun/pro_git.git

  Push  URL: https://github.com/ysyun/pro_git.git

  HEAD branch: master

  Remote branch: // pull 하여 오는 리모트 브랜치 목록 보여줌

    master tracked

  Local branch configured for 'git pull': // Merge 브랜치를 알려줌

    master merges with remote master

  Local ref configured for 'git push':  // master 브랜치가 master 브랜치로 push 함 

    master pushes to master (up to date)


posted by 윤영식
2012. 12. 24. 11:39 Git, GitHub/Git Lec02

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


> Git 저장소 만들기 

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

$ mkdir pro_git


$ cd pro_git


$ git init

Initialized empty Git repository in d:/git-repositories/pro_git/.git/


$ ls -alrt

total 4

drwxr-xr-x   13 yuwonsys Administ     4096 Dec 24 11:01 ..

drwxr-xr-x    9 yuwonsys Administ     4096 Dec 24 11:01 .git

drwxr-xr-x    3 yuwonsys Administ        0 Dec 24 11:01 .


$ touch README.md


$ git add README.md

$ git commit -a -m "add readme.md file"

[master (root-commit) 3b7d2a8] add readme.md file

 0 files changed

 create mode 100644 README.md



> 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 파일이 있는지 보여준다
// tracked이면서 modified 상태 파일이 없음 표시
$ git status
# On branch master
nothing to commit, working directory clean

// Untracked 파일 추가 
$ touch aa.txt

// Untracked 파일 목록을 보여줌 
$ git status
# On branch master
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       aa.txt
nothing added to commit but untracked files present (use "git add" to track)

// tracked 파일인 README.md 파일에 내용을 입력함
$ vi README.md

// Tracked 파일과 Untracked 파일 목록을 보여줌 
$ git status
# On branch master
# 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:   README.md
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       aa.txt
no changes added to commit (use "git add" and/or "git commit -a")
  • git add <파일명 또는 디렉토리경로명> : Tracked 상태로 만들면서 Staged 상태가 된다 
// aa.txt 파일을 add 하여 tracked+staged 상태로 변경함 
$ git add aa.txt

$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       new file:   aa.txt
#
# 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:   README.md
#
  • Modified 상태의 파일을 Stage 하기 

// 수정하여서  Changes not staged for commit: 으로 표현된 README.md파일을 Staged 상태로 변경하기 

$ git add README.md


$ git status

# On branch master

# Changes to be committed:

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

#

#       modified:   README.md

#       new file:   aa.txt

#

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

// 이미 Staged 상태인것을 다시 수정한다

$ vi README.md


// 상태를 확인해 보면 README.md 파일이 Staged 에도 존재하고 modified 상태에도 존재한다.

// 만일 commit을 하게 되면 Staged 상태의 READM.md파일이 커밋된다. 

// 다시 git add README.md를 해준다

$ git status

# On branch master

# Changes to be committed:

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

#

#       modified:   README.md

#       new file:   aa.txt

#

# 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:   README.md

#


// modified 상태의 파일을 staged 상태로 변경한다 

$ git add README.md


// 다시 상태 확인 

$ git status

# On branch master

# Changes to be committed:

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

#

#       modified:   README.md

#       new file:   aa.txt

#

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

# comment

*.a  # 확장자 .a 인 파일 무시

!lib.a # lib.a 파일은 무시하지 않음

/TODO # 루트 디렉토리에 있는 TODO 파일 무시

build/  # build/ 디렉토리 모든 파일 무시

doc/*.txt # doc/*.txt는 무시 그러나 doc/another/*.txt 파일은 무시하지 않음

  • git diff : Staged와 Unstaged 상태의 변경 내용을 보기 (git status 는 단순 상태 정보만을 보여주지만 git diff는 변경 내용을 볼 수 있다)
// aa.txt 파일안에 test라고 내용을 입력한다 
$ vi aa.txt

// working directory의 modified상태와 staging area의 staged 상태의 내역 차이를 비교하고 내용을 보여준다
// 즉 staged 상태가 아닌 파일을 비교해 볼 수 있다. (즉, Ustaged 상태인 것들만 보여준다)
$ git diff
diff --git a/aa.txt b/aa.txt
index e69de29..9daeafb 100644
--- a/aa.txt
+++ b/aa.txt
@@ -0,0 +1 @@
+test

// git diff --cached : staged 와 git directory간의 변경내역을 보고 싶을 경우 
// Staging Area 와 저장소에 커밋한 것을 비교해 볼 수 있다. (즉, Staged 상태인 것들만 보여준다)
$ git diff --cached
diff --git a/README.md b/README.md
index e69de29..47086e9 100644
--- a/README.md
+++ b/README.md
@@ -0,0 +1,2 @@
+hi pro git
+by dowon
diff --git a/aa.txt b/aa.txt
new file mode 100644
index 0000000..e69de29
  • git commit <fileName option> -m <message> : Staging Area 파일을 정일한다. 즉, Staged 파일만 해당 된다. git add 하지 않은 파일은 Modified 상태로 남음.

// master 브랜치에 커밋했고, 체크섬은 9160d86 이라는 의미

$ git commit aa.txt -m "add test file"

[master 9160d86] add test file

 1 file changed, 1 insertion(+)

 create mode 100644 aa.txt

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

// 내용 수정

$ vi README.md


// 현재 상태 : modified 상태가 있지만 Staging Area를 거치지 앟고 바로 Git Direcotry (로컬 저장소)로 보내고 싶을 경우 

$ git status

# On branch master

# Changes to be committed:

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

#

#       modified:   README.md

#

# 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:   README.md

#


// -a 옵션 사용 단, 파일은 최소 1회 이상 commit 이 된 것이어야 한다 

// master 브랜치에 6efd594 체크섬으로 commit 되었음

$ git commit -a -m "modified README.md"

[master 6efd594] modified README.md

 1 file changed, 2 insertions(+)


// commit 이 되었음 

$ git status

# On branch master

nothing to commit, working directory clean

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

// 삭제된 파일이 Staging Area에 Deleted 상태로 있음을 알려준다 
$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       deleted:    aa.txt
#

// commit 하여 Staging Area에 있는 Deleted 상태의 파일을 제거한다 
$ git commit -m "delete aa.txt"
[master b5da470] delete aa.txt
 1 file changed, 1 deletion(-)
 delete mode 100644 aa.txt

// aa.txt 파일이 제거되었다. 
$ git status
# On branch master
nothing to commit, working directory clean
  • git mv <from파일> <to파일> : 파일 이름 변경하기를 하면 Staging Area에 Renamed 상태로 된다.
// 이름을 변경(옮긴다)
$ git mv README.md README

// Staging Area에 Renamed 상태
$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       renamed:    README.md -> README
#
  • git log : 커밋 히스토리 보기. 가장 최근 커밋이 가장 먼저 나온다. -p 옵션은 커밋의 diff 결과를 보여준다. -2 는 두개의 결과만 보여준다. -p 옵션은 diff이기 때문에 동료의 변경 내용을 빠르게 확인 할 수 있다. --stat 각 커밋의 통계 정보를 보여줌. --pretty는 사용자 정의가능 (oneline, short, full, fuller, format 옵션 예, --pretty=oneline). --graph는 브랜치 그래프를 보여줌
// -p 변경 내역을 포함하고 -2  최근 2개만 보여줌 
$ git log -p -2
commit b5da4702608e2980a38d51416af79a35b7fcd904
Author: Yun DoWon <ysyun@yuwin.co.kr>
Date:   Mon Dec 24 14:01:50 2012 +0900

    delete aa.txt

diff --git a/aa.txt b/aa.txt
deleted file mode 100644
index 9daeafb..0000000
--- a/aa.txt
+++ /dev/null
@@ -1 +0,0 @@
-test

commit 6efd594f461e0e71d655efab90cf2341f8d9e290
Author: Yun DoWon <ysyun@yuwin.co.kr>
Date:   Mon Dec 24 13:54:48 2012 +0900

    modified README.md

diff --git a/README.md b/README.md
index e69de29..00ed50f 100644
--- a/README.md
+++ b/README.md
@@ -0,0 +1,2 @@
+hi pro git
+by dowon yun

// 통계 정보를 보여줌 
$ git log --stat
commit b5da4702608e2980a38d51416af79a35b7fcd904
Author: Yun DoWon <ysyun@yuwin.co.kr>
Date:   Mon Dec 24 14:01:50 2012 +0900

    delete aa.txt

 aa.txt | 1 -
 1 file changed, 1 deletion(-)

commit 6efd594f461e0e71d655efab90cf2341f8d9e290
Author: Yun DoWon <ysyun@yuwin.co.kr>
Date:   Mon Dec 24 13:54:48 2012 +0900

    modified README.md

 README.md | 2 ++
 1 file changed, 2 insertions(+)

commit 9160d863411cd3ef7c7977bff6d405ad41608b58
Author: Yun DoWon <ysyun@yuwin.co.kr>
Date:   Mon Dec 24 13:48:06 2012 +0900

    add test file

 aa.txt | 1 +
 1 file changed, 1 insertion(+)

commit 3b7d2a8903cd5b02344ce89b3ff4386ff3f3a038
Author: Yun DoWon <ysyun@yuwin.co.kr>
Date:   Mon Dec 24 11:04:33 2012 +0900

    add readme.md file

 0 files changed

// 한줄로 보여주기 : 내용을 많을 경우 유용함 
$ git log --pretty=oneline
b5da4702608e2980a38d51416af79a35b7fcd904 delete aa.txt
6efd594f461e0e71d655efab90cf2341f8d9e290 modified README.md
9160d863411cd3ef7c7977bff6d405ad41608b58 add test file
3b7d2a8903cd5b02344ce89b3ff4386ff3f3a038 add readme.md file

// format 형식을 준다 
$ git log --pretty=format:"%h -%an, %ar : %s"
b5da470 -Yun DoWon, 15 minutes ago : delete aa.txt
6efd594 -Yun DoWon, 22 minutes ago : modified README.md
9160d86 -Yun DoWon, 29 minutes ago : add test file
3b7d2a8 -Yun DoWon, 3 hours ago : add readme.md file

// 브랜치 히스토리까지 본다 
$ git log --pretty=format:"%h %s" --graph
* b5da470 delete aa.txt
* 6efd594 modified README.md
* 9160d86 add test file
* 3b7d2a8 add readme.md file
* format 옵션 내역

Option Description of Output

%H Commit hash

%h Abbreviated commit hash

%T Tree hash

%t Abbreviated tree hash

%P Parent hashes

%p Abbreviated parent hashes

%an Author name

%ae Author e-mail

%ad Author date (format respects the –date= option)

%ar Author date, relative

%cn Committer name

%ce Committer email

%cd Committer date

%cr Committer date, relative

$s  Subject


* git log 옵션들

--since --after : 명시한 날짜 이후의 커밋만 검색. 예)git log --since=2.weeks : 2주 동안 만들어진 커심들만 조회

--until, --before : 명시한 날짜 이전의 커밋만 검색 

--author : 저자를 지정할 수 있다. 

--committer : 입력한 커밋터의 커밋만 조회 

--grep : 커밋 메세지에서 키워드를 검색

-- <path1> <path2> : 해당 경로 밑의 커밋 히스토리를 조회 


// commit hash와 subject만을 보여주고 저작자 Yun DoWon 이라는 사람의 23이전 커밋 내역 검색

$ git log --pretty="%h - %s" --author="Yun DoWon" --since="2012-12-23"

b5da470 - delete aa.txt

6efd594 - modified README.md

9160d86 - add test file

3b7d2a8 - add readme.md file


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

[Pro Git] Git Alias 사용하기  (0) 2013.01.08
[Pro Git] Tag 사용하기  (0) 2013.01.08
[Pro Git] 리모트 저장소 관리하기  (0) 2012.12.27
[Pro Git] Git 설치와 최초 설정하기  (0) 2012.12.24
[Pro Git] DVCS역사  (0) 2012.12.24
posted by 윤영식
2012. 12. 24. 10:49 Git, GitHub/Git Lec02

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


> Git 설치

  • Git은 curl, zlib, openssl, expat, libiconv를 필요로 한다 
// Fedora yum 이용
$ yum install curl-devel expat-devel gettext-devel openssl-devel zlib-devel
$ yum install git-core

// 데비안 apt-get 이용
$ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext libz-dev libssl-dev
$ apt-get install git-core
// 윈도우 설치
http://code.google.com/p/msysgit  다운로드하여 설치한다

$ tar -zxf git-1.8.1.tar.gz

$ cd git-1.7.2.2
$ make prefix=/usr/local all
$ sudo make prefix=/usr/local install
  • Git이 이미 설치되었다면 최신버전 소스를 다음과 같이 받을 수 있다. 

git clone https://github.com/git/git.git



> Git 환경파일

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

// user 밑의 .gitconfig 파일 내역 

[user]

name = Yun DoWon

email = ysyun@yuwin.co.kr

[http]

postbuffer = 524288000

[push]

default = upstream

[core]

autocrlf = true

[color]

ui = auto


// 현재 프로젝트의 .git/config 파일 내역 

[core]

repositoryformatversion = 0

filemode = false

bare = false

logallrefupdates = true

symlinks = false

ignorecase = true

hideDotFiles = dotGitOnly

[remote "origin"]

url = https://github.com/ysyun/jmqtt_client.git

fetch = +refs/heads/*:refs/remotes/origin/*

[branch "master"]

remote = origin

merge = refs/heads/master


// 전체 설정 내역 보기 : git config {key} 명령으로 특정 Key에 대한 값 확인 (Help 명령: git help config)

$ git config --list

core.symlinks=false

core.autocrlf=true

color.diff=auto

color.status=auto

color.branch=auto

color.interactive=true

pack.packsizelimit=2g

help.format=html

http.sslcainfo=/bin/curl-ca-bundle.crt

sendemail.smtpserver=/bin/msmtp.exe

diff.astextplain.textconv=astextplain

rebase.autosquash=true

user.name=Yun DoWon

user.email=ysyun@yuwin.co.kr

http.postbuffer=524288000

push.default=upstream

core.autocrlf=true

color.ui=auto

core.repositoryformatversion=0

core.filemode=false

core.bare=false

core.logallrefupdates=true

core.symlinks=false

core.ignorecase=true

core.hidedotfiles=dotGitOnly

remote.origin.url=https://github.com/ysyun/jmqtt_client.git

remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*

branch.master.remote=origin

branch.master.merge=refs/heads/master


posted by 윤영식
2012. 12. 24. 10:00 Git, GitHub/Git Lec02

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의 핵심이다. 


posted by 윤영식
prev 1 next