태그와 커밋 기반의 이름 생성 git describe 명령은 가장 가까운 태그 이름, 그 태그 이후 커밋 수, 약식 커밋 해시를 조합하여 이름을 만듭니다. $ git describe v1.6.2-rc1-20-g8c5b85c 사람이 읽기 쉬운 이름 이렇게 만들어진 이름은 숫자 태그보다 사람이 읽기 쉽습니다. Git 설치 후 git --version을 실행하면 이런 식의 빌드 번호를 볼 수 있습니다. git archive 명령 사용 Git은 git archive 명령을 통해 프로젝트의 특정 시점 스냅샷을 압축 파일로 만들 수 있습니다. tar.gz 압축 파일 생성 $ git archive master --prefix='project/' | gzip > git describe master.tar.gz 위 명령..
서명된 태그 생성 git tag -s [태그명] -m '메시지' 명령으로 서명된 태그를 생성할 수 있습니다. 서명된 태그를 생성하려면 PGP 키가 필요합니다. PGP 공개키 배포 서명된 태그를 확인하려면 서명에 사용된 PGP 공개키를 배포해야 합니다. Git 저장소에 Blob 형식으로 공개키를 저장할 수 있습니다. gpg --list-keys로 사용 가능한 PGP 키를 확인할 수 있습니다. gpg -a --export [키ID] | git hash-object -w --stdin으로 PGP 공개키를 Git 저장소에 저장합니다. git tag -a [태그명] [해시값]으로 PGP 공개키를 가리키는 태그를 만듭니다. PGP 공개키 및 서명된 태그 공유 git push --tags로 서명된 태그와 PGP 공개..
리모트 브랜치 등록 및 체크아웃 프로젝트 기여자가 자신의 저장소를 만들고 커밋한 내용을 이메일로 보낼 경우, 해당 리모트 브랜치를 등록하고 체크아웃하여 테스트할 수 있습니다. 지속적인 개발과 리모트 저장소 활용 다른 개발자들과 함께 지속적으로 개발할 때, 리모트 브랜치를 등록하고 Fetch하여 사용하는 것이 효과적입니다. 커밋 히스토리를 알 수 있고, 3-way Merge가 자동으로 적용됩니다. 리모트 저장소 등록 없이 직접 Merge 저장소를 등록하지 않고도 직접 URL을 사용하여 Merge할 수 있습니다. 주로 함께 일하지 않는 개발자와의 작업에서 사용될 수 있습니다. 토픽 브랜치의 커밋 살펴보기 토픽 브랜치에 속한 커밋 중에서 현재 브랜치(master)에 속하지 않는 커밋을 확인하는 명령어입니다. ..
Patch 파일 생성하기 git diff 명령어로 생성하기 파일을 수정하고 나서 git diff 명령어를 입력합니다. # 1.txt 파일 안에 있는 내용을 변경합니다. $ git diff > 1.patch $ cat 1.patch ---------------------------------------- diff --git a/1.txt b/1.txt index f937f7e..1747edd 100644 --- a/1.txt +++ b/1.txt @@ -1 +1 @@ -233 \ No newline at end of file +233555 \ No newline at end of file git format-patch로 생성하기 파일 수정 후 커밋까지 한 상태에서 git format-patch 명령어를 입..
프로젝트 변수 개발자의 수 개발자들이 얼마나 활발하게 활동하느냐가 중요하다. 작은 프로젝트에서는 둘, 셋 정도의 개발자가 활동할 수 있지만, 대규모 프로젝트에서는 수백 명 이상의 개발자가 매일 수십, 수백 개의 커밋을 만들어 낼 수 있다. 프로젝트의 워크플로 프로젝트에서 선택한 워크플로도 중요한 역할을 한다. 중앙집중형 방식인지, 관리자가 모든 패치를 검사하고 통합하는 방식인지, 개발자끼리 수정사항을 검토하고 승인하는 방식인지 등에 따라 기여 방식이 달라진다. 접근 권한 프로젝트에 대한 읽기/쓰기 권한의 여부도 고려해야 한다. 쓰기 권한이 있는지 여부에 따라 직접적인 수정이 가능한지, 혹은 수정사항을 프로젝트에 반영하는 정책이 어떻게 구성되어 있는지 등이 중요하다. 커밋 메시지 작성에 대한 가이드라인 공..
중앙집중식 워크플로 중앙집중식 워크플로에서는 하나의 중앙 저장소를 중심으로 모든 변경 사항이 이루어집니다. 각 개발자는 중앙 저장소를 Clone하여 작업하고, 다른 개발자의 작업을 통합하기 위해 중앙 저장소로 Push합니다. 이러한 방식은 작은 팀이나 중앙집중식 환경에 익숙한 경우에 적합합니다. 모든 변경 사항은 중앙 저장소를 기준으로 처리되며, Git의 브랜치 기능을 사용하여 병렬로 작업할 수 있습니다. Integration-Manager 워크플로 Integration-Manager 워크플로에서는 여러 리모트 저장소를 운영할 수 있습니다. 프로젝트의 대표 저장소가 존재하고, 기여자들은 이 저장소를 Fork하여 작업합니다. 수정이 완료되면 Integration-Manager에게 Pull Request를 ..
내 블로그 - 관리자 홈 전환 |
Q
Q
|
---|---|
새 글 쓰기 |
W
W
|
글 수정 (권한 있는 경우) |
E
E
|
---|---|
댓글 영역으로 이동 |
C
C
|
이 페이지의 URL 복사 |
S
S
|
---|---|
맨 위로 이동 |
T
T
|
티스토리 홈 이동 |
H
H
|
단축키 안내 |
Shift + /
⇧ + /
|
* 단축키는 한글/영문 대소문자로 이용 가능하며, 티스토리 기본 도메인에서만 동작합니다.