Github/Git Starter Guide for Introductory Level

Curtis Kim @ KAKAO

Why Github/Git?

팀으로 일한다는 것 프로젝트 거버넌스 브랜치 전략

효과적인 워크플로우

팀으로 일한다는 것공동의 목표 - 개발하고자하는 공동의 목표 : ‘유저의 만족’, ‘테스트코드의 통과’ 등 - 하나의 목표를 중심으로 일을 분담하게 됨 - Q1 : 일은 어떻게 분담할까? - Q2 : 분담된 일은 어떻게 추적할까? - Q3 : 분담된 결과물(코드)을 어떻게 합칠까? - Q4 : 버전관리는 어떻게할까? - Github/Git 과 같은 형상관리의 목적은 바로 이러한 공동의 결과물을 위해 작업하는 데에서 생기는 다양한 시나리오를 대응하기 위한 것.

Old Paradigm : 중앙화된 관리 - 특정 서버 또는 특정 관리자가 코드를 관리하고 모으는 방식 - “이번에 ‘a.java’파일을 수정했어요. 메일로 보내드릴 테니 변경부탁드릴게요.”

다양한 관리기법과 Git에서의 관리기법을 비교해보자.

팀으로 일한다는 것- 분산 기여 모델

- ‘일반 메일’ 내지는 비슷한 툴을 이용해 패치 파일을 논의 그룹에 보내는 형태 - 작업물을 압축하여 수정사항을 공유했었음 - 수정할 때마다 메일 등을 보내야하므로 작업에 문제가 없도록 신경써야했음 - 메일을 받는 모든 구성원들이 작업을 병합하는 과정이 있었음

- 공동 기여 저장소 모델 - 현대의 오픈소스 프로젝트 개발에 널리 쓰이는 개념 - 일반적으로 공식 저장소와 사본 저장소를 두고 작업함 - 대게의 프로젝트 참여자는 사본 저장소에 수정(commit & push)하고 공식 저장소에 해당 수정을 반영해달라고 요청(pull request)함.

- 공식 저장소는 일부 핵심 커밋터(committer)가 수정되어 반영 요청된 사항을 merge 또는 pull함.

- 공유된 유지보수 모델 - 공동 기여 저장소 모델과 유사하나, 공식 저장소에 모든 사람이 접근 가능 - 모든 개발자는 사본 저장소에서 작업한 뒤 본인의 작업이 완료되어 공식 저장소로 push하여 업데이트함.

- 커스텀 접근 모델 - 권한 제한 등을 통해 여러 모델을 사용

최근의 작업 방식은 공동 기여 내지는 공유된 코드 호스팅 시스템를 복사한 ‘사본 저장소’에서 작업하고 중앙 코드 호스팅 시스템에 반영하는 형태

팀으로 일한다는 것

중앙화된 코드 호스팅 시스템에 마구잡이로 코드를 반영하면, 문제가 되지 않을까?

- 특정 커밋터만이 해당 권한을 갖는 것이 바로 기본적인 ‘공동기여 저장소 모델’ - 하지만 최근의 오픈소스 커뮤니티에서는 누구나 공동저장소에 기여할 수 있도록 하는데, 이를 ‘공유된 유지보수 모델’로 봄

- 누구나 기여할 수 있다는 점에서 ‘규약’이 필요해짐 - 브랜치!! - ‘장기 공개 브랜치’와 ‘단기 비공개 브랜치’로 나눈 규약이 일반적임

- 단기 (비)공개 브랜치 : 새로운 구상을 개발, 버그 수정, 기능 추가 등 - 장기 공개 브랜치 : 단기 공개 브랜치의 결과물을 모아 결과로 만드는 브랜치

팀으로 일한다는 것

일반적인 개발 플로우 일반적 브랜치 규약에 따른 개발 플로우

Github을 중심으로 한 Git 사용법

개념적 Git SourceTree & CLI

개념적인 Git개별 개발자들은 저장소 로컬 사본을 가지고 있음 나도 모르게 다른 개발자들의 수정사항이 자신의 작업에 밀려들어오는 일은 절대 없다는 것.

