Mac OSX 에는 Xcode 라는 좋은 무료 개발도구가 있다. 물론 Mac 에서도 CodeLite, CodeBlocks 와 같은 잘 알려진 오픈소스 개발도구를 쓸 수 있지만, Codeblocks 는 Mac OSX 에서의 안정성이 떨어지는 감이 있고 CodeLite 는 Mac 에서 command-line 프로그램 개발 시 iostream 의 cin 을 제대로 처리 못하는 등 조금씩 문제를 안고 있기 때문에 쓰다 보면 불편함이 쌓이게 되고, 그러다 보니 Apple 에서 Mac 을 가장 잘 지원해 주(는 것으로 믿고 싶은...)는 Xcode 같은 Native app으로 다시 돌아가곤 한다.


이번 글에서는 Xcode 로 C++, Objective-C, Swift 와 같은 언어를 사용한 개발에 있어서, 협업 개발을 위한 git 저장소와 Xcode 가 자체적으로 제공하는 git client 기능을 사용하는 방법을 기록해 두려 한다.


개발자의 결벽증

물론 Remote 저장소에서 repository를 cloning 하거나 Local 저장소에서 작업하다가 그때 그때 push 하면서 "미친 년 널 뛰듯이" 아무렇게나 되는대로 작업할 수는 있다. 그러나 사람마다 기준이나 스타일은 다르겠지만, 하드디스크의 작업 영역에 온갖 너저분한 임시 checkout 디렉토리, 수정하다 만듯한 폴더와 파일 조각들이 여기저기 널려 있는 꼴은, 마치 소스의 indent 가 들쭉날쭉한 참상을 보는 것 만큼이나 속상하는 일이기 때문에 다음과 같은 원칙을 정해 둔다


  • 하나의 프로젝트에 대해 주로 작업하는 Local 저장소와 Remote 저장소의 대응은 1:1 일 것
  • 사용하는 Tool 이 Sublime Text 또는 Sourcetree 이건 Xcode 이건 간에 프로그램 소스가 저장되는 repository는 하나만 존재할 것
  • 프로그램 소스코드와 데이터파일을 제외한 프로젝트파일, 바이너리 실행 또는 오브젝트 파일들은 git 을 통한 버전관리에서 제외 될 것


필요한 것들(또는 지금 쓰고 있는 것들)

  • Remote 저장소(Github, Gitlab 계정 또는 본인만의 git server) - 필자는 Remote git 저장소를 위한 AWS 가상머신(doubleshot.io)
  • Git Client - OSX 에 내장된 자체 git & Sourcetree app



정리해 두려는 것들

  • 이미 존재하는 Remote 저장소를 내려 받고 Xcode 에서 작업하거나 또는,
  • 새로운 Local 저장소를 만들어 Xcode 에서 작업하고, Remote 저장소와 연동, 업로드(보관)



1. Remote 저장소를 내려 받고 Xcode 에서 작업하기


1.1 저장소 이름은 gittest2, Remote 저장소의 주소는 ssh://gituser@doubleshot.io/home/gituser/repos/gittest2 라 하자. 


1.2 가장 먼저, Sourcetree 에서 Remote 저장소를 cloning 해서 Local 로 다운로드 한다. 다음으로 Xcode 에서 작업할 새로운 프로젝트를 생성해 두고, Sourcetree 창을 나란히 배치한다.


해당 repository 에서 R-click, "Show in Finder" click


Finder 에서 저장소 폴더를 선택, Xcode 의 프로젝트 내부로 drag 한다(또는 Finder를 거치지 않고 Sourcetree 에서 Xcode 로 직접 drag 해도 된다)


Xcode 는 외부 폴더를 가져올 때의 옵션을 묻는다. 그림과 같이 설정하고 Finish!(Create Group을 하면 Xcode 내에 그룹이 만들어지고 그 내부에 git 폴더가 논리적으로 참조되고, Create Folder Reference 를 하면 프로젝트 내에 그룹이 만들어지지 않고 git 폴더 자체가 직접 참조된다)


Xcode 프로젝트 안으로 외부 git 저장소가 안전하게 import 되어 있다. 오른쪽 정보창에서 저장된 path 를 확인해 보자. Xcode 가 기본으로 자동 생성해 주는 main.cpp 는 휴지통으로...!



