머가필요해

세입자의 설움으로 전셋집 옮기고 체력고갈,
더불어 진급자 회식 및 결혼 예비 후배들과의 회식들로 인한 추가 체력고갈...
그리고 마지막으로 안또라이들 학습.... 그리고 결정적인 귀차니즘으로 또 다시 오랜만에 찾아온 Git... ^^

조금 더 공부하고 조금 더 분석해야하는데, 그게 말처럼 쉽지가 않다.... 월급쟁이의 비애라고하면 변명이겠지!? ^^


오늘은 remote repository에 대해서 조금 더 알아보고자 한다.

$ git clone /srv/repository/BareRepo.git $ cd ./BareRepo $ git remote $ git remote -v

[ git remote ]라는 명령어는 어떨 때 사용하는걸까!?
어떤 repository의 어떤 branch를 사용하고 있는지 알기 위해서 또는 관리를 위해서 사용하는 명령어이다.

만약 여러 repository를 사용할 경우 그 리스트도 주르륵 보여준다.


여기에서 당연히 의문을 가져야 한다!!!
"여러 repository를 사용"한다고?!

 

$ git remote add other /srv/repository/otherRepo.git $ git remote $ git remote -v

이미 "BareRepo.git"을 가져온 상태에서, 그 안에서 [ git remote add ]를 통해서 다른 repository를 가져온 것이다.
'other'라는 것은 임의로 해당 repository를 지칭하는 별명을 지어준 것이다.

본래 있던 것은 'original'이라는 이름이고, 새로 추가한 것은 'other'라는 이름이다.


그러면, 여기에서 또 하나의 의문이 생겨야 한다.

하나의 공간에 2가지의 것이 같이 있으면, 지금 작업하고 있는 것이 어떤 것에 속하는지 어떻게 알려줄까?

$ git fetch other

아직 branch에 대해서 알아보지 않았으므로 이에 대한 설명은 뒤로 넘기겠다.

여하튼, [ git fetch ]라는 명령어를 이용하여 두 가지를 오락가락 할 수 있다!
그런데, 지금 "otherRepo.git"이라는 repository를 넣었다고 했는데 그 파일들은 어디에 있을까?!

지금 사용하고 있는 "otherRepo.git" repository에 들어있는 파일은 "readme.txt"이다.
그런데, "BareRepo.git" repository에도 같은 이름의 파일이 있다.
"혹시 그래서 뭔가 충돌이 난 것은 아닐까?!"라는 생각이 들었다.

그래서, 응급으로 "otherRepo.git"에 "other.txt" 파일을 push해 넣었다.
그런 후 다시 fetch를 해보았다.

다시 fetch를 했음에도 파일 내용은 바뀐 것이 없다.


이 즈음해서 아! 내가 변경 사항을 받아오는 것에 대해서 살펴보지 않았구나~!!!라는 생각이 번뜩!
그래서 바로 직전 글 [ git pull ]에 대해서 블로깅을 했다!!!!

$ git pull $ git pull other master

그냥 [ git pull ]을 하게 되면 뭔가 받아오는데, 우리가 새로 추가한 repository, otherRepo의 자료는 보이질 않는다.
그러면 어떻게 해야 otherRepo의 내용을 받아올 수 있을까?!

[ git pull other master ]라고 하면 된다.
그런데, 위의 스크린샷을 보면 알겠지만 'CONFLICT'가 발생을 했다.

앞에서도 말했지만, 두 개의 repository에 'readme.txt' 파일이 똑같은 이름으로 존재하고있다.
그래서 충돌이 난 것이다.
보통은 git이 똑똑하게 자동으로 merge를 해주기도 하는데, 위의 경우엔 그것도 실패한 경우이다.



이번 블로그에서는 뭘 배우는 것이 아니라,
앞으로 무엇을 봐야할 지에 대해서 확인하고자 하는 블로깅이다.

[ git pull other master ]라는 명령어에서 'master'라는 것이 무엇인고 하니, 바로 branch 이름이다.
앞으로 branch에 대해서 살펴보도록 하겠다.

그 다음엔 위의 경우처럼 merge를 하는 경우에 대한 것이다.
repository를 여러개를 사용할 경우도 있지만, 주로 서로 다른 branch에서 하나로 merge하는 경우가 더 많을 것이다.


앞으로 하나씩 더 알아가 보도록 하자.

파일을 삭제하는 경우에 대해서 알아보자.

파일을 삭제하는 경우를 테스트 해보기 위해서 미리 삭제용 파일 3개를 넣어놓았다. ^^


1. rm

$ rm rm_test.txt $ git add rm_test.txt $ git commit -m "rm rm_test.txt"

