[Git/Github] 협업을 위한 Github_간단 정리

프로젝트를 진행하면 깃허브를 사용하게 되는데, 

이때 기본적으로 알아야 할 개념에 대해 간단히 정리해보았다.

 

Git 과 Github

Git VS Github

Git - 버전관리 도구

: 이전 버전으로 롤백을 하고싶을 때 사용

 

Github - 코드 저장소

: Git은 로컬에서 작동하기 때문에 다른 개발자와 협업하기 어려움

-> Github를 사용하면 클라우드 서버를 통해 코드 업로드, 공유 가능

---

Github의 Organization 

Organization을 사용하는 이유

: 일반 repository로 관리할 경우, 해당 repository 주인만 Pull Request 등의 작업 가능

-> 따라서, 다수의 관리자를 설정할 수 있는 Organization이 효율적임

---

브랜치 전략

Git-Flow

: 브랜치를 통해 프로젝트를 관리하는 전략

*보통 5개의 브랜치로 구성

 

[구분]

- main(master) : 프로젝트 진행 초기에 main에서 프로젝트 세팅

- develop : 개발 브랜치

- feature : 단위 기능을 개발하는 브랜치

- release : main으로 보내기 전 품질검사(QA)를 하기위한 브랜치

- hotfix : main으로 배포를 진행했으나 버그가 생겼을 때 수정하는 브랜치

 

Git-flow 단계

1. main에서 프로젝트 기초 설정

2. 개발을 위해 develop 브랜치 분기

3. develop브랜치에서 기능 단위로 feature 브랜치 분기(feature-*형식)

4. feature에서 기능개발이 완료되면 develop으로 merge

5. 배포 준비를 위해 develop브랜치에서 release브랜치를 분기(release-*형식)

6. 테스트가 완료되면 release브랜치를 main과 develop에 merge(병합)

---

기능개발을 위한 이슈 생성

프로젝트 작업 단위 – Issue

ex)

1. ‘로그인’ 기능개발을 해야 하는 상황이 발생하면 해당 기능개발에 대한 Issue 생성

2. ‘develop’ 브랜치에서 A 기능개발에 대한 Branch 분기

* 커밋 메시지에 #이슈 번호를 붙이면 해당 이슈 페이지에서 커밋 확인 가능

 

Pull Request(PR)

서로 다른 브랜치 간 변경사항을 Merge 하기 위해 요청하는 것

-> “내가 짠 코드를 반영해줘”라는 뜻

 

[PR까지 전체적인 과정]

1. Organization의 repository를 clone

2. 브랜치 생성 및 이동

3. 소스 코드 작성 및 변경

4. 변경한 내용을 git add로 스테이징 영역에 저장

5. git commit으로 변경사항을 저장

6. git push로 원격 저장소에 소스 코드를 반영

7.Pull Request를 전송

 

반드시 지켜야 할 규칙

ex) 커밋 메시지 규칙 : 커밋 타입의 첫 글자는 대문자로 작성

타입 이름	내용
Feat	: 새로운 기능 추가
Fix	: 버그 수정
Build	: 빌드 관련 파일 수정/모듈 설치 또는 삭제에 대한 커밋
Docs	: 문서 수정
Refactor	: 코드 리팩토링(변수 이름 변경 등)
Rename	: 파일 수정 및 이동
Test	: 테스트 코드 추가/수정

 

커밋 메시지 작성

* 간단한 내용일 경우 제목만 작성

ex) Feat: 로그인 기능 추가(#이슈 번호) 

 

*이슈 번호는 이슈 생성시 “#00” 형태로 생성된다