Presentation is loading. Please wait.

Presentation is loading. Please wait.

Git haecheon100@gmail.com.

Similar presentations


Presentation on theme: "Git haecheon100@gmail.com."— Presentation transcript:

1 git

2 목 차 1. git 이해, 설치 및 기초 2. 원격 저장소와 기존 directory

3 Git의 이해 분산 버전 관리 시스템 소스코드를 저장하는 저장소 여러 사람이 프로젝트를 진행할 시 소스코드에 관리를 도와줌
언제 어디서 변경 되었는지 확인 변경 사항에 대한 기록 남김

4 Git 설치 - linux CentOS $yum install git Fedora
$yum install curl-devel expat-devel gettext-devel openssl-devel zlib-devel $ yum install git-core Ubuntu $ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext libz-dev libssl-dev $apt-get install git

5 Git 설치 - window Download

6 Git 설치 - window

7 Git 설치 - window

8 Git 설치 - window

9 Git 설치 - window

10 Git 설치 - window

11 Git 설치 - window

12 Git 환경설정 Git을 설치하고 나면 Git의 사용 환경을 적절히 설정해 주어야 한다. 한 번만 설정하면 된다. 설정한 내용은 Git을 업그레이드해도 유지된다. 또한, 명령어로 언제든지 다시 바꿀 수 있다. Git은 ’git config’라는 도구로 설정 내용을 확인하고 변경할 수 있다. Git은 이 설정에 따라 동작한다. 이 설정 파일은 세 가지나 된다. 전역 설정 : 시스템의 모든 사용자와 모든 저장소에 적용되는 설정이다. git config --system 옵션으로 이 파일을 읽고 쓸 수 있다. Linux : /etc/gitconfig 파일: 시스템의 모든 사용자와 모든 저장소에 적용되는 설정이다. git config --system 옵션으로 이 파일을 읽고 쓸 수 있다. Windows : C:\Program Files (x86)\Git\etc\gitconfig 특정 사용자 : 특정 사용자에게만 적용되는 설정이다. git config --global 옵션으로 이 파일을 읽고 쓸 수 있다. Linux : ~/.gitconfig 파일 Windows : $HOME Directory(C:\Documents and Settings\$USER)에 있는 .gitconfig 파일 특정 저장소에만 적용 .git/config: 이 파일은 git Directory에 있고 특정 저장소(혹은 현재 작업 중인 프로젝트)에만 적용된다. 각 설정은 역순으로 우선시 된다. 그래서 .git/config가 /etc/gitconfig보다 우선한다.

13 Git 설정 Git은 분산 환경이므로 사용자의 구별이 필요함 Git의 출력 결과를 color로 표시하기 설정 확인하기

14 Unmodified/modified Files
Git 기초 Unmodified/modified Files Staged Files Committed Files Git은 commit이라는 단계 전 까지는 수정, 삭제 등 변경사항을 알지 못함 Working directory(작업 디렉터리)에서 작업을 하고 이를 staging area라는 영역으로 add하게 된다. 여러 번의 add후에 만들어진 stage files을 commit하게 되면 git directory에 반영 된다.

15 Git 기초 Git 저장소를 만드는 방법은 두 가지이다. 기존 자신의 프로젝트를 git 저장소로 만드는 방법
다른 서버에 있는 저장소를 clone하는 방법 우리의 목표는 2번이지만 git을 익히기 위해 1번 방법 먼저 연습을 해보자 My pc 저장소 기존 디렉터리 .git Server 저장소 My pc 저장소 clone, pull, fetch Server에서 clone한 디렉터리 .git 저장소 .git push

16 Git 기초 기존 프로젝트를 Git으로 관리하고 싶을 때 관리할 디렉터리에서 git init명령어 실행
ls –al 명령어를 입력하면 .git이 만들어지고 이는 저장소의 meta데이터를 갖고 있다. Clone 후 git status 명령 입력하면 아직 하나도 수정하지 않았다는 것을 말해준다

17 Git 기초 임의의 파일 생성한 뒤 git status 파일 추적하기
Untracked file에 속해 있는데 untracked 상태라는 것을 말하고 git은 아직 스냅샷(커밋)에 넣어지지 않는 파일이라고 본다. Tracked 상태가 되기 전엔 git은 절대 commit하지 않는다. 파일 추적하기 Changes to be committed는 파일이 staged 상태라는 것을 의미. 커밋하게 되면 git add를 실행한 시점의 파일이 커밋되어 저장소 히스토리에 남는다.

18 Git 기초 Commit 하기 다시 파일을 수정 해보자
-m 옵션과 함께 ‘commit message’입력하게 되면 add해서 staging영역에 있던 file을 commit 영역으로 보내어 git 저장소에 저장되게 된다 Commit message를 남김으로써 README file을 만들었다는 일종의 표시를 하는 것이다 다시 파일을 수정 해보자 git diff 명령을 통해 working 디렉터리에 있는 것과 staging area에 있는 것을 비교하고 아직 stage하는 않은 것을 보여준다. 커밋영역과 staging area를 비교하려면 git diff –cached한다.

19 Git 기초 git log 사용하기 git status를 입력해보면 REAME가 수정되었지만 아직 commit되지는 않은 모습
Commit과 함께 입력했던 commit message가 출력된다 수정했던 내용은 아직 commit하지 않았기에 git은 이를 알 수 없음.

20 Git 기초 다시 commit하고 git log 해보기 Commit message가 최신 순으로 출력된다.

