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

Publication

06-21 09:30

Category

Recent Comment

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 peter yun 윤영식
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 peter yun 윤영식
TAG Pro Git
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 peter yun 윤영식
TAG Pro Git
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


posted by peter yun 윤영식
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 peter yun 윤영식
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 peter yun 윤영식
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 선화

posted by peter yun 윤영식
TAG GIT
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 peter yun 윤영식
TAG GIT
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 peter yun 윤영식
TAG GIT
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] 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 peter yun 윤영식
TAG GIT
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] History 이용 및 관리하기  (0) 2012.12.13
[Git] Merge 종류와 충돌 해결하기  (0) 2012.12.12
[Git] Reset 사용하기  (0) 2012.12.11
[Git] Hash Object 정보보기  (0) 2012.12.11
posted by peter yun 윤영식
TAG GIT
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] Merge 종류와 충돌 해결하기  (0) 2012.12.12
[Git] Reset 사용하기  (0) 2012.12.11
[Git] Hash Object 정보보기  (0) 2012.12.11
posted by peter yun 윤영식
TAG GIT
2012. 12. 11. 11:28 Git, GitHub/Git Lec01

Git의 로컬 Repository에 저장된 commit 내역에서 이전 commit 내역으로 이동하고 싶을 경우. HEAD를 조작함으로써 가능하다. 


  • 지금 까지 커밋 내역 보기 : git reflog  (하기 내역으로 파란색으로 3 번의 commit 이 존재한다)
git reflog
c6d5478 HEAD@{0}: commit: add license properties
aa64af1 HEAD@{1}: checkout: moving from master to rb_1.0
aa64af1 HEAD@{2}: checkout: moving from master to master
aa64af1 HEAD@{3}: merge rb_1.0: Fast-forward
e13af6f HEAD@{4}: checkout: moving from rb_1.0 to master
aa64af1 HEAD@{5}: commit: License Info about mqtt client for java
e13af6f HEAD@{6}: checkout: moving from master to rb_1.0
e13af6f HEAD@{7}: commit: add eclipse foundation software user agreement propert
475d6ae HEAD@{8}: clone: from https://github.com/ysyun/jmqtt_client.git


  • c6d5478 commit 내역에서 aa64af1 commit 내역으로 이동하기 : git reset --soft HEAD~  (staging, working 영향없음)
  • --mixed 는 staging을 local repository와 같게 만든다. 즉, staging에 HEAD정보를 복사하여 영향줌. working 영향없음 
  • --hard 는 staging, working 둘다 영향을 줌
$ git reset --soft HEAD~

yuwonsystem01@YSYUN91005152 /d/git-repositories/jmqtt_client (rb_1.0)
$ git reflog
aa64af1 HEAD@{0}: reset: moving to HEAD~
c6d5478 HEAD@{1}: commit: add license properties
aa64af1 HEAD@{2}: checkout: moving from master to rb_1.0
aa64af1 HEAD@{3}: checkout: moving from master to master
aa64af1 HEAD@{4}: merge rb_1.0: Fast-forward
e13af6f HEAD@{5}: checkout: moving from rb_1.0 to master
aa64af1 HEAD@{6}: commit: License Info about mqtt client for java
e13af6f HEAD@{7}: checkout: moving from master to rb_1.0
e13af6f HEAD@{8}: commit: add eclipse foundation software user agreement propert
475d6ae HEAD@{9}: clone: from https://github.com/ysyun/jmqtt_client.git

// git reset에서 이전 commit 이동하였으나 다시 앞선 커밋인 c6d5478 로 원복하고 싶을 경우
$ git reflog
aa64af1 HEAD@{0}: reset: moving to HEAD~
c6d5478 HEAD@{1}: commit: add license properties
// 위에서 HEAD@{1} 을 reset하면 다시 최신 HEAD로 간다 
$ git reset HEAD@{1}


  • aa64af1 commit 으로 이동했을 때 상태 정보를 확인 : git status  (c6d5478 commit 되기전 rename 명령을 내렸었음)
$ git status
# On branch rb_1.0
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       renamed:    license.dat -> license.properties

// 만일 staging에 있는 변경내역을 반영하고 싶지 않을 경우 
// 변경 파일이 하나 존재 
$ git status
# On branch feature_input_data
# 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:   app/views/moving_average.html
#
no changes added to commit (use "git add" and/or "git commit -a")

// 설명문의 내역에 따라 파일이 있는 경로명과 함께 입력 
$ git checkout -- app/views/moving_average.html

// status로 다시 확인해 보면 방금 변경된 특정 staging에 있는 파일 내역을 이전 commit 당시 상태로 되돌려 놓았음
$ git status
# On branch feature_input_data
nothing to commit, working directory clean

  • Git 에서 HEAD, Branch는 Pointer이다 

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


'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
[Git] Hash Object 정보보기  (0) 2012.12.11
posted by peter yun 윤영식
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
[Git] Hash Object 정보보기  (0) 2012.12.11
posted by peter yun 윤영식
TAG GIT
2012. 11. 26. 11:38 Git, GitHub

