git 써보니 좋은 점 하나

git status했을 때 변경된 파일이 현재 기준으로 상대 경로로 출력된다.
mercurial에서는 항상 repository의 홈 기준으로 경로를 출력해서 파일을 열때 귀찮았는데 git은 그런 점은 좋네.

아직 hg outgoing, incoming 에 대응되는 명령어를 잘 몰라서 제대로 사용하지 못하고 있지만…

불안불안

알 수 없는 이유로 개발 서버에 만든 mercurial repository에 push가 안되는 문제때문에 그냥 수동으로 파일을 관리하고 있다. 너무 불편하다. 시뮬레이션 서버와 개발 서버간에 소스를 매번 일일이 옮겨야 하고.

빨리 git을 배워서 바꿔봐야겠다.

mercurial vs. git

mercurial를 사용하다 git을 사용하니 기존에 mercurial에서 사용하던 명령어가 어떻게 매칭되는 지 잘 모르겠다.

hg incoming 명령어가 아주 유용했는데 git에는 없는 듯하고, hg diff -r revision으로 특정 revision하고 비교하는 기능도 많이 사용했는데 git에서 아직 못 찾겠고. 없을 리가 없는데.

결정적으로 분명히 git push를 했는데 왜 origin repo에 반영이 안되는 걸까?

Synology 4.3에 Git 설치하기

이번 DSM 4.3 버전에 git 패키지가 추가되어 있는데 예상과 달리(아니면 당연하게도) 그냥 패키지만 설치되는 정도네요.
최소한 git 서버 설정하는 방법을 제공해줬으면 했는데 git패키지를 설치할 정도면 git 설치는 다 알거라고 가정한 건지 좀 아쉽네요.

거두절미하고, git 패키지를 설치하려면 아래 링크에 있는 대로 하면 되는데 ssh 암호 안 물어보게 하는 내용은 제외하고 꼭 필요한 내용만 정리하면 다음과 같습니다.

  1. 우선 git 사용자 계정을 만듭니다.
  2. git 패키지를 설치합니다. 실은 1, 2번 순서는 아무래도 상관없습니다.
  3. 시작버튼(?)을 누르면 나오는 아이콘 중에 Git Server를 클릭해서 나오는 화면에 git 서버에 접속할 계정을 git을 선택합니다.
    참고로 git 계정은 git-shell을 사용해서 git 명령어만 수행할 수 있습니다. 아래 나오는 명령어를 수행하려고 git 계정으로
    접속을 시도하면 안됩니다.
  4. admin이나 root 계정으로 synology 에 접속합니다.
  5. /var/services/homes/git 으로 이동합니다. 1번에서 생성한 git 사용자 계정의 홈 디렉토리입니다.
  6. 기호(?)에 맞게 repository를 만듭니다.
    mkdir -p repo/test_1
    cd repo/test_1
    git init —bare
  7. 이제 git 디렉토리를 git 사용자가 접근할 수 있도록 권한을 변경합니다. 4번에서 admin이나 root로 접속했기 때문에 git으로 바꾸지 않으면 권한 문제가 발생합니다.
    cd /var/services/homes/git
    chown -R git:users .

이제 외부에서 git client로 접속합니다.

git clone ssh://git@NAS_IP/var/services/homes/git/repo/test_1

혹은 git 계정이 첫번째 하드 volumes1에 있는 경우 아래와 같이 해도 동일합니다.

git clone ssh://git@NAS_IP/volumes1/homes/git/repo/test_1

핵심은 repository를 만들때는 git 계정이 아닌 admin이나 root로 접속해서 작업한다.
git repository 관리를 위한 위한 별다른 기능은 없다 입니다.

참고 http://forum.synology.com/enu/viewtopic.php?f=229&t=71382

hg serve랑 유사한 git 명령은?

git daemon.

단 차이점이 있는데 hg serve는 mercurial repository에서만 실행할 수 있기 때문에 2개 이상의 repository가 있으면 각각의 위치에서 별도로 실행해야 한다. 덕분에 port 번호도 2개 이상이 필요.

하지만 git daemon 명령은 git repository 가 모여있는 상위 디렉토리에서 한번만 실행하고, 원격 머신에서 clone등의 작업을 할 때 주소에 directory 이름만 추가하면 되기 때문에 하나의 port만을 사용해도 여러 repository를 동시에 서비스 할 수 있다.
git daemon 훨씬 편한 듯한데. 대신 git 프로토콜을 사용. hg serve는 http를 사용하기 때문에 웹 브라우저에서도 보기 쉬운데. git에서 http를 사용하고 싶으면 gitweb같은 걸 써야 한다고

git daemon —reuseaddr —base-path=. —export-all —verbose —port=9000
git clone git://1.1.1.1:9000/project_a/.git project_a
git clone git://1.1.1.1:9000/project_b/.git project_b

Pro git – chapter 3

브랜치

언제 사용하나?

  • 신규 기능이 요구될때 해당 기능 개발 용 브랜치를 분리해서 독립적으로 개발 진행
  • bug-fix가 요구될 때 우선 브랜치를 분리해서 bug-fix 후 확인이 완료되면 master에 merge.
  • 신규 기능 개발 도중에 bug-fix가 요구되는 경우에도 master를 기준으로 bug-fix용 브랜치를 만들어 작업한 후 master에 merge한 후 다시 신규 기능 개발 브랜치에 merge한다. 단 마지막 작업은 bug-fix가 반영된 master와 신규 기능 개발 브랜치를 merge할 수도 있지만, 신규 기능 개발 브랜치에서 하는 게 맞지 않을까?

명령어

git branch branch_name [base branch] // create a new branch
git checkout branch_name // switch the branch
git branch -d branch_name // destroy the branch

혹은 아래와 같이 명령어 하나로

git checkout -b branch_name [base branch] // create and switch to the branch

base branch 를 지정하지 않으면 HEAD가 가리키는 branch에서 branching함. 그러므로 local에서 branch를 만든 후 그 브랜치에서 다시 브랜치를 만들 수 있다. 혹은 remote 서버에서 pull한 branch에서 작업용 브랜치를 만들 수도 있다. 다음은 origin에 있는 feature_2 브랜치에서 branch_3를 만드는 예 (git checkout -b feature_3 origin:feature_2)

주의사항
브랜치에서 개발하다 다른 브랜치에서 개발할 필요가 있는 경우 가능한 현재 브랜치의 작업 내용을 check-in하고 가는 것이 좋다. 아직 commit하지 않은 파일이 checkout 할 브랜치와 충돌나면 브랜치를 변경할 수 없다.(?????) Stashing이나 commit amending으로 해결할 수 있다고 하는데…. 좀 더 공부가 필요

remote branch

* remote branch를 fetch한다고 해서 remote branch가 만들어지는 것은 아니고 브랜치 포인터만 생기는 거다. 일반 브랜치와의 달리 해당 브랜치는 수정할 수 없다.

mergetool