git 으로 관리를 하던 파일을 그냥 삭제를 하게 되면 git 은 어떻게 받아들일까?
위 스크린샷을 보면 알겠지만, 그냥 알아서 변화된 사항을 잘 받아들인다.
그러므로, 그냥 'git add' 후 'git commit'을 해주면 된다.

위에서는 'add + commit = commit -a" 으로 처리를 했다 ^^


2. git rm

$ git rm rm_test2.txt $ git commit -m "rm rm_test2.txt"

git 에서는 삭제를 위한 옵션을 제공을 해준다.
이를 이용하면 삭제와 staging을 한 번에 처리를 할 수가 있다.
이를 상태 그래프로 보면 아래와 같다.

즉, [ rm + add = git rm ] 이다.


3. git rm --cached

$ git rm --cached rm_test3.txt $ git commit -m "rm --cached rm_test3.txt"

이번에는 조금 특수한 경우이다.

Git 에서는 지우고 싶은데, 지금 작업할 때에는 남겨두고 싶은 경우이다.
즉, 지금 당장 파일은 지우기 싫은데, git 에서는 삭제를 해놓고 싶은 경우에 이렇게 하면 된다.

위 스크린샷을 보면, git rm을 했음에도 실제 파일은 삭제가 되지 않았고,
그러다 보니 git 에서는 untracked 파일이 존재하고 있다고 인지하고 있게 된다.


4. Pattern

쉘 상에서 rm을 사용할 때와 마찬가지로 'git rm'에서도 glob 패턴 등을 그대로 사용할 수 있다.
다만, "*"를 사용할 때에 조금 조심해야 한다.

$ git rm \*~ $ git rm ./out/\*.o

위와 같이 "*" 앞에는 백슬레쉬를 붙여주어야 한다.
이는 백슬레쉬 없이 그냥 "*"를 사용할 경우 Git이 다른 식으로 인식을 하기에 조금 주의를 해야한다.

Git 에서 commit을 하기 위해서는 그 이전에 staged 상태로 만들어야 한다고 앞서서 말했다.
즉, "git add"를 먼저 해야하는 것이다.

"git add"는 하나의 파일만 할 수도 있고, 다수의 파일을 할 수도 있다.

이럴 때에 만약, "git add ."를 통해서 다수의 파일을 staged 상태로 했는데,
그 중에서 특정 파일을 제외하고 싶을 때에는 어떻게 해야할까?

우선은 소스 파일의 2개를 수정해보았다.
위 이미지를 보면 "aviParser.py", "readme.txt" 2개의 파일을 수정해 놓은 상태이다.

수정을 한 파일들 일체를 한 번에 일괄 staged 상태로 만들어보자.

$ git add .

수정 후 staged 상태로 만든 파일들 중에서 "aviParser.py" 파일을 unstaged 상태로 만들고 싶은 상황이라면,
"git reset HEAD 해당파일" 명령어를 입력하면 된다.

$ git reset HEAD ./aviParser.py

지금 상황(status)을 보면 "aviParser.py" 파일이 unstaged 상태로 된 것을 확인할 수 있을 것이다.


"git reset HEAD" 명령어는 해당 파일을 "staged" 상태에서 "unstaged" 상태로만 변경시킨다.
파일 자체에 대해서는 어떤 변경도 가하지 않는다.
 

Windows 환경에서 Git을 보다 편하게 사용하기 위한 도구 중에서 가장 유명한 것이 바로 TortoiseGit이다.
Subversion의 도우미로써 엄청난 인기를 끌었던 TortoiseSvn을 Git을 위한 것으로 수정한 도구이다.

http://code.google.com/p/tortoisegit/

# 미리 알아두어야 할 사항들... (위 스크린샷에 적혀있는 내용이다)

   - TortoiseGit을 설치하기 전에 1.6.1 버전 이상의 Git을 미리 설치해야 한다.
   - 되도록이면 1.7.6 버전을 추천한단다.
   - 1.7.3.0 버전 부터는 64bit 버전에 32bit explorer extension을 포함하고 있다.
   - 1.7.0 버전부터는 Win2K를 더이상 지원하지 않는다.
   - 만약 Win2K 환경에서 1.6.5 이하의 버전을 사용한다면, TortoiseGit을 설치하기 전에 GDI+를 먼저 설치해야 한다.

Downloads 탭을 선택 후 알맞은 환경에 맞는 것으로 선택을 하면 된다.
나의 경우에는 WindowsXP 32bit 버전이기에 그에 맞는 "TortoiseGit-1.7.6.0-32bit.msi"를 선택하였다.

설치 과정에 만나는 첫번째 관문!!!
사용할 SSH를 골라라~!

추천하는 것이기도 하고 개인적인 생각으로도 Windows 환경에서는 putty를 사용하는 것이 편하다.

나머지는 그냥 언제나 Next ^^

