# 형상관리(Git)

## Intro

<figure><img src="https://3572862491-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FUON3CGxVeoUR2YdtAhxl%2Fuploads%2FcFeSyuZhwO2t2Stg9t2y%2Fimage.png?alt=media&#x26;token=d4784032-063f-4126-9c0f-746f6ea76cb3" alt=""><figcaption></figcaption></figure>

* 학생시절 레포트를 제출해야할때나, 상사에게 보고해야할 보고자료를 작성할때 위처럼 직접 보고자료에 대한 **버전관리**를 수행해본 경험이 있을 것이다.
* &#x20;단순 파일이나 보고서라면 상관 없겠지만, 복잡한 소프트웨어의 **변경이력**을 관리하기 위해서는 **형상관리**에 대한 개념과 형상관리를 지원하는 도구들에 대해 이해하고 다룰 줄 알아야 한다.

## 1. 형상관리

* 소프트웨어의 변경사항을 체계적으로 관리하고 통제하는  것.
* 변경사항이라 함은 파일의 추가, 삭제 뿐만 아니라 파일 내부의 소스코드의 수정내용 또한 포함 된다.
* 시간이 지남에 따라 변해가는 소프트웨어의 변경사항들을 관리하면서 소프트웨어의 형상을 체계적으로 관리하고 유지하므로 형상관리를 지원하는 도구를  "**형상관리 시스템**"이라고 부른다

## 2. Git

<figure><img src="https://3572862491-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FUON3CGxVeoUR2YdtAhxl%2Fuploads%2F6ufHr0nD5eC6xoQesk9H%2Fimage.png?alt=media&#x26;token=fa67785d-f916-43a5-bc3a-ca8bdab080fa" alt=""><figcaption><p>git</p></figcaption></figure>

* 대표적인 **형상관리 도구**
* 소스코드를 저장하고 이력을 관리하는 **저장소(repository)**&#xC774;다.
* 원하는 시점에 소스코드를 저장하거나, 저장지점으로 돌아가는 기능을 제공하여 프로젝트의 버전을 관리할 수 있다.
* 여러 pc에 소스코드를  저장시키거나 여러 pc에 저장한 내용을 하나로 병합하는 것이 가능하다.

## 3. GitHub

<figure><img src="https://3572862491-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FUON3CGxVeoUR2YdtAhxl%2Fuploads%2FYE8jIHdLlfygQ5t3ZxPX%2Fimage.png?alt=media&#x26;token=f7e20e64-15fd-457b-9913-2d34c33c1e2a" alt=""><figcaption></figcaption></figure>

* Git을 웹으로 이용할 수 있게 만든 원격 저장소(remote repository)이다.
* 여러 개발자가 하나의 원격 저장소를 이용하여 소스코드를 **내려받거나,** **병합**하는 행위가 가능하다. 즉 프로젝트 단위로 하나의 **원격저장소를** 이용하여 협업이 가능한 것이다.

## 4. Git의 구조와 명령어들

### 1) 구조

<figure><img src="https://3572862491-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FUON3CGxVeoUR2YdtAhxl%2Fuploads%2F7m7hkMbl2vvdt1YcZWJl%2Fimage.png?alt=media&#x26;token=23331c1d-7c5d-4c61-b6d8-593f3669df1e" alt=""><figcaption></figcaption></figure>

### 2) Working Directory

* 프로젝트를 진행하는 폴더를 의미하며, `Working Directory`내부에서 소스코드 변경 후 저장 시(ctrl+s) 자동으로 `git add` 명령어가 실행되며, "**변경사항**"을 Staging Area로 전달됨.
* `Local Repository`에 저장된 소스코드를 현재 프로젝트에 `merge`명령어를 통해 병합가능하다.
* `checkout` 명령어를 통해 작업 `Branch` 변경도 가능하다.

### 3) Staging Area

* 변경된 코드가 `Local Repository`에 저장되기 전에 머무르는 **중간영역** 이다. `Local Repository`에 저장할 파일을 선택하고 `commit` 명령어를 통해 저장할 수 있다.
* 저장하기 싫다면 변경 전 코드로 돌아가면 자동으로 Staging Area에서 제외된다.

### 4) Local Repository

