SlideShare a Scribd company logo
1 of 53
오픈 소스 공헌을 위한
필수 지식
㈜ 그루터 / 정재화
About me
• Gruter Corp / BigData Engineer
• Apache Tajo Committer
• jhjung@gruter.com
• Home Page: http://blrunner.com
• Twitter: @blrunner78
• The author of Hadoop book
목차
1. GIT의 이해
2. Case별 GIT커맨드 예제
3. Github 이해하기
4. Tajo 코드 컨트리뷰션 방법
1. GIT의 이해
5
SVN != GIT
저장소 관점에서 SVN vs. GIT
Git
Public Git repo
Git
Public Git repo
Git
Local Git repo
Git
Local Git repo
SVN r
epo
Centralized repo
6
Git
• 오픈소스 분산 버전 관리 도구
• 리눅스 토발즈가 최대 오픈소스 플젝 중
하나인 리눅스 개발을 효율적으로 하기 위
해 개발
• 설치는 생략
7
Git의 저장소 (repository) 이해
• 저장소는 1) 원격 2) 로컬이 있음
• 다수의 원격 저장소를 가질 수 있음
• 각 저장소는 branch와 snapshot 리비전인
tag 를 제공
8
원격 저장소 (remote repo.)
• Remote 장소는 URL로 식별; e.g.,
– git@github.com:apache/tajo.git
– https://github.com/apache/tajo.git
– 그외에 프로토콜도 있음
• Gitweb, Github 등등은 remote 저장소의
브라우징 기능 + alpha를 제공 역할
9
로컬 저장소 (local repo.)
• 분산 버전 관리 시스템이라 불리우는 이유
• 각 개발자의 workspace 역할
• CSV와 SVN과 달리 각 로컬 저장소에 커
밋 가능
• 다수의 개발자들은 공유하는 원격 저장소
를 통해 서로 commit 이력 (변경사항)을
공유10
왜 GIT이 SVN보다 나은가?
• SVN
– 로컬 커밋이 허용되지 않으며 이 상황에서 작업이 길
어질 경우 가능한 선택 사항들이 모두 좋지 않다
– 미완 상태 커밋 허용
• 빌드 깨짐, 테스트 실패에 노출
-> 다른 개발자들에 영향
– 긴 작업을 위해 별도 방법 강구
-> 귀찮음, 불편함
– 브렌치 활용
-> 브렌치는 그냥 copy 일뿐, 따라서 용량이 크게 증가함
11
2. CASE별 GIT 커맨드
Git 로컬 저장소 만들기 (1)
• git clone을 이용해 원격 저장소 복사
$ git clone https://github.com/apache/tajo.git
Cloning into 'tajo'...
remote: Counting objects: 60897, done.
remote: Total 60897 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (60897/60897), 13.71 MiB | 1.42 MiB
/s, done.
Resolving deltas: 100% (34488/34488), done.
Checking connectivity... done.
$ ls -l
total 0
drwxr-xr-x 30 hyunsik staff 1020 Jan 15 04:45 tajo
13
Git 로컬 저장소 만들기 (2)
• git init 을 이용해 새 저장소 만들기
$ ls -lasl
total 0
0 drwxr-xr-x 2 hyunsik staff 68 Jan 15 04:47 .
0 drwxr-xr-x+ 106 hyunsik staff 3604 Jan 15 04:17 ..
$ git init
Initialized empty Git repository in /Users/hyunsik/git_by_e
xample/.git/
$ ls -asl
total 0
0 drwxr-xr-x 3 hyunsik staff 102 Jan 15 04:47 .
0 drwxr-xr-x+ 106 hyunsik staff 3604 Jan 15 04:17 ..
0 drwxr-xr-x 10 hyunsik staff 340 Jan 15 04:47 .git
14
커밋하기
$ echo "This project..." > README
$ git add README
$ git commit -m "Add README"
[master (root-commit) 8e5261f] Add README
1 file changed, 1 insertion(+)
create mode 100644 README
$ git log
commit 8e5261f5170f52299798d347e8869c1cf12a4457
Author: Hyunsik Choi <hyunsik@apache.org>
Date: Thu Jan 15 04:50:25 2015 +0900
Add README
hyunsik@Hyunsiks-MacBook-Pro:git_by_example$
15
로컬 저장소 수정사항 리셋하기
$ git status
On branch master
nothing to commit, working directory clean
$ echo "Tajo is ..." >> README
$ git status
On branch master
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory
)
modified: README
$ git reset --hard
HEAD is now at 8e5261f Add README
16
리모트 저장소 관리 (1)
git remote -h
usage: git remote [-v | --verbose]
or: git remote add [-t <branch>] [-m <master>] [-f] [--tags|--no
-tags] [--mirror=<fetch|push>] <name> <url>
or: git remote rename <old> <new>
or: git remote remove <name>
or: git remote set-head <name> (-a | --auto | -d | --delete |<br
anch>)
or: git remote [-v | --verbose] show [-n] <name>
or: git remote prune [-n | --dry-run] <name>
or: git remote [-v | --verbose] update [-p | --prune] [(<group>
| <remote>)...]
or: git remote set-branches [--add] <name> <branch>...
or: git remote set-url [--push] <name> <newurl> [<oldurl>]
or: git remote set-url --add <name> <newurl>
or: git remote set-url --delete <name> <url>
-v, --verbose be verbose; must be placed before a subco
mmand
17
리모트 저장소 관리 (2)
• 원격 저장소 목록 보기
# 저장소가 하나도 없는 경우
$ git remote –v
$
# 원격 저장소가 많은 경우
$ git remote –v
asf https://git-wip-us.apache.org/repos/asf/tajo.git (fetch)
asf https://git-wip-us.apache.org/repos/asf/tajo.git (push)
gruter-trunk git@github.com:gruter/incubator-tajo_g.git (fetch)
gruter-trunk git@github.com:gruter/incubator-tajo_g.git (push)
locket https://github.com/gruter/locket_project.git (push)
locket https://github.com/gruter/locket_project.git (fetch)
origin https://github.com/hyunsik/tajo.git (fetch)
origin https://github.com/hyunsik/tajo.git (push)
18
리모트 저장소 관리 (3)
• 원격 저장소 추가
• 원격 저장소 제거
$ git remote add origin https://github.com/apache/tajo.git
$ git remote -v
origin https://github.com/apache/tajo.git (fetch)
origin https://github.com/apache/tajo.git (push)
$ git remote remove origin
$ git remote -v
$
19
원격 -> 로컬 동기화
• git pull [repo name] [remote branch]
– 원격 저장소의 지정 브렌치를 현재 브렌치로 동기화
$ git branch
DEVIEW
* PPD
logical_node_visitor
master
$ git pull origin master
warning: no common commits
remote: Counting objects: 54019, done.
remote: Compressing objects: 100% (14677/14677), done.
remote: Total 54019 (delta 31227), reused 54011 (delta 31219)
Receiving objects: 100% (54019/54019), 12.28 MiB | 2.46 MiB/s, done
.
Resolving deltas: 100% (31227/31227), done.
$
20
로컬 -> 원격 동기화
• git push [repo name] [local branch]:[remote branch]
– 로컬 지정 브렌치를 원격 지정 브렌치로 동기화
– local과 remote가 동일할 경우 하나 입력 가능
$ git push origin PPD:master # 로컬 PPD 브렌치 -> 원격 master
warning: no common commits
remote: Counting objects: 54019, done.
remote: Compressing objects: 100% (14677/14677), done.
remote: Total 54019 (delta 31227), reused 54011 (delta 31219)
Receiving objects: 100% (54019/54019), 12.28 MiB | 2.46 MiB/s, done
.
Resolving deltas: 100% (31227/31227), done.
$
$ git push origin TAJO-1234 # 로컬 TAJO-1234 -> 원격 TAJO-1234
…
$ git push origin HEAD:TAJO-1234 # 현재 브랜치 -> 원격 TAJO-1234
21
로컬 브렌치 관리 (1)
• 브렌치 목록 보기
$ git branch
DEVIEW
PPD
logical_node_visitor
* master <- 현재 브렌치
show
22
로컬 브렌치 관리 (2)
• 브렌치 생성을 위해서는 base branch가 항상 활용
• git branch [new branch name] [base branch name]
• 커맨드에서 base branch 생략 시 현재 브렌치가 base branch
• 브렌치 제거: git branch –d [branch name]
• 동기화 되지 않은 브렌치 제거
$ git branch TAJO-1234 master
$ git branch TAJO-1234
$ git branch –d TAJO-1234
$ git branch –D TAJO-1234
23
원격 브렌치 관리 (1)
• 브렌치 목록 보기
• 원격 브렌치는 항상 로컬 복사본 유지 (중요!)
$ git remote -v
gruter git@github.com:gruter/jitvec.git (fetch)
gruter git@github.com:gruter/jitvec.git (push)
origin https://github.com/gruter/jitvec.git (fetch)
origin https://github.com/gruter/jitvec.git (push)
$ git branch -r
gruter/master
origin/DEVIEW
origin/PPD
origin/logical_node_visitor
origin/master
24
원격 브렌치 관리 (2)
• 원격 브렌치 생성은 push 커맨드를 이용
– git push [repo name] [local branch]:[remote branch]
• 원격 브렌치 제거도 push 커맨드 활용
– git push [repo name] :[remote branch]
• 원격 브렌치의 복사본 업데이트
– git fetch [repo name]
$ git push origin WORK:TAJO-1234
$ git push origin :TAJO-1234
$ git fetch origin
25
Branch merge 하기
• 원격/로컬 브렌치를 현재 브렌치로 머지할 수 있다.
– 머지는 두 브렌치의 커밋 이력을 날짜 순으로 하나로 합친다.
– 충돌이 날 경우 충돌 소스를 해결해서 다시 커밋 (git commit)이 필요
• 로컬 브렌치 머지
– git merge [local branch]
• 리모트 브렌치 머지
– git pull [repo name] [remote branch name]
• 머지하며 커밋 하지 않기
– git merge –no-commit [branch name]
• 머지하며 커밋 이력 하나로 합치기 (많은 상황에서 강추)
– git merge –-squash [branch name]
– git pull --squash [repo name] [remote branch name]
$ git merge TAJO-1234
$ git pull origin TAJO-1234
26
Patch 만들기
• 제출 패치가 적용될 로컬 or 원격 브렌치를 지정하여 diff 생성
• 원격브렌치는 경우 [repo name]/[branch name] 형태 이름을 가짐
– git branch –r 명령으로 확인 가능
– 주의) DIFF 명령은 원격 브렌치의 로컬 복사본을 기준으로 동작
$ git branch -r
gruter/master
origin/DEVIEW
origin/PPD
origin/logical_node_visitor
origin/master
$ git fetch origin # 원격 브렌치의 로컬 복사본 갱신, 습관화 필요
$ git diff origin/master > PATCH.txt
원격 브렌치에 대한 patch 생성
27
간단, 권장 Workflow
• Master 브렌치의 커밋이력은 가능한 이슈/기능
단위가 좋음
– 문제 있을 경우 revert 나 추적의 용이함을 위해
– 목적에 맞는 적절한 크기의 단일 커밋 이력은 코드
리뷰를 쉽게 함
• 간단한 변경 외에는 local branch 생성을 권장
– 해당 이슈에 대한 개발이 길어질 경우 작업도 나누어
서 커밋이 필요
• 문제가 있을 경우 복구를 작은 단위로 할 수 있다.
28
GIT 추천 자료
• GIT 한글 매뉴얼  http://git-scm.com/book/ko/v2
• SVN 능력자를 위한 GIT 개념 가이드 
http://www.slideshare.net/einsub/svn-git-17386752
• 버전 관리를 들어본적 없는 사람들을 위한 DVCS-GIT 
http://www.slideshare.net/ibare/dvcs-git
29
3. Github 이해하기
Git != Github
31
Github 란?
• Git의 Repository를 호스팅해주는 서비스
• 대부분의 오픈소스 프로젝트가 Github로 이전
• https://github.com
32
Github를 이용한 전체 흐름
33
Apache
Tajo
Repository
Private
Tajo
Repository
Local
Repository
소스 코드
1. Fork
2. Clone
3. Commit
merge
4. Fetch 4. Fetch
5. merge
6. Push
7. Pull Request
Github
Local Machine
#1 Fork
34
Apache
Tajo
Repository
Private
Tajo
Repository1. Fork
Github
• Tajo 저장소의 지금 상태 그대로를 복사해
서 자신의 Github 계정에 Tajo 저장소를 생
성한다.
• 소스를 수정할 수 있는 저장소 관리를 위
해서 Fork 실행
#2 Clone
• 원격에서는 소스를 수정할 수 없으므로, Fork한
저장소를 작업할 로컬 머신에 내려받는 과정
35
Apache
Tajo
Repository
Private
Tajo
Repository
Local
Repository 2. Clone
Github
Local Machine
#3 Commit
• 로컬에서 수정한 소스 코드를 커밋한다
• Master 브랜치에서 다른 브랜치를 생성해서 작
업하는 것을 권장
• SVN의 커밋과는 다르게 원격 저장소에 적용되
는 것은 아님
36
Local Machine
Local
Repository
소스 코드
3. Commit
#4 Fetch & Merge
37
Apache
Tajo
Repository
Private
Tajo
Repository
Local
Repository
merge
4. Fetch
4. Fetch
5. merge
Github
Local Machine
• 원격 저장소의 변경 사항을 fetch로 로컬에 가져온
후 로컬의 브랜치에 merge
TIP) 귀찮을때는 “git
pull 리파지토리
브랜치”
#5 Push
38
Apache
Tajo
Repository
Private
Tajo
Repository
Local
Repository
6. Push
Github
Local Machine
• 로컬에서 수정한 커밋들을 자신의 원격 저장소에
적용
#6 Pull Request
39
Apache
Tajo
Repository
Private
Tajo
Repository
7. Pull Request
Github
• 자신의 원격 저장소에 올린 변경 사항을
원본 Tajo 저장소에 적용할 것을 요청
• Tajo 원본 저장소에 대한 쓰기 권한이 없기
때문에 Pull Request를 요청함
Github 추천 자료
• http://blog.outsider.ne.kr/865
• http://blog.outsider.ne.kr/866
• http://mobicon.tistory.com/170
• http://teamblog.gruter.com/apache-tajo-contributor-
starter/
40
4. Tajo 코드 컨트리뷰션 방법
42
• JDK 1.8 설치
• Protocol Buffer 2.5 설치
• Git, Maven 설치
• IDE 설치 : Eclipse 혹은 IntelliJ
• Github 계정 생성
• Apache JIRA 계정 생성
1. 개발환경 구성하기
43
• User 메일링 리스트
– 사용자 모임 메일링 리스트, 버그 및 사용법 문의
– user-subscribe@tajo.apache.org 에 메일 발송
• Dev 메일링 리스트
– 개발자 대상 메일링 리스트, JIRA 이슈 및 Pull Request 관
련 메일 포함
– dev-subscribe@tajo.apache.org 에 메일 발송
• 초기에는 User 메일링 리스트만 등록
• 구글 그룹
(https://groups.google.com/forum/#!forum/tajo-user-
kr) 및 페북 그룹
(https://www.facebook.com/groups/tajokorea)에도 가
입
2. 메일링 리스트에 가입한다.
44
• JIRA 사이트:
https://issues.apache.org/jira/browse/TAJO
• newbie 태그: 초보자용 이슈
• 적당한 이슈가 없으면, 직접 이슈를 만든다
• 공헌 대상
– 문서화
– Bug Fix
– Improvement
– New Feature
3. 공헌할 이슈를 찾는다.
45
• Assignee가 없을 경우, 바로 나에게 할당
할 수 있다. (일부 프로젝트들의 경우 할당
권한을 허가하지 않는다)
• 공헌하고 싶은 이슈가 있는데, 이미
Assginee가 있을 경우는 얼마나 오래 진행
됐는지 확인 후, 담당자를 바꿔줄 수 있는
지 정중하게 묻는다.
3-1. 이미 이슈가 있을 경우
46
• 이슈 제목은 명확하게 기술한다.
• Description에 왜 이 이슈를 해야하는지 서술
한다. 버그라면 올바른 동작, 현재 동작, 차이
점, 차이를 재현할 수 있는 방법등을 작성한
다.
• 큰 기능을 구현할 경우
– 설계 문서나 아키텍처 등을 첨부해서, 개발 방향
에 대한 합의가 이뤄진 후 진행한다.
– 반드시 Umbrella 이슈로 만들어서, 세부 작업은
sub-task로 진행한다.
3-2. 새로운 이슈를 만들 경우
47
• 브랜치 이름은 이슈 번호로 작성 (예: TAJO-1004)
• 이슈 범위를 벗어나는 작업은 피한다.
• 최신 소스를 받아서 작업한다.
• 이슈에 대한 패치를 개발할 경우 반드시 유닛 테스
트를 포함한다.
• 코드 컨벤션을 준수한다.
https://cwiki.apache.org/confluence/display/TAJO
/Contributing+to+Tajo
• 반드시 타조 로컬 클러스터 모드에서 테스트를 진
행한다.
• Findbug 를 활용한다.
4. 로컬 개발하기
48
• Pull Request 타이틀은 JIRA 이슈 타이틀과
동일하게 작성한다.
• Description에 왜 이러한 방법으로 구현을
했는지, 리뷰어가 어떻게 재현이 가능한지
기술한다.
5. Pull Request 보내기
49
• 리뷰어의 코멘트에는 모두 답변한다.
• 자주 Rebase를 한다.
• 커미터가 +1을 할 경우, 패치가 수락됨
• 커미터가 -1을 하거나, 아무런 코멘트가 없
을 경우 패치가 거부된 것임. 하지만 리뷰
를 놓치는 경우도 있으니, 리뷰 여부를 묻
는 것이 좋음
• 리뷰어에게 (립서비스라할지라도) 고마움
을 표시하는 센스
6. 코드 리뷰
50
• TAJO-1004 이슈에 Pull Request 보내기
– git clone https://git-wip-us.apache.org/repos/asf/tajo.git
– cd tajo
– git remote rename asf
– git remote add origin https://github.com/blrunner/tajo.git
– git checkout –b TAJO-1004
– 소스 코드 수정
– git status
– git commit -a
– git push origin TAJO-1004
– 수시로 Rebase: git pull asf master (혹은 fetch + merge)
– Github 자신의 저장소에서 TAJO-1004 브랜치로 이동한 후 Pull
Request 버튼을 클릭
– 패치에 대한 Description 작성 후 Send pull request 버튼 클릭
Pull Request 예제
51
• 사소한 피드백도 프로젝트 컨트리뷰터들
에게는 큰 힘이 됩니다.
• 개발이 아니더라도, 버그 제보, 문서화, 블
로그 포스팅도 훌륭한 공헌입니다.
• 찐한 리뷰를 통해 개발 역량이 성장됩니다.
• 영어 실력은 덤…
마무리
오픈소스 컨트리뷰션 추천 자료
• http://www.soscon.net/download/day28/GB1/S_28_1
000_강대명.pdf
• http://www.slideshare.net/sanxiyn/how-to-
contribute-to-oss
• http://www.slideshare.net/seoeun25/how-to-
contribute-to-open-source-55803326
52
GRUTER: YOUR PARTNER
IN THE BIG DATA REVOLUTION
Phone +82-2-508-5911
Fax +82-2-508-5912
E-mail contact@gruter.com
Web www.gruter.com

More Related Content

What's hot

Git 기본개념과 사용법 그리고 어플리케이션
Git 기본개념과 사용법 그리고 어플리케이션Git 기본개념과 사용법 그리고 어플리케이션
Git 기본개념과 사용법 그리고 어플리케이션
Dabi Ahn
 
버전관리를 들어본적 없는 사람들을 위한 DVCS - Git
버전관리를 들어본적 없는 사람들을 위한 DVCS - Git버전관리를 들어본적 없는 사람들을 위한 DVCS - Git
버전관리를 들어본적 없는 사람들을 위한 DVCS - Git
민태 김
 
버전관리시스템 종류와 소개
버전관리시스템 종류와 소개버전관리시스템 종류와 소개
버전관리시스템 종류와 소개
Jong-il Seok
 

What's hot (20)

Git Tutorial
Git TutorialGit Tutorial
Git Tutorial
 
Git
GitGit
Git
 
git, 이해부터 활용까지
git, 이해부터 활용까지git, 이해부터 활용까지
git, 이해부터 활용까지
 
11. git basic
11. git basic11. git basic
11. git basic
 
Git 기본개념과 사용법 그리고 어플리케이션
Git 기본개념과 사용법 그리고 어플리케이션Git 기본개념과 사용법 그리고 어플리케이션
Git 기본개념과 사용법 그리고 어플리케이션
 
Git - Level 2
Git - Level 2Git - Level 2
Git - Level 2
 
버전관리를 들어본적 없는 사람들을 위한 DVCS - Git
버전관리를 들어본적 없는 사람들을 위한 DVCS - Git버전관리를 들어본적 없는 사람들을 위한 DVCS - Git
버전관리를 들어본적 없는 사람들을 위한 DVCS - Git
 
Git 코드랩 스터디 2
Git 코드랩 스터디 2Git 코드랩 스터디 2
Git 코드랩 스터디 2
 
버전관리시스템 종류와 소개
버전관리시스템 종류와 소개버전관리시스템 종류와 소개
버전관리시스템 종류와 소개
 
Git 입문자를 위한 가이드
Git 입문자를 위한 가이드Git 입문자를 위한 가이드
Git 입문자를 위한 가이드
 
svn 능력자를 위한 git 개념 가이드
svn 능력자를 위한 git 개념 가이드svn 능력자를 위한 git 개념 가이드
svn 능력자를 위한 git 개념 가이드
 
Git 사용법 공유 + Unity3D with git
Git 사용법 공유 + Unity3D with gitGit 사용법 공유 + Unity3D with git
Git 사용법 공유 + Unity3D with git
 
LinqPad for DevOps
LinqPad for DevOpsLinqPad for DevOps
LinqPad for DevOps
 
GitHub 실습 교육
GitHub 실습 교육GitHub 실습 교육
GitHub 실습 교육
 
Git 더하기 GitHub(Git클라이언트 활용) / Getting started with git+github
Git 더하기 GitHub(Git클라이언트 활용) / Getting started with git+githubGit 더하기 GitHub(Git클라이언트 활용) / Getting started with git+github
Git 더하기 GitHub(Git클라이언트 활용) / Getting started with git+github
 
이클립스로 GIT 사용하기
이클립스로 GIT 사용하기이클립스로 GIT 사용하기
이클립스로 GIT 사용하기
 
Git 강별
Git   강별Git   강별
Git 강별
 
Git의 개념과 사용
Git의 개념과 사용Git의 개념과 사용
Git의 개념과 사용
 
Git이란 (Git 소개 및 기초 이론)
Git이란 (Git 소개 및 기초 이론)Git이란 (Git 소개 및 기초 이론)
Git이란 (Git 소개 및 기초 이론)
 
Git+, Git 조금 더 배워보기
Git+, Git 조금 더 배워보기Git+, Git 조금 더 배워보기
Git+, Git 조금 더 배워보기
 

Similar to 오픈소스 공헌을 위한 필수 지식

Git basic2 chaos
Git basic2 chaosGit basic2 chaos
Git basic2 chaos
Yunkyu Choi
 
Git from google techtalks by Randal
Git from google techtalks by RandalGit from google techtalks by Randal
Git from google techtalks by Randal
yagurchoi
 
git, git flow
git, git flowgit, git flow
git, git flow
eva
 

Similar to 오픈소스 공헌을 위한 필수 지식 (20)

Git: A Motivating Introduction
Git: A Motivating IntroductionGit: A Motivating Introduction
Git: A Motivating Introduction
 
Git Tutorial
Git TutorialGit Tutorial
Git Tutorial
 
Git
GitGit
Git
 
[T아카데미] 비개발자를 위한 Git과 Github Page 블로그 만들기
[T아카데미] 비개발자를 위한 Git과 Github Page 블로그 만들기[T아카데미] 비개발자를 위한 Git과 Github Page 블로그 만들기
[T아카데미] 비개발자를 위한 Git과 Github Page 블로그 만들기
 
Git basic2 chaos
Git basic2 chaosGit basic2 chaos
Git basic2 chaos
 
Git & Github Seminar-2
Git & Github Seminar-2Git & Github Seminar-2
Git & Github Seminar-2
 
XECon2015 :: [1-3] 김덕홍 - Git Workflow with GitHub
XECon2015 :: [1-3] 김덕홍 - Git Workflow with GitHubXECon2015 :: [1-3] 김덕홍 - Git Workflow with GitHub
XECon2015 :: [1-3] 김덕홍 - Git Workflow with GitHub
 
[오픈소스컨설팅] Docker를 활용한 Gitlab CI/CD 구성 테스트
[오픈소스컨설팅] Docker를 활용한 Gitlab CI/CD 구성 테스트[오픈소스컨설팅] Docker를 활용한 Gitlab CI/CD 구성 테스트
[오픈소스컨설팅] Docker를 활용한 Gitlab CI/CD 구성 테스트
 
Fun git hub
Fun git hubFun git hub
Fun git hub
 
Git from google techtalks by Randal
Git from google techtalks by RandalGit from google techtalks by Randal
Git from google techtalks by Randal
 
git-workflow
git-workflowgit-workflow
git-workflow
 
[VCS] Git&GitLab_Designer
[VCS] Git&GitLab_Designer[VCS] Git&GitLab_Designer
[VCS] Git&GitLab_Designer
 
OSS SW Basics Lecture 08: Software Configuration Management (2)
OSS SW Basics Lecture 08: Software Configuration Management (2)OSS SW Basics Lecture 08: Software Configuration Management (2)
OSS SW Basics Lecture 08: Software Configuration Management (2)
 
제로부터시작하는 Git 두번째 이야기
제로부터시작하는 Git 두번째 이야기제로부터시작하는 Git 두번째 이야기
제로부터시작하는 Git 두번째 이야기
 
Git 기본
Git 기본Git 기본
Git 기본
 
Git
GitGit
Git
 
git, git flow
git, git flowgit, git flow
git, git flow
 
[NEXT 프연 Week1] Git 시작하기
[NEXT 프연 Week1] Git 시작하기[NEXT 프연 Week1] Git 시작하기
[NEXT 프연 Week1] Git 시작하기
 
Fluentd with MySQL
Fluentd with MySQLFluentd with MySQL
Fluentd with MySQL
 
20141029 하둡2.5와 hive설치 및 예제
20141029 하둡2.5와 hive설치 및 예제20141029 하둡2.5와 hive설치 및 예제
20141029 하둡2.5와 hive설치 및 예제
 

오픈소스 공헌을 위한 필수 지식

  • 1. 오픈 소스 공헌을 위한 필수 지식 ㈜ 그루터 / 정재화
  • 2. About me • Gruter Corp / BigData Engineer • Apache Tajo Committer • jhjung@gruter.com • Home Page: http://blrunner.com • Twitter: @blrunner78 • The author of Hadoop book
  • 3. 목차 1. GIT의 이해 2. Case별 GIT커맨드 예제 3. Github 이해하기 4. Tajo 코드 컨트리뷰션 방법
  • 6. 저장소 관점에서 SVN vs. GIT Git Public Git repo Git Public Git repo Git Local Git repo Git Local Git repo SVN r epo Centralized repo 6
  • 7. Git • 오픈소스 분산 버전 관리 도구 • 리눅스 토발즈가 최대 오픈소스 플젝 중 하나인 리눅스 개발을 효율적으로 하기 위 해 개발 • 설치는 생략 7
  • 8. Git의 저장소 (repository) 이해 • 저장소는 1) 원격 2) 로컬이 있음 • 다수의 원격 저장소를 가질 수 있음 • 각 저장소는 branch와 snapshot 리비전인 tag 를 제공 8
  • 9. 원격 저장소 (remote repo.) • Remote 장소는 URL로 식별; e.g., – git@github.com:apache/tajo.git – https://github.com/apache/tajo.git – 그외에 프로토콜도 있음 • Gitweb, Github 등등은 remote 저장소의 브라우징 기능 + alpha를 제공 역할 9
  • 10. 로컬 저장소 (local repo.) • 분산 버전 관리 시스템이라 불리우는 이유 • 각 개발자의 workspace 역할 • CSV와 SVN과 달리 각 로컬 저장소에 커 밋 가능 • 다수의 개발자들은 공유하는 원격 저장소 를 통해 서로 commit 이력 (변경사항)을 공유10
  • 11. 왜 GIT이 SVN보다 나은가? • SVN – 로컬 커밋이 허용되지 않으며 이 상황에서 작업이 길 어질 경우 가능한 선택 사항들이 모두 좋지 않다 – 미완 상태 커밋 허용 • 빌드 깨짐, 테스트 실패에 노출 -> 다른 개발자들에 영향 – 긴 작업을 위해 별도 방법 강구 -> 귀찮음, 불편함 – 브렌치 활용 -> 브렌치는 그냥 copy 일뿐, 따라서 용량이 크게 증가함 11
  • 12. 2. CASE별 GIT 커맨드
  • 13. Git 로컬 저장소 만들기 (1) • git clone을 이용해 원격 저장소 복사 $ git clone https://github.com/apache/tajo.git Cloning into 'tajo'... remote: Counting objects: 60897, done. remote: Total 60897 (delta 0), reused 0 (delta 0) Receiving objects: 100% (60897/60897), 13.71 MiB | 1.42 MiB /s, done. Resolving deltas: 100% (34488/34488), done. Checking connectivity... done. $ ls -l total 0 drwxr-xr-x 30 hyunsik staff 1020 Jan 15 04:45 tajo 13
  • 14. Git 로컬 저장소 만들기 (2) • git init 을 이용해 새 저장소 만들기 $ ls -lasl total 0 0 drwxr-xr-x 2 hyunsik staff 68 Jan 15 04:47 . 0 drwxr-xr-x+ 106 hyunsik staff 3604 Jan 15 04:17 .. $ git init Initialized empty Git repository in /Users/hyunsik/git_by_e xample/.git/ $ ls -asl total 0 0 drwxr-xr-x 3 hyunsik staff 102 Jan 15 04:47 . 0 drwxr-xr-x+ 106 hyunsik staff 3604 Jan 15 04:17 .. 0 drwxr-xr-x 10 hyunsik staff 340 Jan 15 04:47 .git 14
  • 15. 커밋하기 $ echo "This project..." > README $ git add README $ git commit -m "Add README" [master (root-commit) 8e5261f] Add README 1 file changed, 1 insertion(+) create mode 100644 README $ git log commit 8e5261f5170f52299798d347e8869c1cf12a4457 Author: Hyunsik Choi <hyunsik@apache.org> Date: Thu Jan 15 04:50:25 2015 +0900 Add README hyunsik@Hyunsiks-MacBook-Pro:git_by_example$ 15
  • 16. 로컬 저장소 수정사항 리셋하기 $ git status On branch master nothing to commit, working directory clean $ echo "Tajo is ..." >> README $ git status On branch master Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory ) modified: README $ git reset --hard HEAD is now at 8e5261f Add README 16
  • 17. 리모트 저장소 관리 (1) git remote -h usage: git remote [-v | --verbose] or: git remote add [-t <branch>] [-m <master>] [-f] [--tags|--no -tags] [--mirror=<fetch|push>] <name> <url> or: git remote rename <old> <new> or: git remote remove <name> or: git remote set-head <name> (-a | --auto | -d | --delete |<br anch>) or: git remote [-v | --verbose] show [-n] <name> or: git remote prune [-n | --dry-run] <name> or: git remote [-v | --verbose] update [-p | --prune] [(<group> | <remote>)...] or: git remote set-branches [--add] <name> <branch>... or: git remote set-url [--push] <name> <newurl> [<oldurl>] or: git remote set-url --add <name> <newurl> or: git remote set-url --delete <name> <url> -v, --verbose be verbose; must be placed before a subco mmand 17
  • 18. 리모트 저장소 관리 (2) • 원격 저장소 목록 보기 # 저장소가 하나도 없는 경우 $ git remote –v $ # 원격 저장소가 많은 경우 $ git remote –v asf https://git-wip-us.apache.org/repos/asf/tajo.git (fetch) asf https://git-wip-us.apache.org/repos/asf/tajo.git (push) gruter-trunk git@github.com:gruter/incubator-tajo_g.git (fetch) gruter-trunk git@github.com:gruter/incubator-tajo_g.git (push) locket https://github.com/gruter/locket_project.git (push) locket https://github.com/gruter/locket_project.git (fetch) origin https://github.com/hyunsik/tajo.git (fetch) origin https://github.com/hyunsik/tajo.git (push) 18
  • 19. 리모트 저장소 관리 (3) • 원격 저장소 추가 • 원격 저장소 제거 $ git remote add origin https://github.com/apache/tajo.git $ git remote -v origin https://github.com/apache/tajo.git (fetch) origin https://github.com/apache/tajo.git (push) $ git remote remove origin $ git remote -v $ 19
  • 20. 원격 -> 로컬 동기화 • git pull [repo name] [remote branch] – 원격 저장소의 지정 브렌치를 현재 브렌치로 동기화 $ git branch DEVIEW * PPD logical_node_visitor master $ git pull origin master warning: no common commits remote: Counting objects: 54019, done. remote: Compressing objects: 100% (14677/14677), done. remote: Total 54019 (delta 31227), reused 54011 (delta 31219) Receiving objects: 100% (54019/54019), 12.28 MiB | 2.46 MiB/s, done . Resolving deltas: 100% (31227/31227), done. $ 20
  • 21. 로컬 -> 원격 동기화 • git push [repo name] [local branch]:[remote branch] – 로컬 지정 브렌치를 원격 지정 브렌치로 동기화 – local과 remote가 동일할 경우 하나 입력 가능 $ git push origin PPD:master # 로컬 PPD 브렌치 -> 원격 master warning: no common commits remote: Counting objects: 54019, done. remote: Compressing objects: 100% (14677/14677), done. remote: Total 54019 (delta 31227), reused 54011 (delta 31219) Receiving objects: 100% (54019/54019), 12.28 MiB | 2.46 MiB/s, done . Resolving deltas: 100% (31227/31227), done. $ $ git push origin TAJO-1234 # 로컬 TAJO-1234 -> 원격 TAJO-1234 … $ git push origin HEAD:TAJO-1234 # 현재 브랜치 -> 원격 TAJO-1234 21
  • 22. 로컬 브렌치 관리 (1) • 브렌치 목록 보기 $ git branch DEVIEW PPD logical_node_visitor * master <- 현재 브렌치 show 22
  • 23. 로컬 브렌치 관리 (2) • 브렌치 생성을 위해서는 base branch가 항상 활용 • git branch [new branch name] [base branch name] • 커맨드에서 base branch 생략 시 현재 브렌치가 base branch • 브렌치 제거: git branch –d [branch name] • 동기화 되지 않은 브렌치 제거 $ git branch TAJO-1234 master $ git branch TAJO-1234 $ git branch –d TAJO-1234 $ git branch –D TAJO-1234 23
  • 24. 원격 브렌치 관리 (1) • 브렌치 목록 보기 • 원격 브렌치는 항상 로컬 복사본 유지 (중요!) $ git remote -v gruter git@github.com:gruter/jitvec.git (fetch) gruter git@github.com:gruter/jitvec.git (push) origin https://github.com/gruter/jitvec.git (fetch) origin https://github.com/gruter/jitvec.git (push) $ git branch -r gruter/master origin/DEVIEW origin/PPD origin/logical_node_visitor origin/master 24
  • 25. 원격 브렌치 관리 (2) • 원격 브렌치 생성은 push 커맨드를 이용 – git push [repo name] [local branch]:[remote branch] • 원격 브렌치 제거도 push 커맨드 활용 – git push [repo name] :[remote branch] • 원격 브렌치의 복사본 업데이트 – git fetch [repo name] $ git push origin WORK:TAJO-1234 $ git push origin :TAJO-1234 $ git fetch origin 25
  • 26. Branch merge 하기 • 원격/로컬 브렌치를 현재 브렌치로 머지할 수 있다. – 머지는 두 브렌치의 커밋 이력을 날짜 순으로 하나로 합친다. – 충돌이 날 경우 충돌 소스를 해결해서 다시 커밋 (git commit)이 필요 • 로컬 브렌치 머지 – git merge [local branch] • 리모트 브렌치 머지 – git pull [repo name] [remote branch name] • 머지하며 커밋 하지 않기 – git merge –no-commit [branch name] • 머지하며 커밋 이력 하나로 합치기 (많은 상황에서 강추) – git merge –-squash [branch name] – git pull --squash [repo name] [remote branch name] $ git merge TAJO-1234 $ git pull origin TAJO-1234 26
  • 27. Patch 만들기 • 제출 패치가 적용될 로컬 or 원격 브렌치를 지정하여 diff 생성 • 원격브렌치는 경우 [repo name]/[branch name] 형태 이름을 가짐 – git branch –r 명령으로 확인 가능 – 주의) DIFF 명령은 원격 브렌치의 로컬 복사본을 기준으로 동작 $ git branch -r gruter/master origin/DEVIEW origin/PPD origin/logical_node_visitor origin/master $ git fetch origin # 원격 브렌치의 로컬 복사본 갱신, 습관화 필요 $ git diff origin/master > PATCH.txt 원격 브렌치에 대한 patch 생성 27
  • 28. 간단, 권장 Workflow • Master 브렌치의 커밋이력은 가능한 이슈/기능 단위가 좋음 – 문제 있을 경우 revert 나 추적의 용이함을 위해 – 목적에 맞는 적절한 크기의 단일 커밋 이력은 코드 리뷰를 쉽게 함 • 간단한 변경 외에는 local branch 생성을 권장 – 해당 이슈에 대한 개발이 길어질 경우 작업도 나누어 서 커밋이 필요 • 문제가 있을 경우 복구를 작은 단위로 할 수 있다. 28
  • 29. GIT 추천 자료 • GIT 한글 매뉴얼  http://git-scm.com/book/ko/v2 • SVN 능력자를 위한 GIT 개념 가이드  http://www.slideshare.net/einsub/svn-git-17386752 • 버전 관리를 들어본적 없는 사람들을 위한 DVCS-GIT  http://www.slideshare.net/ibare/dvcs-git 29
  • 32. Github 란? • Git의 Repository를 호스팅해주는 서비스 • 대부분의 오픈소스 프로젝트가 Github로 이전 • https://github.com 32
  • 33. Github를 이용한 전체 흐름 33 Apache Tajo Repository Private Tajo Repository Local Repository 소스 코드 1. Fork 2. Clone 3. Commit merge 4. Fetch 4. Fetch 5. merge 6. Push 7. Pull Request Github Local Machine
  • 34. #1 Fork 34 Apache Tajo Repository Private Tajo Repository1. Fork Github • Tajo 저장소의 지금 상태 그대로를 복사해 서 자신의 Github 계정에 Tajo 저장소를 생 성한다. • 소스를 수정할 수 있는 저장소 관리를 위 해서 Fork 실행
  • 35. #2 Clone • 원격에서는 소스를 수정할 수 없으므로, Fork한 저장소를 작업할 로컬 머신에 내려받는 과정 35 Apache Tajo Repository Private Tajo Repository Local Repository 2. Clone Github Local Machine
  • 36. #3 Commit • 로컬에서 수정한 소스 코드를 커밋한다 • Master 브랜치에서 다른 브랜치를 생성해서 작 업하는 것을 권장 • SVN의 커밋과는 다르게 원격 저장소에 적용되 는 것은 아님 36 Local Machine Local Repository 소스 코드 3. Commit
  • 37. #4 Fetch & Merge 37 Apache Tajo Repository Private Tajo Repository Local Repository merge 4. Fetch 4. Fetch 5. merge Github Local Machine • 원격 저장소의 변경 사항을 fetch로 로컬에 가져온 후 로컬의 브랜치에 merge TIP) 귀찮을때는 “git pull 리파지토리 브랜치”
  • 38. #5 Push 38 Apache Tajo Repository Private Tajo Repository Local Repository 6. Push Github Local Machine • 로컬에서 수정한 커밋들을 자신의 원격 저장소에 적용
  • 39. #6 Pull Request 39 Apache Tajo Repository Private Tajo Repository 7. Pull Request Github • 자신의 원격 저장소에 올린 변경 사항을 원본 Tajo 저장소에 적용할 것을 요청 • Tajo 원본 저장소에 대한 쓰기 권한이 없기 때문에 Pull Request를 요청함
  • 40. Github 추천 자료 • http://blog.outsider.ne.kr/865 • http://blog.outsider.ne.kr/866 • http://mobicon.tistory.com/170 • http://teamblog.gruter.com/apache-tajo-contributor- starter/ 40
  • 41. 4. Tajo 코드 컨트리뷰션 방법
  • 42. 42 • JDK 1.8 설치 • Protocol Buffer 2.5 설치 • Git, Maven 설치 • IDE 설치 : Eclipse 혹은 IntelliJ • Github 계정 생성 • Apache JIRA 계정 생성 1. 개발환경 구성하기
  • 43. 43 • User 메일링 리스트 – 사용자 모임 메일링 리스트, 버그 및 사용법 문의 – user-subscribe@tajo.apache.org 에 메일 발송 • Dev 메일링 리스트 – 개발자 대상 메일링 리스트, JIRA 이슈 및 Pull Request 관 련 메일 포함 – dev-subscribe@tajo.apache.org 에 메일 발송 • 초기에는 User 메일링 리스트만 등록 • 구글 그룹 (https://groups.google.com/forum/#!forum/tajo-user- kr) 및 페북 그룹 (https://www.facebook.com/groups/tajokorea)에도 가 입 2. 메일링 리스트에 가입한다.
  • 44. 44 • JIRA 사이트: https://issues.apache.org/jira/browse/TAJO • newbie 태그: 초보자용 이슈 • 적당한 이슈가 없으면, 직접 이슈를 만든다 • 공헌 대상 – 문서화 – Bug Fix – Improvement – New Feature 3. 공헌할 이슈를 찾는다.
  • 45. 45 • Assignee가 없을 경우, 바로 나에게 할당 할 수 있다. (일부 프로젝트들의 경우 할당 권한을 허가하지 않는다) • 공헌하고 싶은 이슈가 있는데, 이미 Assginee가 있을 경우는 얼마나 오래 진행 됐는지 확인 후, 담당자를 바꿔줄 수 있는 지 정중하게 묻는다. 3-1. 이미 이슈가 있을 경우
  • 46. 46 • 이슈 제목은 명확하게 기술한다. • Description에 왜 이 이슈를 해야하는지 서술 한다. 버그라면 올바른 동작, 현재 동작, 차이 점, 차이를 재현할 수 있는 방법등을 작성한 다. • 큰 기능을 구현할 경우 – 설계 문서나 아키텍처 등을 첨부해서, 개발 방향 에 대한 합의가 이뤄진 후 진행한다. – 반드시 Umbrella 이슈로 만들어서, 세부 작업은 sub-task로 진행한다. 3-2. 새로운 이슈를 만들 경우
  • 47. 47 • 브랜치 이름은 이슈 번호로 작성 (예: TAJO-1004) • 이슈 범위를 벗어나는 작업은 피한다. • 최신 소스를 받아서 작업한다. • 이슈에 대한 패치를 개발할 경우 반드시 유닛 테스 트를 포함한다. • 코드 컨벤션을 준수한다. https://cwiki.apache.org/confluence/display/TAJO /Contributing+to+Tajo • 반드시 타조 로컬 클러스터 모드에서 테스트를 진 행한다. • Findbug 를 활용한다. 4. 로컬 개발하기
  • 48. 48 • Pull Request 타이틀은 JIRA 이슈 타이틀과 동일하게 작성한다. • Description에 왜 이러한 방법으로 구현을 했는지, 리뷰어가 어떻게 재현이 가능한지 기술한다. 5. Pull Request 보내기
  • 49. 49 • 리뷰어의 코멘트에는 모두 답변한다. • 자주 Rebase를 한다. • 커미터가 +1을 할 경우, 패치가 수락됨 • 커미터가 -1을 하거나, 아무런 코멘트가 없 을 경우 패치가 거부된 것임. 하지만 리뷰 를 놓치는 경우도 있으니, 리뷰 여부를 묻 는 것이 좋음 • 리뷰어에게 (립서비스라할지라도) 고마움 을 표시하는 센스 6. 코드 리뷰
  • 50. 50 • TAJO-1004 이슈에 Pull Request 보내기 – git clone https://git-wip-us.apache.org/repos/asf/tajo.git – cd tajo – git remote rename asf – git remote add origin https://github.com/blrunner/tajo.git – git checkout –b TAJO-1004 – 소스 코드 수정 – git status – git commit -a – git push origin TAJO-1004 – 수시로 Rebase: git pull asf master (혹은 fetch + merge) – Github 자신의 저장소에서 TAJO-1004 브랜치로 이동한 후 Pull Request 버튼을 클릭 – 패치에 대한 Description 작성 후 Send pull request 버튼 클릭 Pull Request 예제
  • 51. 51 • 사소한 피드백도 프로젝트 컨트리뷰터들 에게는 큰 힘이 됩니다. • 개발이 아니더라도, 버그 제보, 문서화, 블 로그 포스팅도 훌륭한 공헌입니다. • 찐한 리뷰를 통해 개발 역량이 성장됩니다. • 영어 실력은 덤… 마무리
  • 52. 오픈소스 컨트리뷰션 추천 자료 • http://www.soscon.net/download/day28/GB1/S_28_1 000_강대명.pdf • http://www.slideshare.net/sanxiyn/how-to- contribute-to-oss • http://www.slideshare.net/seoeun25/how-to- contribute-to-open-source-55803326 52
  • 53. GRUTER: YOUR PARTNER IN THE BIG DATA REVOLUTION Phone +82-2-508-5911 Fax +82-2-508-5912 E-mail contact@gruter.com Web www.gruter.com