Git, 분산버전 관리시스템(4) – Git 기초: 추가하고 커밋하기

1.         Git 기초: 추가하고 커밋하기

1.1.        파일 추가하기

새로운 파일을 추가하거나 저장소의 내용을 변경하는 일은 빈번한 작업이다.
git add는 2가지 역할을 한다.
추가할 파일명이나 파일들을 전달하면 Git은 커밋하려고 변경사항을 스테이징한다.

스테이징된 변경 사항은 저장소에 반영하려는 작업 트리의 변경 사항일 뿐이다.
변경사항을 스테이징 하면 Git이 참조하고 있는 관리 목록을 갱신한다.
대부분의 사람들은 이것을 스테이징 영역이라고 부른다.

 

스테이징 영역은 저장소에 커밋하기 전에 커밋을 준비하는 위치다.
한번에 커밋 할 수도 있지만, 스테이징 영역에 대해 알아야 한다.
스테이징 영역은 원하는 변경사항을 커밋하기 전에 정교하게 다듬을 수 있는 기회를 제공한다.
하지만 변경사항을 다듬기 전에 변경 사항을 추가해야 한다.
변경 사항을 추가하려면 git add 명령어를 사용한다.

 

다른 Git 명령들과 같이 git add도 단순히 파일을 추가하는 것 외에도 다양한 기능을 가지고 있다. 여러 가지 옵션을 지정하여 git add 동작을 변경할 수 있으며, 매우 유용한 옵션도 몇 가지 있다.

 

대화형 add 모드를 사용하면 파일이나 파일의 일부분을 선택하여 커밋하도록 스테이징할 수 있다. 대화형 모드는 –i 옵션을 추가하면 사용할 수 있다.

대회형 셀의 사용하여 변경 사항을 스테이징 하거나, 새로운 파일을 추가할 수 있고, 심지어는 파일의 일부분도 스테이징할 수 있다.

 

Biography 링크를 About으로 변경한다.

<li><a href="bio.html">About</a></li>

 

그리고 git add –i를 실행한다.
대화형 모드를 실행하면, 대화형 프롬프트가 나타난다.

$ git add –i   1: status 2: update 3: revert 4: add untracked 5: patch 6: diff 7: quit 8: help

 

여기서 다양한 옵션을 선택할 수 있다

1을 입력하면, 처음 시작할 때와 동일한 상태 정보를 보여준다.

파일을 추가하려면 2를 입력하여 파일을 스테이징 하게끔 한다.

2를 입력하면 스테이징 할 수 있는 파일 목록을 보여준다.

 

지금은 추가해야 할 파일이 1개만 있으므로 1을 입력하자.
그러면 파일 이름 옆에 별표(*)가 추가되어 스테이징 대상임을 알 수 있다.

이 모드에서 필요한 작업을 완료했다면, 엔터키를 입력하여 메인 메뉴로 돌아갈 수 있다.

 

상태정보를 다시 확인해보면, 스테이징된 변경사항이 하나 있으며,
스테이징 되지 않은 변경 사항 목록에는 아무것도 없음을 확인할 수 있다.

 

스테이징한 변경 사항을 취소하려면 3을 입력해서 되돌리기(revert)를 사용할 수 있다.
사용법은 앞에서 스테이징한 것과 비슷하다.
상태정보를 보면, 현재 변경 사항이 다시 스테이징 되지 않았음을 확인할 수 있다.

 

아직 추적되고 있지 않은 파일을 스테이징 하려면 4번째 옵션을 사용할 수 있다.

 

패치 모드는 대화형 모드에서 가장 유용한 기능이다.
다른 모드와 동일한 방식으로 실행하며, 패치모드를 사용해 추가하고자 하는 파일을 하나 이상 선택 할 수 있다.
일단 이 모드를 선택하면 변경된 파일간의 차이를 표시하고, 해당 변경 사항 추가 여부를 묻는 옵션을 보여준다.

 

패치 모드에는 헝크(hunk)를 추가, 취소할지를 결정하는 옵션이 있다.
헝크는 파일에서 하나의 변경사항을 의미한다.
연속된 변경사항은 하나의 헝크로 취급된다.
파일 안에서 차이가 있는 각 영역이 한 개의 헝크가 된다.

 

