개발이 뭐야?

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

1.1.        파일 추가하기

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.2.        변경 사항 커밋하기.

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

빈 디렉터리 추적하기

하지만 변경 사항을 중앙 저장소로 보내지는 않는다.
다른 사람이 우리의 변경사항을 풀링할 수도 있고, 반대로 우리가 변경사항을 다른 저장소에 푸싱할 수도 있다.
그러나 갱신 과정이 자동으로 되진 않는다.
참고) 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을 호출하여 커밋을 종료한다.
절차는 다음과 같다.

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

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

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 status는 스테이징된 변경사항만을 보여준다.

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

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

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

1.4.        파일 관리하기

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

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

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의 출력 결과는 사용하는 편집기에 따라 약간씩 다를 수 있다.

저장소에 추가할 필요가 없는 파일을 .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

1.         첫 프로젝트 만들기

1.1.        저장소 생성하기

대부분의 버전 관리 시스템에서 저장소는 자신이 가지고 있는 복사본과 떨어져 존재하지만,
Git에서는 작업트리와 함께 .git 디렉터리에 저장된다.

Git에서 저장소를 생성하려면,
먼저 프로젝트 코드를 저장할 위치를 정해야 한다.
예제는 간단한 HTML 페이지를 생성한다. 프로젝트 이름은 mysite라고 하자.
프로젝트 이름과 같은 디렉터리를 생성하고, 디렉터리 안으로 이동한 다음, git init을 입력한다.
전체 과정은 다음과 같다.

이것으로 끝이다. 이제 프로젝트를 추적할 수 있는 Git 저장소가 생겼다.

git init은 .git 디렉터리를 생성하고, 여기에 저장소 메타데이터를 모두 저장한다.
그리고 현재 비어있는 mysite 디렉터리는 저장소에서 체크아웃 할 코드의 작업트리가 된다.

1.2.        변경하기

빈 저장소에 파일을 추가한다.

index.html 파일을 생성하고, 헤더와 ‘Hello World!’란 텍스트를 추가한다.

Git에게 이 파일을 추적하겠다는 사실을 알린다.
Git에게 알리는 작업은 2단계에 걸쳐서 진행된다.
먼저 git add 로 HTML파일을 Git의 관리 목록에 추가한다.
그리고 나서 git commit 한다.

추적하려는 파일이나 파일의 목록을 git add에 매개변수로 전달한다.
Git를 이용해 파일을 추가하는 몇 가지 유용한 방법은 4.1절.

git commit은 커밋을 생성한다.
커밋은 저장소에 저장된 개별적인 이력으로,
각 커밋은 코드의 진행 상태를 기록한다.
Git은 앞에서 설정한 내용을 참조해서, 사용자의 이름과 이메일 주소를 기록하고, 각 커밋에 메시지를 추가한다.

앞의 명령에서 –m 다음의 문자열이 커밋에 추가되는 메시지다.

지금까지 새로운 파일을 저장소에 추가했다.
git log를 실행하면 다음과 같은 커밋 내용을 볼 수 있다.

첫째 줄은 커밋명. 커밋명은 커밋을 추적할 수 있도록 Git이 생성한 SHA-1 hash 값이다.
Git은 각 커밋의 식별자가 완벽히 고유하도록 SHA-1 를 이용한다.
분산환경에서는 완벽히 고유하다는 점이 중요하다.

둘째 줄은 커밋한 사람의 정보.

셋째 줄은 커밋한 날짜.

마지막 줄은 커밋 로그.

Git에서 SHA-1 해시를 사용하는 이유

중앙 집중식 버전 관리 시스템은, 서버가 각 커밋의 고유 번호를 할당한다.
이 경우 숫자로도 충분하다. 하지만 분산환경에서는 그렇지 않다.

2명이 동일한 코드를 이용해 작업한다면 revision181이 둘중 누구의 181을 의미하는지 어떻게 판단해야 할까? Git은 SHA-1해시를 이용해 이 문제를 해결한다.

SHA는 보안해시 알고리즘(Secure Hash Algorithm)의 약어다.
SHA는 미국가보안국(The U.S. National Security Agency, NSA)에서 개발했고,
데이터의 짧은 문자열이나 요약 메시지만으로도 다른 해시와 충돌할 가능성의 거의 없도록 설계됐다.

물론 충돌 가능성은 있지만 무시할 만큼 적은 확률이다. (2^63분의 1 = 1/9,233,372,036,854, 775, 808)

1.3.        프로젝트를 이용한 작업 시작하기

