Open Source Contribution 입문

Contributing Technique

기여의 목적을 명확히 하자

단순히 기여를 위한 기여는 비효율적일 수 있다.

따라서 자신이 실제로 사용하는 프로젝트나 관심 있는 분야에 기여하는 것이 더 의미 있고 동기 부여가 쉽기 때문에 프로젝트의 규모나 유명세보다는 자신이 사용해본/관심있는 프로젝트나 기술에 기여하는 것이 효과적이다.

1. 이슈 탐색 및 등록

프로젝트를 사용하다가 발견한 버그나 개선 사항을 이슈로 등록한다.
이는 개발자들에게 실제 사용자 피드백을 제공하는 중요한 기여이다.

• 버그 리포트 작성법: 재현 가능한 최소한의 예제를 포함하고, 발생한 환경과 버전 정보를 상세히 기술
• 개선 제안: 기능 추가나 성능 개선에 대한 아이디어를 공유

2. 문서 개선

많은 오픈소스 프로젝트에서 문서는 종종 후순위로 밀린다.
문서의 오타 수정, 가독성 개선, 예제 코드 추가 등은 프로젝트의 접근성을 높일 수 있다.

• 번역 기여: 다국어 지원이 필요한 프로젝트에서는 번역 작업이 큰 도움이 된다.
• 가이드 작성: 초보자를 위한 튜토리얼이나 FAQ를 작성하여 신규 사용자 유입을 도울 수 있다.

3. 테스트 케이스 작성

테스트는 소프트웨어의 안정성을 높이는 데 필수적이다.

• 유닛 테스트 추가: 코드 커버리지를 높이기 위해 부족한 테스트 케이스를 추가한다.
• 테스트 자동화: CI/CD 파이프라인에 테스트를 통합하여 지속적인 품질 관리를 지원한다.

4. 코드 리팩토링

코드의 가독성과 유지보수성을 높이기 위한 작은 개선도 큰 도움이 된다.

• 간단한 리팩토링: 변수명 개선, 중복 코드 제거, Code Formatting 등을 수행한다.
• 정적 분석 도구 활용: Lint 도구를 사용하여 잠재적인 버그나 비효율적인 코드를 발견한다.

5. 빌드 및 배포 환경 개선

프로젝트의 설정과 배포 과정을 개선하여 개발자 경험을 향상시킬 수 있다.

• Dockerfile 작성: 개발 환경 설정을 단순화하고 일관성을 유지한다.
• CI/CD 설정: 자동 빌드, 테스트, 배포 파이프라인을 구축하여 개발 효율을 높인다.

빠르게 기여할 수 있는 방법

초보자용 이슈 찾기

많은 프로젝트에서 초보자를 위한 이슈를 따로 표시해 둔다.

• 라벨 검색:

  • good first issue
  • help wanted
  • beginner friendly

• 기여 가이드라인 확인: 프로젝트의 CONTRIBUTING.md 파일을 읽어보면 기여 방법에 대한 정보를 얻을 수 있다.

기여 전에 알아두면 좋은 것들

• 프로젝트의 코드 스타일 준수: 코딩 컨벤션을 지켜 일관성을 유지한다
• 라이선스 이해: 프로젝트의 라이선스를 확인하고 이에 따라 기여한다.
• 커뮤니케이션: 이슈나 PR을 만들 때는 명확하고 예의 바른 소통을 한다.

GitHub 기여 가이드 / 오픈소스 참여 방법 / 초보자를 위한 오픈소스 프로젝트 모음

Contributing Guide

0. Fork Repository

1. Clone Repository

2. Work

3. add / commit / push

4. Send Pull Request

만약 작업한 내용에 관한 기존 이슈가 등록되어 있다면 #1713처럼 # 뒤에 이슈 번호를 적어 참조를 달아준다.

풀 리퀘스트를 날리고나면 메인테이너가 내용을 확인하고 Merge해주길 기다린다.
만약 요청이 묻힌 것 같다면 @ParkSB처럼 댓글로 태그해 정중하게 리뷰를 요청해볼 수 있다.

5. Keep repository up to date

$ git remote add upstream https://github.com/...

원본 저장소를 업스트림(Upstream)이라고 하며, 위 명령을 실행하면 upstream이라는 이름으로 원격 저장소가 추가된다. 업데이트된 원본 저장소의 내용을 가져오려면 아래 명령을 입력한다.

$ git fetch upstream
$ git checkout master
$ git merge upstream/master

fetch로 upstream 저장소의 내용을 가져와서 merge 명령으로 upstream 저장소의 master 브랜치 내용을 내 로컬 저장소에 병합한다. 이렇게 한 번씩 fetch와 merge를 해주면 로컬 저장소를 최신으로 유지할 수 있다.

https://velog.io/@ppp3195/%EC%98%A4%ED%94%88%EC%86%8C%EC%8A%A4-%EC%9E%85%EB%AC%B8%EC%9D%84-%EC%9C%84%ED%95%9C-%EC%95%84%EC%A3%BC-%EA%B5%AC%EC%B2%B4%EC%A0%81%EC%9D%B8-%EA%B0%80%EC%9D%B4%EB%93%9C