Checkout : 새로운 브랜치를 생성하거나 기존의 브랜치로부터 작업을 시작.

Pull : 중앙화된 코드 호스팅 시스템에서 코드를 가져와 로컬 저장소(사본저장소)에 반영한다.

Commit : 로컬 저장소에서 수정한 내용을 완료하는 하나의 단위

Push : 내가 수정 완료한 코드(Commit)를 중앙화된 코드 호스팅 시스템에 코드를 반영시킨다.

개념적인 Git단기 브랜치(기능, 버그수정)의 목표가 끝나면 통합 브랜치로 병합하여 코드를 합치게 됨.

Merge : 기능1, 기능2 브랜치의 내용을 통합 브랜치에 합침 Rebase : 기능1, 기능2 브랜치의 내용으로 통합 브랜치 내용을 교체함

개념적인 Git요약하면 대체적인 프로세스는 아래와 같음.

- 중앙 저장소에서 코드를 Clone해 사본을 만듬. - Pull을 통해 최신 코드를 가지고 옴. - 작업할 브랜치를 Checkout함. - 수정된 내용을 Commit하여 사본저장소에 작업 완료됨을 알림 - Push를 통해 해당 내용을 중앙 저장소에 업데이트 함 - 해당 내용이 전체 코드에 반영되어도 좋을지 판단함

- 코드 리뷰, QA, 테스트 등 - 통합 브랜치에 Merge하여 반영함 - (작업하던 브랜치를 제거함)

이 내용을 실제로 SourceTree 툴을 이용해 진행해보겠음. - https://www.sourcetreeapp.com/ - github 내에 임의의 빈 Repository를 하나 만들고 실습!

Github 내에 임의의 빈 Repository를 하나 만들기.Github 사이트에서 Create new Repository.

무제한 public 저장소 private 저장소는 사용량에 따라 부분 유료.

‘Initialize this repository with a README’ 체크 - 커맨드 라인으로 초기화할 수도 있지만.. 귀찮으니까.

Add .ignore - Python 선택 - 파이선 관련된 불필요한 파일이 자동으로 등록되는 것 방지

Clone : 중앙저장소(github)를 사본저장소로 복사하기중앙저장소 주소를 복사 사본저장소 복사하기

또는…

$ git clone git@github.com:ildoonet/github-practice.git

Log : 저장소의 히스토리 보기

저장소가 초기화된 로그만 있음

저장소가 초기화될 때, 2개의 파일이 생성(+)

각 파일 변화 내역도 오른쪽에 나타남.

$ git log commit 7c138fd071448c71ee260bf474920eff262caa5b Author: Ildoo Kim <ildoo@ildoo.net> Date: Thu Feb 9 13:34:45 2017 +0900

Initial commit

$

Pull : 중앙저장소에 있는 최신 코드를 가져오기SourceTree CLI

* git pull —help 를 통해 자세한 옵션을 지정할 수 있음.

$ git pull

Already up-to-date.

Branch & Checkout : 작업할 브랜치 선정SourceTree CLI

* 브랜치 이름은 ‘타입-이슈번호-설명’ 형태가 일반적 * ex) feat-2333-web_server * ex) bug-3521-no_log_in_textfile

* ‘*’가 붙어있는 브랜치가 현재 작업 중인 브랜치 * checkout 시 기존에 없던 브랜치면 새로 생성

$ git branch * master

$ git branch feat-1-default_webserver $ git branch feat-1-default_webserver * master

$ git checkout feat-1-default_webserver Switched to branch ‘feat-1-default_web_server' $ git branch * feat-1-default_webserver master

SourceTree

test.py 라는 파일을 추가하고 Commit 해보기.CLI

* Commit : 작업의 주요 지점마다 스냅샷을 만드는 개념 * Commit까지만 하면 현재 저장소에만 반영한 것이므로, 중앙 저장소에 업로드 되지 않음. (push 이전)

