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

Publication

Statistics Graph

Recent Comment

2013.01.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 peter yun 윤영식
2013.01.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 peter yun 윤영식
TAG Pro Git
2013.01.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 peter yun 윤영식
TAG Pro Git
2013.01.25 09:05 Git, GitHub/Git Lec02

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


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

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

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

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


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

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


  - 메세지 작성

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

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

    + 글은 현재형을 사용한다 

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

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

   예)

   

저작자 표시 비영리 변경 금지
신고
posted by peter yun 윤영식
TAG Pro Git
2013.01.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 peter yun 윤영식
2013.01.08 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.01.08 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
prev 1 next