---

좋은 Git 커밋 메시지를 작성하기 위한 7가지 약속

왜 커밋 메시지를 잘 써야 할까?

• 더 좋은 커밋 로그 가독성을 위해서다.
• 더 나은 협업과 리뷰 프로세스를 위해서다.
• 더 쉬운 코드 유지보수를 위해서다.

많은 프로그래머들이 잘 쓰인 커밋 메시지가 더 유익하다는 사실에 동의한다. 그렇다면 좋은 커밋 메시지를 작성하기 위한 보편적인 기준은 무엇일까?

좋은 Git 커밋 메시지를 작성하기 위한 7가지 약속

1. 제목과 본문을 한 줄 띄워 분리한다.
2. 제목은 영문 기준 50자 이내로 작성한다.
3. 제목의 첫 글자를 대문자로 쓴다.
4. 제목 끝에 마침표를 사용하지 않는다.
5. 제목은 명령문 형태로 작성한다.
6. 본문은 영문 기준 72자마다 줄 바꿈한다.
7. 본문은 어떻게보다 무엇을, 왜에 맞춰 작성한다.

1. 제목과 본문을 한 줄 띄워 분리한다.

Git의 커밋 메시지는 제목과 본문 사이에 빈 줄을 추가하면 가독성이 향상된다. 이는 git log --oneline과 같은 명령어 사용 시 제목만 깔끔하게 보여준다.

2. 제목은 영문 기준 50자 이내로 작성한다.

제목을 50자 이내로 제한하면 간결하고 읽기 쉬운 커밋 메시지를 작성할 수 있다.

3. 제목의 첫 글자를 대문자로 쓴다.

영문법에 따라 제목의 첫 글자를 대문자로 작성하면 전문적이고 깔끔한 인상을 준다.

4. 제목 끝에 마침표를 사용하지 않는다.

제목에 마침표를 찍지 않는 것이 일반적인 관례다.

5. 제목은 명령문 형태로 작성한다.

Git 자체가 자동 커밋 메시지를 생성할 때 명령문을 사용하므로, 이에 맞춰 제목을 명령문으로 작성하면 일관성을 유지할 수 있다.

• 예: Add new feature (O)
• 예: Added new feature (X)

6. 본문은 영문 기준 72자마다 줄 바꿈한다.

Git은 자동으로 줄 바꿈을 하지 않으므로, 본문을 72자마다 줄 바꿈하여 가독성을 높인다.

7. 본문은 어떻게보다 무엇을, 왜에 맞춰 작성한다.

본문에서는 변경사항이 무엇인지, 왜 했는지에 초점을 맞춰 설명한다.

GitHub 이슈를 자동으로 종료시키기

커밋 메시지에 특정 키워드와 이슈 번호를 포함하면 GitHub에서 해당 이슈를 자동으로 닫아준다.

• 사용 가능한 키워드: close, fix, resolve 등.
• 예: Fix #123 - Correct calculation error

https://meetup.nhncloud.com/posts/106

---

firstcontributions/first-contributions

Fork Repository

아래 repository를 위와 같이 Fork한다

https://github.com/firstcontributions/first-contributions

Clone Repository

 ~/Git/OPEN-SOURCE-CONTRIBUTION
$ git clone https://github.com/judemin/first-contributions.git
Cloning into 'first-contributions'...
remote: Enumerating objects: 98414, done.
remote: Counting objects: 100% (213/213), done.
remote: Compressing objects: 100% (81/81), done.
remote: Total 98414 (delta 140), reused 205 (delta 132), pack-reused 98201 (from 1)
Receiving objects: 100% (98414/98414), 47.79 MiB | 20.90 MiB/s, done.
Resolving deltas: 100% (62426/62426), done.

이후 fork한 repository를 clone한다

Create new Branch

git checkout -b feat-feature

이후 feat-feature 라는 브랜치를 만들고, 해당 브랜치로 이동한다.

Update Contributors.md

Contributors의 맨 첫줄이나 아랫줄을 제외한 아무 곳을 수정하고

git status
git add .
git commit -m "Add judemin to Contributors list"

위와 같이 커밋을 생성한다.

Push Commit

git push origin judemin

Pull Request

이후 Github에서 위와 같이 Pull Request 요청을 날리고

First Contribution

조금 기다리면 자동으로 upstream에 merge해주는 것을 볼 수 있다.

---

Github Code Search Syntex

특수한 코드 한정자, 정규식, bool 연산자를 사용하여 수많은 Github의 프로젝트들 중에서 원하는 결과를 얻는 검색 쿼리를 작성할 수 있다.

코드 검색 쿼리 구조

검색 쿼리는 검색하려는 텍스트와 검색 범위를 좁히는 한정자로 구성된다.

