[TIL] Day54 - 오픈소스, 깃허브

오픈소스 코드 공개시 > 깃허브 가이드

수익을 챙길시 꼼꼼히 챙기기

오픈소스의 공식 홈페이지 링크를 활용하기

 

프로젝트에 사용시 > 깃허브 레포지토리 Readme / License.txt 에 명시

오픈 소스 가이드

GitHub 프로젝트를 공개하는 것은 프로젝트 라이센싱과 동일하지 않습니다.
 공개 프로젝트는 GitHub의 서비스 약관에 명시되어 있으며, 다른 사람들이 프로젝트를 보거나 포크할 수는 있지만, 다른 권한은 없습니다.

오픈소스 정보 복사로 가져오기만 해도 ㄱㅊㄱㅊ

GPL 분유의 라이선스는 출처 외에도 챙겨야할 사항이 많다 > MIT 추천하는 문화

 

GitHub에서 새로운 프로젝트를 만들 때, 라이선스를 추가할 것인지 물어봅니다.

리포지토리 라이선싱 - GitHub Docs

레포 생성 후 추후에 라이선스 추가할 수도 있다!

리포지토리에 라이선스 추가 - GitHub Docs

 

license.md (txt) 문서 구조

• LICENSE.md
• LICENSE.txt : 마크대운이 아닌, 텍스트 형식의 파일. md와 같은 내용. 오픈소스 라이선스 전문 명시 문서
  • 이 파일이 있으면 = 이 플젝은 이 오픈소스 라이선스 하에 배포되어야 한다.
  • 최상위 디렉토리에 존재한다.
• README.md : 오픈소스의 사용방법 및 목적 설명하는 문서
• COPYRIGHT.txt : 오픈소스의 저작권자에 대한 설명
• NOTICE.txt : 오픈소스 라이선스 개요 설명
• CONTRIBUTING.md : 컨드리뷰터가 되어보자!
• code of conduct : 오픈소스 프로젝트(커뮤니티)에 참여하는 방법에 대한 표준 = 모든 기여 존중, 서로 존중, 호의적 포용적 환경 + 멤버간 이슈 발생에 대한 문제 해결 방안에 대한 내용도 포함되어있다.

 

CONTRIBUTING.md문서

이 프로젝트에 기여하는 것

프로젝트(오픈소스)의 수정에 어떻게 기여할 수 있는지 설명한 문서이다.

오타 및 수정, 변경, 발전 등

해당 프로젝트에 기여하는 절차를 안내한다.

 

hubot/CONTRIBUTING.md at main · hubotio/hubot

 

ex.

• api나 기능을 바꾸고 싶다면 > __ 프로세를 확인해 보아야 한다.
• 이미 존재하는 이슈인지 아닌지 파악하고
• fork하고 clone해서
• 작업을 하고~~ 어쩌구~~

We love pull requests. Here's a quick guide:
If you're adding a new feature or changing user-facing APIs, check out the Hubot Evolution process.
Check for existing issues for duplicates and confirm that it hasn't been fixed already in the main branch
Fork the repo, and clone it locally
npm link to make your cloned repo available to npm
Follow Getting Started to generate a testbot
npm link hubot in your newly created bot to use your hubot fork
Create a new branch for your contribution
Add tests (run with npm test)
Push to your fork and submit a pull request

브랜치, 풀리궤, 릴리즈 언제 되는지 문서도 작성되어있음

 

code of conduct 문서

코드 사용조항. 시행 강령

hubot/CODE_OF_CONDUCT.md at main · hubotio/hubot

contributor 이 코드를 수정해서 기여하려는 사람에서 > 지켜야할 협업예의? 지침과 비슷한 내용

- 인종,,, 국가,,, 성별,,, 등 인간적인 이야기를 함

- 독재자처럼 사용하지 말아라~ 

커뮤니티에 참여하기 위한 윤리강령에 호의적인 개발집단이다~ 라고 설명하는 문서

 

(오픈 소스 프로젝트=)커뮤니티 상태파일

• LICENSE.md, LICENSE.txt, README.md, COPYRIGHT.txt, NOTICE.txt, CONTRIBUTING.md, code of conduct

깃허브는 커뮤니티에 대한 행동 기준! 공정한 방식으로 즐겁게 생산하는 환경!

커뮤니티를 빌딩한다

 

프로필 권장 체크리스트 Insights

이 깃허브에 기여한 사람에 대한 정보, 기간 및 어떤 부분

GitHub - pronist/hello: 😎 당신의 멋진 블로그에 걸맞는 최고의 티스토리 스킨

운영이 잘 되고 있는지 체크할 수 있다.

 

깃허브 이슈 Issue 탭

Open, Close

프로젝트에서 발생할 수 있는 이슈 : 문제, 버그, 개선, 기능추가, 작업 task, 기획 등등

즉 모든 활동을 뜻함

 

왜 이슈를 등록해서 사용하는지? todo list 개념, 해야할 task 가 `Open` 되어 있고 or 계획으로도 사용할 수 있다. + 질문, 댓글을 통한 협업

완료된 이슈를 `Close` 표시, 계획취소 및 중단

 

Issue 로 할일 을 등록하고, 커밋할때 이슈 끌고와서 참조해서 작성할 수 있음.

 

* Jira : 칸반보드 시스템

 

이슈 등록의 템플릿 깃허브에서 메뉴로 제공한다

 

실무에서는 별도의 문서나 소통창구가 존재할 것이다. 오픈소스의 이슈 많이 활용 vs 실무 이슈 많이 활용하지 않는다.

 

Pull Request

pull 당기다

main > 추가 branch를 생성해서 개발한다

병합, 충돌 시에 분기해서 개발한 기능을 > 기존 브랜치에 병합해도 되는지 물어볼때 > Pull Request 풀리퀘 요청한다

Branch가 Branch에게 요청하는 방식 > 컨펌 코드리뷰 후에 merge 진행함.

 

pr 템플릿을 깃허브에서 설정할 수 있다.

 

Discussions 토론 게시판

pronist hello · Discussions

의견 논의

토픽 + 댓글로 커뮤니티처럼 개선사항, 질문 등을 진행한다. (General ,ideas, QnA 등 카테고리 세분화 분리)

code of conduct 대신 깃허브 community guideline 도 사용할 수 있다.

 

☑️ 배운 점

그냥 사용하던 깃허브를 활용하는 방법 배울 수 있었다.

license, cicd, issues, pr, commit 사용하고 있었는데

템플릿 및 규칙을 설정하는 방식을 알 수 있었다. 깊게 알 수 있어서 좋았다.

깃허브 멤버의 역할도 정할 수 있음.