슬라이드 1

Size: px

Start display at page:

Download "슬라이드 1"

강우 육
5 years ago
Views:

1 Git 심화 l NIPA KOSSLab. Taeung Song taeung@kosslab.kr

2 Instructor 송태웅 (Taeung Song, - NIPA KOSS(Korean Open Source Software) Lab. Software Engineer - Linux Kernel 프로젝트 Contributor - 전 ) XS inc. (Embedded, ARM, Server, Linux) 선임연구원

3 Index Git 내부구조 l Git 협업실습 l Git 서버구축 l Git 추가실습

4 Git 내부구조 - Git init 으로 생성되는 metadata(.git 폴더 ) - Git 의 저장방식 (object) - Git 의 commit object 살펴보기

5 1.1 Git Metadata 1) 임의의 폴더를 생성하고 경로 이동해서 # mkdir test; cd test 2) Git init 을 하게 되면 # git init Initialized empty Git repository in /home/taeung/test/.git/ 3) 다음과같이.git 폴더를 확인 할 수 있다. # ls -F.git branches/ config description HEAD hooks/ info/ objects/ refs/

6 1.2 Git 의 저장방식 (Object) 1) 소스파일 hello_world.c 을 만들어보고 확인해보자. # cat hello_world.c #include <stdio> int main() { printf( hello world!\n ); return 0; } 2) 소스파일 hello_world.c 을 commit 해보자. # git add hello_world.c ; git commit -m first commit 3) hello_world.c 파일을 git 에서 관리할때의 파일명 (hash 값 ) 을 보자. # git hash-object hello_world.c d37e285be34ff9690cae977d133cf5ebb1

7 1.2 Git 의 저장방식 (Object) 3) hello_world.c 파일을 git 에서 관리할때의 파일명 (hash 값 ) 을 보자. # git hash-object hello_world.c d37e285be34ff9690cae977d133cf5ebb1 4) git 시스템 내부에서 hello_world.c 파일을 어떻게 관리하는지 찾아보자. # find.git/objects -type f.git/objects// e6b1e54d4e1790a050db66c2d26.git/objects/90/f b2184a23c2fb0f0c49d2f1.git/objects/70/6896d37e285be34ff9690cae977d133cf5ebb1 5) git 시스템 내부에서 hello_world.c 파일을 어떤타입의 object 로 관리하는가? # git cat-file -t d37e285be34ff9690cae977d133cf5ebb1 blob

8 1.2 Git 의 저장방식 (Object) 6) git 시스템 내부에서 압축된 (zlibc)hello_world.c 파일을 확인해보자. # cat.git/objects/70/6896d37e285be34ff9690cae977d133cf5ebb1 > import sys > import zlib > > input = sys.stdin.read() > result = zlib.decompress(input) > print result > " blob 73#include <stdio.h> int main() { printf("hello world!\n"); return 0; } python -c "

9 1.3 Git 의 commit object 살펴보기 1) 이전에 commit 했을때 생긴 commit ID 을 살펴보자. # git show --quiet commit 90f b2184a23c2fb0f0c49d2f1 Author: Taeung Song <treeze.taeung@gmail.com> Date: Sat Sep 3 00:28: first commit 2) git 내부에서 commit object 의 타입은 무엇인가? # git cat-file -t 90f67 commit 3) git 내부에 저장된 commit object 90f67 의 내용은 무엇인가? # git cat-file -p 90f67 tree e6b1e54d4e1790a050db66c2d26 author Taeung Song <treeze.taeung@gmail.com> committer Taeung Song <treeze.taeung@gmail.com> first commit

10 Git 협업실습 - Git 필수명령 리뷰 및 실습준비 - Rebase 는 언제 쓸까? - A, B 로 역할 나누어 협업실습 하기

11 2.1 Git 필수명령 리뷰 < Git 필수 명령 > add : 커밋할 목록에 추가 commit : 커밋 ( 히스토리의 한단위 ) 만들기 push: 현재까지 역사 (commits) Github 에 밀어넣기 add 커밋할 목록 (the index) - 파일 1 - 파일 2 커밋 3 commit 커밋 2 커밋 1 커밋 3 push 커밋 3 커밋 3

12 2.2 Git 실습목표 본 강의는 실습 90% 이론 10% ( 스파르타 ) 나중에 하는건 없다 무조건 오늘 목표는 이루고 가자 질문은 모두를 이롭게 한다 내 손으로 명령어를 직접 입력해보자 터미널 환경 경험하자 GUI(Graphic User Interface) 대신 CLI(Command Line Interface) 경험하자 vi 에디터를 사용해보자