업그레이드도 아닌데, 번거로우니 Changelog는 생략하자 ^^

TortoiseGit의 환경설정을 한 번 살펴보자

다양한 설정을 할 수 있는 것을 볼 수 있다.
안타깝게도 기본적으로 언어는 English밖에 안된다.
그런데, Korean을 지원을 해도 English를 사용하는 것이 좋다.
한글로 하면 오히려 더 햇갈릴 수도...

폴더에서 오른쪽 버튼을 누르면 메뉴에서 Git과 관련된 명령어들이 추가된 것을 볼 수 있을 것이다.
즉, 필요하면 여기서 바로 "git clone"을 할 수 있다!



보다 더 필요한 사항들은 나중에 기회가 되면 보충해보겠다 ^^

지금은 졸려서...

이번에 소개할 내용은 일단 알려는 드리지만, 절대 추천하지 않는 명령어(옵션?) 이다.

파일을 수정한 이후 git에 등록하기 위해서는 add를 통하여 staged 상태로 만든 후 commit을 해야한다.
그런데, 이러한 과정이 귀찮다면?


1. git commit -a

   - 소스 파일을 수정한 이후 add 과정 없이 바로 commit을 통해서 한 번에 처리할 수 있다.
   - commit의 옵션 중 '-a'를 사용하면 된다.

   - '-m' 옵션은 앞에서 살펴본 바와 같이 주석을 바로 적어주고 싶을 때 사용하는 옵션이다.

   - add 작업과 commit 작업을 합쳐서 한 번에 할 수 있는 것이다.



[ 주의사항 ]

새로운 파일을 등록할 때에도 'git add'를 사용한다.
그렇다면, 새로운 파일을 등록하고 commit을 할 때에도 'git commit -a'를 사용해도 될까?

답은 "안된다!" ^^




하지만, 이는 결코 추천하지 않는 방법이다.
그 이유는 무엇을 commit 하는지 명시하지 않는 방법이기 때문이다.
이는 종종 원하지 않는 것까지 commit을 하는 실수를 범한다.

무엇을 commit할 것인지 제대로 확인하지 않고 그냥 편의만 추구하는 것은
형상관리의 영속성을 해치는 가장 큰 악습 중 하나이다!!!!

이러한 방법이 있는 것만 확인하고 사용하지는 않기를 바란다~!!!
(그러면서 알려준다는 것 자체가 죄악인데... ^^)

git 의 Review 기능을 설명하고자 하는 것이 아니라,
지금까지 하나씩 알아보았던 것들 중에서 놓친 것이나 조금 더 알아볼 것들에 대해서 언급하고자 한다.


1. stage

   - git 에게 어떠한 action을 취할 대상들을 알려주는 과정이 필요하다.

   - 형상 관리를 하고자 하는 새로운 파일들, 반영을 하고자 하는 수정한 파일들 또는
     파일 이름을 변경하거나 삭제를 하거나 등등의 작업의 대상을 등록하는 것이다.

   - 다시 말하면, commit 을 할 내역을 알려주기 위한 과정이다.

   - 즉, 소스 파일을 수정을 열심히 하고 나서 commit 만 덜렁 하면?! 안된다!
     먼저 'git add'를 통해 stage 상태로 등록을 하고 commit을 해야 한다!


2. git commit -m

   - 간단한 주석과 함께 가볍게 commit을 하기 위해서는 '-m' 옵션을 사용하면 된다.

   - 앞에서 작업했던 것을 그대로 가지고 테스트를 해봤다.


3. git add --all

   - 앞에서 우리는 파일을 staging 하기 위해서 'git add 파일이름' 과 같이 일일이 명시해줬다.
   - 귀찮은 우리를 위해 좋은 옵션이 있다! 'git add --all'

4. git commit

   - 별다른 옵션 없이 그냥 'git commit'을 하게 되면 주석을 적기 위핸 에디터 창이 뜨게 된다.

   - 한글도 별 이상 없이 그냥 된다.
   - 다만 어려운 것은, 주석을 적을 때마다 느끼는 것이지만... 뭐라 적어야 할 지 모르겠다는 점... ^^

5. git config --list & git log

   - 위에서 'git commit'을 하게 되면 에디터가 뜬다고 했는데, 나의 경우에는 'nano'가 떴다.
   - 예전에 이미 다 했던 것이지만, 복습하는 차원에서 다시 한 번 확인만 해보자.

   - 더불어 아쉬운 마음에 'git log'까지 한 번 확인해보자.


오늘은 여기까지~^^

지난 내용에 더불어서 좀 특이한 경우를 살펴보기 위해서 보충해서 좀 적어보겠다.

소스 파일을 수정을 한 후 git 에게 commit을 할 것들을 알려주기 위해서 add를 했는데,
그리고 나서 또 수정을 하게 되면 어떻게 될까?


