머가필요해

Linux 환경에서 build (compile) 시간을 짧게하기 위한 방법을 찾아보면 꼭 나오는 방법이 있다.
바로 ccache 와 distcc 다!

여기에서는 ccache에 대해서 알아보겠다.

원리는 비교적 간단하다.
처음에 빌드를 할 때에 정보와 함께 그 결과물을 저장하고 있다가,
다음 번 빌드를 할 때엔 정보를 비교해서 같은 파일의 빌드를 한다면 저장하고 있는 결과물을 활용하는 것이다.
그렇게 함으로써 두 번째 빌드부터는 변경된 부분만 빌드를 수행하므로 소요시간이 짧아지는 것이다.




1. 공식 사이트

     - http://ccache.samba.org/
     - License : GPL3

     - 기본적으로 gcc 컴파일에 적용을 할 수 있으며, Cross-compiler (Tool-chain)에도 적용할 수 있다.

     - 안전성에 대해서는 나름 자부를 하고 있는 상당히 오래된 프로젝트이며,
       구글의 안드로이드에서도 공식적으로 옵션으로 적용을 하고 있다.




2. Install

     - Ubuntu에서는 편하게 패키지로 제공을 해준다.

     - 이걸로 끝이다. 간단하지 않은가 ?!




3. PATH

     - ccache를 활용하기 위해서는 PATH 설정만 해주면 된다.

     - 환경파일에서 PATH 값에서 제일 앞에 "/usr/lib/ccache:" 경로를 추가해주면 된다.
     - 일단은 이러면 끝이다.




4. Environment

     - 그러면 대체 왜 "/usr/lib/ccache" 디렉토리를 경로에 추가를 해줘야할까?

     - 검색해서 자료들을 보면 "export CC='ccache cc'"등을 설정하기도 하고,
       Makefile을 수정하기도 하는 등 다른 방식으로 처리하기도 하지만...
     - 최근엔 그냥 '/usr/lib/ccache' 디렉토리를 이용하면 모든 것이 끝이다.

     - Compiler를 모두 ccache로 대체하면 되는 것이다.

     - 만약 Cross-compiler (Tool-chain)을 사용하는 경우라면 위 디렉토리에 링크를 만들어주면 된다.







5. cache dir

     - ccache를 적용하면 빌드 결과물을 어딘가에 저장해놓는다고 했는데, 어디에 위치할까?

     - 상태(status)를 확인하고 싶을 때 사용할 수 있는 명령이다.

     - 기본적으로는 홈 밑의 ".ccache" 디렉토리에 위치하며, 기본 용량제한은 1GB이다.





6. clear

     - 빌드 결과가 왠지 이상하다거나 cache 데이터를 지우고 싶을 때엔 다음 명령으로 처리할 수 있다.

몇 가지 더 옵션들이 있지만, 알고 싶으면 공식 사이트를 참조하기 바란다.
실제로 적용해보면 탁월하게 효과가 있다~!!!

 
오픈소프트웨어 등을 다운받을 때에 가장 자주 접하던 사이트가 예전엔 SourceForge.com이었다.
하지만, 최근에는 GitHub.com이 대세이다.

심지어,
프로그래머 경력 중에서 요즘 가장 각광받는 것이 GitHub.com을 통해서 공개하고 있는 프로젝트가 있는지라고 한단다.

GitHub에 대해서 한 번 살펴보도록 하자.