13 2.3 Rebase 이해하기 Rebase 와 Merge 의 차이는? 둘다 두 branch 의 차이점 (commits) 을 합치는것은 매한가지나 Rebase 는 합치기 전에 되감기 (rewinding) 를 하고 Merge 는 안하고 합친다.

14 2.4 Rebase 는 언제 쓸까? commit 을 역사의 한단위 ' 블럭 ' 이라 하고 블럭들의 모임을 'tree' 라 할때 내가 쌓은 블럭을 잠시 빼고 ( 뺀 나머지 ) 기준이 되는 tree 를 최신 업데이트 한 후에 그 위에 다시 내 블럭을 쌓아 올릴때 쓸 수 있다.

15 2.5 협업을 위한 2 인팀짜기 옆사람과 2 인팀을 만들자! (A 역할, B 역할 각각 담당 ) 한번의 선택이 오늘 실습의 결과를 좌우한다.. 똑똑한 친구를 고르도록 하자.. 협업실습 참고 URL :

16 2.6 협업을 위한 organization 만들기 한 사람의 계정으로 organization 을 만들자

17 2.6 협업을 위한 organization 만들기 팀이름, 메일 입력하고 생성하기

18 2.6 협업을 위한 organization 만들기 팀원추가해주고 생성완료

19 2.6 협업을 위한 organization 만들기 새로운 remote 저장소 만들기

20 2.6 협업을 위한 organization 만들기 프로젝트명 쓰고 생성하기

21 2.6 협업을 위한 organization 만들기 생성된 URL 복사하기

22 2.7 perf 소스 초기 commit & push 1) 아래 다운로드 링크를 통해서 perf 소스를 다운 받자. 2) 압축풀고 linux-perf 폴더로 들어가서 git 초기화 하자. # cd mkdir linux-perf; test; cd git testinit 3) 초기 commit 을 만들자. # git mkdir add test; -A; git cd test commit -m [Advanced Git] Initial Commit 4) organization 에서 만든 Remote 저장소 URL 등록후 push 하자. mkdir test;add cd origin test # git remote <remote 저장소 URL> # git push origin master

23 2.7 perf 소스 초기 commit & push 아래와 유사하게 push 가 정상적으로 완료가 되면 setting 에 들어간다.

24 2.7 perf 소스 초기 commit & push 협업을 할 친구의 ID 를 등록한다.

25 2.8 각자 fork 를 해놓자. 각자 본인의 ID 로 로그인해서 fork 를 한다.

26 2.9 STAGE 0 : A, B 미션 1) 각자 본인이 fork 해서 만든 프로젝트 URL 로 clone 받자 # cd mkdir ~ test; cd test # git clone < 본인계정아래 fork 된 프로젝트 URL>

27 2.9 STAGE 1 : A 미션 프로젝트 세팅 1) 아래 다운로드 링크를 통해서 A 미션을 위한 준비물 파일을 받고 압축풀자. 2) 방금 clone 받은 프로젝트로 경로를 이동 후 브랜치 생성 # cd mkdir linux-perf; test; cd git testcheckout -b develop 3) ~/Downloads/A/PR-1 폴더 내에 있는 patch 파일을 commit 으로 만들자. # git mkdir amtest; 00-perf-config-Tidy-up-the-code-setting-buildid-dir.patch cd test 4) 방금 만들어진 commit 을 내 이름으로 수정해보자. mkdir test;--amend cd test--author= 본인이름 < 본인이메일 > # git commit 5) 수정이 잘되었나 저자명 (Author) 을 확인하자 # git mkdir show test; cd test

28 2.9 STAGE 2 : B 미션 프로젝트 세팅 1) 아래 다운로드 링크를 통해서 B 미션을 위한 준비물 파일을 받고 압축풀자. 2) 방금 clone 받은 프로젝트로 경로를 이동 후 브랜치 생성 # cd mkdir linux-perf; test; cd git testcheckout -b develop 3) ~/Downloads/B/PR-1 폴더 내에 있는 patch 파일들을 commit 으로 만들자. # git mkdir amtest; 00-perf-config-Introduce-perf_config_set-class.patch cd test # git am 00-perf-config-Let-show_config-work-with-perf_config_se.patch 4) 방금 만들어진 commit 을 내 이름으로 수정해보자. # mkdir test;--amend cd test--author= 본인이름 < 본인이메일 > git commit # git show

