권교의 개발 블로그

NEXTERS 3주차 

HttpRequest 사용하기.

8기 개발자 권기호. 

서론 

Android 환경에서 서버와 통신을 해야 하는 경우가 종종 있습니다.  여러분들은 어떤 모듈을 사용하여 서버와 통신하시나요? 

제가 처음 맞이했던 API는 Apache의 HttpClient였어요! 그래서 이번 3주차 활동에서는 Apache의 HttpClient를 이용한 서버와 통신하는 원리, 사용 방법 등을 알려드리고 싶었는 데... 오랜만에 보니…  

* deprecated…. 가슴이 아프네요… 

그러므로 이번 주는 HttpClient에서 HttpRequest로 주제가 변경되었습니다.  

*** 

그래도 혹시 사용해보고 싶으신 분들이 있을 것 같아 몇몇 자료를 첨부합니다! HttpClient를 사용하기 위해선 먼저 API를 설치해야 합니다. 아래 링크로 이동하여 소스를 다운로드 합시다. (전 4.5.2버전 사용합니다.)  아! 혼자 공부하시는 분들을 위하여 API 문서 링크를 따로 첨부했습니다.  

HttpRequest 시작하기 

처음부터 코드를 보기보단 조금 이론적인 부분을 보고 가는 것이 좋겠죠?  

Hyper-Text Transfer Protocol(HTTP)은 오늘날 인터넷에서 사용되는 가장 중요한 프로토 콜입니다. (다 아는 사실이죠) HTTP에 사용하는 여러 가지 메소드가 있습니다. HTTP/1.0 스 펙에 기재되어 있는 요청 방법에는 GET, HEAD, POST 방ㅇ식이 있으며 1.1 스펙에서 추가 된 PUT, DELETE, TRACE 방식이 있습니다. (다음 링크에 HTTP/1.1 스펙이 잘 설명되어 있네 요. – mindseye.tistory.com/145 ) 

우리는 서버의 자원을 어떻게 사용하는지에 따라 GET, POST 방식를 많이 사용합니다. GET 방식은 “서버의 자원을 가져올 때 사용”합니다. 더 정확히는 한 트랜잭션이 진행되면 서 동기화 이슈를 불러 일으키지 않는 선에서만 사용됩니다. GET 방식의 사용법을 정확히 알게 되는 오늘은 서버의 자원을 가져올 때만 사용하는 것이 아니라 ‘한 트랜잭션에 대해 서 동기화 이슈에 위반되지 않을 경우’에 사용하면 됩니다. (GET 방식을 쓸 때 다양한 이 슈들이 존재합니다. 쿼리 스트링에 제한이 있기도 하죠!! 보안적인 문제도 있고~ㅋ 하지 만 웹 브라우저가 쿠키를 거부한다면…? 즉 스크릿 모드라면..? 등등? 이에 대해 고민하는 것은 여러분의 몫! ) 

POST는 1.1스펙에 멱등 방식이 아닌, 즉 정확한 트래잭션을 가지고 있는 방식입니다. 그래서 GET방식과 다르게 POST는 동기화 이슈에서 안전합니다(Thread safe). 그렇기 때문 에 서버에 데이터를 insert, update, delete의 요청을 할 때에 POST 방식을 이용합니다.  

 이와 같이 HttpRequest는 이 요청 방식들과 관련된 get, post, head, put 등 모든 메소드 들을 정적(static)으로 제공합니다! HttpRequest를 new 하지 않고도 사용할 수 있는 것이 죠~! 멋있어… 더 자세한 내용은 다음 페이지에서 설명하겠습니다. 

HttpRequest는 모두들 “단 하나만의 클래스이며, 무척 가볍다”라고 이야기를 합니다. 저 는 “무척 가볍다”라는 말에는 동의하지만 단 하나의 클래스라는 말에는 동의하지 않습니 다. 외부에서 보기엔 단 하나의 클래스인건 맞지만 단 하나의 클래스 속에 여러 개의 정 적 네스티드 클래스(nested class)와 인터페이스(interface)가 정의되어 있기 때문이죠. 

참고로 소스를 확인해보시면 아시겠지만, HttpRequest는 java.net 패키지의 HttpURLConnection을 기반으로 하여 작동합니다. 이를 개발한 팀 역시 HttpURLConnection을 사용하는 Android 개발자들을 위하여 혹은 가벼운 성능의 HTTP 요청을 전송하는 개발자들을 위해 개발했습니다.  

