Coding/git

[팀 개발을 위한 Git, GitHub 시작하기] - Ch 6. Github 100% 활용하기

서머스 2024. 7. 29. 10:18

프로필 꾸미기

 

참고한 사이트

 

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 생성을 하게 되면 최소 하나 이상의 리뷰 승인이 필요하기 때문에 병합이 차단된다.

생성한 자신은 스스로 리뷰 승인을 할 수 없다.

 

다른 계정에서 코멘트와 함께 승인을 할 수 있다.