혼자 개발하면 외롭다.

특히, 코드 리뷰를 받고 싶은데 내 마음 같은 사람 만나기도 어렵고 ...

 

우리의 구글님은 이런 외로운 개발자를 위해서

공짜로 Gemini를 제공해주신다 !!! 경배하라 !!!

 

의외로 모르시는 분들이 많은데,

GitHub.com 왼쪽 메뉴를 살펴보면 `Marketplace`가 있다.

- https://github.com/ 

 

 

Marketplace에서는 여러 유형의 상품(?)을 제공해주고 있는데, `Apps` 항목을 살펴보자.

좀 더 편하게 살펴보기 위해 `AI Assisted` 카테고리를 선택하면 `Gemini Code Assist`를 발견할 수 있다.

 

 

오해를 줄이기 위해서는 `Gemini Code Assist for GitHub`이라고 해야할 것 같은데...

https://github.com/marketplace/gemini-code-assist 

 

 

생각보다 설치 수가 좀 적어서 깜짝 놀랐다 !!

 

GitHub PR(Pull-Request)과 관련된 몇 가지 명령어를 제공해주고 있다.

 

 

우리의 구글님은 이런 아름다운 기능을 `Free`로 제공해주고 계신다 !! 경배하라 !!

하지만, 나중에는 십일조라도 받아가시겠지!? ^^

 

 

지금은 Free Tier 이지만,

나중에 얼마든지 십일조를 걷어가기 위해 `결제 정보`는 요구하고 있다.

 

 

개인 계정을 기준으로 설치할 수도 있고, Organization 단위로 설치할 수도 있다.

 

화끈하게 All repositorues를 선택해도 좋지만,

처음에는 조심스럽게(소심하게?) `Only select repositories`를 선택해보자.

 

 

이제서야 `Gemini Code Assis for GitHub`라고 자백하는구나 !!

 

 

우리의 구글님께 모든 권한을 바칩니다 !!! 

 

 

개인 계정 또는 Organization을 선택해야 한다.

 

 

리뷰의 정도를 선택할 수 있는 것 같은데, 일단은 Medium !

 

 

이 정도의 설정만 해주면 된다.

 

 

지정한 Repository의 Settings를 보면 잘 설치되어 있는 것을 확인할 수 있다.

 

 

이렇게 해놓은 상태에서, PR을 신규로 올리면 자동으로 코드 리뷰를 진행해준다.

그리고, 직접 명령을 내릴 수도 있다.

 

 

이렇게 명령을 내리면, gemini가 지켜보는 이모지가 등장한다 !! 귀엽다 !!

 

 

그렇게 시간이 좀 지나면, Gemini가 리뷰를 준다.

 

 

Summary는 기다림 없이 바로 이루어진다.

 

 

리소스 할당에 따라 지켜보는 이모지가 선택적으로 나오는 것일까?

 

 

코멘트 중간에 Gemini 홍보(광고? 안내? 공지?)도 들어있다.

 

무료인데 안쓸 이유는 없을 것 같다 !! 고고씽 !!

반응형

Git을 이용해서 소스코드 버전 관리를 하며 개발을 한다고 하면서

branch와 code-review(pull-request)를 이야기하지 않으면 안될 것 같다.

 

[ Default Branch ]

Git을 처음 공부하면 기본적으로 main branch를 사용한다고 배울 것이다.

(master branch라고 하면 나이 많이 들었다고 인정하는 것이다 !!! 😅)

 

조금 더 공부하다보면 꼭 "main" 이름이 아니어도 된다는 것을 알 수 있다.

하지만, 그냥 "main"으로 정하는 것이 속편하다는 것도 알게된다.

 

그렇지만 GitHub을 사용한다면, `기본 브랜치(base branch)`를 변경하는 것이 상당히 쉽다.

 

 

 

그럼, 이렇게 설정한 default branch에는 바로 commit을 반영하지 못하고

반드시 Pull-Request를 통해서 approve 받은 내역만 merge가 되도록 설정을 해보자.

 