이제 저장소를 준비했으며, 이미 첫 번째 파일을 추적하고 있다.

이제부터 변경사항을 다뤄보자.

<head>, <title>을 추가한다.

방금 파일을 변경했음을 Git도 알고 있다.

git status 는 저장소의 현재 시점인 작업 트리의 상태를 보여준다.

출력 결과를 통해, 변경된 파일을 Git이 알고 있지만, 이것을 어떻게 처리할지는 아직 모른다는 사실을 알 수 있다.

변경한 파일은 수정된 파일(modified)로 표시되지만, 갱신 전(Changed but not updated) 헤더에 있다.
이 파일을 커밋 하려면 변경 사항을 stage 해야 한다.

변경 사항을 stage하면 커밋 할 수 있도록 준비한다.
Git에서는 사용자의 코드를 3곳에 저장한다.
첫째 위치는, 파일을 편집할 때 직접 이용하는 작업 트리다.
둘째 위치는, 인덱스이며, 이후에는 staging area이라 부른다.
스테이징 영역은 작업 트리와 저장소 사이의 buffer 공간이다.
마지막 저장 위치는, Git이 코드를 저장하는 저장소다.
스테이징 영역은 저장소에 커밋하려는 대상만 올려두는 용도로 사용한다.
스테이징 영역의 사용에 대해서는 4.1 ‘파일 추가하기’에서 다룬다.

이제 git add 를 다시 이용하면 index.html 파일의 변경 내용을 스테이징 할 수 있다.
이전 절의 새 파일을 추가하기 위해서 사용한 명령어와 동일하다.
이번에는 새로운 파일임을 알리는 용도가 아니라, 추적할 새로운 변경 내용이 있음을 Git에게 알린다.

수정된 index.html 파일을 추가한 다음,
git status 를 실행하면,
헤더 영역이 갱신 전(Changed but not updated)에서
커밋 예정(Changes to be committed)으로 바뀐 것을 확인할 수 있다.

색상 출력을 켜놨다면 index.html을 가리키는 줄의 색이,
빨간 색에서 녹색으로 바뀐 것도 볼 수 있다.

git commit을 실행한다.

2개의 –m을 사용했다.

Git에서는 원하는 대로 –m을 사용할 수 있고, 매개변수마다 하나의 문단으로 취급한다.

git log로 메시지가 2개의 문단으로 구성됨을 확인할 수 있다.

git log 의 매개변수로 -1을 이용했다.
숫자를 변경하면, 보고 싶은 커밋 개수만큼, git log의 출력을 제한할 수 있다.

1.4.        브랜치 사용하고 이해하기

브랜치를 이용하면, 작업 중인 프로젝트의 분기 이력을 관리 할 수 있다.

실제 유용한 형태의 브랜치는 2가지가 있다.
바로 프로젝트의 여러 버전을 브랜치 별로 관리하기 위해 생성한 브랜치와
특정 기능을 다루는 주제 브랜치다.
이 절에서는 첫 번째 형태의 브랜치를 다룬다.

mysite 코드는 릴리스 준비가 거의 끝났지만, 그래도 관련된 사람들에게 승인을 받아야 한다. 승인을 기다리는 중에도 다음 버전의 새로운 기능을 추가할 수 있다.

브랜치를 이용하면 릴리스 준비가 된 코드의 복사본을 보관해 둘 수 있으므로 개발을 멈출 필요가 없다.

브랜치를 생성하는 명령어는 git branch이며 매개변수를 2개 받는다.
첫번째는 브랜치 명이고,
두번째는 분기해 나올 브랜치명이다.

master 브랜치에서 RB_1.0이라는 브랜치를 생성한다.
Git에서 master는 기본 브랜치명이다.
CVS, SVN 에서는 Git의 master 브랜치와 같은 역할을 trunk라고 부른다.

RB는 release branch의 약어이다.

이제 릴리스 준비 중인 코드에 영향을 주지 않고 내용을 변경할 수 있다.
index.html 파일에 약력(Biography) 페이지로 가는 링크를 추가한다.

이제 변경 사항을 커밋하자.

-a 를 이용하면 Git에서 알고 있는 모든 변경된 파일을 커밋한다.

지금 마스터 브랜치를 변경했고, 이는 릴리스 브랜치에는 없는 내용이다.
릴리스 브랜치로 변경하고, 릴리스 전에 마지막으로 내용을 수정하자.
브랜치를 변경하는 명령어는 git checkout이다.

