clean-parking/README-git.md

GIT

목차

• 0. 개요
• 1. Branch
• 2. Commit
• 3. Push
• 4. Pull Request
• 5. 배포

0. 개요

Git Branch, Commit & push 전략을 설명하는 가이드

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

0-1. 기본 원칙

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

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

1. Branch

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

2. Commit

• SVN 이랑 다르게 Local Branch 에서 스냅샷을 찍는 개념임.
• 해당 Commit을 Push 함으로 최종 저장함.
• Local Branch 끼리 이동(Check Out) 할때는 변경사항을 커밋해야 다른 Branch에 영향을 안줌.
  
  
• 추후 형상관리 이슈추적을 위해 커밋메시지는 가능한 자세히 작업내용을 적도록 함.
• 아래는 커밋메시지 예제이다.

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

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

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

4. Pull-Request

Mian Remote Branch에 병합요청 (Merge)

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

5. 배포

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