29 2.9 STAGE 3 : A 미션 pull-request 하기 1) PR-1 폴더에 있는 내용 commit 으로 적용했다면 push 한다. # git mkdir push test; origin cd test develop

30 2.9 STAGE 3 : A 미션 pull-request 하기 develop 브랜치 성공적으로 push 했다면 pull-request

31 2.9 STAGE 3 : A 미션 pull-request 하기 Pull-request 보내기

32 2.9 STAGE 3 : A 미션 pull-request 하기 Pull-request 보냈다면 아래 처럼 organization 의 본래 프로젝트에 확인 가능

33 2.9 STAGE 4 : B 미션 comment 달기 Commit 이 한번에 많은 내용이 담겼습니다. 3 개정도로 나누는게 좋을것같습니다. 답변적는다.

34 2.9 STAGE 5 : A 미션 피드백에 맞춰서 두번째 pull-request 1) 기존 commit 를 지우고 원래 상태로 복원한다. # git mkdir reset test; HEAD^; cd test git checkout -- tools/ 2) PR-2 폴더에 있는 내용 patch 파일들을 새롭게 적용한다. # git am 00-perf-config-Remove-duplicated-the-code-calling-set_b.patch # git am 00-perf-config-Rework-buildid_dir_command_config-to-per.patch # git am 00-perf-config-Rename-v-to-home-at-set_buildid_dir.patch

35 2.9 STAGE 5 : A 미션 피드백에 맞춰서 두번째 pull-request 3) 방금 적용한 3 개 commit 을 모두 rebase -i 로 수정한다. (3 개 모두 edit 으로 지정 ) # git mkdir rebase test;-i cdhead~3 test 4) commit 을 하나씩 차례차례 수정한다 x3 (3 번 반복 ) mkdir test;--amend cd test--author= 본인이름 < 본인이메일 > # git commit # git rebase --continue 5) commit 수정 완료했다면 push 한다. # git mkdir push test; origin cd test develop -f

36 2.9 STAGE 5 : A 미션 피드백에 맞춰서 두번째 pull-request push 만 했음에도 불구하고 자동으로 pull-request 두번째 버전이 이어진 다는것을 확인

37 2.9 STAGE 6 : 최초 프로젝트 생성한 멤버의 미션 최초에 프로젝트 생성한 멤버가 해당 commit 을 merge 시킨다. merge 하기

38 2.9 STAGE 7 : B 미션 rebase 하기 1) 본래의 organization 의 프로젝트 URL 을 upstream 으로 등록하자. # git mkdir remote test;add cd upstream test 명 >/linux-perf.git 2) A 미션에 의해서 merge 된 새로운 commit 들을 가져오자. # git mkdir fetch test; upstream cd test 3) base( 기존 commit 들 ) 가 변경되었으니 rebase 하자. # git mkdir rebase test;upstream/master cd test First, rewinding head to replay your work on top of it... Applying: perf config: Introduce perf_config_set class Applying: perf config: Let show_config() work with perf_config_set

39 2.9 STAGE 8 : B 미션 pull-request 하기 1) 이젠 B 의 차례이다. rebase 마무리 되었다면 push 하자. # git mkdir push test; origin cd test develop

40 2.9 STAGE 8 : B 미션 pull-request 하기 develop 브랜치 내용을 기반으로 Pull-request 보내기

41 2.9 STAGE 9 : A 미션 소스라인에 comment 달기 첫번째 commit 을 열어보자.

42 2.9 STAGE 9 : A 미션 소스라인에 comment 달기 free(item value); 코드라인에 아래와같이 comment 를 달자.

43 2.9 STAGE 9 : A 미션 소스라인에 comment 달기 두번째 commit 을 열어보자.

44 2.9 STAGE 9 : A 미션 소스라인에 comment 달기 struct list_head *sections = &set sections; 소스라인에 comment 달기

45 2.9 STAGE 10 : B 미션 피드백에 맞춰서 두번째 pull-request 1) 기존 commit 를 지우고 원래 상태로 복원한다. # git mkdir reset test; HEAD^^ cd test && git checkout -- tools && git clean -f 2) PR-2 폴더에 있는 내용 patch 파일들을 새롭게 적용한다. # git mkdir amtest; 00-perf-config-Introduce-perf_config_set-class.patch cd test # git am 00-perf-config-Make-show_config-use-perf_config_set.patch