21 Git 기초 기타 명령어 파일 지우기 파일 이름 변경하기 git rm 명령으로 staging area에서 삭제하게 된다.
지운 뒤 commit해야 한다. 파일 이름 변경하기 mv 명령을 하고 git rm을 통해 바꾸기 전의 파일을 지우고 이름이 바뀐 파일을 add한 것과 같다.

22 Git 기초 Branch Commit을 3번 했을 때 아래와 같은 모습이고, branch란 commit 사이를 이동할 수 있는 일종의 포인터이다. 기본적으로 git은 master 브렌치를 만든다. $git add README test.rb LICENSE ( 3개의 파일 있다고 가정 ) 가장 마지막 커밋을 가리키고 있음 commit 개체

23 Git 기초 브랜치 하나 만들어 보자 $git branch testing 새로 만든 브랜치도 마지막 커밋을 가리킴
지금 작업 중인 브랜치를 가리키는 HEAD라는 포인터가 존재 브랜치를 새로 만들었지만 git은 아직 master 브랜치를 가리킴

24 Git 기초 작업 브랜치 변경 어떤 update 후에 commit 한번 더 해본다 $git checkout testing
HEAD가 testing 브랜치를 가리킴 어떤 update 후에 commit 한번 더 해본다 $vim test.rb $git add test.rb $git commit –m ‘made a change’ master 브랜치는 그대로 있지만 testing 브랜치는 앞으로 이동한다

25 Git 기초 Master 브랜치로 되돌아가기 $git checkout master HEAD가 master로 이동
Working directory의 파일도 그 시점으로 되돌려 놓음 다시 새로 커밋을 하게되면 이전 작업들과 별개로 진행 됨 testing 브랜치에서 임시로 작업하고 원래 master 브랜치로 돌아와 하던 일을 할 수 있음

26 Git 기초 다시 파일을 수정하고 commit하면 두 작업이 서로 독립적으로 각 브랜치에 존재하는 모습을 확인할 수 있음
후에 필요에 따라 다시 merge하여 프로젝트를 하나로 합쳐 진행할 수도 있다

27 2. 원격 저장소와 기존 directory 진행 순서 사용자 등록 앞의 내용에서 진행 Server에서 로컬 저장소로 받아오기
Local에서 임의의 파일 원격 저장소에 push 연습하기 두 사람이 공통 git server사용 연습하기 기존 working directory를 추가 하기 기존 working directory 원격 저장소로 push하기 원격 저장소에 pushing한 기존 working directory pull하기

28 Server에서 저장소 받아오기 각자의 컴퓨터에서 git clone 명령을 통해 받아오기 확인하기
Ex) embedded 대신에 -> 자신의 Team name으로 입력한다. Password : 팀장 이름 Server ip : 보안상 메일을 통해 보냄 확인하기 .git 디렉터리를 생성하고 여기에 저장소 메타데이터를 모두 저장한다.

29 Local에서 원격 저장소에 push하기 git init하기
git clone을 통해 .git 디렉터리를 받아왔기에 git init명령이 필요 없다. Server에서 받은 디렉터리에 파일 추가 및 add, commit 파일 추가 git에게 알리는 두 단계 작업이 필요 서버에 push하기

30 Local에서 원격 저장소에 push하기 디렉터리 삭제 후 다시 clone 해보기 git remote 명령
Commit 했던 README가 적용되어 clone된 모습을 확인할 수 있음 git remote 명령 현재 프로젝트에 등록된 리모트 저장소를 확인 할 수 있다. ( defualt로 origin이라는 이름 ) -v 옵션을 주어 단축이름과 URL을 함께 볼 수 있다.

31 두 사용자가 공통git server이용 방금 전 내용까지 cheon이라는 이름의 사용자이었음
마찬가지로 user의 정보를 추가해줘야 함 ch_user라는 사용자가 같은 방법으로 git clone한다. ( $server는 기존 ip주소 ) 확인해보면 cheon 사용자가 서버에 push한 README파일을 가져온 모습

32 두 사람이 공통 git server사용 ch_user 사용자가 main.c를 만들고 이를 cheon 사용자가 내려받기
add하고 commit 하기

33 두 사람이 공통 git server사용 main.c를 추가한 것을 push 명령어로 서버의 저장소에 push할 수 있다
다시 cheon 사용자에서 이를 받아오기

34 두 사람이 공통 git server사용 확인 Cheon 사용자가 main.c file을 받아 온 모습
git log 명령어 – 내용을 살펴보면 ch_user_name, 갖는 사용자가 Commit message : make main.c를 통해 main.c를 생성했음을 나타낸다.

35 기존 working directory를 추가하기
cheon 사용자가 기존 working directory를 갖고 있다고 가정 모든 파일을 원격 저장소에서 받아온 directory에 복사 어떤 파일은 git에 추가할 필요가 없을 수도 있다. vi .gitignore파일을 열어 무시할 파일 패턴을 적는다

36 기존 working directory 원격 저장소로 push하기
복사한 파일을 git add *.c를 통해 staging 영역으로 보내기 여러 번의 add가 있을 수 있고, 그 후 commit한다 다시 원격 저장소에 push한다

37 원격 저장소에 pushing한 기존 working directory pull하기
ch_user사용자에서 git pull를 통해 원격 저장소에서 새로 내려 받는다. cheon 사용자에서 올린 기존 파일들을 ch_user사용자가 내려 받은 모습

38


Download ppt "Git haecheon100@gmail.com."

Similar presentations


Ads by Google