HttpRequest를 이용한 코드 작성 

HttpRequest는 여러 개의 네스티드 클래스와 인터페이스를 가지고 있습니다. 여러 개의 네스티드 클래스 중 제가 관심 있게 보고 있는 인터페이스가 있습니다. 바로 ConnectionFactory라는 인터페이스인데요~!! 이 인터페이스는 HttpRequest가 내부적으로 빌더(Builder) 디자인 패턴을 적용시키기 위하여 설계되어 있습니다. 또한 내부적으로 URL 클래스의 openConnection메소드를 호출하는 등 여러 모로 관심 덩어리입니다. 

ConnectionFactory interface는 2개의 추상 메소드를 가지고 있고, 자기 자신을 구현한 멤버필드를 가지고 있습니다. (인터페이스에 싱글톤을 적용시켰네요!) HttpRequest 서버로 요청을 보낼 때 마다 새로운 HttpURLConnection을 생성합니다~!  이런 특별한 구조로 HttpRequest는 HTTP의 다양한 요청 방식을 구현해냅니다. HttpRequest를 파헤쳐 보는 것은 또한 여러분의 몫입니다. 다음 링크에서 소스를 확인해 보세요!(링크) 

이제 그 요청 방식들 중 HttpRequest를 이용하여 어떻게 GET 방식의 요청을 하는지 알 아봅시다.  

GET  

다음과 같이 URL을 설정해준 뒤, HttpRequest에 사용할 요청방식 GET을 나타내는 get 메소드를 호출합니다. HttpRequest에 포함되어 있는 HTTP 요청 방식 메소드들은 모두 static 메소드이므로, 따로 HttpRequest 인스턴스를 생성할 필요가 없습니다.   

get 메소드 내부에선 HttpRequest 객체를 생성해서 리턴해줍니다.   

HttpRequest 생성자에는 인자가 두 개 있습니다. 첫 번째 인자는 요청을 보낼 URL, 두 번째 인자는 요청에 사용할 메소드입니다. (여기에서 java.net 패키지의 URL클래스를 사용합니다.)   

HttpRequest 객체 생성이 완료되었습니다. 이렇게 생성된 HttpRequest 객체는 서버로 요청을 보낼 모든 준비가 완료된 ‘준비된 객체’입니다.   

이제 이 준비된 객체를 서버로 요청을 보내기 위해선 응답(response)을 받을 수 있는 메 소드를 호출하면 됩니다.  

위 그림에선 code()메소드를 호출했습니다. code()내부에선 getConnection()메소드를 호출 합니다.  

getConnection()메소드는 createConnection()메소드를 호출하네요? 이 메소드는 무엇인지 따라가보면~!  

내부적으로 HttpURLConnection 객체를 생성하는 것을 볼 수 있습니다.  

CONNECTION_FACTORY는 ConnectionFactory객체입니다. 

이와 같이 응답의 정보에 따라 다양한 메소드를 이용할 수 있습니다. 서버가 보내주는 응답의 Header 정보를 확인하면 됩니다. Response Code를 확인해보는 code() 메소드, 응 답 메시지를 확인하는 body() 메소드, 통신이 성공했는지 확인하는 ok() 메소드가 있습니 다~!! 이렇게 서버의 응답을 확인하는 첫 메소드를 호출하는 순간 서버와 통신이 시작됩 니다. (두 번째부터 호출되는 메소드는 서버와 재 통신하지 않습니다.)  이제 위의 GET 방식과 더불어 POST 방식으로 요청을 전송하는 코드를 확인하겠습니다. 

최종코드   

주의 사항 

· 해당하는 메소드들을 첫 번째로 호출할 당시 호출한 위치가 Android의 UI Thread or runOnUiThread()일 경우 NetworkOnMainThreadException이 발생합니다. 

10  

· code(), ok()와 같은 메소드들은 첫 요청 이후 여러 번 재 호출해도 되지만 body() 메 소드는 한 번 호출 이후 재호출을 할 경우 IOException이 발생합니다. 

· 재 호출이 아니더라도 body() 메소드를 UIThread에서 호출할 경우 IOException이 발생합니다. 

HttpRequest 객체를 이용해서 UIComponent에 직접 데이터를 갱신해 주면 좋지만 모 든 작업은 Worker Thread에서 처리 후, 최종 결과만 UIThread에 전달하시길 권고합니다. 