46 2.9 STAGE 10 : B 미션 피드백에 맞춰서 두번째 pull-request 3) 방금 적용한 2 개 commit 을 모두 rebase -i 로 수정한다. (2 개 모두 edit 으로 지정 ) # git mkdir rebase test;-i cdhead~2 test 4) commit 을 하나씩 차례차례 수정한다 x2 (2 번 반복 ) mkdir test;--amend cd test--author= 본인이름 < 본인이메일 > # git commit # git rebase --continue 5) commit 수정 완료했다면 push 한다. # git mkdir push test; origin cd test develop -f

47 2.9 STAGE 11 : 최초 프로젝트 생성자미션 merge 하기 B 가 작업한 두번째 pull-request 정상확인 되었다면 merge 하자.

48 2.9 STAGE 12 : A 미션 새로운 commit 들 추가 1) feature 폴더에 있는 patch 파일들을 차례로 적용시킨다. (develop 브랜치 ) # git mkdir amtest; 00-perf-ordered_events-Introduce-reinit.patch cd test # git am 00-perf-session-Make-ordered_events-reusable.patch # git am 00-perf-data-Add-perf_data_file switch-helper.patch

49 2.9 STAGE 13 : A 미션 rebase 하기 1) 본래의 organization 의 프로젝트 URL 을 upstream 으로 등록하자. # git mkdir remote test;add cd upstream test 명 >/linux-perf.git 2) B 미션에 의해서 merge 된 새로운 commit 들을 가져오자. # git mkdir fetch test; upstream cd test 3) base( 기존 commit 들 ) 가 변경되었으니 rebase 하자. # git mkdir rebase test;upstream/master cd test First, rewinding head to replay your work on top of it... Applying: perf ordered_events: Introduce reinit() Applying: perf session: Make ordered_events reusable Applying: perf data: Add perf_data_file switch() helper

50 2.9 STAGE 14 : A 미션 develop 브랜치에 있는 commit 들 feature 브랜치로 옴기기 1) master 브랜치로 변경한다. # git mkdir checkout test; cd master test 2) 새로운 브랜치 feature 를 만든다. # git mkdir checkout test; cd -btest feature 3) develop 브랜치에 있는 3 개의 commit 을 가지고 온다. cherry-pick ( 오래된 커밋 )..( 최신커밋 ) 범위지정 가능 # git cherry-pick develop~3..develop [feature 2cbd1c1] perf ordered_events: Introduce reinit() Author: Wang Nan <wangnan0@huawei.com> Date: Wed Apr 13 08:21: files changed, 10 insertions(+) [feature f7de143] perf session: Make ordered_events reusable Author: Wang Nan <wangnan0@huawei.com> Date: Wed Apr 13 08:21: file changed, 5 insertions(+), 1 deletion(-) [feature ada1f7d] perf data: Add perf_data_file switch() helper Author: Wang Nan <wangnan0@huawei.com> Date: Wed Apr 13 08:21: files changed, 51 insertions(+), 1 deletion(-)

51 2.9 STAGE 15 : B 미션 develop 브랜치에 있는 commit 한개 feature 브랜치로 옴기기 1) feature 폴더에 있는 patch 파일을 적용시킨다. (develop 브랜치 ) # git mkdir amtest; 00-perf-config-Fix-abnormal-termination-at-perf_parse_f.patch cd test 2) master 브랜치로 변경한다. # git mkdir checkout test; cd master test 3) 새로운 브랜치 feature 를 만든다. # git mkdir checkout test; cd -btest feature 4) develop 브랜치에 있는 가장최신 1 개의 commit 을 가지고 온다. # git cherry-pick develop [feature d84ff6b] perf config: Fix abnormal termination at perf_parse_file() Date: Mon Jun 6 19:52: file changed, 7 insertions(+), 9 deletions(-)

52 Git 서버구축 - Git 서버로 push 할 준비태세 - ssh 접속하기 - 미니 git 서버 구축하기 - Git 서버에 내 SSH 공개키 등록하기 - 내 프로젝트 push 하기

