# GIT

## 목차

- [0. 개요](#0-개요)
- [1. Branch](#1-Branch)
- [2. Commit](#2-Commit)
- [3. Push](#3-Push)
- [4. Pull Request](#4-Pull-Request)
- [5. 배포](#5-배포)


### 0. 개요
Git Branch, Commit & push 전략을 설명하는 가이드</br></br>

- Git은 Local / Remote 로 나누어진다.
- 1(Branch), 2(Commit)은 [Local]에서 하는 작업이다.
- 3(Push)는 Local -> Remote 로 업로드 하는 과정이다 (svn으로 치면 commit)
- svn은 한번의 커밋으로 원본을 바로 수정하는 반면, 깃은 Local에서 커밋을 하고, 체크후 푸쉬를 한다.
- 더욱 안전한 형상관리가 가능하다.

<img src="src/main/webapp/resources/img/git-img1.png"> </br></br>

### 0-1. 기본 원칙
- 에러가 나고 있는 상황은 절대로 Main(dev)에 Push하지 않는다.
- Push 하기 전, 무조건 Main(dev)를 본인이 작업한 Branch에 Update(Pull) 받고 충돌체크를 한다.
- Push 하기 전, 프로젝트 정상기동은 반드시 체크한다.</br>


*위 사항을 지키지 않을시 공동 작업자들이 힘들어짐.*


</br></br></br></br></br>



### 1. Branch
- 레파지토리, 작업공간이라고 생각하면된다.
- Local Branch 와 Remote Branch 로 나눠진다.
- Local Branch 는 작업자가 원하는 만큼 원할때 마음것 만들고 지우고 해도 된다.
- 단, 여러 Local Branch를 Remote에 Push 할꺼면 작업자의 폴더를 만들어서 해당 폴더안에 깔끔하게 정리하도록 한다.
- 각기 다른 작업을 한 Branch는 Merge후 하나로 만들어서 Push 하도록 한다.

<img src="src/main/webapp/resources/img/git-img2.png"> </br></br>


</br></br></br></br></br></br>




### 2. Commit
- SVN 이랑 다르게 Local Branch 에서 스냅샷을 찍는 개념임.
- 해당 Commit을 Push 함으로 최종 저장함.
- Local Branch 끼리 이동(Check Out) 할때는 변경사항을 커밋해야 다른 Branch에 영향을 안줌.
</br></br>
- 추후 형상관리 이슈추적을 위해 커밋메시지는 가능한 자세히 작업내용을 적도록 함.
- 아래는 커밋메시지 예제이다.
```
-----------------------------------------------
feat : Sample 작업
1. sample 프론트 페이지 작업
2. sample 조회 쿼리 작업
3. sample 벨리데이션 추가
-----------------------------------------------
fix : 프로퍼티 설정 수정 및 db 주소 수정
1. 운영 프로퍼티 키값 수정
2. db 수정 211.xxx.xxx.xx -> 211.xxx.xxx.xx
-----------------------------------------------
```
아래는 Commit Message Rule

```
//아래와 같이 여러가지가 있지만 feat/fix/refactor 정도면 충분할꺼 같다.
feat -> 새로운 기능에 대한 커밋
fix -> 버그 수정에 대한 커밋
refactor ->	코드 리팩토링에 대한 커밋

build -> 빌드 관련 파일 수정 / 모듈 설치 또는 삭제에 대한 커밋
chore -> 그 외 자잘한 수정에 대한 커밋
ci -> ci 관련 설정 수정에 대한 커밋
docs -> 문서 수정에 대한 커밋
style -> 코드 스타일 혹은 포맷 등에 관한 커밋
test -> 테스트 코드 수정에 대한 커밋
perf -> 성능 개선에 대한 커밋
```

### 3. Push
- Remote Branch 에 Commit을 밀어넣는 과정이다.
- 기존 SVN으로 따지면 Commit 과 같은과정이다. 
</br></br>
- 현재 Git 전략 구성은 prod(master) / dev(dev) / developer(개발자 브랜치) 로 나누도록 한다.
- prod(master) : 운영서버에 배포될 소스.
- dev(dev) : 회사 개발서버(테스트)에 배포될 소스.
- developer(개발자 브랜치) : 각 개발자들이 임시로 저장하는 소스. (사실상 커밋만으로도 충분해서 임시푸시는 지양한다.)
</br></br></br></br>
[작업(개발/완료후Push)에 앞서 해야하는 과정들]</br>
Remote Dev(항상 가장 최신버전임. master가 1.0.0 버전이라면 dev는 아직 배포가 되지않은 1.0.1의 느낌)

1. Remote Dev를 Local Dev에 업데이트 (Remote Dev는 다른작업자들이 한 작업이 수시로 업데이트됨)
2. Local Dev - Local developer 를 Merge

</br></br>
** 하루 개발시작전, 개발완료 후 Push 직전 해당과정을 꼭 거쳐서 소스 충돌이 없도록 한다. ** </br>
** Push 직전 Merge 후, 구동에 문제 없으면 Push 하도록 한다. **



</br></br></br></br></br></br>




### 4. Pull-Request
Mian Remote Branch에 병합요청 (Merge)
- 각 개발자들은 developer(개발자 브랜치) 자신의 Local Branch 에서 작업을 한다.
- 작업이 완료되면, Remote dev/master 에 Push 하는게 아닌 Remote developer(개발자 브랜치)에 Push 한다.
- 이후, git에 들어가서 Pull Request를 생성한다.
- 해당 Pull Request는 관리자가 체크 후 구동에 문제가 없으면 수락한다. 문제가 있을시 롤백 및 요청을 거잘한다.
- 수락이되면 작업내용이 dev에 반영된다.
- 거절이 되면 다시 작업하고 다시 요청을 보내도록 한다.
</br></br>


<img src="src/main/webapp/resources/img/git-img3.png"></br></br>
<img src="src/main/webapp/resources/img/git-img4.png"></br></br>
<img src="src/main/webapp/resources/img/git-img5.png"></br></br>
<img src="src/main/webapp/resources/img/git-img6.png"></br></br>

</br></br></br></br></br></br></br>



### 5. 배포
- 배포는 Remote Master 브랜치를 기준으로 배포한다.