1.3 위의 과정을 거치면 Xcode 내에서 add, commit, push 등 모든 git 기능을 사용할 수 있다. Xcode 프로젝트 내에 Working copy 가 복사되어 만들어지는 것이 아니라, Sourcetree 가 Clone 해 둔 repository를 그대로 사용하는 것이다.



2. Local 저장소로 Xcode 에서 작업하고 Remote 저장소와 연동하기


2.1 Git server 에서 Remote 저장소를 생성해 둔다(이 과정은 아래 2.7 이후에 해도 된다). 저장소 이름은 xcodegit_repo, Remote 저장소의 주소는 ssh://gituser@doubleshot.io/home/gituser/repos/xcodegit_repo 라 하자. 


2.2 Sourcetree 에서 "Create a local repo..." 선택, Local 저장소를 생성한다(이 때, "Also create remote..." Check는 반드시 해제).



2.3 Xcode 에서 작업할 새로운 프로젝트를 생성한다.



Xcode 에서 프로젝트 생성 후, 자동 생성되는 main.cpp 는 휴지통으로... 만약 사용할 필요가 없다면 main.cpp 파일이 속한 그룹 전체를 삭제해도 무방함



2.5 Sourcetree 에서 Local 저장소를 R-click, "Show in finder" 선택. Finder 에서 Xcode 프로젝트 내부로 폴더 drag

Xcode 의 프로젝트 내부로 drag(Sourcetree 에서 직접 drag 해도 된다)


1.2와 마찬가지로 가져오기 옵션 설정



2.6 Xcode 로 가져온 Local 저장소 폴더 R-click, "New file" 을 선택(저장되는 path 확인), 작업할 소스 파일(cpp 등) 생성.



2.7 Xcode 에서 소스 파일을 편집, 저장 후 git add, commit 등 실행(로컬 저장소에 저장)


2.8 작업이 완료된 소스 파일을 Remote 저장소와 연동 저장하기 위해서는 소스 파일이 저장된 폴더 선택, Xcode 메뉴의 "Source Control" 선택, Remote 저장소 정보를 설정한다.


Add Remote 선택


Git server 에서 생성해 둔 Remote 저장소의 주소를 등록


코딩 및 테스트 작업이 끝나면 Xcode 메뉴에서 "Source Control" -> Push 를 통해 Remote 저장소에 업로드할 수 있다


<참고> Git server 와의 연결을 ssh 프로토콜을 통할 경우에는, Xcode 가 생성해 주는 ssh 인증키를 git server 측과 '키교환'을 해 두어야 한다  


- Barracuda -


저작자 표시 비영리 변경 금지
신고
블로그 이미지

Barracuda

Bryan의 MemoLog. 쉽게 익혀 보는 IT 실습과 개념원리, 코딩 세계의 얕은 맛보기들, 평범한 삶 주변의 현상 그리고 進上, 眞想, 진상들



개인용 wiki 사이트, git 서버용으로 쓰던 Amazon EC2 vm에 고정 ip인 소위 Elastic IP를 물리고 인터넷 도메인(doubleshot.io)을 할당해서 쓰고 있다. git 서버의 접속 주소가 바뀌었으니 당연히 그에 맞게 git 의 remote 설정을 바꿔야 해서, 그 과정을 샘플  노트 형태로 작성해 둔다.