53 3.1 Git 서버로 push 할 준비태세 1) Git 서버에 push 할 임의의 프로젝트 생성 ( 용량작아야함 ) # mkdir advanced_git; cd advanced_git 2) Git 초기화 및 한개 commit 생성 # git init; touch test; git add test; git commit -m first 3) 나중에 사용할 ssh public key 생성하기 (Linux/Mac OS 와 Window 약간다름 ) Public key 생성도중에 나오는 입력값은 모두 Enter 키 눌러서 default 값으로 진행 # ssh-keygen -t rsa or # ssh-keygen.exe -t rsa 4) id_rsa.pub 내용미리 공개키 내용 복사해두기 ( 우 클릭 Copy) # cat ssh-keygen ~/.ssh/id_rsa.pub -t rsa

3.2 SSH 접속하기 1) Linux/Mac OS 환경이라면 터미널에서 ssh 접속 (ip 및 id/pw 는 현장에서 공지 ) # ssh git@192.168.xxx.

54 3.2 SSH 접속하기 1) Linux/Mac OS 환경이라면 터미널에서 ssh 접속 (ip 및 id/pw 는 현장에서 공지 ) # ssh git@ xxx.xxx 2) Window 환경이라면 putty 설치해서 접속 Download Link : 사용법 참고 :

55 3.3 SSH 접속 후 Git 서버구축하기 주의 : 다른사람의 Git 저장소 폴더를 지우지 말자.. 1) /repo/git/ 경로에서 본인의 이름으로 폴더 생성 # cd /repo/git; mkdir < 본인 영문이름 > 2) 자신의 프로젝트명으로 Git remote 저장소 구축하기 # cd < 본인 영문이름 >; mkdir advanced_git.git 3) Git remote 저장소 초기화 하기 # cd advanced_git.git; git init --bare

56 3.4 Git 서버에 내 SSH 공개키 등록하기 주의 : 다른사람의 SSH Public Key 를 지우지 말자.. 1) 현재는 ssh 접속되어 있는상태인데 /home/git/.ssh 경로로 이동한다. # cd /home/git/.ssh 2) authorized_keys 파일에 내 공개키를 추가로 덧붙힌다.(append) 반드시 >> 두개를 이용할것.. > 하나만 쓰면 남의 key 를 지워버리게 된다.. ( 조심 ) # echo < 아까 복사한 내 ssh public key 내용 > >> authorized_keys

57 3.5 내 프로젝트 push 하기 1) 내가 3.1 에서 만들어둔 폴더로 이동하자. # cd advanced_git 2) Git 초기화 및 한개 commit 생성 # git remote add origin git@<git 서버 IP>:/repo/git/< 본인이름 >/< 프로젝트명 > 만약 이전에 Git 서버에서 /repo/git/ 아래 만들어둔 본인의 이름이 taeung 프로젝트명이 advanced_git.git 이라면 아래와 같다. # git remote add origin git@<git 서버 IP>:/repo/git/taeung/advanced_git.git 3) 마지막으로 미리 구축해둔 미니 Git 서버에 push 한다. 성공했다면 미션 완료!! # git push origin master

58 Git 추가실습 - node.js 소스 Git 으로 살펴보기 미션 - submodule 간단한 실습 - stash 간단한 실습

59 4.1 Blame 이란 해당 소스라인 대해서 누가 마지막으로 수정을 했는지 commit ID 추적이 가능하다 f9273d6 5f9273d6 5f9273d6 5f9273d b6ab94e 0b93da17 aa61fd05 205ca Documentation/perf_counter/config.c tools/perf/util/config.c tools/perf/util/config.c tools/perf/util/config.c tools/perf/util/config.c Documentation/perf_counter/config.c Documentation/perf_counter/config.c Documentation/perf_counter/config.c Documentation/perf_counter/config.c Documentation/perf_counter/config.c Documentation/perf_counter/config.c Documentation/perf_counter/config.c tools/perf/util/config.c tools/perf/util/config.c tools/perf/util/config.c tools/perf/util/config.c Documentation/perf_counter/config.c (Ingo Molnar (Namhyung Kim (Namhyung Kim (Namhyung Kim (Namhyung Kim (Ingo Molnar (Ingo Molnar (Ingo Molnar (Ingo Molnar (Ingo Molnar (Ingo Molnar (Ingo Molnar (Josh Poimboeuf (Namhyung Kim (Wang Nan (Taeung Song (Ingo Molnar :00:56 22:52: 22:52: 22:52: 22:52: 15:00:56 15:00:56 15:00:56 15:00:56 15:00:56 15:00:56 15:00:56 09:39:39 12::15 11:13:34 16:53:18 15:00: ) 2) 3) 4) 5) 6) 7) 8) 9) 10) 11) 12) 13) 14) 15) 16) 17) /* * config.c * * Helper functions for p.. * Originally copied from.. * * Copyright (C) Linus Torval.. * Copyright (C) Johannes S.. * */ #include "util.h" #include "cache.h" #include <subcmd/exec-cmd.h> #include "util/hist.h" #include "util/llvm-utils.h" #include "config.h"

