프로필 꾸미기
참고한 사이트
https://github.com/Naereen/badges
GitHub - Naereen/badges: :pencil: Markdown code for lots of small badges :pushpin: (shields.io, forthebadge.com etc) :sunglasses
:pencil: Markdown code for lots of small badges :ribbon: :pushpin: (shields.io, forthebadge.com etc) :sunglasses:. Contributions are welcome! Please add yours! - GitHub - Naereen/badges: :pencil: M...
github.com
https://github.com/anuraghazra/github-readme-stats
GitHub - anuraghazra/github-readme-stats: :zap: Dynamically generated stats for your github readmes
:zap: Dynamically generated stats for your github readmes - anuraghazra/github-readme-stats
github.com
https://github.com/DenverCoder1/readme-typing-svg
GitHub - DenverCoder1/readme-typing-svg: ⚡ Dynamically generated, customizable SVG that gives the appearance of typing and del
⚡ Dynamically generated, customizable SVG that gives the appearance of typing and deleting text for use on your profile page, repositories, or website. - DenverCoder1/readme-typing-svg
github.com
더 좋은 풀 리퀘스트 만들기
conventional commits에 따른 변경 사항 분류
feat | 새로운 기능을 구현했을 때(서비스의 기능이 수정되는 것이라면 모두 포함. 문구 수정도 포함 |
fix | 기능에는 수정 사항이 없고 버그가 수정되었을 때 |
perf | 서비스나 라이브러리의 성능을 개선했을 때 |
refactor | 기능 추가도 없고, 버그 수정도 없는 단순 리팩터링 |
test | 테스트를 추가하거나 기존에 잇는 테스트를 수정했을 때 |
build | 빌드 시스템이나 npm 배포에 대한 수정 |
ci | CI 설정이 수정되었을 때(Jenkins, Travis) |
chore | 그 외 실제 코드에는 영향이 없는 단순 수정 |
PR(Pull Request)를 만들 때 여러가지 기능을 개발해서 PR을 작성하려 하지 말고, 하나의 기능만 담을 수 있도록 쪼개는게 좋다.
또한 Conventional Commits 기준으로 변경 사항의 의도를 드러내는 것이 좋다.
description에 변경 사항을 작성한다.
세부적으로 리뷰받고 싶은 곳이나 부가 설명이 필요한 코드가 있다면 review를 달 수도 있다.
풀 리퀘스트 병합하기
병합 커밋 생성(Create a merge commit)
가장 기본적인 방법
스쿼시해서 병합(Squash and merge)
a b c의 변경사항을 하나로 퉁쳐서 합친다.
PR에 커밋을 아무리 많이 올렸어도 main 브랜치의 커밋 히스토리에는 PR마다 커밋 1개만 남는다.
리베이스해서 병합(Rebase and merge)
내 커밋 히스토리를 그대로 살려서 최신 main 브랜치에 떼어 붙이는 코드 병합 방식이다. main 브랜치에서 커밋 히스토리를 모두 볼 수 있다는 특징이 있다.
그림 출처 : https://velog.io/@injoon2019/Git-Merge-종류
[Git] Merge 종류
출처: https://im-developer.tistory.com/182GitHub은 아래 3가지의 Merge Button이 가능해요.Merge CommitSquash MergingRebase Merging저장소에 맞게 허용 가능한 병합 방법을 Settings
velog.io
GitHub에서 풀 리퀘스트 되돌리기
feat/bug 라는 브랜치를 만든다.
세 개의 버그 커밋을 만든다.
feat/bug의 내용을 푸시한다.
새로운 PR을 작성한다.
Merge pull request - Confirm merge 를 하여 PR을 병합한다.
풀 리퀘스트를 한번에 리버트하기
Revert 버튼을 클릭한다.
Revert를 위한 PR이 새로 만들어진다.
PR 리버트가 완료된다.
main 브랜치로 checkout 한 후 pull하게 되면 아래와 같은 그래프가 된다.
병합커밋 2개와 revert 커밋 1개가 생성되어 있다.
브랜치 보호하기
branch protection rule을 사용하면 다양한 규칙으로 브랜치에 위험한 작업이 수행되는 것을 막을 수 있다.
우측의 [Add classic branch protection rule]을 클릭한다.
리뷰를 강제하고 브랜치를 보호한다.
이렇게 하면 지정된 main 브랜치에는 반드시 다른 브랜치 커밋들의 PR을 통해서만 커밋이 생성된다.
[Require approval] 옵션은 리뷰어 승인이 있어야만 PR을 병합할 수 있게 한다.
관리자에게도 적용되도록 한다.
main 브랜치에 직접 커밋을 만들고 push 하면 에러가 난다.
feat/f 브랜치를 만든 후 임의로 파일을 수정하고 commit 후 push 한다.
PR 생성을 하게 되면 최소 하나 이상의 리뷰 승인이 필요하기 때문에 병합이 차단된다.
생성한 자신은 스스로 리뷰 승인을 할 수 없다.
다른 계정에서 코멘트와 함께 승인을 할 수 있다.
'Coding > git' 카테고리의 다른 글
[팀 개발을 위한 Git, GitHub 시작하기] - Ch 7. CLI 환경에서 Git 명령어 살펴보기 (0) | 2024.12.08 |
---|---|
[팀 개발을 위한 Git, GitHub 시작하기] - Ch 4. 둘 이상의 원격 저장소로 협업하기 (0) | 2023.09.10 |
[팀 개발을 위한 Git, GitHub 시작하기] - Ch 3. 여러 명이 함께 Git으로 협업하기 (0) | 2023.09.05 |
[팀 개발을 위한 Git, GitHub 시작하기] - Ch 0. 빠른 실습으로 Git, Github 감 익히기 (0) | 2023.08.20 |
작년과 올해, 깃 변화 (0) | 2021.12.31 |