index.html 을 열어둔 상태라면 편집기가 파일이 변경됐다고 알려준다.
내용을 갱신하고 계속 진행하자.
마스터 브랜치에서 편집한 내용이 편집기에서 사라진다. 편집기에서는 사라졌지만 마스터 브랜치에는 잘 저장되어 있다.
릴리스 전에 추가할 마지막 변경 사항은 페이지를 설명하는 메타 태그를 추가하는 일이다.

저장한 다음 변경한 내용을 커밋한다.

릴리스 준비가 끝났다. 이제 태그를 이용해 릴리스를 기록할 시간이다.

1.5.        릴리스 다루기

지금까지 작업한 코드의 1.0 릴리스 준비를 끝냈다. 여기에 태그를 붙여보자.
Git에서 코드에 태그를 붙이면, 저장소 이력의 특정 지점을 기록하기 때문에, 나중에 참조하기가 쉽다.
1.0 릴리스에 대한 태그니 숫자로 태그를 붙이자.

2 매개변수는 순서대로 태그명과 태그를 붙여둘 위치를 나타낸다.
브랜치 RB_1.0에 1.0이라는 태그명을 붙였다.

git tag 를 매개변수 없이 실행하면, 저장소의 태그 목록을 볼 수 있다.

지금은 앞에서 만든 1.0 태그만 보여준다.

2개의 브랜치를 가지고 있고, 커밋 내용을 서로 모른다. 2.0 기능을 개발할 마스터 브랜치는 RB_1.0 브랜치에 추가한 <meta> 코드에 대해 알아야 한다.

브랜치를 병합할 때 git rebase 를 이용한다.

새로운 기준설정은 한 브랜치의 변경 사항을 가져와 다른 브랜치에 적용한다.

현재의 저장소는 다음과 같지만

재정렬하면 다음과 같다.

먼저 마스터 브랜치로 전환한다.

그 다음 git rebase 를 실행한다.
지금은 재정렬할 브랜치 이름에 해당하는 매개변수 하나면 된다.

릴리스 브랜치의 삭제하기.
RB_1.0 브랜치를 커밋하면서, 붙여둔 태그는 여전히 유효하므로 릴리스 정보는 그대로다.
git branck 에 –d 와 브랜치 명을 더해서 브랜치를 삭제한다.

릴리스 브랜치 없이 1.0.x 브랜치에 대한 패치 만들기.

간단하게, 태그에서 브랜치를 만들면 된다.

이전에 브랜치를 만들었던 내용을 떠올려, 브랜치가 분기해 나올 브랜치명을 이용했다.
이 브랜치명 대신 태그명을 지정하면 된다.

git log로 확인해 보면 RB_1.0.1 브랜치에는 오직 3개의 커밋만 있다.

릴리스에 대한 압축파일 생성하기.

릴리스 할 때 프로젝트의 이력을 항상 함께 배포하지는 않는다.
대개는 태그를 붙여둔 내용만을 tar, zip으로 제공하는 정도로도 충분하다.
git archive를 이용해 압축파일을 생성하자.

--format : Git이 생성할 출력 파일의 형식을 tar로 지정한다.

--prefix : mysite-1.0/ 의 모든 내용을 mysite-1.0/ 디렉토리 아래 포함시키도록 한다.

1.0 : 압축 파일에 어떤 내용을 저장할지 결정하는 태그명이다.

gzip > mysite-1.0.tar.gz : git archive의 출력 결과인 tar 파일을 파이프라인으로 연결해서 gzip으로 압축한다. 출력 결과는 배포 가능한 형태인 mysite-1.0.tar.gz이 된다.

git archive는 zip도 지원한다.

1.6.        원격 저장소 복제하기

mysite 저장소는 지역 저장소를 이용하는 명령어만 사용해서 구축했다.

Git를 이용해서 원격 저장소를 통해 작업 내용을 공유하거나, 다른 저장소의 복사본을 가져올 수 있다.

원격 저장소를 이용하려면 git clone 으로 원격 저장소를 복제해야 한다.

매개변수1: 복제하려는 저장소의 위치

매개변수2: 사용자 컴퓨터에서 저장소로 사용할 디렉터리 (옵션)

정리

git add,

git commit

git status

git log

git branch

git tag

git rebase

git clone

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

1.         Git 설정하기

1.1.        Git 설치하기

$ sudo apt-get build-dep git-core git-doc

$ git --version

1.2.        Git 구성하기

Git을 이용하려면 몇 가지 정보가 필요하다.
Git에는 분산 환경이라는 특성 때문에 사용자 이름과 이메일 주소를 제공하는 중앙 저장소가 없다.

git config 명령을 이용해 이름과 이메일 주소를 설정한다.