60 4.1 Node.js 소스 Git 으로 살펴보기 미션 1 : node_http_parser.cc 의 Parser 클래스 만든 최초 Commit 을 찾아내라. 1) Node.js 소스 받기 # git clone 2) node_http_parser.cc 가 있는 해당 경로로 이동하자. # cd node/src/; 3) blame 을 통해서 Parser 클래스 소스구현 라인중에 최초 commit 을 찾아보자. # git blame node_http_parser.cc;

61 4.1 Node.js 소스 Git 으로 살펴보기 미션 2 : node.cc 파일이 탄생한 진짜 최초 Commit 을 찾아내라. 1) node.cc 가 있는 해당 경로로 이동하자. # cd node/src/; 2) git log 을 통해서 node.cc 파일이 생성된 최초 commit 을 찾아보자. # git log --reverse -- node.cc; node_http_parser.cc; 3) 만약 최초 생성 commit 이 아니라 단순 경로 이동이라면 그 commit ID 를 바로 직전 commit 의 시점으로 돌아가보자. # git reset --hard <commit ID>~1 4) src/ 폴더아래가 아닌 node/ 아래로 이동해서 다시한번 log reverse 로 추적. # git log --reverse -- node.cc; node_http_parser.cc;

62 4.1 Node.js 소스 Git 으로 살펴보기 미션 3 : node 프로젝트 자체가 처음 만들어질때 최초부터 Commit 3 개 찾아내라. 1) rev-list 명령을 통한 최초 commit 찾기 # git rev-list --max-parents=0 HEAD 2) 최초 commit 을 확인해보자. # git show <commit ID> 3) 최초부터 3 개까지 commit 을 찾고 show 를 통해서 살펴보자. # git rev-list HEAD tail -3; git show <commit ID>

63 4.2 Submodule 이란 프로젝트를 수행하다 보면 다른 프로젝트를 함께 사용해야 하는 경우가 종종 있다. Git 저장소 안에 다른 Git 저장소가 들어갈 수 있다는것이 서브모듈이다.

64 4.2 Submodule 간단한 첫번째 실습 1) 임의 프로젝트 생성 후 해당 경로로 이동 # mkdir submodule_test; cd submodule_test; 2) Git 초기화 및 한개 commit 생성 # git init; touch test; git add test; git commit -m first 3) 서브모듈 추가하기 # git submodule add 4) 추가한 모듈에 대해서 확인해보자 # cat.gitmodules

65 4.2 Submodule 간단한 두번째 실습 1) 서브모듈을 포함하는 프로젝트 clone 하기 # git clone 2) 포함된 서브모듈정보를 확인해본다 # cat.gitmodules 3) 원래 포함해야하는 서브모듈에 대한 초기화 # git submodule init 4) 비어있던 서브모듈 소스 받아오기 ( 업데이트 ) # git submodule update

66 4.3 Stash 간단한 실습 Stash 란 add 하지 않은 변경사항 임시저장 해두는 기능 taeung ~/git/linux-perf/tools/perf :> git status On branch perf/config/default-value-v6 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: modified: util/config.c util/config.h no changes added to commit (use "git add" and/or "git commit -a")

67 4.3 Stash 간단한 실습 1) 하나의 프로젝트를 clone 해서 내려받아서 # git clone 2) README.md 파일을 임의로 수정해보고 stash 로 임시저장하자. # cd git-training; vi README.md; git stash 3) 현재 임시저장된 사항에 대한 리스트를 확인한다 # git stash list 4) 특정 stash 기록을 적용한다 # git stash apply stash@{0} 5) 특정 stash 기록을 삭제한다 # git stash drop stash@{0}

68 Thank You References l Namhyung Kim - Advanced Git Usasge (Git internals and useful tips) Scott Chacon, Ben Straub - Pro Git chapter 10.

github_introduction.key

github_introduction.key 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 &