[SOJU] GIT

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

---

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브랜치에는 직접 커밋하지 말고 머지만

 

+ Git 실습

https://learngitbranching.js.org/?locale=ko 

Learn Git Branching

 

---

Ref)

깃, 깃허브 제대로 배우기 (기본 마스터편, 실무에서 꿀리지 말자)

[GIT] Fast-Forward (병합 방법)

GitHub의 Merge, Squash and Merge, Rebase and Merge 정확히 이해하기

패스트캠퍼스 (처음 배우는 Git & GitHub)

우린 Git-flow를 사용하고 있어요

 

---

2. 개인블로그  Vercel 에 배포

• https://build-own-blog-with-next-js-idleday.vercel.app/