먼저 몇 가지 전역 값부터 설정한다.
여기서 설정하는 값은 시스템에서 생성하는 모든 저장소에서 기본값으로 사용한다.
전역 설정 값으로 이용하려면 --global 옵션을 추가한다.

user.name과 user.email값은 반드시 필요하다.

user.name은 변경 사항을 커밋하면 표시되는 이름이고,
user.email은 다른 개발자가 변경 사항에 대해 문의 할 때 사용하는 이메일 주소다.

설정 값을 잘 저장했는지 확인하려면 git config명령에서 --list 매개변수를 이용한다.

user.name, user.email은 반드시 설정해야 하는 값이며,
이외에도 130개 이상의 값을 설정할 수 있다.
대부분의 값은 따로 변경할 필요가 없지만, 출력 결과를 여러 가지 색으로 표현하기를 좋아한다면 한가지 설정 값을 더 변경하자.

color.ui 설정은 Git 사용자 인터페이스의 색상을 제어하는데 사용한다.

color.ui 값을 “auto”로 설정하고, 출력 결과를 터미널에서 보면 여러 색으로 Git의 출력을 확인할 수 있다.

다음 명령어를 이용해 color.ui 설정을 켤 수 있다.

한글 커밋 메시지 사용하기

Git 커밋 메시지의 기본 인코딩은 UTF8이다.
맥 사용자라면 터미널의 기본 인코딩도 utf8이기에 일부러 터미널의 인코딩을 변경하지 않았다면 한글 로그 메시지에 대해서 신경 쓰지 않아도 된다.

한글 윈도 사용자라면, 명령 프롬프트의 기본 인코딩이 cp949이기에 다음과 같이 커밋 메시지의 인코딩과 로그 메시지의 인코딩을 설정해야 한다.

앞서 설명한대로 --global을 붙이면 모든 프로젝트의 기본값이 된다.

커밋 인코딩을 지정하지 않으면 Git에서 기본 인코딩이 UTF8이 아니라는 사실을 알려준다. 잘못된 인코딩으로 커밋하면 git log 명령어를 이용할 때, 제대로 보이지 않을 뿐 아니라 GUI 도구에서도 제대로 보이지 않는다. 반드시 올바른 값을 지정하자.

윈도우에서 한글을 보려면 한 가지 설정이 더 필요하다.
LESSCHARSET 환경 변수의 값을 latin1로 설정해야 로그 메시지를 제대로 볼 수 있다.
‘제어판 –시스템 –고급 –환경변수 –새로만들기’를 통해, LESSCHARSET 환경변수를 만들고 변수 값을 latin1을 입력하자.

현재 실행된 콘솔에서만 환경 변수를 적용하려는 경우 명령 프롬프트를 이용한다면

을 실행하고,

Git Bash을 이용한다면

을 실행하면 된다.

msysGit에서 로그 메시지를 콘솔 화면에 출력할 때,
페이지 단위로 나눠서 보여주기 위해 사용하는 less 명령어의 기본설정으로는
한글을 제대로 표시하지 못하기에 필요한 환경 변수이다.

1.3.        Git의 GUI 사용하기

Git는 Tcl/Tk GUI 인터페이스를 제공한다.
명령 프롬프트에서, 프로젝트 디렉터리로 이동한 다음, git guui를 입력하면 GUI 인터페이스를 실행할 수 있다.

OS에 따라 몇 가지 인스톨러는 현재 위치(프로젝트 이름)를 git-gui에서 열어주는 컨텍스트 메뉴를 제공하기도 한다.

git-gui는 변경사항을 커밋하는 등의 인터페이스는 제공하지만, 저장소의 이력을 보는 인터페이스를 제공하지는 않는다. 대신 gitk가 이력 보기 기능을 제공한다.
커맨드라인에서 프로젝트 디렉터리로 이동하여 gitk를 입력하면 실행할 수 있다.

gitk는 저장소의 모든 변경 사항에 대한 이력을 표시한다.
브랜치 간의 연관성을 보려고 --all 매개변수를 추가하면, 현재 브랜치 대신 모든 브랜치를 보여준다.

마지막으로 맥 OX X 사용자에게 GitX다.
GitX는 Pieter de Bie가 맥 환경에 맞게 만든 gitk 복제본이다.
GitX는 GitHub의 호스팅을 이용하여 GitHub 웹페이지에서 다운로드 링크를 제공한다.

1.4.        Git 내장 도움말 사용하기