* 커밋 메세지는 명확하게 작성할 필요가 있음 * 이슈 번호, 문제 상황, 해결된 것 등을 기재하여 나중에 확인 가능하도록.

$ git ls-files —others # untracked file list test.py

$ git add test.py $ git commit -m “add test.py file.” [feat-1-default_webserver 66f41a5] add test.py file. 1 file changed, 2 insertions(+) create mode 100644 test.py

test.py 라는 파일을 추가하고 Commit 해보기.

Commit 만 이루어진 상태(Push 이전)에서는 중앙 저장소인 Github에 아무런 변화가 없음.

feat-1-default_web_server 브랜치가 생겼고, 작성했던 커밋메세지대로 해당 파일에 대한 변경사항이 기록됨.

Push 방법

Push하여 저장소에 반영하기

$ git push --set-upstream origin feat-1-default_web_server Counting objects: 3, done. Delta compression using up to 8 threads. Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 350 bytes | 0 bytes/s, done. Total 3 (delta 0), reused 0 (delta 0) To github.com:ildoonet/github-practice.git * [new branch] feat-1-default_web_server -> feat-1-default_web_server Branch feat-1-default_web_server set up to track remote branch feat-1-default_web_server from origin.

Push 되고 나면 중앙 저장소에서도 확인 가능함

Merge 하여 코드를 메인브랜치(master)에 반영하기1번째 방법 / 3가지 방법 - github에서 ‘pull request’하여 merge하도록 함 - pull request를 하면 해당 코드를 리뷰할 사람을 지정하는 등의 기능이 있음

- 주로 pull request를 작성한 사람이 아닌 다른 사람이 코드 리뷰 및 테스트 후 코드를 합침.

2번째 방법 / 3가지 방법

3번째 방법 / 3가지 방법

$ git checkout master $ git merge feat-1-default_web_server Updating 7c138fd..66f41a5 Fast-forward test.py | 2 ++ 1 file changed, 2 insertions(+) create mode 100644 test.py

다시보는 개념적인 Git요약하면 대체적인 프로세스는 아래와 같음.

- 중앙 저장소에서 코드를 Clone해 사본을 만듬. - Pull을 통해 최신 코드를 가지고 옴. - 작업할 브랜치를 Checkout함. - 수정된 내용을 Commit하여 사본저장소에 작업 완료됨을 알림 - Push를 통해 해당 내용을 중앙 저장소에 업데이트 함 - 해당 내용이 전체 코드에 반영되어도 좋을지 판단함

- 코드 리뷰, QA, 테스트 등 - 통합 브랜치에 Merge하여 반영함 - (작업하던 브랜치를 제거함)

기타 사항

좋은 Commit 메세지 Conflict가 발생하는 경우 자주 사용될 주요 기타 명령어

Commit 메세지 작성하기좋은 커밋 단위 - 오직 관련된 코드만 추가하자. 여백 수정 이런거 말고. - 코드 내 문서화를 포함해 코딩 표준이 맞는지 검토한다. - 적당한 크기가 좋다. 너무 많은 작업 내용이 있는 한 단위는 좋지 않음 - 작업을 설명하는 좋은 커밋 메세지를 포함한다.

커밋 메세지 - 로그 검색을 위해서 표준 형식을 최대한 갖추자. - 현재 코드의 문제점을 좀 더 자세히 설명하고 해당 수정사항이 중요한 이유를 적는다. - 잠재적 부작용이 있다면 적는다. - 논의사항이 있는 웹사이트, 이슈번호 등의 다른 참조는 포함한다. - 문서 업데이트가 포함되어야 하면 해당 내용과 업데이트를 같이 한다.

Conflict이 발생하는 케이스여러 사람이 작업하다보니 Commit 시점, Merge 시점 등에 같은 코드를 수정했다는 이유로 Conflict가 발생.

Conflict가 발생한 파일에는 2가지 코드가 다 존재하고, 사람에게 수정을 요구함

<<<<<<< HEAD This is test file. ======= This is a test file. >>>>>>>

사람이 위 부분을 수정해서 ‘<<‘부터 ‘>>’까지를 해결해서 코드 작성 후 Commit 할 필요가 있음.