* 내 컴퓨터(PC)내에 존재하는  **저장소**이다. 소스코드의 변경/추가등의 이력을 기록한다.
* `Local Repository`에 저장된 내용은 `push` 명령어를 통해 `Remote Repository`로 밀어 넣을수 있고 fetch 명령어를 통해`Remote Repository`에서 당겨 올 수 도 있다.
* `fetch`와 `merge`를 합친 `pull` 이라는 명령어도 존재한다. 단  `pull`을 통한 자동병합보다는 `fetch`후 수동병합을 권장한다.

### 5) Remote Repository

* Git Hub에 존재하는 **저장소**이다.&#x20;

## 5. Branch

<figure><img src="https://3572862491-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FUON3CGxVeoUR2YdtAhxl%2Fuploads%2FGkLF3F1EuMWn7S8HQrO2%2Fimage.png?alt=media&#x26;token=cdaa7964-2248-45e2-82a2-67b0158105b3" alt="" width="188"><figcaption></figcaption></figure>

* Git에는 **Branch**를 통해 하나의 저장소 내에 **여러 버전**을 만들어 작업할 수 있다.
* 협업시 `master`브랜치를 여러개로 나누어 각 개발자는 **독립적인 작업**을 진행한다.
* 각 branch로 가져간 코드는 원본에 영향을 미치지 않으므로 자유로운 작업이 가능하며, branch의 변경된 내용만 `master` 에병합 시키는 **PR(Pull Request)**&#xB97C; 보낼 수 있다.
* 프로젝트에 참여한 개발자들은 PR이 들어온 경우 요청 내용을 다같이 **검토(Review)**&#xD55C;다
* 문제가 없다면 **PR(Pull Request)**&#xC2B9;인 후 변경 내용을 `master`에 병합한다

## 6. Git Branch 전략

### 1) Git Flow 전략

<figure><img src="https://3572862491-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FUON3CGxVeoUR2YdtAhxl%2Fuploads%2FQjlDzYcQ4E6wTH1ZnhHF%2Fimage.png?alt=media&#x26;token=414c0854-a617-4a57-baa7-61161964b419" alt="" width="563"><figcaption></figcaption></figure>

* Git Flow는 기능개발(feature), 릴리즈(release), 버그수정(hot fixes), 개발(develop)의 목적에 맞춰 브랜치를 분리하여 관리하는 브랜칭 모델이다
* 가장 표준화된 깃 브랜치 사용방법으로, 브랜치별 역할 분담이 잘 되어 있어 효율적으로 브랜치를 사용할 수 있다.
* 규모가 큰 개발 팀에서 사용하는 방식

### **브랜치의 종류와 역할**

1. `master` : 실제 **프로덕션(운영) 환경에 배포되는 코드를 관리**하는 브랜치로, 즉시 배포 가능한 상태를 유지해야 한다.
2. **`develop` : 개발의 중심 브랜치. feature(기능)**&#xBE0C;랜치의 코드들을 **병합** 하고, 병합완료   후 release로 소스코드를 다시 병합한다.
3. `feature/*` : 새로운 기능 개발을 위한 브랜치. develop에서 분기하고, 기능개발 완료후 develop에 merger한다.
4. `release/*` : 릴리즈(테스트)준비를 위한 브랜치. develop에서 분히 후 문제 없을 시 master, develop에 merge한다.
5. `hotfix/*` : 운영환경에서 발생하는 버그를 수정하기 위한 브랜치. master에서 분기 후 , master와 deveop에 머지한다.

### 2)  GitHub Flow

* **master브랜치와 feature 브랜치 2가지 종류**로만 관리하는 간단한 브랜치 전략으로, 소규모 팀단위에서 사용하면 적절한 방식의 브랜치 관리 방법이다.(**세미/파이널시 사용할 전략**)

<figure><img src="https://3572862491-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FUON3CGxVeoUR2YdtAhxl%2Fuploads%2FsHCl1LiYxGfgysxuTs4I%2Fimage.png?alt=media&#x26;token=0ec69bf4-f705-4152-8678-c876222dee90" alt="" width="563"><figcaption></figcaption></figure>

* GitHub Flow 관리방법
* **matser브랜치는 항상 배포가능한 상태로 관리**한다.
* **모든 기능**은 master브랜치에서 분기 후 **feature bracnh에서 작업** 하구, PR(Pull Request)요청을 통해 리뷰 후 matser브랜치에 병합한다.(master에서 직접 작업하지 않는다)
* 기능이 완성된 브랜치는 자동/수동 삭제 처리하여 브랜치를 깔끔하게 관리한다.