마치며… POST 방식은 다음 장의 세션 유지하기에서 form data 전송과 함께 다시 한 번 더 보겠습니다. 

HttpRequest의 UML  

아! Multipart 종류들의 메소드들은 HttpRequest.part() 메소드를 사용하시면 됩니다! 

사용된 코드 & 도움된 사이트

HttpRequest - https://github.com/kevinsawicki/http-request

HttpRequest API - http://kevinsawicki.github.io/http-request/apidocs/index.html

HttpRequestProject(Android) – https://github.com/KwonGiho/HttpRequestProject

HttpRequestServer(J2EE) - https://github.com/KwonGiho/HttpRequestServer

HTTP1.1스펙 한글판 - mindseye.tistory.com/145

HTTP1.1 스펙 - https://tools.ietf.org/html/rfc2616#section-2.2

NEXTERS 9기 활동 1주차.

Git 사용법.

활동 1주차.

8기 개발자 권기호.

Git의 기초.

회사나 특정 돈이 걸려있는 프로젝트에서의 필요한 개발자의 역량은 이론보단 당장 사용 가능한 프로그래밍 언어 그리고 학습스피드 등등 있겠지만 NEXTERS는 그런 관계로 묶여 있는 것이 아니니까 이론도 함께 보고 가겠습니다.

Git의 핵심은 생각보다 별게 없습니다. Git은 Subversion이나 Perforce와 같은 VCS를 사용하시던 분들이 아니면 쉽게 익힐 것 이라 생각합니다. 다른 VCS는 인터넷이 가능한 환경에서만 커밋을 할 수 있지만, Git은 인터넷이 연결되어 있지 않은 지하 혹은 비행기 안에서도 커밋이 가능합니다. 이건 오로지 Git형님만 구사할 수 있는 능력이죠.

Git은 모든 데이터를 “저장하기 전”의 체크섬(해시)를 구하고 그 체크섬으로 데이터를 관리합니다. 체크섬(해시)가 없이 어떠한 파일이나 디렉토리도 변경할 수 없습니다. 체크섬은 Git에서 사용하는 가장 기본인(Atomic)데이터 단위이자 Git의 기본 철학입니다.

Git은 SHA-1해시를 사용하여 체크섬을 만듭니다. 처음 들어본 것 같지 않은 것 처럼 익숙한 SHA-1. Google에서 API키를 발급받기 위하여 SHA-1키를 콘솔에서 확인한 경험이 있는 개발자들은 익숙하겠죠~.

Git의 상태.

1.     Committed(git directory)

è  Committed란 데이터가 로컬 데이터베이스에 안전하게 저장되었다는 것을 의미합니다.

2.     Modified(checkout 하고 파일들을 수정했지만 staging area에 추가하지 않은 상태)

è  Modified란 수정한 파일을 아직 로컬 데이터베이스에 커밋하지 않은 것을 말합니다.

3.     Staged(파일을 수정하고 Staging area에 추가(add)한 상태. )

è Staged란 현재 수정한 파일을 곧 커밋할 것이라고 표시한 상태를 의미합니다.

git directory는 git이 프로젝트의 메타데이터와 객체 데이터베이스를 저장하는 곳을 말합니다. 즉 git의 핵심이라고 할 수 있죠. 이건 다른 컴퓨터에 있는 저장소를 clone할 때 git 디렉토리가 만들어집니다.

working directory는 프로젝트의 특정 버전을 checkout한 것입니다. git디렉토리는 지금 작업하는 디스크에 있고 그 디렉토리에 압축된 데이터베이스를 파일을 가져와서 워킹 디렉토리를 만듭니다.

staging area는 git디렉토리에 있습니다. 단순한 파일이고 곧 커밋할 파일에 대한 정보를 저장합니다. 종종 인덱스라 부르기도 하지만 Staging Area라는 명칭이 표준이 되고 있습니다

방금 말한 것 처럼 Git이 하는 일을 간단하게 말하자면 이렇습니다.

1.     working directory에서 파일을 수정한다

2.     staging area에 파일을 stage해서 커밋할 스냅샷을 만든다.

3.     staging area에 있는 파일들을 커밋해서 git디렉토리에 영구적인 스냅샷으로 저장한다

Git 설치

