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
|
전반적으로 이 문서는 유형-이론을
바탕으로 쓰여졌습니다.
브랜치 부분을 꼭 두 번 이상 읽어보시길 권장합니다.
브랜치 부분을 다 읽어보신 후에 유형-테스트
부분을 두번이상 클리어 해보시길 권장합니다.
참고 사이트 - 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