1. modify cycle

   - 일반적으로 파일을 수정하는 경우는 아래와 같이 표현할 수 있다.

   - 소스 파일을 수정한 후 'git add'를 하여 staged 상태로 만든 후 'git commit'을 하면 되는 것이다.


2. modify

   - 소스 파일을 수정하는 과정까지 일단 해본다.

   - 위 화면을 설명해보면...

      ① 파일 목록을 확인 [ ls -al ]
      ② 현 상태 확인 [ git status ] → 'nothing to commit (working directory clean)'
      ③ 소스 파일 수정 [ nano abiParse.py ]
      ④ 현 상태 확인 [ git status ]
      ⑤ 변경 사항 확인 [ git diff ]


3. git add

   - 일단 staged 상태로 만들기 위해 'git add'를 하자.

4. modify

   - 'commit' 하기 전에 다시 또 수정을 하면 어떻게 되는지 확인해보자.

   - 지금 상황에서 commit을 하게 되면 지금 수정하기 바로 전에 add를 한 시점에서의 내용이 commit이 되고,
   - 지금 변경한 내용까지 같이 commit을 하고 싶으면 다시 'git add'를 해주면 된다.


5. git diff

   - 이런 이상한 상황에서 각각을 확인하기 위한 'git diff' 에 대해서 알아보자.

   - [ git diff ]
      ▷ staged 되지 않은 변경 내역을 확인해 준다
      ▷ 즉, 수정을 하고 'git add' 를 하지 않은 내용을 보여준다
   - [ git diff --staged ]
      ▷ 지난 마지막 commit 에서부터 staged 된 내용까지의 변경된 내역을 확인해 준다
      ▷ 즉, 수정을 하고 'git add'를 해놓은 내용을 보여준다

조금 뭔가 햇갈리기 시작하시는 분은 아직 git의 staged 상태에 대해서 느끼지 못하셔서이다.
다음 번에는 이 staged 된 상태에 대해서 보다 더 다뤄보도록 하겠다.

지난 번에 글을 올리고 너무 오래간만의 업데이팅이다.
사실 일주일에 2-3번 정도의 업데이팅을 하고 싶었는데... 반성해야겠다!

지난 번에는 새로운 파일을 git에게 알려주고 관리를 받기 위한 과정을 살펴보았다.
이번에는 git에게 관리를 받지 않기 위한 방법을 알아보도록 하겠다.

1. git status

   - 샘플로 사용할 파일이 작업공간(Work Space) 위치하고 있는 상황이다.
   - 이 상태에서 'git status'를 하게 되면 untracked file이 존재하고 있다고 알려준다.

2. create [.gitignore]

   - ".gitignore" 파일을 생성하자.
   - 확장자가 "avi"인 파일들을 제외해보자.

3. git status

   - 다시 확인을 해보면 이번에는 untracked file이 변경되어서 나온다.
   - 이전에 있었던 "Sample.HDTV.Xvid-NoTV.avi" 파일이 사라지고,
   - 방금 만든 ".gitignore" 파일이 등장했다.

4. git add

   - 새로 생성한 [.gitignore] 파일도 또한 git 으로 관리를 해야한다.
   - git add .gitignore
   - git commit -m "add .gitignore"


5. .gitignore

   - git에게 관리하지 않을 것들에 대해서 알려주기 위한 ".gitignore"파일에 대한 문법을 알아보자.

      ▷ # 으로 시작하는 줄은 주석으로 간주한다 (빈 줄도 마찬가지로 무시한다)
      ▷ 표준 glob 패턴의 적용이 된다
      ▷ 제일 뒤에 "/" (forward slash) 를 붙이면 디렉토리로 간주한다
      ▷ "!"로 시작하는 것은 예외로 간주한다

01: # blahblah 02: 03: *.avi 04: !chani.avi 05: sample/ 06: source/*.o

   → 01, 02 두 라인은 그냥 무시
   → 03라인은 확장자가 'avi'인 모든 파일을 관리하지 말라는 의미
   → 04라인의 의미는 03라인에서 모든 avi 파일을 관리하지 말라고 했지만, 'chani.avi'파일은 예외라는 의미
   → 05라인은 'sample' 디렉토리 밑의 모든 것들을 관리하지 말라는 의미
   → 06라인은 'source' 디렉토리 밑의 확장자가 'o'인 모든 파일을 관리하지 말라는 의미


[.gitignore] 파일은 보통 빌드를 하면서 생성되는 중간 산출물이나 최종 산출물들을
git에게 관리하지 말라고 알려주기 위해서 사용한다.

사실 별 것이 아닌 팁과 같은 느낌이지만, 이를 모르고 사용하지 않으면 상당히 귀찮은 경우가 많다.

부디 잘 사용하시길...