• 기본 용어: 파일의 콘텐츠나 파일 경로와 일치한다.
• 여러 용어: 공백으로 구분하여 여러 용어를 모두 포함하는 문서를 찾을 수 있다.
  • 예: sparse index는 sparse와 index를 모두 포함하는 문서를 찾아준다.

정확한 일치 검색

공백을 포함한 정확한 문자열을 찾으려면 따옴표로 묶으면 된다.

• 예: "sparse index"는 정확히 이 문자열과 일치하는 결과를 찾아준다.

한정자에서도 따옴표를 사용할 수 있다.

• 예: path:git language:"protocol buffers"

따옴표와 백슬래시 검색

• 따옴표 " "를 검색하려면 백슬래시로 이스케이프해야 한다.
  • 예: "name = \"tensorflow\""
• 백슬래시 \를 검색하려면 이중 백슬래시 \\를 사용한다.
  • 예: "C:\\Program Files"

부울 연산자 사용

검색을 더 정확하게 하기 위해 부울 연산자를 사용할 수 있다.

• AND: 기본적으로 공백은 AND로 처리된다. 모든 용어를 포함하는 결과를 찾아준다.
• OR: 둘 중 하나라도 포함하면 된다.
  • 예: sparse OR index
• NOT: 특정 용어를 제외하고 검색할 수 있다.
  • 예: "fatal error" NOT path:__testing__

괄호 ()를 사용하여 복잡한 조건을 만들 수 있다.

• 예: (language:python OR language:ruby) AND NOT path:/tests/

한정자 사용

특수 키워드를 사용하여 검색 범위를 좁힐 수 있다.

• repo:: 특정 리포지토리에서 검색한다.
  • 예: repo:octocat/Spoon-Knife
• org:: 특정 조직 내에서 검색한다.
  • 예: org:github
• user:: 특정 사용자 내에서 검색한다.
  • 예: user:octocat
• language:: 특정 프로그래밍 언어로 검색한다.
  • 예: language:javascript
• path:: 특정 경로나 파일에서 검색한다.
  • 예: path:/src/*.js
• symbol:: 함수나 클래스 같은 기호를 검색한다.
  • 예: symbol:initialize
• content:: 파일의 콘텐츠만 검색한다.
  • 예: content:TODO
• is:: 리포지토리 속성으로 필터링한다.
  • 예: is:public, is:fork, is:archived

정규식 사용

슬래시 /로 감싸서 정규식을 사용할 수 있다.

• 예: /sparse.*index/는 sparse와 index 사이에 어떤 문자들이 와도 일치한다.
• 경로에서 정규식을 사용할 때도 슬래시로 감싸면 된다.
  • 예: path:/^App\/src\//

검색어 구분

검색어, 한정자, 부울 연산자 등은 공백으로 구분해야 한다.

• 괄호 안의 내용은 공백으로 구분하지 않아도 된다.

대소문자 구분

• 기본적으로 검색은 대소문자를 구분하지 않는다.
• 대소문자를 구분하고 싶다면 정규식에서 (?-i)를 사용하면 된다.
  • 예: /(?i)HTTP/는 대소문자 구분 없이 HTTP를 찾지만, /(?-i)HTTP/는 정확히 대문자 HTTP만 찾는다.

---

CodeTriage

또한 여러 오픈소스 프로젝트 선택 도구를 살펴본 결과 CodeTriage가 현재 사용하고 있는 오픈소스 프로젝트들이 많이 포함되어 있고, 이슈를 가장 체계적으로 정리해주고 있어, 이를 활용해 Contribution을 시작할 계획이다.

References
https://github.com/firstcontributions/first-contributions
https://velog.io/@skynet/%EC%98%A4%ED%94%88%EC%86%8C%EC%8A%A4-%EA%B8%B0%EC%97%AC-%EC%9E%85%EB%AC%B8
https://velog.io/@ppp3195/%EC%98%A4%ED%94%88%EC%86%8C%EC%8A%A4-%EC%9E%85%EB%AC%B8%EC%9D%84-%EC%9C%84%ED%95%9C-%EC%95%84%EC%A3%BC-%EA%B5%AC%EC%B2%B4%EC%A0%81%EC%9D%B8-%EA%B0%80%EC%9D%B4%EB%93%9C
https://docs.github.com/ko/search-github/github-code-search/understanding-github-code-search-syntax
https://seongjin.me/how-to-contribute-to-open-source/
https://seohyun0120.tistory.com/entry/%EC%98%A4%ED%94%88%EC%86%8C%EC%8A%A4-%EC%9E%85%EB%AC%B8-%EB%88%84%EA%B5%AC%EB%82%98-%EB%94%B0%EB%9D%BC%ED%95%A0-%EC%88%98-%EC%9E%88%EB%8A%94-%EC%98%A4%ED%94%88%EC%86%8C%EC%8A%A4-%EC%BB%A8%ED%8A%B8%EB%A6%AC%EB%B7%B0%ED%84%B0-%EB%90%98%EA%B8%B0
https://github.com/firstcontributions/first-contributions
https://meetup.nhncloud.com/posts/106