git에서의 commit은 오직 로컬 레파지토리와 관계가 있다. SVN이 자신의 로컬 PC에 있다고 생각하면 된다. 개발자 혼자서 마음대로 가지고 놀 수 있는 레파지토리인 셈이다. 


어디에서 수행할 수 있을까? (참조)

  • workspace
    • commit -a -m 'msg'  : "workspace" -> "local repository"
  • index
    • commit -m 'msg' : "index" -> "local repository"
    • commit --amend :  "index" -> "local repository" (마지막 commit 수정하고 새로운 commit을 한다 )


commit이란?  (참조)

  • workspace 또는 index(stage)의 소스를 local repository로 저장하면서 "새로운 commit object"가 생성된다. 
    • 이때 HEAD와 현재 Branch가 가르키는 포인터는 "새로운 commit object" 주소로 바뀐다
    • index의 포인터도 "새로운 commit object" 주소로 바뀐다 


posted by peter yun 윤영식
2012. 11. 22. 11:11 Git, GitHub

diff는 commits 된 것들 사이에서 차이를 보기위한 방법이다. (참조

어디에서 수행할 수 있는가?

  • workspace 입장 (Working Directory)
    • git diff : "workspace" <- "index"
    • git diff HEAD or <another branch> : "workspace" <- "local repository"
  • index 입장 (Stage)
    • git diff : "workspace" <- "index"
    • git diff --cached : "index" <- "local repository"
  • local repository 입장
    • git diff HEAD  or <another branch>  : "workspace" <- "local repository"
    • git diff <commit 1> <commit 2> : "local repository" commit 1 -> commit 2
    • git diff --cached : "index" <- "local repository" 


위 내용에 대한 정리를 보자. 

> local repository 내부 비교 : git diff <commit> <commit>  예) git diff da985 b325c
> local repository와 index 비교 : git diff --cached
> local repository 특정 branch와 workspace 비교 : git diff HEAD 또는 git diff maint

> index와 workspace 비교 : git diff



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

[Git] 실수를 다시 원복하고 싶을 경우 많이 사용하는 명령들  (0) 2013.01.13
[Git] commit 사용하기  (0) 2012.11.26
[Git] diff 사용하기  (0) 2012.11.22
[Git] Ubuntu 에 설치하기  (0) 2012.11.14
[Git] Branch 전략  (1) 2012.11.14
SVN에 대하여 이해하기  (0) 2012.09.20
posted by peter yun 윤영식
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] Ubuntu 에 설치하기  (0) 2012.11.14
[Git] Branch 전략  (1) 2012.11.14
SVN에 대하여 이해하기  (0) 2012.09.20
[Git] 레퍼런스 모음  (0) 2012.09.10
posted by peter yun 윤영식
TAG GIT
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
[Git] Branch 전략  (1) 2012.11.14
SVN에 대하여 이해하기  (0) 2012.09.20
[Git] 레퍼런스 모음  (0) 2012.09.10
posted by peter yun 윤영식
2012. 10. 25. 17:48 Git, GitHub/GitHub

GitHub의 Wiki는 단순 페이지만을 생성하는데, 일반 위키들 처럼 오른쪽에 목차가(Sidebar) 나오고 하단에는 footer등을 넣고 싶을 경우 다음을 참조하자 



내 프로젝트에서도 한번 써봐야 겠다. 그동안 wiki 페이지 기능이 단순해서 사용하지 않았는데, 확장을 할 수 있게 되어 있었다. 

  • OSS인 골룸(gollum)을 통해서 GitHub의 wiki를 확장할 수 있다
  • Sidebar 넣기 
    • _Sidebar.ext 파일을 만든다. 물론 내용은 wiki 형식을 따르면 된다 : .md파일이 없는 모든 sub directory에 영향을 미친다 (요건 체크해 볼일이다)
    • wiki git을 checkout 한다 (wiki의 Git Access 탭에서 git url을 얻으면 됨)
    • wiki repository를 local로 다 가져온후 _Sidebar.md 파일을 만든다
    • .md 파일안에 markdown syntax로 link를 [[link]] 형식으로 넣는다 
    • _Sidebar.md 파일을 commint한후 origin master에 push 한다 
  • Header 넣기
    • _Header.ext 파일 만든다 (wiki 포멧)
    • _Header.md 파일 만든다 (markdown syntax)
  • Footer 넣기
    • _Footer.ext 파일 만든다 (wiki 포멧)
    • _Footer.md 파일 만든다 (markdown syntax)  


요점만 정리했는데, 실제로 해볼일~~에구구

posted by peter yun 윤영식
TAG Github
2012. 9. 20. 00:48 Git, GitHub

SVN에 대하여 잘 설명해 놓은 글이 있네요. Branch와 HEAD, revision에 대한 내용등과 merge할때 상황별 정책도 정리해 놓았네요. 


강추 : http://ghostsheep.tistory.com/9

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

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