* git repository 에 해당하는 디렉토리(MyCppProjects)로 이동하여 변경 이전의 접속 주소를 "git remote" 로 확인
* 접속 방식은 기존 pem 인증키를 이용한 ssh 방식이므로 .git/config 파일의 접속주소 중 도메인 부분을 새로운 도메인(doubleshot.io)으로 교체하고 저장
✔ ~/MyCppProjects [master L|✔] 
22:16 $ git remote -v
wttest ssh://gituser@ec2-52-69-153-237.ap-northeast-1.compute.amazonaws.com/home/gituser/repos/MyCppProjects.git (fetch)
wttest ssh://gituser@ec2-52-69-153-237.ap-northeast-1.compute.amazonaws.com/home/gituser/repos/MyCppProjects.git (push)
✔ ~/MyCppProjects [master L|✔]
22:16 $ vi .git/config
[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
[remote "wttest"]
        url = ssh://gituser@doubleshot.io/home/gituser/repos/MyCppProjects.git
        fetch = +refs/heads/*:refs/remotes/wttest/*


* 변경된 주소를 확인하고 push 를 실행하여 git 서버와 동기화 진행

✔ ~/MyCppProjects [master L|✔] 

22:26 $ git remote -v

wttest ssh://gituser@doubleshot.io/home/gituser/repos/MyCppProjects.git (fetch)

wttest ssh://gituser@doubleshot.io/home/gituser/repos/MyCppProjects.git (push)

✔ ~/MyCppProjects [master L|✔] 

22:26 $ git push wttest master

Everything up-to-date

✔ ~/MyCppProjects [master L|✔] 

22:31 $


- Barracuda -



저작자 표시 비영리 변경 금지
신고
블로그 이미지

Barracuda

Bryan의 MemoLog. 쉽게 익혀 보는 IT 실습과 개념원리, 코딩 세계의 얕은 맛보기들, 평범한 삶 주변의 현상 그리고 進上, 眞想, 진상들



ungit은 git 사용자를 위한 유용한 GUI 브라우저이다. ungit 은 node.js 상에서 동작하므로 이참에 node.js 를 source로부터 build하고 ungit 을 설치하는 과정을 메모해 둔다.




1. tarball 소스로부터 node.js 빌드 & 설치


bryan@bryan-laptop1:~/Downloads$ wget https://nodejs.org/dist/v0.12.7/node-v0.12.7.tar.gz

bryan@bryan-laptop1:~/Downloadssudo apt-get install build-essential python-dev

bryan@bryan-laptop1:~/Downloadstar xvzf node-v0.12.7.tar.gz

bryan@bryan-laptop1:~/Downloadscd node-v0.12.7/

bryan@bryan-laptop1:~/Downloads/node-v0.12.7./configure

bryan@bryan-laptop1:~/Downloads/node-v0.12.7make

bryan@bryan-laptop1:~/Downloads/node-v0.12.7sudo make install

bryan@bryan-laptop1:~/Downloads/node-v0.12.7node --version

v0.12.7


2. ungit 설치 및 테스트


bryan@bryan-laptop1:~sudo npm install -g ungit

bryan@bryan-laptop1:~$ cd git/bumblebee-ui/

✔ ~/git/bumblebee-ui [master ↓·4|✔] 

10:36 $ ungit



<관련 글 보기>

2015/08/03 - [Git Tip] Git Branch와 상태를 보여주는 Linux Prompt(bash-git-prompt)

2015/07/31 - [Git Tip] Git 브랜치를 보여주는 Linux 프람프트(prompt) - Ubuntu 14.04, bash 기준

2015/07/24 - [Git Tip] Git에 대한 궁금증들

2015/07/23 - [Git Tip] AWS EC2 VM을 이용한 Git 서버설정과 git 기본 사용법


- Barracuda -


저작자 표시 비영리 변경 금지
신고
블로그 이미지

Barracuda

Bryan의 MemoLog. 쉽게 익혀 보는 IT 실습과 개념원리, 코딩 세계의 얕은 맛보기들, 평범한 삶 주변의 현상 그리고 進上, 眞想, 진상들


지난 번 Git 을 위한 Linux Prompt 변경 내용에 추가하여, Github.com 프로젝트 중에서 쓸만 한 것이 있어서 소개해 두도록 한다. 단순히 Branch 명을 보여 주는 것에서 벗어나서 브랜치의 자세한 상태까지 Prompt 에서 보여 주므로 아주 실속 있는 Git용 프람프트 유틸리티가 아닐까 한다. 설치 과정도 아주 간단하여 쉽게 적용해 볼 수 있다.


* 적용 대상: Bash를 사용하는 Linux 또는 Mac

* 설치 방법: https://github.com/magicmonty/bash-git-prompt 에 있는 내용 참조


* 설치 과정(Ubuntu 14.04, Bash 사용)

bryan@bryan-XenPC:~cd ~

bryan@bryan-XenPC:~git clone https://github.com/magicmonty/bash-git-prompt.git .bash-git-prompt

bryan@bryan-XenPC:~$ vi .bashrc <== .bashrc 의 case "$TERM" ... 문 다음의 적당한 위치에 추가

...

# If this is an xterm set the title to user@host:dir

case "$TERM" in

xterm*|rxvt*)

    PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u@\h: \w\a\]$PS1"

    ;;

*)

    ;;

esac


# gitprompt configuration

# Set config variables first

GIT_PROMPT_ONLY_IN_REPO=1

# GIT_PROMPT_FETCH_REMOTE_STATUS=0   # uncomment to avoid fetching remote status

# GIT_PROMPT_START=...    # uncomment for custom prompt start sequence

# GIT_PROMPT_END=...      # uncomment for custom prompt end sequence

# as last entry source the gitprompt script

# GIT_PROMPT_THEME=Custom # use custom .git-prompt-colors.sh

# GIT_PROMPT_THEME=Solarized # use theme optimized for solarized color scheme

source ~/.bash-git-prompt/gitprompt.sh


# enable color support of ls and also add handy aliases

...

bryan@bryan-XenPC:~$ source .bashrc


* ~/.bash-git-prompt/themes 내에 테마파일을 설정해 두고 커스텀 테마를 지정해서 사용할 수도 있다

* 다음은 bash-git-prompt 프로젝트 홈에 소개 된 프롬프트 심볼들에 대한 간단한 설명들이다


[Local Status Symbols] 로컬브랜치 상태 심볼들

    ✔: repo가 더 이상 건드릴 부분 없이 clear 함

    ●n: n개의 staging된(index 에 add되었지만 commit은 되지 않은) 파일들이 있음

    ✖n: n개의 merge 되지 않은 파일들이 있음

    ✚n: n개의 수정되었지만 staging되지 않은(add가 필요한) 파일들이 있음

    …n: n개의 트래킹 되지 않은 파일들이 있음

    ⚑n: n개의 스태쉬(임시 저장소)가 존재함

[Branch Tracking Symbols]리모트저장소와 비교된 트래킹 심볼들

    ↑n: 리모트저장소보다 n개의 commit 단계가 앞서 있음(push 가 필요한 상태 암시)

    ↓n: 리모트저장소보다 n개의 commit 단계가 거슬러 내려가 있음

    ↓m↑n: 리모트저장소에 비해 브랜치가 갈라져 있음, 위 2가지가 복합됨

     L: 로컬브랜치만 존재함


[관련 글]

2015/07/23 - [Git Tip] AWS EC2 VM을 이용한 Git 서버설정과 git 기본 사용법

2015/07/24 - [Git Tip] Git에 대한 궁금증들

2015/07/31 - [Git Tip] Git 브랜치를 보여주는 Linux 프람프트(prompt) - Ubuntu 14.04, bash 기준


- Barracuda -


저작자 표시 비영리 변경 금지
신고
블로그 이미지

Barracuda

Bryan의 MemoLog. 쉽게 익혀 보는 IT 실습과 개념원리, 코딩 세계의 얕은 맛보기들, 평범한 삶 주변의 현상 그리고 進上, 眞想, 진상들


Git을 사용하는 방식은 명령형(커맨드라인; Command line; 또는 터미널 방식) 이거나 GUI Client 형(Mac, Windows)이거나 둘 중 하나일 것이다. Git의 내부 메커니즘을 알기 위해서이기도 하지만 커맨드라인 방식이 익숙해 지면 훨씬 수월해 지는 경우가 많은 듯 하다. 이 때 어쩔 수 없이 git status 를 쳐서 현재 어떤 브랜치에서 작업중인지를 수시로 확인해야 하는데, Linux 의 프람프트를 개조해서 사용하면 편리한 점이 많으므로 그 방법을 정리한다.


"Git 은 브랜치로 시작해서 브랜치로 울고 웃다가 브랜치로 끝난다" - Barracuda -


* 준비물: github 에서 공개된 아래의 스크립트를 계정의 Home에 내려 받아 둔다

* git-prompt.sh 는 Bash, Zsh 를 지원한다

bryan@bryan-XenPC:~$ curl -o ~/.git-prompt.sh https://raw.githubusercontent.com/git/git/master/contrib/completion/git-prompt.sh


* 홈 디렉토리의 .bashrc를 아래와 같이 수정하고 적용

* 기존의 프람프트에 영향, 변형이 없어야 하며, Git 으로 관리되는 작업 디렉토리에서만 프람프트가 자동으로 변경

bryan@bryan-XenPC:~$ vi .bashrc

...

# For Git prompt # <== Homedir에 .git-prompt.sh 가 있는지 확인하는 if문 추가

if [ -f ~/.git-prompt.sh ]; then 

    source ~/.git-prompt.sh 

fi


if [ "$color_prompt" = yes ]; then

    if [ -f ~/.git-prompt.sh ]; then # <== 원래의 PS1 설정을 위한 if 블록에 __git_ps1 변수 값을 끼워넣는 if 문 추가

        PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$$(__git_ps1 "(Branch:%s)") '

    else

        PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '

    fi

else

    if [ -f ~/.git-prompt.sh ]; then # <== 위와 마찬가지

        PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$$(__git_ps1 "(Branch:%s)") '

    else

        PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '

    fi

fi

unset color_prompt force_color_prompt

...


* 스크립트가 정상 작동하는지 디렉토리를 이동하면서 확인해 본다

~/git-test/gittest 디렉토리와 ~/PycharmProjects/PyTestProjects 는 git 으로 트래킹되는 working 디렉토리이다

bryan@bryan-XenPC:~$ source .bashrc

bryan@bryan-XenPC:~$ cd git-test/gittest/

bryan@bryan-XenPC:~/git-test/gittest$(Branch:develop) cd ../../kernel_src/

bryan@bryan-XenPC:~/kernel_src$ cd ../PycharmProjects/PyTestProjects/

bryan@bryan-XenPC:~/PycharmProjects/PyTestProjects$(Branch:master)


[관련 글]

2015/07/23 - [Technical/Development] - [Git Tip] AWS EC2 VM을 이용한 Git 서버설정과 git 기본 사용법

2015/07/24 - [Technical/Development] - [Git Tip] Git에 대한 궁금증들

2015/08/03 - [Git Tip] Git Branch와 상태를 보여주는 BASH-GIT-PROMPT



- Barracuda -


저작자 표시 비영리 변경 금지
신고
블로그 이미지

Barracuda

Bryan의 MemoLog. 쉽게 익혀 보는 IT 실습과 개념원리, 코딩 세계의 얕은 맛보기들, 평범한 삶 주변의 현상 그리고 進上, 眞想, 진상들


Git 을 다루는 엔지니어들이 점점 늘고 있다. 한글 입력상태에서 자판으로 git을 치면 '햣' 이 된다, 햣~! 너도 나도 써야한다라고 하니, 이게 마치 무슨 대세가 된 건 아닌가 착각도 하게 되는데, 막상 써보려니 손에 익고 간편한 cvs, svn 과는 비슷하면서도 뭔가 좀 다르고 어렵기도 하다.


근데, 간편안내서 같은 곳을 보면 "어렵지 않아요 ;)" 하면서 사람을 막 꼬드긴다(가서 보면 더 너무 쉽게 써놔서 더 아리송하다). 그게 대체 뭐길래...하면서 약도 좀 오르고 궁금하기도 하다. 이제, 하나 하나 따져가면서 왜 그런가 고민하고 정리해 두는 버릇이 있는 필자가 git을 한 번 다루어 보려 한다.



Git을 써야 하는 이유


결론부터 간단히 말하자면, Git 은 약간의 개념공부와 실습이 필요한 Tool 이다. cvs, svn 과는 달리 Git은 Distributed+VCS(버전관리도구) 이고 cvs가 하지 못하는 일을 가능하게 하기 때문이다. Linux의 주인공 리누즈 토발츠는 자신이 만든 Git을 소개하면서 cvs를 'devil'(악마...라기 보다는 죄악에 가깝다고 본다) 라고 까지 한다(아래 유튜브 영상 참고). cvs나 svn을 쓰면서 branch-merge하기 전에 풀백업을 받아 두는 엔지니어의 심정이라면 Git을 써야만 하지 않을까?



왜 Git을 써야 하는지에 대해 인터넷에 수많은 문서들이 올라오고 있지만, 이 페이지를 보고 좀 더 명료해 지리라 생각된다.

http://pismute.github.io/whygitisbetter/



아마도, 이 정도 개념만 잡고 개발팀에 투입 돼도 "이 친구 쫌 하는데!" 라는 시선을 받아 볼 수 있을런지도 모르겠다. 칭찬은 엔지니어에게 스팀팩을 놔주는 거 아닐까...



Git 에 관한 필수 용어와 관행(Convention) 또는 약속



master, branch와 origin


* Repository(저장소=줄여서 repo)가 만들어지면(git init) 최초로 유일하게 존재하는 브랜치가 master branch 이고 전체 저장소의 본류가 된다. 이 브랜치는 그 자체로 'master' 라는 이름을 가진다

* 'origin' 은 약속된 이름으로, 현재 push(원격 서버에 업로드) 또는 clone/pull(원격서버로부터 내려받음), Fetch(원격 repo내용 확인) 하려는 원격저장소(서버의 repo)의 기본(default) 이름이다

  - git clone git://remote.blah/test.git 을 하게 되면 자동으로 현재 디렉토리에 test 가 만들어지고 원격저장소의 이름은 'origin' 이 된다(-o 옵션으로 마지막 인수로 새로운 디렉토리명(예: test_dev)을 덧붙여서 다른 이름을 부여할 수도 있다)

  - 굳이 원격저장소의 이름을 origin 으로 하지 않아도 무방하지만, 프로젝트의 최초에 생성되는 원격저장소는 오리지널 이라는 의미의 'origin' 이란 이름을 가지도록 한다

  - origin 이 아닌 원격저장소의 이름은 git remote rename oldname newname , git remote rm name1 ... 이런 식으로 변경 또는 삭제가 가능하다. 또는 다른 저장소이름을 origin 으로 바꾸는 것도 물론 가능하다



작업 디렉토리, 로컬/원격저장소(repository), Index, Head


*작업디렉토리는 버전을 관리할 소스 파일들이 있는 곳이며, git init 으로 초기화한 디렉토리와 그 하위 디렉토리 전체가 관리 대상이다. 이 곳의 전체 또는 일부의 파일들은 git add 로 index라는 가상공간에 등록(staging 단계) 되며, Git에 의한 관리 대상이 된다. 수정 또는 새로이 추가된 파일은 항상 git add 명령으로 스테이징단계를 거쳐야 한다

* Staging 단계의 파일들은 git commit 명령에 의해 repo라는 가상 공간에 기록되며, commit 되는 각 단계의 Head[각주:1] 내용이 기록된 시간 순서대로 꼬리를 물고 늘어서 있는 구조이다. commit 시에 저장되는 내용은 파일 전체 내용이 아닌, 각 파일들의 변경사항들이 묶음으로 기록됨으로써 빠르고 가벼운 동작이 잘 유지된다.

* Git에서 repository는 로컬(development)과 원격에 각각 존재하므로, 개념을 잘 구분해서 써야한다


Git protocol


* Git이 원격저장소와 통신하는 방식은 4가지가 있다

  - 로컬 프로토콜: 로컬 디스크나 NFS로 연결된 저장소일 경우 file:///디렉토리/xxx.git 과 같은 방식으로 연결

  - SSH프로토콜: ssh를 통한 암호화된 통신 방식으로 ssh를 이용할 로그인 계정이 있을 때 사용할 수 있다. 공개용 프로젝트에는 부적합하다

  - Git프로토콜: SSH와 유사하지만 전송 속도가 빠르며 TCP 9418port를 사용한다.  별도의 인증수단이 없어서 Gitosis 와 같은 별도의 인증패키지를 사용해야 한다

  - HTTP/HTTPS 프로토콜: 의미 그대로 HTTP 또는 HTTPS 프로토콜을 그대로 사용하며, 방화벽에 크게 구애받지 않는다


Log 와 Commit Identifier


* Git으로 수행한 모든 commit들은 빠짐 없이 저장소에 기록되며, 각 commit 단계별로 유일한 Key(해시 키) 값(예: f6f9e... 처럼 생긴 16진수들) 이 관리된다.

* git log --graph 와 같은 명령으로 이 Key 값을 조회한 후 revert(되돌리기), cherry-pick(브랜치 가져오기), Tag(꼬리표 달기) 등의 명령을 수행하게 된다


Tag 달기


* Git에서 수행한 commit 단계(의 Key 값)에 대해 의미를 가진 꼬리표를 달아서 버전관리의 이정표를 구분하도록 한다

  - 예: git tag 1.0.0 edbbca65716825e770d1509e9359612260c08c73



Git 과 전문가들이 권고하는 관행(Convention)


reponame.git 형태로 repository 디렉토리명을 쓴다


유일한 오리지널 저장소(repo)인 경우 원격 저장소에 "origin" 이라는 이름을 붙여 쓴다


Branch 의 종류와 네이밍 관행


Vincent Driessen 이 제시하는 브랜칭 모델


backlogtool.com/git-guide 에서 정리한 브랜칭 모델. 위와 모델은 같으나 단순화 되어 눈에 더 잘 들어온다


* Main 브랜치: Master, Develop

* Supporting(Topic) 브랜치: Feature, Release, Hotfix

 - Feature 브랜치: Develop 에서 분기하는 일종의 Topic 브랜치(들), 완료되면 Develop에 병합(merge)한 후 Push

 - Release 브랜치: Develop 에서 릴리즈를 위한 분기(release-브랜치명), 완료되면 Master에 병합한 후 release 태깅

    배포 후 Develop에 병합

 - Hotfix 브랜치: 긴급 수정 작업, Master 에서 긴급 수정작업을 위한 분기(hotfix-브랜치명), 완료되면 Master에 병합, 배포 후 Develop에 병합


[참고]  이 브랜칭 모델이 모든 경우에 정답일 수는 없다. 프로젝트나 사업의 성격상, 어떤 경우는 여러 개의 Release가 고객사별로 브랜칭되어 동시에 병행/교차되어 진행되는 복잡한 구조가 더 적합할 수도 있다. 단, 관리의 복잡성으로 인한 부담이 너무 크지 않다면 말이다. 결국 Git 라는 Tool 자체의 자유도로 인하여, 기존의 SVN등으로 해결 못하던 많은 한계점들을 피해갈 수 있는 가능성이 생겼다는 것은 분명해 보인다.


도움이 되는 온라인 실습/강의/설명 자료


[한글로 된 친절한 문서 페이지들]

https://git-scm.com/book/ko/v2

http://backlogtool.com/git-guide/kr/

http://www.slideshare.net/einsub/svn-git-17386752

http://sapeyes.blog.me/70118257910

https://opentutorials.org/module/217

http://www.creativeworksofknowledge.com/2014/09/03/git-intro-and-common-workflow/



[영문으로 된 실습, 설명, 강의 페이지들]

http://pcottle.github.io/learnGitBranching/ - 한글(일부만) 지원

http://gitref.org/

https://www.atlassian.com/git/tutorials/

http://gitimmersion.com/index.html

http://wildlyinaccurate.com/a-hackers-guide-to-git/


[관련 글]

2015/07/23 - [Git Tip] AWS EC2 VM을 이용한 Git 서버설정과 git 기본 사용법


- Barracuda -

  1. 마치 카세트테이프의 헤드(또는 구식 LP 레코드의 바늘) 처럼, 재생되는 현재의 위치를 가리키는 개념이다. 그래서 merge 옵션에 보면 --no-ff (패스트포워드 하지마삼...) 같은 것도 있다. [본문으로]
저작자 표시 비영리 변경 금지
신고
블로그 이미지

Barracuda

Bryan의 MemoLog. 쉽게 익혀 보는 IT 실습과 개념원리, 코딩 세계의 얕은 맛보기들, 평범한 삶 주변의 현상 그리고 進上, 眞想, 진상들


git(깃) 서버를 Amazon EC2 인스턴스에 설치하고, Repo를 운영 관리하는 기초과정 정리


* 준비해야 할 것들

 - 서버: AWS EC2 t2.micro, ubuntu 14.4, 접속주소: ec2-xx.amazonaws.com

 - 클라이언트: Ubuntu 14.4 PC, EC2 vm ssh 접속을 위한 보안 키파일(여기서는 AWSKP_as1.pem)


EC2 vm측, git 서버 설치 과정


* 필수 패키지 설치

root@aws-ubt14-as01:~# apt-get install git-core

root@aws-ubt14-as01:~# apt-get install openssh-server


* linux 계정(=gituser) 추가, 권한 설정 및 key pair 생성

* 이 방법은 git 계정을 공용으로 사용하는 경우로 사용자 개별 설정은 불가(사용자별 권한 설정 등 세부적인 관리가 필요할 경우 gitolite 와 같은 관리 패키지 사용 필요)

root@aws-ubt14-as01:~# adduser --home /home/gituser --shell /bin/bash gituser

root@aws-ubt14-as01:~# visudo <== 아래 line 추가

...

gituser ALL=(ALL) ALL

...

root@aws-ubt14-as01:~# su - gituser


* 생성된 Key pair의 공용(public)키 부분을 .ssh/authorized_keys 에 추가

gituser@aws-ubt14-as01:~ssh-keygen -b 1024 -f gituser -t dsa

gituser@aws-ubt14-as01:~cat gituser.pub >> .ssh/authorized_keys


gituser@aws-ubt14-as01:~chmod 600 .ssh/authorized_keys

gituser@aws-ubt14-as01:~sudo chown -R gituser.gituser .ssh/

gituser@aws-ubt14-as01:~$ mkdir repos; cd repos


* Remote client에서 사용할 작업디렉토리 생성, repo 설정

* 새로운 repo 가 필요해질 때마다 별도로 작업해 주어야 함

gituser@aws-ubt14-as01:~/repos$ mkdir ec2new.git; cd ec2new.git

gituser@aws-ubt14-as01:~/repos/testprj.git$ git init --bare --shared



Remote client(개발자 PC)측 git 설정


* 기존 ec2new 프로젝트를 Local PC에서 git 서버에 push(업로드&동기화)하는 과정까지...

* EC2 vm에서 생성한 key pair의 개인(private)키 파일을 local 로 복사해 와서 저장

* ssh-add 로 키 파일이 자동 적용되게 한 후, EC2 vm 의 gituser 계정에 ssh 로그인이 가능한지 확인

bryan@bryan-XenPC:~$ scp -i AWSKP_as1.pem root@ec2-xxx.amazonaws.com:/home/gituser/gituser ./gituser.pem

bryan@bryan-XenPC:~$ ssh-add /home/bryan/gituser.pem

bryan@bryan-XenPC:~$ ssh gituser@ec2-xxx.amazonaws.com


* 작업 디렉토리(프로젝트: ec2new) 가 있다고 가정

bryan@bryan-XenPC:~/git-test/ec2new$ ls -l

합계 12

-rw-rw-r-- 1 bryan bryan  6  7월 22 20:39 README

-rw-rw-r-- 1 bryan bryan 31  7월 22 20:39 a.c

-rw-rw-r-- 1 bryan bryan 51  7월 22 22:33 b.cpp


* 현재 디렉토리를 git repo 등록(초기화)

bryan@bryan-XenPC:~/git-test/ec2new$ git init


* git repo에 현재 디렉토리의 모든 파일 추가(tracking 가능=staging상태=index에 등록)

bryan@bryan-XenPC:~/git-test/ec2new$ git  add .


* a.c 파일을 수정하였다면 수정 사실을 git에 알린다(관리 대상으로 등록 의미)

bryan@bryan-XenPC:~/git-test/ec2new$ git  add a.c


* Commit 이전까지는 Staging 단계, commit 이되면 HEAD에 기록(= local에 commit)됨

* 즉, git에서 commit 은 local 에서의 최종 저장 단계

bryan@bryan-XenPC:~/git-test/ec2new$ git commit -m "1st commit"

[master 346b586] Modified a.c

 1 file changed, 1 insertion(+)


* Remote repo 주소를 git에게 알림

bryan@bryan-XenPC:~/git-test/ec2new$ git remote add ec2new ssh://gituser@ec2-xxx.amazonaws.com/home/gituser/repos/ec2new.git


* Remote repo 확인

bryan@bryan-XenPC:~/git-test/ec2new$ git remote -v

ec2new ssh://gituser@ec2-xxx.amazonaws.com/home/gituser/repos/ec2new.git (fetch)

ec2new ssh://gituser@ec2-xxx.amazonaws.com/home/gituser/repos/ec2new.git (push)


* Remote repo 에 업로드(최종 기록)

bryan@bryan-XenPC:~/git-test/ec2new$ git push ec2new master

Counting objects: 5, done.

Delta compression using up to 4 threads.

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

Writing objects: 100% (3/3), 341 bytes | 0 bytes/s, done.

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

To ssh://gituser@ec2-xxx.amazonaws.com/home/gituser/repos/ec2new.git

   eaacfc7..346b586  master -> master

[관련 글]

2015/07/24 - [Technical/Development] - [Git Tip] Git에 대한 궁금증들


- Barracuda -


저작자 표시 비영리 변경 금지
신고
블로그 이미지

Barracuda

Bryan의 MemoLog. 쉽게 익혀 보는 IT 실습과 개념원리, 코딩 세계의 얕은 맛보기들, 평범한 삶 주변의 현상 그리고 進上, 眞想, 진상들