프롬프트에
y를 입력하면, 변경사항을 스테이징하고,
n을 입력하면, 건너뛴다.
a를 입력하면 파일에 있는 나머지 모든 변경 사항을 추가하고,
d를 입력하면 나머지 모든 변경 사항을 추가하지 않는다.
?를 입력하면 헝크를 처리할 때 사용하는 옵션을 설명하는 도움말을 표시한다.

 

Git의 대부분의 기능처럼, Git 은 대화형 모드를 사용하지 않고, 패치 모드를 바로 실행하는 방법도 제공한다.
git add 에 –p 매개변수를 추가하면, 패치 모드를 바로 실행할 수 있다.

 

 

 

1.2.        변경 사항 커밋하기.

커밋은 변경 사항을 저장소의 이력에 추가하고, 커밋명을 할당하는 비교적 직관적인 절차다.

 

빈 디렉터리 추적하기

Git 은 디렉터리를 추적하지 않는다. 예전부터 빈 디렉터리를 추적하는 것에 대한 반대의견이 있었고, 이 주장에 따르면 유지보수가 잘 된 프로젝트는 실제로 빈 디렉터리가 없다. 앞으로 Git 도 디렉터리를 추적하게끔 바뀔지 모르겠지만, 만약 지금 당장 빈 디렉터리를 저장하고자 한다면 간단한 방법이 있다. 추적하려는 디렉터리에 빈 파일을 추가하고, 해당 파일을 저장소에 추가하면 된다. 빈 파일의 이름을 무엇으로 정해도 상관 없지만, 대부분의 사람은 이 파일의 이름을 마침표(.)로 시작한다. 그 이유는 대부분의 파일 시스템이 마침표로 시작하는 파일을 무시하기 때문이다.

 

하지만 변경 사항을 중앙 저장소로 보내지는 않는다.
다른 사람이 우리의 변경사항을 풀링할 수도 있고, 반대로 우리가 변경사항을 다른 저장소에 푸싱할 수도 있다.
그러나 갱신 과정이 자동으로 되진 않는다.
참고) 7.3 ‘최신 상태 유지하기’, 7.4 ‘변경 사항 푸싱하기’

 

git commit을 사용하여, 다양한 방법으로 변경 사항을 저장소에 커밋할 수 있으며,
커밋을 할 때는 항상 로그 메시지를 작성해야 한다.
-m “우리의 메시지”와 같이 명령어에 지정하면, 간단하게 메시지를 추가할 수 있으며,
메시지는 유효한 문자열이어야 한다.
메시지를 다수의 단락으로 기술하고 싶다면, -m 옵션을 단락의 개수에 맞게 지정하면 된다.

 

-m 옵션 없이 git commit 을 실행하면, 로그 메시지 작성에 필요한 편집기가 실행된다.

Git은 편집기를 실행하려고 할 때, 다음과 같은 순서대로 환경변수를 참조한다.

1.       GIT_EDITOR 환경변수

2.       Git의 core.editor 구성변수

3.       VISUAL 환경변수

4.       EDITOR 환경변수

5.       Git은 설정된 환경변수가 없으면, vi을 이용한다.

 

편집기를 사용하여 커밋 메시지를 작성할 때, -v 옵션을 추가하면, Git은 커밋하려는 변경 사항과 저장소의 차이점(diff)을 편집기에 표시한다.
편집기에 ‘#’으로 시작하는 줄이 많이 보이겠지만, ‘#’으로 시작하는 줄은 커밋 메시지에 포함되지는 않는다.

 

대부분의 Git 명령어와 마찬가지로, 몇 가지 다른 방법으로 커밋할 수 있다.
실제로 커밋하기 전에 커밋하는 3가지 방법.

1.       커밋하려는 파일을 지정하여, git add를 호출하는 방법.
또는, 변경한 일부분만 추가하려면 git add –p를 사용할 수 있다.
이렇게 하면 커밋하려는 변경사항을 스테이징하고, git commit을 호출하여 커밋을 종료한다.
절차는 다음과 같다.

