Github Pull Request 실습하기

오픈소스컨트리뷰션 1주차

실습 내용

1주차 오프라인 모임에서는 Pull Request에 대한 실습을 진행하였다.

해당 Repository를 fork한 후 README에 각자 자기소개를 작성한 뒤 PR을 올렸다.

 

GitHub - sukkyun2/kindergarten: Let's practice!

 

 

실습은 어렵지않게 했지만 내가 PR을 날리는 과정을 정리해보려고 한다.

(실제로 나도 많이 PR을 사용해보지는 않았다..)

 

 

PR 관련한 협업 프로세스를 두가지로 정리해볼 수 있다.

 

1. 내가 PR을 올릴 경우

2. 다른 사람이 PR을 올리는 경우

 

 

내가 PR을 올릴 경우

처음에 할 일은 Local Repository  main 혹은 develop 브랜치에서 checkout을 하는 것이다.

checkout시, 새로운 브랜치의 이름은 아래 규칙을 따른다. 

 

예를 들어서 

DeepSORT를 사용하여 객체추적 기능을 개발했다면 브랜치의 이름은 feat/object-tracking-using-deepsort

Github Actions Workflow를 수정했다면 브랜치의 이름은 build/modify-actions

 

개발을 하다보면 이 경우들 이외의 경우가 발생하기도 하는데 나는 그냥 chore로 퉁쳐서 사용한다.

타입이름	내용
feat	새로운 기능에 대한 커밋
fix	버그 수정에 대한 커밋
build	빌드 관련 파일 수정 / 모듈 설치 또는 삭제에 대한 커밋
chore	그 외 자잘한 수정에 대한 커밋
doc	README.md 파일 등 문서 수정에 대한 커밋
refactor	코드 리팩토링에 대한 커밋
test	테스트 코드 수정에 대한 커밋

 

이렇게 커밋을 한 후에 Local Repository:feat** 에서 Orgin Repository:feat** 로 Push한다.

 

그다음에는 Origin Repository:feat** 에서 Upstream Repository:develop 으로 PR을 올린다.

 

올린 PR이 merge되면 끝

 

다른 사람이 PR을 올리는 경우

다른 사람이 올린 PR이 merge된다면 Upstream Repository:develop 에는 변경사항이 생긴다.

 

이때 Upstream Repository:develop  에서  Local Repository:develop 로 Pull을 하면 다른 사람의 변경사항을 가져올 수 있다.

 

Local Repository:develop 은 상위 Repository에 대한 변경사항을 최신화하는데 쓰인다.

 

이 브랜치에서 커밋을 하지는 않으며 이후 개발을 진행할 때는 

Local Repository:develop 에서 Local Repository:feat** 으로 또 다시 checkout을 진행한다.

 

 

Litmus Chaos PR 방법

Litmus Chaos에서는 어떤 방식으로 PR을 올려야하는지 확인해보았다.

 

아래 내용은 CONTRIBUTING.md 에서 발췌한 내용이다.

 

Submitting a Pull Request

To submit any kinds of improvements, please consider the following:

• Submit an issue describing your proposed change. If you are just looking to pick an open issue do so from a list of good-first-issues maintained here.
• We would promptly respond back to your issue
• Fork this repository, develop and test your code changes. See the Highlighted Repositories section below to choose which area you would like to contribute to.
• Create a feature branch from your forked repository and submit a pull request against this repo’s main branch.
  • If you are making a change to the user interface (UI), include a screenshot of the UI changes.
• Follow the relevant coding style guidelines
  • For backend contributions, popular ones are the Go Code Review Comments and the Formatting and style section of Peter Bourgon's Go: Best Practices for Production Environments.
  • If you are making any changes in backend, make sure you have run and tested the code locally, the reviewers might ask for relevant screenshots in the comments.
  • For frontend contributions, we follow the Airbnb style guide
• Your branch may be merged once all configured checks pass, including:
  • The branch has passed tests in CI.
  • A review from appropriate maintainers (see MAINTAINERS.md and GOVERNANCE.md)