백날 공부해봤자 사용하지 못하면 소용이 없죠. 그렇기 때문에 지금부턴 설치 한 뒤 진행하도록 하겠습니다.

리눅스에 설치하기

개발자로써의 개인 철학은 “터미널 환경이 제공되는 프로그램이라면, UI는 되도록 사용하지 말자”라는 것이 개인 철학입니다. 그 이유는 , 어떤 이슈가 발생하고 그 이슈에 접근하기 위해선 가장 기본이 되는 것 들을 정확하게 알고 있어야 한다고 생각하기 때문입니다.

1.     Fedora

è yum install git-core

2.     Ubuntu – 데비안류 배포판은 apt-get을 사용하면 됩니다.

è apt-get install git

3.     Mac

è http://sourceforge.net/projects/git-osx-installer/

è sudo port install git-core +svn +doc +bash_completion +gitweb

4.     Window

è http://msysgit.github.com/

Git 초기 설정

웹, 게임과 같은 특정 서비스를 이용하기 위해선 사용자의 초기 정보가 필요하고, 초기 정보를 이용하여 회원가입을 진행합니다. Git도 이와 같은 초기 회원가입(config설정)을 해줘야 하죠. 초기 설정은 이름과 같이 한번만 해주면 되고 사용하면서 바꿀 수 있는 명령어가 존재합니다.

1.    사용자 정보.

è Git을 설치하고 나서 가장 먼저 해야하는 일은 사용자의 이름과 이메일 주소를 설정하는 것입니다. Git은 커밋할 때마다 이 정보를 사용하죠. 한번 커밋한 후에는 정보를 변경할 수 없습니다.

git config --global user.name “kwongiho”

git config --global user.email “shng10503@naver.com”

--global로 설정해준 정보는 모든 프로젝트가 커밋할 때 사용하게 됩니다. ( 말 그대로 전역변수에요~ ) 만약 프로젝트마다 다른 이름과 다른 이메일 주소를 사용하고 싶으면  --global속성을 빼고 실행시키면 됩니다.

2. 편집기 설정

Git의 기본 편집기는 Vi,Vim입니다. 하지만 gEdit , Nano , gVim , emacs 등등 다른 편집기를 사용하고 싶은 분들도 계시겠죠. 그럴땐 다음 명령어와 같이 입력하시면 됩니다.

git config --global core.editor [편집기이름]

2.    설정확인

이렇게 설정한 모든 정보들을 아래의 명령어로 확인할 수 있습니다.

git cnofig --list

본격적인 Git 시작하기.

Git의 명령어에 익숙해 지는 것이 가장 중요하겠죠.

Git에서 사용 가능한 명령어와 설명을 볼 수 있는 명령어가 있습니다.

git help config

Git 저장소 만들기.

Git 저장소를 처음 만드시는 분은 다음과 같은 상황일 것입니다.

상황 1. 기존의 NEXTERS가 아닌, 다른 그룹에서 진행하던 프로젝트가 있다. 그런데 이번에 Git에 대해서 공부했고, 로컬에 있는 소스코드들을 Git으로 옮기기를 원한다.

상황 2. 형상 관리가 필요할 만큼 일정 수준의 사람들과 협업을 해본적이 없다. 하지만 이제부터라도 형상 관리툴을 이용하여 프로젝트를 진행해 보고 싶다.

자! 이런 모든분들! 다같이 저장소를 만들어 봅시다.

1.     git init

2.     git touch readMe.txt

3.     vi readMe.txt

A.     vi readMe.txt - vi에디터로 readMe.txt파일을 열어라 라는 뜻입니다. 만약에 readMe.txt파일이 없으면 새로 생성하고 파일을 엽니다.

B.     i키(insert)를 입력하고 프로젝트에 대한 설명을 간단하게 작성합니다.

C.     Esc-> : -> wq키를 입력하여 vi 에디터에서 탈출합니다.

4.     git add --all

5.     git commit –m “initial project version. first commit”

이와 같이 매우 짧은 명령어들을 통하여 Git 저장소를 만들 수 있습니다.

è 다음 명령어들은 상황2에 맞춘 명령어 입니다. 상황 1의 경우라면, readMe.txt파일이 아니라 어느정도 코딩을 한 후에 커밋을 하셔도 됩니다. ( 하지만 이 상황은 초기 설정이므로 readMe.txt파일을 만드시는 것을 권장합니다.)

