책/프로 Git 썸네일형 리스트형 분산 환경에서의 Git-4 - 프로젝트에 기여하기 - 공개 팀 공개 소규모 팀 공개 팀을 운영 할 때에는 모든 개발자가 프로젝트 공유 저장소에 직접적으로 쓰기 권한을 가지지 않는다. 그래서 프로젝트 관리자는 몇가지 일을 더 해줘야 한다. Fork를 지원하는 Git호스팅에서 Fork를 통해 프로젝트에 기여하는 법을 예제를 통해 살펴본다. repo.or.cz나 Github 같은 Git 호스팅 사이트느 Fork 기능을 지원하며 프로젝트 관리자는 보통 Fork하는 것으로 프로젝트를 운영한다. 다른 방식으로 이메일과 Patch를 사용하는 방식도 있다. 우선 처음 할 일은 메인 저장소를 Clone 하는 것이다. 그러고 나서 토픽 브랜치를 만들고 일정 부분 기여한다. $ git clone $ cd project $ git checkout -b featureA ... work ... 더보기 분산 환경에서의 Git-2 - 프로젝트에 기여하기 - 비공개 소규모 팀 비공개 소규모 팀 보통 서브버젼 같은 중앙 집중형 버젼관리 시스템에서 사용하던 방식을 사용한다. 물론 Git이 가진 오프라인 커밋, 브랜치기능도 사용한다. 가장 큰 차이점은 서버가 아닌 클라이언트에서 Merge를 한다는 점이다. 두 개발자가 저장소를 공유하는 시나리오를 살펴보자. 개발자 John은 저장소를 Clone하고 파일을 수정 로컬에 커밋한다. $ git clone john@githost:simplegit.git $ cd simplegit/ $ vim lib/simplegit.rb $ git commit -am 'removed invalid default value' 개발자 Jessica도 저장소를 Clone하고 나서 파일을 하나 새로 추가하고 커밋한다. $ git clone jessica@gith.. 더보기 분산 환경에서의 Git-3 - 프로젝트에 기여하기 - 비공개 대규모 팀 비공개 대규모팀 이런 상황에는 보통 팀을 여러개로 나눈다. 그래서 각각의 작은 팀이 서로 어떻게 하나로 Merge하는지를 살펴본다. John과 Jessica는 한 팀이고 프로젝트에서 어떤 한 부분을 담당한다. 또한 Jessica와 Josie도 다른 부분을 담당하는 한 팀이다. 이런 상황이라면 회사는 Integration-Manager Workflow를 선택하는게 좋다. 작은 팀이 수행한 결과물은 Integration-Manager가 Merge하고 공유 저장소의 master 브랜치를 업데이트 한다. 팀마다 브랜치를 하나씩 만들고 Integration-Manager는 그 브랜치를 Pull해서 Merge한다. 두 팀에 모두 속한 Jessica의 작업 순서를 살펴보자. 우선 Jessica는 저장소를 Clone하.. 더보기 분산 환경에서의 Git-1 - 분산 환경에서의 Workflow 분산 환경에서의 Workflow 중앙집중식 Workflow 중앙 저장소는 딱 하나 있고 변경사항은 모두 이 중앙 저장소에 집중된다. 팀이 작거나 이미 중양 집중식 에 적응한 상황이라면 이 Workflow에 따라 Git을 도입하여 사용할 수 잇다. 중앙 저장소를 하나 만들고 개발자 모두에게 Push권한을 부여한다. 모두에게 Push 권한을 부여해도 Git은 한 개발자가 다른 개발자의 작업을 덮어 쓰도록 허용하지 않는다. 한 개발자가 Clocne 하고 나서 수정하는 사이에 이미 다른 개발자가 중앙 저장소에 무언가 Push했다면 이 개발자는 Push 할 수 없다. Git은 Fetch하고 Merge해야 서버로 Push할 수 있다고 알려준다. Integration-Manger Workflow Git을 사용하면 리.. 더보기 Git 브랜치-2 브랜치 관리 git branch : 아무런 옵션없이 실행시 브랜치의 목록을 보여준다. $ git branch iss53 * master testing -v 옵션 : 브랜치마다 마지막 커밋 메시지도 함께 보여준다. $ git branch -v iss53 93b412c fix javascript issue * master 7a98805 Merge branch 'iss53' testing 782fd34 add scott to the author list in the readmes --merged 옵션 : 현재 checkout 한 브랜치를 기준으로 이미 Merge 한 브랜치 목록 확인 * 기호가 붙어 있지 않은 브랜치는 git brandch -d 명령으로 삭제해도 되는 브랜치이다. $ git branch --m.. 더보기 Git 브랜치-1 브랜치란 무엇인가? 파일을 Stage하면 Git 저장소에 파일을 저장하고( Blob ) Staging Area에 해당 파일의 체크썸을 저장한다. $ git add README test.rb LICENSE $ git commit -m 'The initial commit of my project' git commit으로 커밋하면 먼저 루트 디렉터리와 각 하위 디렉터리의 트리 개체를 체크섬과 함께 저장소에 저장한다. 커밋 개체를 만들고 메타데이터와 루트 디렉터리 트리개체를 가리키는 포인터 정보를 커밋 개체에 넣어 저장한다. 그래서 필요하면 언제든지 스냅샷을 다시 만들 수 있다. 이 작업을 마치고 나면 Git 저장소에는 다섯개의 개체가 생긴다. 각 파일에 대한 Blob 3개 파일 디렉터리 구조가 들어있는 트리개.. 더보기 Git의 기초 Git 저장소 만들기 기존 디렉터리를 Git 저장소로 만들기 이 명령은 저장소가 필요한 뼈대 파일이 있는 .git 디렉터리를 만든다. $ git init Git이 파일을 관리하게 하려면 저장소에 파일을 추가하고 커밋해야한다. $ git add *.c $ git add README $ git commit -m 'initial project version' 기존 저장소를 Clone하기 서브버젼에서는 checkout 이라는 명령어를 쓰지만 Git에서는 clone 이라는 명령어를 사용한다. Git은 서브버젼과 다르게 서버의 프로젝트 히스토리 데이터를 전부 복사해 온다. 이는 서버에서 디스크가 망가져도 클라이언트에서 복구할 수 있다는 장점이 된다. Ruby 용 Git 라이브러리인 grit을 Clone 하는 예이다.. 더보기 Git의 시작 Git 기초 델타가 아니라 스넵샷 대부분의 VCS(Version Control System)은 각 파일의 변화를 시간순으로 관리하는데 반해 Git은 시간순으로 프로젝트의 스냅샷을 저장한다. Git의 데이터는 파일 시스템의 스냅샷으로 크기가 아주 작다. 거의 모든 명령을 로컬에서 실행 거의 모든 명령이 로컬 파일과 데이터만 사용하기 때문에 네트워크에 있는 컴퓨터는 필요없다. 프로젝트 히스토리를 조회할 때 서버없이 조회한다. 오프라인 상태에서도 비교할 수 있고, 커밋도 가능하다. Git의 무결성 Git은 모든 데이터를 저장하기 전에 체크섬(또는 해시)을 구하고 체크섬으로 데이터를 관리한다. 체크섬 없이 어떠한 파일이나 디렉터리도 변경할 수 없다. Git은 SHA-1 해시를 사용하여 체크섬을 만든다. 체크섬은.. 더보기 이전 1 2 다음