티스토리 뷰

SW 개발

Git 사용 방법 정리

지단로보트 2017. 5. 14. 21:13

원격 저장소에 Git 설치하기

# 기본 설치된 1.7.1 버전을 제거
$ sudo yum remove git

# IUS 저장소를 추가
$ sudo rpm -Uvh https://centos6.iuscommunity.org/ius-release.rpm

# IUS 저장소에서 2.12.2 버전 설치
$ sudo yum --enablerepo=ius install git2u

# 설치된 Git 버전 확인
$ git --version
git version 2.16.5

# 언어셋으로 UTF-8 지정 
$ export LESSCHARSET=utf-8

Git 내 정보 설정하기

  • Git을 설치하고 가장 먼저 필요한 작업은 내 정보를 설정하는 것이다. 아래와 같이 설정한다. [관련 링크]
# 한글 깨짐 현상 수정
$ SET LC_ALL=ko_KR.UTF-8

# 현재 적용된 Git 환경 설정 출력
$ git config --list
user.name=someuser
user.email=someuser@foobar.com

# 현재 작업 컴퓨터 전체에 적용될 내 계정 정보 설정
$ git config --global --replace-all user.name "anotheruser"
$ git config --global --replace-all user.email "anotheruser@foobar.com"

로컬에서 Git 원격 저장소 클로닝하기

  • GitHub으로 생성한, 또는 이미 존재하는 저장소를 클로닝하는 것이 대개 Git과의 첫 만남이라고 할 수 있다. 굳이 내가 작성하지 않은 소스 코드라도, 특히 유명한 오픈 소스 공개 저장소를 클로닝하여 IDE로 분석해보면 자신의 실력을 일취월장할 수 있다.
### GitHub 원격 저장소 클로닝
$ git clone https://github.com/some-projects/some-project.git

### 클로닝한 프로젝트 디렉토리로 이동
$ cd some-project

Git 작업내역 반영하기

  • Git 생태계에서 특정 작업의 시작은 최신 상태의 master 브랜치에서 내가 작업할 새로운 브랜치를 생성하는 것에서 시작한다. 커밋은 로컬 브랜치에 반영되며, 내가 작업한 내역이 컴퓨터의 고장 등으로 유실되지 않으려면, 최종적으로 원격 저장소에 푸시가 되어야 한다.
  • 최종 작업분까지 푸시가 완료되면 Pull Request(PR)을 통해 팀원들의 리뷰를 거쳐 최종적으로 master 브랜치에 머지되어 배포 가능한 상태로 전환된다.
### 작업 전 master 브랜치 전환 후 최신 상태로 갱신
$ git checkout master
$ git pull

### 로컬에 기능을 작업할 새 브랜치 생성 후 전환
$ git checkout -b feature/foobar

### 소스 코드 작업 후 로컬에 작업내용 반영
$ git add .

### 로컬 브랜치에 작업내용 커밋
$ git commit -m "foobar feature added."

### 원격 저장소에 작업내역 푸시
$ git push --set-upstream origin feature/foobar

작업 중인 내 브랜치에 마스터 브랜치의 작업내역 받아오기

  • 특정 브랜치에서의 작업이 길어지면 계속 업데이트되는 master 브랜치와 차이가 발생하기 시작한다. 수시로 master 브랜치를 현재 작업 브랜치에 머지하여 소스 코드가 충돌하는 부분을 수정해주는 습관을 들이는 것이 좋다.
### 내 작업 브랜치로 이동
$ git checkout mybranch

### 모든 브랜치의 최신 작업내역 내려받기
### master 브랜치 백머지 전에 필요한 작업
$ git pull

### 내 작업 브랜치에 master 브랜치 머지
### 내 작업 브랜치가 1번도 푸시된 적 없는 로컬 브랜치일 경우
$ git rebase origin/master

### 내 작업 브랜치에 master 브랜치 머지
### 내 작업 브랜치가 1번 이상 푸시된 원격 브랜치일 경우
$ git merge origin/master

원격지에 푸시한 작업내역 취소하기

  • 가끔씩, 실수로 원격지에 푸시한 작업내역을 취소하고 싶은 경우가 있다. git revert 명령어로 작업내역을 취소할 수 있다. 이 경우 취소한 작업내역 또한 커밋 이력에 남는다. (반대로 git reset 명령어를 사용하면 취소한 작업내역은 완전히 제거되고, 취소에 대한 커밋 이력 또한 남지 않는다.)
### 작업내역을 취소, 파라메터에는 취소할 커밋 해시를 입력
$ git revert d8e1dd65ea448a0c0e06cbca27a0c5a9419d09e5
$ git push

Git Submodules 제어하기

  • Git에서의 Submodules는 리파지터리 속의 리파지터리라고 말할 수 있다. 만약 특정 리파지터리 속의 특정 경로의 소스 코드가 다른 리파지터리에서도 중복으로 사용할 수 있다고 가정해보자. 해당 소스 코드가 갱신되면 다른 리파지터리는 매번 소스 코드를 복사해야 한다. 이러한 중복 문제를 효율적으로 해결하고 관리하기 위해 Submodules 개념이 등장했다. 대표적인 사용 방법은 아래와 같다.
### 서브모듈을 모두 포함하여 원격 저장소를 로컬로 복제
$ git clone --recurse-submodules -j8 https://github.com/some-projects/some-project.git

### 서브모듈을 모두 포함하여 원격 저장소로부터 최신 파일을 갱신
$ git pull --recurse-submodules
  • 특정 원격 저장소를 로컬로 복제하면 서브모듈에 해당하는 디렉토리는 텅 빈채 복제가 된다. --recurse-submodules 옵션(v2.13부터 가능) 주면 해당 저장소에 포함된 모든 서브모듈을 자동으로 복제할 수 있다. 추가적으로 -j8(v2.8부터 가능) 옵션을 주면 서브모듈을 동시에 8개까지 병렬로 동시에 복제할 수 있어 시간을 단축할 수 있다.
  • 서브모듈을 포함한 특정 저장소에 대한 변경 작업을 로컬에서 수행한 후 커밋과 푸시는 어떻게 해야 할까? 서브모듈과 상위 저장소에 대한 커밋/푸시를 각각 별도로 진행해야 한다. 사용 예는 아래와 같다.
### 먼저 서브모듈이 포함된 경로로 이동하여 커밋/푸시를 수행
$ cd some-submodule
$ git add .
$ git commit -m "some-comment"
$ git push

### 마지막으로 본 저장소로 이동하여 커밋/푸시를 수행
$ cd ..
$ git add .
$ git commit -m "some-comment"
$ git push

Pull Request란?

  • Pull Request(PR)Git에는 없고 GitHub에 존재하는 개념으로 개발자가 작업한 브랜치를 최종적으로 언제든지 배포 가능한 프로덕션 레벨의 master 브랜치에 머지를 요청하는 절차를 의미한다. PR을 요청하면 팀원 간의 활발한 코드 리뷰와 대화를 통해 최종적으로 머지를 결정하게 된다.
  • base 브랜치는 master 브랜치가 되며 compare 브랜치는 작업자의 브랜치가 된다.

참고 글

댓글
댓글쓰기 폼