원격 저장소에 프로젝트를 연결하기.

깃을 사용하게 되면 또 다시 두 가지의 상황을 맞이하게 됩니다.

상황 1. 다른 프로젝트에 참여(Contribute)하거나 다른 컴퓨터에서 push한 내용을 다른 컴퓨터에서 이어서 하고싶다. à git clone [URL]

상황 2. 깃을 완전 처음 사용해봐서, 환경설정 및 저장소는 만들었지만 원격 저장소엔 연결을 하지 못했다. -> git remote add origin [URL]

è Git은 여러 프로토콜은 제공합니다. 지금까진 git://프로토콜을 사용했지만, http(s)://을 사용할 수 있고 user@server:/path.git처럼 SSH의 프로토콜을 사용할 수 있습니다.(각 프로토콜의 장단점은 가장 마지막인 번외에 작성하도록 하겠습니다.)

수정하고 저장소에 저장하기

Git 저장소를 만들고 초기설정을 진행했습니다. 원격 저장소에 로컬 저장소를 연결도 했습니다. 이제는 파일을 수정하고 파일을 커밋해 보도록 하겠습니다.

워킹 디렉토리의 모든 파일은 크게 Tracked와 Untracked로 나뉩니다 (단어의 말 그대로 관리하는 대상과 관리하지 않는 대상이란 뜻이죠~). Tracked(관리 대상)은 Staged(커밋 직전의 상태)와 Modified(수정 되고 있는중)상태 중 하나입니다. 그리고 나머지 파일들은 Untracked파일입니다. Untracked파일들은 워킹 디렉토리에 있는 모든 파일이 포함되어 있는 것은 아니고, Staging Area에 있는 것도 아닙니다. 처음 저장소를 Clone하면 모든 파일들은 Tracked이면서 Unmodified상태가 됩니다.(파일을 checkout하고 아무것도 수정하지 않았기 때문이죠.)

마지막 커밋 이후 어떤 파일이 수정이 이루어지면, Git은 그 즉시 파일을 Modified상태로 인식합니다. 그리고 수정한 파일을 Stage하고, Staged상태인 파일을 커밋합니다. 이 라이프 사이클은 다음 그림처럼 반복합니다.

파일의 상태를 확인하려면 보통 git status 명령을 사용합니다.  보통 clone을 한 직후의 프로젝트의 상태는 Tracked이나 Modified상태의 파일이 하나도 없다는 의미 입니다. Untracked파일은 아직 존재하지 않아 목록에 보여지지 않습니다. 그리고 현재 작업중인 브랜치를 보여주며, 기본 브랜치가 master이기 때문에 master로 나옵니다.

프로젝트에 readMe.txt파일을 새로 만들어보겠습니다. readMe.txt파일은 새로 만들어진 파일이기 때문에 git status를 실행하면 Untracked files에 포함되어 있습니다. ( deleted는 기존 리모트 서버에 readMe.txt파일이 존재했고, 이 파일을 삭제한 다음 진행했기 때문에 저희에게 보여집니다. )

이렇게 만들어진 readme 파일은 untracked라는 것은, 파일이 Tracked상태가 되기 전까지는 Git은 절 때 그 파일을 커밋하지 않는다. ( git이 바이너리까지 커밋하는 행위를 막아주는 것이죠~)

그럼 README파일을 추가해서 Tracked상태로 만들어 봅시다.

git add reame 명령어로 readme 파일만 Tracked 상태로 변환합니다. ( add 명령어로 Staged 상태로 변하는 것을 확인할 수 있습니다.) 

그렇다면 기존에 Tracked 상태인 파일을 수정하는 방법을 보겠습니다.

readme파일을 수정하고 나서 git status명령을 수행하면 다음 결과처럼 나옵니다.

이렇게 수정 된 파일들을 commit하면 체크섬[master 534a8d3]이 저장되고, staged 상태로 전환된다.

Git 커밋 수정하기.

종종 너무 일찍 커밋 하거나 커밋 메시지를 잘못 적었을 때 커밋을 수정하고 싶은 경우가 종종 있습니다. 이럴 때 다시 커밋하기 위해서 --amend옵션을 사용합니다.

git commit --amend

파일 상태를 Unstage로 변경하기.