1. Site

     - 일단 사이트에 접속하자.

     - 상단의 [ Signup and Pricing ]을 클릭하면 된다.

     - 분명히 GitHub는 무조건 무료로 운영되는 자원봉사 단체는 아니다.
       개성강한 많은 사람들이 근무하고 있는 회사다(https://github.com/about/team).
     - 하지만, open source를 개발하는 입장에서는 천국과도 같은 곳이기도 하다.

     - 오픈 소스가 아닌 사적인(?) 프로젝트를 운영하기 위해서도 돈을 주고 repository를 할당 받아야 한다.
     - 또, GitHub 시스템 자체는 오픈 소스는 아니다. 돈을 주고 구매(?)해야만 하는 시스템이다.
       물론 GitHub와 유사한 시스템을 위한 GitLab HQ와 같은 오픈소스 프로젝트들은 있다(http://gitlabhq.com/).



2. Create account

     - 뭐 여하튼 0달러의 유지비로 사용가능한 "Create a free account"를 선택하면 된다.

     - 입력할 사항이 정말 없다. 정말 친절하고도 바람직한 사이트다.
     - 가뿐하게 입력하고 [ Create an account ]를 누르면 된다.

     - 처음엔 정말 깜짝 놀랐다. "아니~ 이렇게 귀여운 이미지들은 대체 뭐야?!"




이걸로 가입 과정은 끝~

응!? 너무 쉽다고?! 뭐 이 다음부터가 진짜로 GitHub에 대한 이야기가 될 것이다.

SSH 공개키도 등록하고, Repository도 만들고 프로젝트도 공유하고, 내 프로젝트에 다른 사람들을 참여도 시키고...
다른 프로젝트를 Fork하기도 하고... 등등...

나름의 목적을 가지고 열심히 포스팅을 하고 있는 블로그이지만,
댓글 하나 없이 몇 날 몇 일이 흐르면 조금 외롭게 되는데, 최근 댓글을 잘 달아주시는 분들이 생겨서 너무 좋다.
그런 감사한 분들 중 한 분이 알고 싶으시다는 내용이기도 하고 내가 하려고 했던 내용이기도 하다.


EGit에 대한 정보는 다음을 참조했다.
     - http://wiki.eclipse.org/EGit/User_Guide


여기에서 알아보고자 하는 내용은 바로 "Eclipse"에서 Git 사용하기!!!



01. Eclipse

     - 개발 환경으로 가장 유명한 도구 중 하나임은 다시 설명할 필요가 없을 것이다.
     - Java 기반의 프로그램으로써 한계를 고스란히 안고 있는 것 또한 사실이다. 무겁다는 말이다.

     - JDK 설치 먼저 해야하는 것은 당연하고...
        → http://www.oracle.com/technetwork/java/javase/downloads/index.html
     - Eclipse 역시 다운 받아서 설치, 아니 압축을 풀어주면 된다.
        → http://www.eclipse.org/downloads/



02. 확인

     - Eclipse에서 사용할 수 있는 Git plugin은 크게 JGit 과 EGit 두 가지가 있다.
     - 그런데, 예전에는 이 plug-in들을 별도로 설치를 해주어야 했지만 최근들어 이걸 기본적으로 제공해주고 있다.

     - 하지만, Eclipse Classic을 설치하면 포함이 안되어있다.

     - Import 하는 부분에 CVS는 있지만, Git은 안보인다.

03. 설치

     - GIt 관련 Plug-in이 내장되어있지는 않지만, 제공은 해주고 있다.

     - [ Help ] → [ Install New Software ]
     - Work with 부분에서 "Indigo"를 골라주자.

     - "Collaboration" 항목을 확장해서 "Eclipse EGit"을 선택하면 된다. 나머지 과정은 그냥 쓕쓕~

     - 설치를 마치고 나면, 재시작을 물어본다. 당연히 재시작해주면 된다.




04. Preference

     - EGit Plug-in의 환경 설정을 하자.

     - [ Window ] → [ Preference ]

     - "Team" → "Git" 항목을 선택하면 위와 같은 화면이 나온다.



05. User Settings

     - 개발 PC에서 Git을 사용하기 위해 환경을 맞출 때에 제일 먼저 해야할 것은 내가 누구인지 알려주는 것이다.

     - 기본적인 환경 설정에 대해서 잘 확인하고 입력해놓자.



06. SSH public key

     - 우리는 지금 Gitolite를 사용하고 있는 환경에 대해서 알아보고 있으므로 공개키를 등록해보자.

     - [ Git ] 항목이 아니라 [ General ] 항목에서 "Network Connections - SSH2" 부분에서 설정을 한다.
     - 앞 포스팅에서 "Git Bash"를 통해 "ssh-keygen"으로 키를 만들었으면 위와 같은 설정을 그대로 사용하면 된다.
     - 물론 만약 다른 경로에 위치하고 있다면, 그에 맞게 변경하면 된다.



07. Import

     - 이제 Remote Repository에 있는 프로젝트를 가져오는 과정에 대해서 알아보자.

     - [ File - Import ] 메뉴를 선택해서 나오는 창을 살펴보면 "Git"이라는 항목이 새로 나온 것이 확인된다.
     - "Projects from Git"을 선택하면 된다.

     - Remote Repository로 부터 받아올 것이니 당연히 "URI"를 선택하면 된다.

     - URI를 작성할 때에 바로 URI를 작성할 필요없이, 밑의 항목들을 입력하면 자동으로 URI가 완성된다.
     - Host, Repository path, Protocol(다시 한 번 ssh 선택해주면 된다), User를 입력해주자.
     - Password는 비워두면 된다. 왜냐하면, 우리는 SSH 공개키를 등록했기 때문이다.

     - 성공적으로 연결이 되면 branch를 선택하는 창이 나온다.

     - 어디에다가 파일들을 받을 것인지, 어느 branch로 시작을 할 것인지, Remote 이름을 확인하자.

     - 그러면 위와 같이 cloning 작업을 수행한다.

     - 다 받아오게 되면 위와 같이 받아온 소스코드를 프로젝트와 어떻게 연결할 것인지를 묻는 화면이 나온다.
     - 일단은 위 스크린샷과 같이 새로운 프로젝트로 만들어보자.

     - 받아온 소스코드 성격에 따라서 프로젝트 타입을 골라주면 된다.

     - 그리고, 프로젝트 名을 적어주면 된다.

     - 그러면, 이제 마무리가 되어야 하는데...

     - 뭔가 이상하지 않은가??????



08. Directory

     - 그렇다. 프로젝트를 만들었는데, 파일들이 안보인다.

     - 앞에서 살펴본 부분에서 Directory들을 한 번 살펴보면 이상한 원인이 보일 것이다.

     - 프로젝트를 만들 때 location을 확인해야 한다.
     - Remote Repository를 clone 받을 때에 지정했던 경로와 동일하게 설정을 해주어야 하는 것이다.

     - 이번에는 제대로 파일들이 보일 것이다!



09. Share Project

     - 그러면 Git 관련 작업을 할 때엔 어떻게 해야할까?!

     - [ Team - Share Project ]를 실행하면 창이 하나 나오는데...

     - 경고 메시지가 나온다. "HOME" 이라는 이름의 환경변수를 설정해야 한다는 말이다.

     - 하지만, 안내메시지처럼 알아서 기본 경로를 잘 잡아준다.
     - 귀찮으면 "Do not show again"을 체크함으로써 끝~

     - 공식 가이드에 의하면 Windows 7 환경에서는 "Users" 디렉토리의 대소문자 오류가 있으니 참고~!!

     - [ Use or create repository in parent folder of project ]에 체크를 하고 "Finish"를 해주면 된다.

     - 모두 설정하고 나면 오른쪽 버튼의 "Team" 항목에 위 스크린샷과 같이 새로운 메뉴가 나타난다.




여기까지~~~~~~
Eclipse 환경에 대해서 너무 길게 포스팅한 것 같지만... 그래도 좀 아쉬운 부분도 있다.



오늘은 이 블로그를 통해서 좋은 인연을 맺게 된 분과 처음으로 만났다.
그로 인해서 너무나 감사한 기회를 얻게 될 것 같은데... 뭔가 정해지면 다시 또 공유해보겠다.

포스팅을 할 때 가장 즐거운 일은 댓글을 확인하는 것이다 ^^
이번에는 저에게 너무나 큰 기쁨을 주는 댓글을 통해 문의하신 것 중 하나에 대해서 포스팅 해보고자 한다.

Gitolite에 대해서 어려워 하시는 분들의 대부분은 Gitolite 때문이 아니라,
SSH에 대한 이해와 더불어 공개키(public key)에 대한 사항 때문에 어려움을 겪게 된다.


Windows에서 공개키 만들고 등록하는 것은 Linux 환경에서 하는 것과 거의 동일하다.
그래도 다시 한 번 되돌아 보는 의미로 살펴보면서 공개키에 대해서 같이 살펴보도록 하겠다.



1. 공개키 등록하기

     - 새로운 사용자, 지금 상황에서는 Windows XP 환경의 사용자가 등록을 하고 싶은 경우를 살펴보자.

     - 왼쪽 하단의 'chaniXP'라는 이름의 사용자가 공개키를 만들어서,
       왼쪽 상단의 gitolite 관리자에게 보내면, 그 관리자가 등록 및 설정을 하고,
       오른쪽의 Server에 push를 하면,
       chaniXP 사용자는 Server로부터 허용된 repositories를 clone 받을 수 있게 되는 것이다.

     - 여기서 중요한 점은 chaniXP라는 사용자는 Server의 계정이 아니다.
     - Gitolite를 사용하게 되면, Server에서는 'git-repo'라는 계정 하나만 있으면 된다.




2. Git Bash

     - Windows 환경에서 Git 설치하기를 하셨다면, Git Bash가 있을 것이다.

     - 무슨 말인지 모르겠다면, 다음 포스팅을 참조하면 된다.
     - http://whatwant.tistory.com/288





3. Windows에서 공개키 만들기

     - Linux 때와 마찬가지로 [ ssh-keygen ]을 실행하여 공개키를 만들어주자.

     - Windows 환경에서도 분명히 사용자 이름이 있으며, home directory는 존재한다.
     - 그냥 엔터만 쳐도 잘 만들어진다.




4. 공개키 보내기

     - Gitolite 관리자에게 공개키를 보내서 등록해달라고 해야한다.
     - 여기에서는 gitolite라는 계정에게 scp를 통해서 공개키를 보내주도록 하겠다.

     - 중요한 점은 이전에도 한 번 언급했지만, 일반적으로 [ 계정명.pub ] 형식의 파일명을 사용한다는 것이다.




5. Gitolite 관리자

     - 이제부터는 Gitolite 관리자가 해야하는 일이다.

     - 우선은 새로운 파일이 잘 들어왔는지 확인을 하고, 그 계정에게 권한을 부여해주면 된다.

     - ./keydir directory 안에 [ chaniXP.pub ]라는 파일이 잘 들어왔는지 확인을 하고,
     - [ ./conf/gitolite.conf ] 환경 파일을 수정해주면 된다.

     - 공개키를 등록한다해도, 그 계정이 어느 repository에 권한을 갖는지 정해주지 않는다면 무용지물이다.




6. push

     - 제일 중요한 과정이다. 바로 서버에 해당 정보들을 보내주어야 모든 것이 이루어진다.

     - 위 스크린샷과 명령어 정리한 내용과 차이가 있다.

     - 정말 종종 실수하는 부분인데, 기존에 등록된 파일의 수정이 아니라 새로운 파일이 등록되었을 경우에는
        [ git commit -a -m "..." ] 명령으로 처리가 되지 않는다. 별도로 등록을 해주어야 하는 것이다!!!!!
     - 이 부분만 주의해서 정리하고 push 해주면 모든 것은 끝난다!!!




강원도 솔비치로 2박3일 가족여행을 다녀오자마자 내 방에 처박혀서 포스팅을 하고 있으니,
우리 아가와 와이프가 째려본다.... ㅋㅋㅋ ^^

솔비치 호텔에서 2박 모두 했는데 바로 앞에 바다가 있어서 아가랑 놀러가기에는 정말 좋은 것 같다.
다만, 아직까지는 물이 차가워서 모래놀이 위주로 했지만...

다음에는 호텔이 아니라 콘도로 예약을 해야겠다 ^___^

Git의 가장 큰 장점인 자유로운 branch, 그 branch의 자유로운 사용의 최종 종착지는 바로 merge다.
즉, branch를 생성해서 자유롭게 작업하다가 그 결과가 쓸만해지면 master에 merge하는 것이 일반적인 경우이다.
그런데, 바로 이 자유로운 branch 때문에 repository 내부가 지저분해질 우려가 다분히 많다.

많은 사용자가 달라붙어서 작업을 하다보면 별의 별 희한한 개발습관을 보여주는 개발자가 꼭 존재하고,
이러한 개발자들로 인해서 master branch가 바보가 되어버리는 경우도 종종 발생한다.

문제는 이러한 경우로 인해서 Git의 안전성을 의심받기까지 한다는 점이다.

제대로 이해를 하고 사용하는 사용자들은 무관하지만,
어설픈 지식으로 말도 안되는 행위를 과감히 행하는 개발자들이 문제가 되는 것인데...

그렇다 하더라도 무조건 그 책임을 무지한 개발자 탓으로 할 수는 없다.

그 부분을 해결하는 것은 해당 repository를 운영하는 담당자의 몫이며,
그러한 부분에 대한 분명한 프로세스 또는 가이드를 제시해주어야 한다.

이런 막중한 책임과 임무를 가진 관리자에게 merge 명령어 외에도 또 하나의 무기를 Git에서 제공해주고 있다.
그것이 바로 rebase 이다.


1. branch

    - rebase를 설명해보기 위해서 상황을 준비해보자.

     - 우선 branch 하나를 만들어 주고,

     - 파일 하나 수정해서 commit까지 해보자.




2. before log

     - rebase 하기 전에 현재 log를 살펴보고 시작하자.

3. rebase

     - 우선은 'hotfix branch'의 log 부터 확인하고,

     - merge 대신에 우리모두 rebase 하자!

     - 어?! 뭔가 rebase가 정상적으로 이루어지지 않은 것 같다!

     - 바로 뒤에 설명을 하겠지만, 위와 같은 상황에서는 rebase를 할 것이 없다.

     - master branch에서 commit 하나 추가해보자.

     - 위 그림과 같이 A commit에서 각 branch 별로 분기를 하도록 한 것이다.

     - 다시 rebase 해보자.
     - 그런데, log를 보면 이전 master branch에서 작업한 내용까지만 있다. 뭐지?!
     - rebase 후 해야하는 것이 fast-forward 해줘야 한다.

     - 어?! 뭔가 이상하지 않은가?
     - merge의 다른 방법이 rebase라는데, rebase를 하고도 결국 다시 merge를 해야하다니???

     - 일단, rebase를 하고 나면 아래와 같은 상태가 된다.

     - 뭔가 다른 점을 찾았는지.....?!
     - A에서 분기를 했던 hotfix branch의 B commit이 사라지고,
       master branch의 C commit 뒤에 새로운 B` commit이 생겼다.

     - rebase는 branch로 인한 commit의 분기를 한 줄로 다시 줄을 세운다. 그것도 새로운 commit을 만들어서...
     - 더불어 신기한 것은 기존의 commit은 사라진다(실제로 물리적으로 지워지는지는 나중에 살펴보겠다).

     - 그런데, 여기서 또 하나 잡아야 하는 포인트는 rebase 후에 master branch의 위치가 기존의 위치다.
     - hotfix branch의 내용을 master branch에 반영하기 위해서는 B` commit의 위치로 master branch가 가야한다.

     - 자료들을 보면 rebase 후 fast-forward 해주면 된다는데, fast-forward가 대체 뭔지....?! ㅋ~ 정답은 merge다.

     - 위와 그림과 같이 이루어진다.



앞에서 적었던 내용에 대해서 정정을 해야할 것 같다.

별도의 branch를 만들어서 작업을 하고 그것을 합치는 방법이 merge와 rebase의 두가지가 있다고 했는데,
이 말은 조금 틀린말 같다.

branch를 만들어서 작업한 내용을 합치는 방법은
바로 (즉시 merge)를 하는 방법과 (rebase 후 merge)를 하는 두 가지 방법이 있다.

rebase를 하는 이유는 commit을 깔끔하게 정리해서 일렬로 줄을 세워서 정리를 해주는 것이다.
즉, branch의 남발로 인해서 commit들이 꼬일 우려가 있는 상황에서 단순화 할 수 있는 좋은 수단이다.


다만, rebase를 사용하는 것은 작업하는 branch가 임시일 때 유용하다.
지속적으로 개발 branch를 유지하는 개발 프로세스를 사용한다면 rebase는 적합하지 않다.



오늘 두산이 KIA의 윤석민을 잡았다~!!! ^^
즐거운 하루~~~~ 인데, 포스팅을 하다보니 새벽 1시가 다가오네.... ㅠㅠ

모두 파이팅~!!!

"Gitolite"는 특이하게 "personal branches"라는 것을 지원해준다.


처음에는 Pro-Git 책에서 이에 대한 언급이 있어서 여기저기 살펴보았었는데,
자료가 너무나 심플하게만 있고 원론적인(?) 이야기만 있어서 그냥 그런갑다~하고 넘어갔었다.


그러다가 회사에서 업무를 하던 중 아래와 같은 개발자의 VOC(?)를 듣게 되었다.

즉, 자신이 작업하는 내용에 대한 백업이 필요하다는 말이었다.



이 이야기를 듣고 처음에는 충격이었다.

Git 의 가장 큰 강점이 바로 "분산 형상 관리"이다.

즉, 작업 내용을 commit 할 때마다 서버에 접근하지 않아도 된다는 점이 Git의 강점이라는 것인데,
commit 한 내용이 로컬에 머무른다는 것이 단점이 될 수도 있다는 사실에 좀 충격이었다!!!

절대 위와 같은 Work Flow로 작업을 하라고 가이드 하는 것은 아니다.
지금 설명을 위해서 위와 같은 branch 정책을 가지고 개발을 한다고 가정을 해보는 것이다. 샘플!!!

아래 글로 적힌 내용에 대해서는 잘 읽어보는 것을 추천한다 ^^
(실제 회사에서 이루어지는 것을 반영한 부분도 있으니...^^)

왼쪽은 Server Repository이고, 오른쪽이 Local Repository이다.

Server에서는 master와 develop branch를 운영하는데,
기본적으로 두 개의 branch 모두 어느 정도 다듬어진 결과물이 올라와야 한다.

빌드를 기준으로 말하자면
Server의 master, develop branch 모두 빌드가 항상 성공되어야 한다.

반면, Local에 있는 develop branch에서 개발자가 열심히 개발을 하는데,
Server의 develop branch에는 빌드가 정상적으로 되는 결과물만 push 해줘야 한다.
즉, 이래 저래 작업한 내용을 막 push 하면 안되고, 그것은 local 안에서 commit만 이루어지도록 해야한다.

그런데, 개발자는 작업한 결과물 뿐만 아니라
작업 중인 내용물에 대해서도 서버에 백업이 되었으면 좋겠다고 하는 것이다.

그래서 개발자는 별도의 branch를 local에 만들어서 작업을 해본다.
my_br 이라는 branch를 만들어서 작업을 하고 그걸 다시 local에 위치한 develop으로 merge를 해주는 방식이다.
이제 이 my_br이라는 branch만 어디 다른 곳에 저장할 수 있으면 되는 것이다.

오른쪽에 새로 생긴 부분과 같이 Local에서 작업한 내역을 push할 수 있는 Server Repository가 있다면...?!



앞에서 우리는 Gitolite 설치와 운영에 대해서 알아보았다.
문제는 대부분의 회사에서 일반 개발자들에게 repository 생성 권한을 주지 않는다는 점이다.

물론 개인적으로 별도의 Git Server를 만들어서 그곳으로 push 하도록 한다던지 뭐 다양한 방법이 있겠지만,
우리의 Gitolite는 Personal Branch라는 기능을 제공해준다.

푸헬~ 위에 주저리 주저리 적었는데, 별 쓸모 없는 말만 주절거린 것 같다.
하지만 뭐 그래도 적은 것이 아까우니까.... ^^



1. Gitolite

     - "personal branch"를 사용하기 위해서는 Gitolite 설정을 해줘야 한다.

 

     - Gitolite의 환경파일을 변경해야하기 때문에 Gitolite 관리자 계정으로 접속하자.
     - [ gitolite-admin.git ] repository를 clone 한 곳으로 이동하자.

     - [ gitolite.conf ] 파일을 수정하면 된다.

     - 위에 별도로 색으로 칠한 부분이 핵심이다.
     - [ /USER/ ]와 같이 되어있는 부분은 일종의 예약어이다. (personal 으로 되어있는 부분은 임의)

     - 위와 같이 하면 [ refs/personal/사용자계정/ ]이라는 네임스페이스를 사용할 수 있게 되는 것이다.
     - 그런데, 왜 브랜치가 아니라 네임스페이스라고 하였을까?!
     - 실제로 사용할 때에는 [ refs/personal/사용자계정/branchname ]과 같이 사용한다.

     - 수정 후 종종 잊는 것이 commit과 더불어 push이다. 꼭 반영하길~




2. push

     - personal branch에 대한 자료가 너무 없어서 개인적으로 알아본 것으로만 정리를 하겠다.
        (적어도 국내 한글로 된 자료 중에서는 최초의 personal branch 관련 자료가 아닐지...)
     - 이제 어떻게 사용하는지 한 번 알아보자.

     - Local에 있는 특정 branch의 내용을 Server의 내 personal branch의 임의의 branch로 push해 주는 것이다.

     - personal branch는 백업의 의미로 사용하는 것이 큰 것으로 보인다.
     - 즉, 그냥 사용하는 branch와는 그 용도가 조금 다른 것이다.
     - 물론 위의 스크린샷과 같이 변경 사항을 포함하는 내용을 push 할 수도 있지만, 그냥도 push할 수 있다.

     - [ git push origin (local branch 名):refs/personal/(계정)/(임의의 branch 名) ]



3. pull

     - 그러면 personal branch 내용을 받아올 때에는 어떻게 할까?

 

     - personal branch의 내용을 내려받을 때엔 임의의 branch로 내려 받는다.

     - [ git pull origin refs/personal/(계정)/(branch 名):(임의의 local branch 名) ]



4. delete

     - 만들었으면 지우는 방법도 알아보자.

 

     - 일반 branch를 삭제하는 것과 같은 방법으로 삭제할 수 있다.




5. Server

     - 이렇게 만든 personal branch는 Server에서 어떻게 확인할 수 있을까요?

     - Server에 위치한 repository를 살펴보면 personal branch의 상황에 대해서 알 수 있다.
     - 위 스크린샷은 delete를 해버려서 안보이지만, 만들어놓은 상태라면 위와 같이 따라가서 확인할 수 있다.




헥헥... 알고보면 별 것도 아닌 내용이지만,
워낙에 설명을 찾아보기 힘든 부분이라서 많은 시간을 할애해야만 했다.

그러던 중에, 여기 이 블로그를 통해서 너무 반가운 소식이 들어와서 잠시 헬렐레~했고,
부처님 덕분에 연휴를 맞이했고,
장모님의 환갑을 맞이했고,
뭐 그런 연유로 이제서야 포스팅~ ^^

앞으로 해야할 부분이 너무나 많이 남았네요~ 부지런히 달려봅시다~!!