$ git add some-file $ git commit –m “changes to some-file”

 

2.       git commit 에 –a 매개변수를 지정하는 것이다.
그러면 작업 트리의 가장 최근 버전으로 저장소에 커밋한다.
하지만 –a 매개변수는 새로운 파일이나 추적하지 않는 파일을 추가하지 않으며,
기존에 추적한 파일만 커밋한다.
이전 예제에서 작업 트리의 some-file 만 변경했다면, 다음 명령어를 실행하여 동일한 커밋을 수행할 수 있다.

$ git commit –m “changes to some-file”–a

 

3.       커밋하려는 하나 이상의 파일을 지정하는 것이다.
Git에 전달하기를 원하는 모든 옵션을 지정한 후에 커밋하려는 각 파일을 추가한다.
-a 매개변수와 마찬가지로, 이 방법도 작업 트리의 가장 최신 버전을 커밋하지만, 단지 지정한 파일만 커밋하는 차이가 있다.
다음은 이전 2가지 방법과 동일한 예제이다.

$ git commit –m “changes to some-file”some-file

 

3가지 예제 모두 각자의 쓰임새가 있다.
스테이징 후 커밋하는 방식은, git add –p 를 사용하여, 파일을 일부 커밋할 때 유용하다.
변경한 파일 중에서 하나만 풀링하려면, 해당 파일을 명시적으로 지정하여 커밋할 수 있다.

 

스테이징 후 커밋하는 1번 방법과 모든 변경 사항이나 특정 파일의 변경사항을 커밋하는 방법에는 중요한 차이점이 있다.
전자의 1번 방법은 스테이징한 시점의 변경 사항을 커밋한다.
후자의 2방법은 커밋한 시점의 파일 내용을 커밋한다.

스테이징한 시점에서 변경사항을 커밋한다는 말은,
변경 사항을 스테이징하고 난 후에, 파일을 수정했다면, 스테이징한 변경 사항을 커밋해도, 작업 트리에는 여전히 커밋되지 않은 변경사항이 남아있음을 의미한다.

스테이징 영역은 일종의 버퍼처럼 생각하면 된다.
git add로 버퍼에 추가할 수 있으며, 버퍼는 git commit으로 저장하기 전까지 추가된 내용을 유지한다.

 

 

 

1.3.        변경된 내용 살펴보기

작업 트리에서 무엇을 변경했는지, 그리고 어떻게 변경했는지를 찾아야 한다.
git status, git diff 를 사용하면 해당사항을 확인할 수 있다.

 

 

 

1.3.1.       현재 상태 보기

저장소에서 발생한 모든 변경 사항을 알아보려면 git status를 사용하면 된다.
git status는 관리 목록에 올려둔 내용, 그리고 현재 작업 복사본과 저장소가 추적하고 있는 내용을 비교한 결과를 출력한다.
앞에서 스테이징한 변경 사항도 확인이 가능하다.

 

 

 

1.3.2.       차이점 살펴보기

Git은 작업트리의 변경사항, 스테이징돼서 커밋하려는 변경사항, 저장소간의 차이점을 보여줄 수 있다.
차이점을 확인하려면 git diff 를 사용한다.

매개 변수 없이 git diff를 실행하면, 아직 스테이징되지 않고, 커밋되지도 않은 작업트리의 변경사항을 보여준다.

$ git diff

 

git diff를 매개변수 없이 실행하면, 작업트리의 변경사항과 스테이징 영역을 비교한다.
스테이징 영역에는 커밋 예정인 변경 사항이 있다.
git status는 스테이징된 변경사항만을 보여준다.

--cached 매개변수를 추가하여 스테이징 영역과 저장소의 차이점을 확인할 수 있다.

$ git diff --cached

 

--cached 를 사용하면, 스테이징되지 않은 변경 사항을 표시하지는 않는다.
작업트리, 스테이징된 변경사항, 저장소의 모든 차이점을 비교하고 싶다면, git diff 명령어에 HEAD 매개변수를 추가하면 된다.

$ git diff HEAD

 

HEAD는 현재 작업중인 브랜치에서 가장 최신의 커밋을 나타내는 키워드다.

 

