Github opensource 참여하기

깃허브 Fork

원하는 오픈소스 프로젝트를 Fork한다. 예를들어 https://github.com/fsoftwareengineer/githubtutorial 이 프로젝트에 참여하고 싶다면 오른쪽 상단에 보이는 Fork버튼을 눌러 이 리파지토리를 본인의 리파지토리로 복사한다. 

 

Fork를 하는 것은 본인 버전의 리파지토리를 생성하는 것과 같다. Fork를 누르면 다음과 같이 자신의 리파지토리로 넘어간다.

상단의 리파지토리 이름이 <아이디>/<포크 한 리파지토리 이름>으로 설정되어 있을 것이다. 이렇게 해서 본인 버전의 리파지토리를 가지게 되었다. 본인 버전의 리파지토리라 함은 당신이 이제 이  Fork된 버전의 리파지토리를 Clone 및 Commit 할 수 있는 권한이 생겼다는 것이다.

 

깃허브 Clone

리모트(remote) 환경에 있는 리파지토리를 로컬(local) 환경(컴퓨터)로 다운로드 하는 것을 Clone이라고 부른다. 클론을 하기 위해서는 리파지토리의 주소가 필요한데 주소는 본인이 포크란 리파지토리에 "Clone or download"에서 찾을 수 있다.

 

깃허브 Branch

<git directed acyclic graph - 색이 있는 동그라미는 commit, 회색 동그라미은 branch off 또는 merge in을 의미한다.>

 

이 그림은 마스터 브랜치의 타임라인이다. 마스터 브랜치를 release브랜치로 사용 하는 경우 대부분 develop브랜치를 따로 둔다. develop브랜치란 개발자들이 checkout하고, 자신의 브랜치를 만들고 개발을 진행하는 브랜치를 의미한다. 예를들어서 위의 스크린샷을 보면  master브랜치 위에 feature/develop이라는 브랜치가 있는 것을 확인 할 수 있다. 앞으로는 feature/develop 브랜치에서부터 브랜치 오프(branch off)를 하면 된다는 뜻이다.

 

현재 이 리파지토리의 타임라인은 다음과 같다. 마스터 브랜치가 존재하고 그 이후에 branch off된 feature/develop브랜치가 존재한다. 브랜치의 이름은 오픈소스마다 다르고 어떻게 브랜치를 이용하는지도 오픈소스마다 다르다. 따라서 어떤 오픈소스에 참여 한다면 그 오픈소스의 문서를 반드시 읽어보기 바란다. 대부분의 오픈소스는 컨트리뷰터들을 위한 가이드가 준비되어있다.

이제 당신은 feature/develop 브랜치 위에 있다. 그렇다면 여기에서 이제 개발을 하면 되는 것인가? 내가 commit하고 push할 코드는 나의 개발이 끝날 때 까지 다른 사람들의 코드와 분리되어 있어야 한다. 그렇지 않으면 동작하지 않는 코드를 commit/push하고 다른 사람들의 코드까지 엉망진창으로 만들어 버릴 수 있다. 그런 상황을 막기 위해 "내가 개발할 이슈" 브랜치를 만들도록 하자. 위에서 봤듯이 내가 개발할 이슈 브랜치는 보통 해당 브랜치의 <상위 브랜치>/<프로젝트>-<이슈넘버>로 구성된다. 이 포스트에서는 tutorial-1을 개발 할 것이므로 브랜치는 feature/tutorial-1이 된다. 이 글을 보는 삐멜 독자들 중에서 위 과정을 전부 실습 하고 싶다면 https://github.com/fsoftwareengineer/githubtutorial/issues 의 목록중에서 하나 골라서 실습 해 보도록 해라. 만약 이슈가 없는 경우 실습 하고 싶으니 이슈를 만들어달라고 댓글로 남기면 이슈를 만들고, 끝까지 실습을 진행 할 수 있도록 최대한 돕도록 하겠다. 이제 예제를 보자.

 

git checkout -b feature/tutorial-1
Switched to a new branch 'feature/tutorial-1'

아까와 같이 git branch를 통해 자신이 어느 브랜치에 있는지 확인해도 좋다. 지금 브랜치 타임라인은 다음과 같다.

 

git checkout -b feature/tutorial-1을 했을 당시의 브랜치가 feature/develop이었기 때문에 현재 우리는 feature/develop에서 복사된 복사본을 갖고 있다고 생각하면 쉽다. 이제 이 브랜치에서 개발을 하면 된다. 이슈 설명에서 말했듯이 이 브랜치에서는 Main클래스 내부에 있는 Contact클래스를 바깥으로 옮기도록 하겠다. 수정 완료 시 git add를 통해 파일을 스테이징 시키고, git commit을 이용해 커밋한다. 커밋 시 메시지를 "이슈제목"으로 하라. 오픈소스마다 커밋 메시지를 작성하는 방법이 다르니 참여하는 오픈소스의 문서나 다른 사람들이 어떻게 커밋 메시지를 작성했나 확인하고 커밋하기 바란다.

:githubtutorial feature/tutorial-1 ✗ 4d △ ✓ ◒ ➜ git add src/Contact.java
:githubtutorial feature/tutorial-1 ✗ 4d △ ✓ ➜ git add src/Main.java

커밋 시 다음 처럼 커밋 메시지를 이슈제목으로 한다. 다시 말하지만 커밋을 어떻게 하느냐는 오픈소스마다 다르다. 

➜ git commit -m "tutorial-1:separate Contact from Main class"
[feature/tutorial-1 8aeb5b7] tutorial-1:separate Contact from Main class
3 files changed, 14 insertions(+), 6 deletions(-)
create mode 100644 .gitignore
create mode 100644 src/Contact.java

커밋 했다면 이제 push하도록 한다. push를 하는 순간 본인이 만든 브랜치가 깃허브의 브랜치 목록에 뜰 것이다

 

깃허브 Pull Request 

자 이제 깃허브로 돌아가면 다음과 같은 화면을 볼 수 있을 것이다.

 

지금까지 당신은 개발 브랜치에서 당신의 "이슈" 브랜치를 따와 그 브랜치에서 개발을 했고, 개발이 완료되어 해당 브랜치를 remote리파지토리에 push했다. 따라서 새로 만들어진 브랜치가 깃허브에 반영된 것이다. 하지만 당신의 브랜치는 여전히 다른 브랜치들과 분리된 상태로, 당신은 자신의 브랜치가 개발브랜치인 "feature/develop"로 합쳐 질 수 있도록(merge라고 한다.) 이 프로젝트의 관리자 또는 리드 개발자에게 요청해야 한다. 그 요청을 바로 "Pull Request"라고 한다. "Compare & pull request"를 눌러보자.

출처: https://imasoftwareengineer.tistory.com/5?category=769323 [삐멜 소프트웨어 엔지니어]