더보기
- 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브랜치에는 직접 커밋하지 말고 머지만
+ Git 실습
https://learngitbranching.js.org/?locale=ko
Ref)
깃, 깃허브 제대로 배우기 (기본 마스터편, 실무에서 꿀리지 말자)
GitHub의 Merge, Squash and Merge, Rebase and Merge 정확히 이해하기
2. 개인블로그 Vercel 에 배포
'SOJU 2기' 카테고리의 다른 글
[SOJU] JavaScript (2) (0) | 2023.05.10 |
---|---|
[SOJU] JavaScript (1) (0) | 2023.04.25 |
[SOJU] HTML & CSS (0) | 2023.04.11 |
[SOJU] 웹개발 개념들 (0) | 2023.03.23 |