* SourceTree 등에는 Conflict를 2가지 코드 중 하나로 쉽게 선택하는 등의 기능이 있음.

HEAD 부분(현재 브랜치의 마지막 최신 사항)

Conflict가 발생한 새 커밋.

작업을 수행하는 과정에서 취소하는 3가지 : Reset / Revert / Stash

작업을 수행하는 과정에서 취소하는 3가지 시나리오

Reset - 커밋을 하지는 않았지만 현재 작성한 코드를 최신 커밋으로 되돌리고 싶을 때. - 모든 변경 사항을 리셋하거나 특정 파일을 리셋하여 최신 커밋 상태로 돌릴 수 있음

Stash - 현재 작업하던 내용을 잠시 중단하고 새로운 작업을 하고 싶을 때 stash를 사용하면 특정 메세지 아래에 작업 내용을 저장하고 나중에 불러올 수 있음.

- stash하는 순간 reset과 동일한 상태로 변경되지만, 현재 사항이 저장되고 나중에 불러올 수 있다는 점이 다름.

Revert - 이미 커밋된 사항의 변경사항들을 되돌리는 기능 - 변경사항을 그대로 되돌린 후 해당 사항을 새 커밋으로 기록함.

브랜치 간 병합하는 3가지 방법 : Merge / Rebase / Cherry-pick

Merge - 다른 브랜치의 변경점만 합침

Rebase - 다른 브랜치의 내용으로 현재 브랜치를 오버라이드함.

Cherry-pick - 다른 브랜치의 특정 커밋 변경점들만 합침.

코드 추적하는 기본적인 2가지 방법 : Blame, Bisect

Blame - 파일, 특정 수정의 히스토리를 찾아서 누가 고쳤는지 찾아냄

Bisect - 해당 파일이 수정된 마지맛 커밋 찾아내기 - ‘이게 언제부터 문제가 된 거지’

자주 사용될 Git 명령어 (1/2)

자주 사용될 Git 명령어 (2/2)

참고하면 좋은 자료

(eBook) 팀을 위한 Git

GitHub 간단 소개 : http://codedragon.tistory.com/4

GitHub을 사용하는 사례를 영상으로 만든 저장소 : https://github.com/mixed/github-usecase

코드리뷰, GitHub으로 바로 적용하기 : https://realm.io/kr/news/codereview-howto/

Github Gist 소개 : https://gist.github.com/msjang/e30f71fc6cdfd0d27e3c

기타 : 팀으로 일하기에 좋은 기본적인 팁테스트 주도 개발 : TDD - 먼저 합격 테스트를 작성해 개발하는 방식 - 언제 문제가 생겼고, 언제 해결되었는지가 명확함 - 해결할 문제가 무엇인지를 명확히 작성하는 과정이기도 함 - 자동 테스트를 통해서 QA팀, 전문검수자가 테스트를 진행하기 전에 기본적인 품질을 보증할 수 있음 - 많은 사람이 참여하는 프로젝트에서는 (1) 문제를 명확히하고, (2) 업무의 방향이 명확하고, (3) 다양한 코드에 따른 side-effect를 검증할 수 있고, (4) 코드의 기본적 품질을 언제나 보증할 수 있음.

개발환경을 최종 제작 환경과 비슷하게 맞추기 - 서버 환경 모형 : Docker, Vagrant - 환경설정 인프라 : Chef, Puppet, Ansible 등

합의지향개발

스프린트 - 일주일 단위의 짧은 스프린트 등 작업을 진행하는 일정한 속도 또는 흐름 - 일정 회의 등 매주 여러 차례 같은 시간에 진행. - 스프린트 데모 : 매주 한번은 작업 현황을 서로에게 보여줄 기회를 갖도록 함. - 스프린트 회고 : 매 스프린트가 끝날 때마다 작업 과정에 대해 논의함. - ‘스프린트’라는 책 참고.

Github/Git Starter Guide for Introductory Level

Curtis Kim @ KAKAO