중앙 저장소

네트워크

저장소

스테이징 영역

작업트리

 

 

 

1.4.        파일 관리하기

1.4.1.       파일이름을 변경하고 파일 이동하기

Git에서 git mv <원본파일> <새로운 파일> 명령을 내리면, 파일을 이동시킬 수 있다.
이 명령어는 존재하는 파일의 내용으로 새로운 파일을 생성하고, 기존 파일의 이력을 유지한 상태로 원본 파일을 제거한다.

 

$ git mv index.html hello.html $ git status

 

git mv 가 없어도, Git이 파일의 이동을 인지할 수 있지만, 몇 가지 단계가 더 필요하다.
새로운 파일에 대해서 git add를 호출해야 하고,
예전 파일의 경우는 파일을 저장소에서 지우는 명령인 git rm을 호출해야 한다.

 

 

 

1.4.2.       파일 복사하기

subversion을 사용해봤다면, Git에는 git cp와 같은 복사 명령어가 없다는 사실에 의아해할지도 모른다. 사실 Git에는 git cp와 같은 명령어는 필요가 없다.

서브버전에서 복사 명령어는 주로 브랜치와 태그를 생성하는데 사용하지만,
Git에는 브랜치와 태그를 직접 다루는 명령어가 있다.
Git은 복사된 코드도 추적할 수 있다.

 

Git은 파일을 추적하지 않는다. 파일의 내용을 추적한다.

Git이 파일이 아니라 내용을 추적하는 이유는 다음과 같다.
사실 파일명은 파일 내용에 추가된 메타데이터에 지나지 않으므로 별도로 관리할 수 있다.
Git은 파일 시스템에 요청하여 파일명을 알아낼 수 있지만, Git 의 관심 대상은 파일에 저장된 내용이다.

그렇다면 이러한 개념이 파일을 복사할 때 어떻게 적용될까?
Git은 내용만을 추적하므로, 동일한 내용을 명시적으로 git mv를 사용해 복사하지 않아도, 다수의 커밋에서 중복된 내용을 인지할 수 있다.

 

 

 

1.4.3.       파일 무시하기

git status의 출력 결과는 사용하는 편집기에 따라 약간씩 다를 수 있다.

$ git status

 

저장소에 추가할 필요가 없는 파일을 .gitignore 파일에 추가하면, 저장소에서 사라진다.
무시하고자 하는 파일을 한번에 한 개만 추가하는 것은 비효율적이므로, Git은 와일드카드를 지원한다.

.swp 파일을 .*.swp형태로 gitignore 파일에 추가한다.
그러면 Git은 와일드카드에 일치하는 모든 파일을 무시한다.

 

.gitignore 파일도 다른 파일과 마찬가지로 저장소에 추적되고 배포되므로, 당연하겠지만 저장소를 복제한 모두에게 동일하게 적용된다.

하지만 일반적으로 개발자들은 자신이 좋아하는 편집기를 사용하며,
각 편집기는 파일을 임시로 저장하는 방식과 파일이 열린 상태로 표시하는 방식이 다르다.
따라서 개인적인 환경 설정 정보를 저장소에 포함하여 배포하는 것은 좋은 생각이 아니다.

특정 파일을 배제시키는 정보를 모든 사람들과 공유하지 않고, 지역 저장소에서만 해당 파일을 무시하도록 설정할 수도 있다.
.git/info/exclude 파일을 수정하여 필요한 조건을 추가하면 된다.

 

 

 

1.4.4.       무시할 수준 결정하기

.gitignore를 사용하여 저장소 차원에서 무시할지,
.git/info/exclude를 사용하여 자신의 컴퓨터에서만 무시할지는 다음과 같은 간단한 질문을 스스로에게 해보면 된다. 이러한 종류의 파일을 저장소에 추가하는게 모두에게 필요한가?

 

질문의 답이 그렇다면, .gitignore 파일에 규칙을 추가하고 저장소에 커밋한다.
하지만 자기 자신만 해당된다면, .git/info/exclude 파일에 추가한다.

출처 : http://youmin3.egloos.com/1965469