(오해는 하지 말아야 한다. 반드시 default branch에 대해서만 이렇게 할 수 있는 것은 아니다 !!!)

 

 

[ Branch protection rules ]

Repository의 Settings 메뉴 중 `Branches` 부분을 살펴보도록 하자.

 

 

기존 방식의 `Add classic branch protection rule` 항목이 아직도 보이지만,

현재 새로 힘을 주고 있는 rulesets 방식으로 살펴보도록 하자.

 

`Add branch ruleset` 버튼을 누르고 왼쪽 메뉴를 보면

`Rules` 항목으로 점프한 것을 볼 수 있을 것이다.

 

요즘 GitHub에서 Rules 부분으로 뭔가 다 모으고 있다.

 

 

`Rulesets` 항목이 여러가지인데,

지금 우리가 진행하는 항목은 `branch ruleset`이다.

 

Ruleset 이름은 편하게 지어주면 되고,

이렇게 만들어진 ruleset은 활성화 여부를 선택할 수 있다. (Enforcement status)

 

사용자들의 다양한 요구사항이 있어서인지

왠지 기존에 GitHub에서 잘 반영해주지 않던 Bypass와 같은 옵션도 추가가 되어 있다.

 

다음으로

어떤 branch에 지금 ruleset을 적용할 것인지 선택해보자.

 

 

pattern을 지원해주면서 정말 자유도가 확! 올라갔다.

지금은 그냐 default branch로 정하고 진행해보자.

 

 

한동안 살펴보지 않은 동안에, 정말 신기하고(?) 요상한 옵션들이 많이 생겼다. 공부 많이 해야할 것 같다😥

 

지금 중요한 옵션은 `Require a pull request before merging` 이다 !!!

 

 

다행히 예전(classic ?) 옵션들과 크게 바뀌지 않았다.

`Required approvals` 부분을 1 이상 값으로 넣어버리자 !!!

 

 

형상관리(소스코드 버전 관리)에서 가장 해로운 행위인 `force push` !!!

기본적으로 설정되어 있는 `Block force pushes` 옵션은 꼭 유지하자 !!!

 

이렇게 해서 만들게 되면 아래와 같이 Rulesets이 저장된다.

 

 

 

[ Practice ]

이렇게 적용하면 어떻게 되는지 살펴보자.

 

기존에 하듯이 commit 작성 후 `main` branch에 push를 하면 reject을 당한다.

 

 

코드리뷰(pull-request)를 받지 않은 commit을 집어넣으려고 하니 거절을 하는 것이다.

 

 

새로운 branch를 만들어서 그렇게 집어넣으면 이것은 잘 들어간다.

이렇게 되면 GitHub에서는 pull-request를 할거냐고 묻게 된다.

 

 

당연히 Pull-Request 생성하면 된다 !!

 

 

이렇게 만들어지면 앞에서 만든 Ruleset에 의해 제약이 걸리게 된다.

 

 

빨간 딱지들을 잘 봐야 한다.

리뷰를 반드시 받아야 하며(approve), 지금은 조건을 충족하지 못했기에 merge가 막혀있다 !!!

 

어?! 그런데, 어떻게 하지!?

나는 Pull-Request를 만든 사람이기에 approval을 할 수가 없다 😅

 

 

다른 누군가가 도와줘야 한다 😍

 

 

혼자서는 ... 코드리뷰를 동반한 S/W개발은 팀으로 해야하는 것이다 !!! ㅋ

 

혼자서라도 어떻게든 되도록 하고자 한다면,

`Required approvals` 값을 0으로 해야 한다.

 

AI Agent 세상에서 코드 리뷰의 필요성은 더욱 더 커졌다.

- 사람이 작성한 코드에 대한 AI 코드 리뷰

- AI가 작성한 코드에 대한 사람의 코드 리뷰

 

이러한 프로세스를 강제화 하고 자동화 하기 위한 기본 개발환경 설정을 살펴보았습니다.

반응형

+ Recent posts