도움말 문서는 소스를 빌드했을 경우에 기본적으로 설치되지 않으며, 몇 가지 패키지 관리자는 도움말 문서를 git-doc 패키지로 나눠뒀다.

소스를 빌드했다면 make 타깃(target)으로 doc과 install-doc을 호출해야 한다.
일반 텍스트 형식 Git 문서를 매뉴얼 형식으로 변환하려면 Asciidoc이 필요하다.

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

1.         Git 방식으로 버전 관리하기

1.1.        저장소.

버전 관리 시스템에서 저장소(repository)는 사용자가 변경한 모든 내용을 추적하는 공간이다.
대부분의 버전 관리 시스템은 코드의 현재 상태는 물론이고 변경이 언제 발생했는지, 누가 변경했는지, 변경 사항을 설명하는 텍스트 로그 메시지까지 저장한다.

CVS, SVN은 중앙 집중식 저장소 모델을 따른다.
중앙 집중식 저장소는 컴퓨터에 직접 접근해야 하는 문제는 개선했지만, 여전히 한계가 있다.
먼저, 사용자는 최신 버전의 코드만 가지고 있다. 변경 이력을 보려면 저장소에 정보를 요청해야 한다.
정보를 요청해야 한다는 점 때문에 2번째 문제가 발생한다. 대개 네트워크상에서 원격 저장소로 접근해야 한다는 점이다.
이렇게 인터넷에 연결할 수 없는 환경은 Git이 따르는 모델인 분산 버전 관리 시스템의 가장 큰 장점 하나를 부각시킨다.
모든 팀원이 변경사항을 전송하는 중앙 저장소를 가지는 대신, 각자가 프로젝트의 전체 이력이 있는 자신만의 저장소를 가진다. 커밋할 때는 원격 저장소에 연결할 필요 없이, 변경사항을 지역 저장소에 기록한다.

개발자가 직접 변경 사항을 중앙 저장소에 전송하려고 접속할 수 있다. 이런 행동을 Git에서는 푸싱(pushing)이라고 한다. 또는, 변경사항을 모아둔 패치를 만들어 프로젝트를 관리하는 사람에게 제출해서 중앙 저장소에 반영하게 할 수 있다.

1.2.        무엇을 저장해야 하나.

프로젝트를 진행하는데 필요한 전부.

1.3.        작업 트리

모든 변경은 작업 트리에서 이뤄진다.

작업 트리는 저장소를 바라보는 자신의 현재 시점이다.
작업 트리는 소스 코드, 빌드 파일, 단위 테스트 등 프로젝트의 모든 파일을 가지고 있다.

다른 버전 고나리 시스템에서는 작업트리를 작업 복사본(working copy)이라고 한다.
서브버전 같은 버전 관리 시스템에서 저장소는 ‘저 너머’의 다른 서버에 존재한다.
Git에서 ‘저 너머’란 로컬 컴퓨터의 프로젝트 디렉터리에 있는 .git/ 디렉터리를 의미한다.
즉, 저장소의 이력을 보고 변경사항을 살펴보려고 다른 서버에 있는 저장소와 통신하지 않아도 된다.

작업트리를 가져오려면, Git에게 자신의 프로젝트를 저장소에 초기화하도록 요청하거나, 기존 저장소의 프로젝트를 복제(clone)할 수 있다.

복제하기는 지역 저장소를 만든 후, 개발의 기본 흐름인 마스터 브랜치에서 복사본을 checkout한다. checkout은 Git이 사용자의 작업 트리를 저장소의 특정 시점과 일치하도록 변경하는 작업이다. 복제하기는 7.2절에서.

1.4.        파일 다루고 동기화하기

1.5.        프로젝트, 디렉터리, 파일 추적하기.

최하위 계층에서 Git은 저장소에 저장한 파일을 내용 단위로 추적한다. 이런 점에서 파일을 추적하는 여타 버전 관리 시스템과는 다르다.
Git는 models.py 파일을 추적하는 대신 models.py에 있는 변수나 함수 등을 구성하는 각 문자와 줄을 추적하며, 이름, 파일모드, 심볼릭 파일 여부와 같은 메타데이터를 models.py에 추가한다.

이러한 점은 저장소의 전체 이력을 저장하는데 필요한 공간을 줄인다. 그리고 2 파일사이에서 함수나 클래스의 이동을 알아내거나 어디에서 복사된 코드인지 결정하는 것과 같은 작업이 가능해졌으며 빠르다.

1.6.        태그를 이용해 마일스톤 추적하기

1.7.        브랜치로 분기 이력 만들기

1.8.        합치기

1.9.        잠금 옵션

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