두 개 이상의 파일을 수정하고 따로따로 커밋하려고 했지만, 실수로 git add --all / git add * 이라는 명령어를 실행시켜 버렸다. 두 파일은 모두 Staging Area(modified)에 들어가 있습니다.

그럴 경우 reset 명령어로 Unstage상태로 변경할 수 있습니다.

git reset HEAD [file name]

다음 그림에선 git add * 이 아닌 특정 파일만 해줬지만 add *이라 생각하시고 테스트 해보셔도 됩니다.

reset 명령어는 rollback과 같은 개념이라 생각하시면 됩니다. 특정 파일만을 reset할 수도 있고, 전체적으로 commit한 내용들을 몇 단계든지 reset할 수 있습니다.

git reset HEAD~[단계수]

Modified 파일 되돌리기

에고.. 큰일 났습니다. Clone하고 나서 수정하지 말아야 할 파일을 수정했거든요. Clone 받아놓으라고 한 사수는 1분뒤에 들어옵니다. 어떻게 해야할까요?

git checkout -- [파일명]

수정 되어있던 파일이 수정 되기 전으로 되돌와 있네요?

리모트 저장소

리모트 저장소에 대하여 정확히 알아야지 다른 사람들과 일할 수 있습니다. 리모트 저장소는 인터넷이나 네트워크가 어딘가에 존재하는 저장소를 말합니다. 저장소가 여러 개 있을 수 있는데, 어떤 저장소는 읽기 쓰기 모두 가능하고 어떤 저장소는 읽기 권한만 있을 수 있습니다.

간단히 말하면 협업 한다는 것은 리모트 저장소를 관리하면서 데이터를 리모트에 Push 하고 Pull 하는 것 입니다.

개발자는 리모트 저장소를 어떻게 추가,삭제 하는 방법을 알 뿐만 아니라 브랜치를 관리하고 어떻게 트래킹할지 매우 중요합니다.

리모트 저장소 확인하기

git remote 명령어로 프로젝트에 등록된 모든 리모트 저장소를 확인할 수 있습니다. 이 명령은 리모트 저장소의 이름을 보여줍니다. 앞에서 봤던 것 처럼 Clone명령어를 사용하면 자동적으로 remote와 연결이 되기 때문에 초기에 origin이라는 이름을 볼 수 있습니다.

원격 리모트도 한 개 이상을 등록 할 수 있습니다.

리모트 저장소 추가

git remote add [별칭] [url]

이렇게 remote를 추가해 주면, 한 프로젝트가 두 개 이상의 remote를 가지게 되는데, 그럼 fetch를 받을 땐 앞에서 설정한 별칭으로 받아오면 된다

이렇게 추가한 remote의 별칭은 다음의 명령어로 변경이 가능하다.

git remote rename [원래이름] [바꿀이름]

리모트 저장소를 Pull하거나 Fetch하기..

만약 git remote add otherRemote http://github.com/Kwongiho/otherremmote 이렇게  등록했다면 다음과 같이 실행시키면 된다.

git fetch otherRemote .

이 명령은 http://github.com/Kwongiho/otherremote에 있는 저장소를 로컬 저장소로 가져오는 역할을 한다.

git pull 명령어로 리모트 저장소의 데이터를 로컬 저장소로 가져오면 자동적으로 merge까지 해준다.

리모트에 Push 하기

어느 기능을 완성하면 “야 푸쉬좀 해줘!! “ 라는 이야기를 많이 하게 될겁니다.

git push [리모트 저장소 이름] [브랜치 이름] 으로 쉽게 할 수 있습니다.

master 브랜치를 origin 서버에 푸쉬 하려면 다음과 같이 push 합니다.

git push origin master.

Git 브랜치

Git의 브랜치 직접 브랜치를 만들어보고, Merge하면서 학습하시길 권장합니다.

브랜치 부분부턴 잘 정리되어 있는 사이트가 있어 첨부합니다.

전반적으로 이 문서는 유형-이론을 바탕으로 쓰여졌습니다.

브랜치 부분을 꼭 두 번 이상 읽어보시길 권장합니다.

브랜치 부분을 다 읽어보신 후에 유형-테스트 부분을 두번이상 클리어 해보시길 권장합니다.

참고 사이트 - https://git-scm.com/book/ko/v1/Git-%EB%B8%8C%EB%9E%9C%EC%B9%98-%EB%B8%8C%EB%9E%9C%EC%B9%98%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80%3F // learnbranch.urigit.com