[SOJU] GIT

SOJU 2기

[SOJU] GIT

idleday 2023. 3. 23. 14:36

Git, Github 사용법을 익힌다.
블로그를 배포한다.
마크다운 문서를 작성한다.
개인 블로그에 글을 올린다

1. 필수 강의 정리

스스로 기억하고 싶은 것만 기록

+ 다양한 Merge 방법

Fast-Forward
main branch의 Head Commit이 분리된 branch의 Head Commit 이후로 이동된다
단순하게 커밋 이동과 같은 효과이기에, merge commit 이력이 생기지 않는다

non-Fast-Forward
분리된 branch가 main branch의 모든 커밋정보를 갖고있지 않음 (main branch에 새로운 커밋이 있는 경우..etc)
병합하면 main branch 커밋 이력에 feature branch와 병합(merge)된 새로운 커밋으로 생성

gitflow 기본은 non fast-forward

↑

두 방법 모두, 분리된 branch의 커밋들이 main branch에 착 달라가 붙는 형식으로 병합된다.

main branch : M - - - - - - M'
feature branch : \ a-b-c /
병합 후) M -- a-b-c -- M'

Squash and Merge
여러 커밋을 하나의 새로운 커밋으로 추가해 병합
develop - feature 브랜치 간 병합할 경우 유용하다. 일반적으로 병합 후 feature 브랜치를 삭제하기에, feature 브렌치의 커밋 히스토리를 모두 develop 브랜치에 남길 필요가 없습니다.

main branch : M - - - - - - M'
feature branch : \ a-b-c /
병합 후) M -- (abc) -- M'

Rebase and Merge
분리된 브랜치의 원래 base인 main 브랜치의 최신 Head Commit으로 새로 설정해 추가

main branch : M - - - - - - M'
feature branch : \ a-b-c /
병합 후) M - - - - - - M' - a-b-c

+ Pull Request 와 Gitflow

PR로 Merge 요청 보내기
팀으로 작업한다면 직접 merge하기보다 모두 pull request을 통해서 하자
내 pull request(PR)을 보고 코드리뷰를 받고 동료의 PR에 댓글로 change request를 보낼 수 있다
오픈소스에 PR을 보낼 때는 contribution guideline을 반드시 참고하기

Gitflow
깃 브랜치 전략

master : 제품으로 출시될 수 있는 브랜치

develop : 다음 출시 버전을 개발하는 브랜치

feature : 실질적으로 기능을 개발하는 브랜치

release : 이번 출시 버전을 준비하는 브랜치, 실서버 배포용

hotfix: 출시 버전에서 발생한 버그를 수정 하는 브랜치

직접 커밋은 feature, hotfix 브랜치에서만
dev나 master, release브랜치에는 직접 커밋하지 말고 머지만