상세 컨텐츠

본문 제목

La Piscine 2일차 - Git

카테고리 없음

by 테크투아트 2020. 7. 28. 13:21

본문

1. Introduction

 

Git 은 팀으로 버전 관리를 쉽게 할 수 있도록 도와준다.

 

 

 

 

A의 파일을 B와 C가 내려받아서 각각 수정을 했다.

그리고 B가 다시 A의 서버로 수정한 파일을 올리고, C도 뒤이어서 자신이 수정한 파일을 올렸다.

 

이런 식으로 협업을 할 경우, B의 수정 내용은 사라지고 C가 업로드한 파일만이 남는다.

이럴 때에는, C가 올리기 전에 A에 바뀐 내용이 있는지 확인해야한다.

이 경우, B가 수정 파일을 올렸으므로 C는 B의 업로드한 파일을 내려받아 그 파일에 자신의 코드 수정 내용을 일일이 적어 넣어야 한다.

 

이런 불편함을 해소해주는 것이 Git이다.

Git은 시간별(t, t+1, t+2 ...)로 스크린샷 찍듯이 코드를 찍어서 바뀐 부분을 비교하고 자기가 바뀐 부분을 적용시켜준다.

게다가 코드를 수정한 사람(커밋한 사람)과 수정 내용에 대한 history도 제공하기 때문에 언제든지 돌아가서 확인도 할 수 있다.

 

버전 만들기

 

 

working tree : 파일을 수정하는 곳

Staging Area : 버전을 만들 파일을 올리는 곳. working tree에서 수정한 파일 10개 중 2개만 버전으로 만들고 싶다면 2개만 Staging Area에 올린다.

Repository : .git폴더라고 봐도 된다. 즉, 만들어진 버전이 저장된다.

 

2. init, add, rm, commit, status, diff

 

 git init 

 

깃을 사용하고 싶은 폴더의 위치에서 git init 명령어를 입력하면 새로운 깃 저장소가 만들어집니다.

 

 

 

git init 명령어를 입력한 뒤 ls -a 를 쳐보면 .git 이라는 폴더가 생긴 것을 확인할 수 있습니다.

 

 

 

 

 

 

생성된 깃 폴더 안을 살펴보면 이런 것들이 들어있네요.

 

 

 git status 

 

현재 상태를 보여주는 명령어로, 가장 많이 쓰이는 명령어 중 하나입니다.

 

 

 

 

 

우리가 On branch master에 있다는 것을 알 수 있고, (On branch master)

아직 한 번도 commit한 적이 없다는 것을 알 수 있습니다.  (No commits yet)

 

그리고 Untracked files 가 있다는 것을 알려주네요.

마지막 줄에는 nothing added to commit 이라고 commit할 내용이 없다?는 문구가 나옵니다.

 

 

git add

Working tree에서 수정된 파일들 중 버전을 만들고 싶은 파일을 Staging Area로 올려주는 일입니다.

 

git add [폴더이름]

 

의 명령어를 치게 되면, 이제 그 폴더의 history를 깃이 tracked 하게 됩니다.

즉, 앞에서 말한대로 git add 시킨 파일들의 스크린샷을 계속 찍으면서 무엇이 바뀌었는지 커밋할 거리가 있는지 확인해주게 되는 것이죠.

 

 

 

 

 

On brach master, No commits yet 는 그대로 입니다.

그런데 그 다음줄에 보면, 이제 커밋할 수 있는 것들이 있다고 알려주고 있습니다.

이런게 깃의 편리한 점입니다~!

 

또한, git rm --cached <file>... 을 입력하면, 그 파일에 대해 깃은 다시 untracked 하게 됩니다!

 

git commit

git commit -m "commit message"

 

git commit -m을 입력한 뒤 메모할 커밋 메시지를 덧붙여 적어줍니다.

m은 message의 약자입니다.

 

 

 

 

깃 커밋을하고, git status를 해보면 nothing to commit, working tree clean이라는 메시지가 뜹니다.

 

 

그 후 git log 명령어로 기록을 확인해보면 누가 언제 무엇을 커밋했는지를 알 수 있습니다.

 

git log 옵션

git log --stat

git log -p

 

 git diff 

 

그럼 로컬저장소에서 파일을 살짝 수정해볼까요?

수정한 뒤,  git status로 확인해보면 무언가 바뀌었다는 것을 확인할 수 있습니다.

 

 

 

 

Changes not staged for commit : Staging Area로 올라가지 않은 변경사항들을 말합니다.

 

추천문구들을 보면

git add <file> ... 을 통해 변경사항들을 Staging Area로 올리던지,

git restore <file> ... 을 해서 바뀐 내용을 없던 일로 rollback 시키라고 합니다.

 

 

좀 더 구체적으로 git diff를 쳐보면 무엇이 어떻게 바뀌었는지를 확인할 수 있습니다.

 

 

 

 

원래는 파일에 Z가 써있었는데

제가 ZY로 내용을 고쳤는데 그 내용이 나오네요!

 

내용도 확인했다면 이제 바뀐 내용을 commit 시켜봅시다.

 

git add (Working Tree --> Staging Area)

git commit (Staging Area --> Repository) 

순으로 진행합니다.

 

 

 

확인은

git log

git status

등의 명령어로 하면 됩니다!

 

 

3. checkout, branch

branch는 가지를 뜻합니다.

프로젝트가 순차적으로 하나의 라인에서 수정되면 branch가 하나여도 괜찮지만,

용도에 따라 다르게 버전을 만들거나, 프로젝트가 여러부분으로 나누어져있어 각각의 부분을 따로 수정해야할 때

branch를 나누어서 작업합니다.

 

git branch 확인하기

 

 

-a 는 all을 뜻함.

현재는 master 하나의 branch가 있는것을 알 수 있다.

 

 

git branch 만들기

git branch [branch이름] 을 입력해서 새로운 branch를 생성한다.

 

 

 

 

git branch로 이동하기

git checkout [branch이름]

 

 

 

 

git checkout을 통해 pouet branch로 이동합니다.

그리고 git status를 확인해보면 On branch pouet이라고 branch를 이동한 것을 볼 수 있습니다.

그 후 git log를 살펴봅시다.

 

branch를 생성했을 때, 갈라진 branch는 master branch의 이력을 그대로 가져오는 것을 알 수 있습니다.

 

 

그런데 과거의 log에서부터 branch를 생성할 수도 있습니다.

 

git log의 log번호를

git checkout 뒤에 입력하면 그 log의 history로 상태가 이동합니다.

그 상태에서 git status를 하면 HEAD detached at 라고 메시지가 뜹니다.

가장 최근의 log가 아니라고 말해주는 겁니다.

 

 

 

 

거기서 바로 gir branch youpi를 써서 youpi라는 branch를 생성합니다.

그리고 git log를 확인하면 first commit만 log에 뜨는 것을 확인할 수 있습니다.

다시 git checkout master로 branch를 이동하여 git log를 확인해보면 원래대로 두 개의 log가 뜨는 것을 확인할 수 있습니다.

 

 

git branch 삭제하기

git branch -d [branch name] 명령어를 통해 git branch를 삭제할 수 있습니다.

 

 

 

 

branch 생성과 checkout을 동시에 하기

new라는 branch를 생성과 동시에 checkout 해봅니다.

 

 

 

 

 

checkout을 통해 last version으로 돌아가기

git checkout -- [파일이름]

modified된 파일을 원래대로 되돌릴 수 있다.

 

그런데, 이미 stage 된 파일은 다음과 같이 해야한다.

 

git reset HEAD [파일이름]

이 명령어를 수행하면 stage된 파일이 working tree로 내려간다.

 

 

 

4. merge, rebase

to update your local branch with another branch

 

 

rebase

터미널에 man git-rebase라고 치면 다음과 같은 그림으로 설명되어 있다.

 

 

 

 

위의 그림과 같이 파일이 commit 되어 왔고, 현재 branch가 topic 일때,

 

git rebase master 명령어를 치면

 

밑에 그림처럼 topic branch에 master의 가장 최신 branch까지를 합쳐줍니다.

 

이때, 같은 파일 같은 줄에 각각 다른 작업을 topic과 master에서 하게 되면 충돌이 일어납니다.

이럴 때는 직접 그 부분을 찾아서 무엇으로 수정할지 수정해주고

 

git rebase --continue로 rebase를 계속 진행하면 됩니다.

 

git log를 확인해보면

위의 두 번째 그림에서 A, B, C가 A', B', C' 가 되어 master 의 G commit 뒤로 합쳐졌기 때문에

원래 git log topic 에서의 A, B, C 와는 다른 id의 git log가 들어가있을 겁니다.

그러나 D, E, F, G는 기존의 git log id와 같습니다.

 

rebase 후에 branch는 계속 topic, master로 유지되며

topic의 git log는 5개(D, E, A, B, C)에서 7(D, E, F, G, A', B', C')개로 늘어나지만

master의 git log는 기존의 4개로 유지됩니다.

 

 

merge

 

 

 

 

merge 는 master branch에서 진행합니다.

git merge topic을 하면 topic이 master에 합쳐져서 새로운 merge commit을 만듭니다.

 

이때 topic의 git log는 D, E, A, B, C 로 계속 유지되고

master의 git log는 D, E, F, G, H로 바뀝니다.

 

 

5. stash

다른 브랜치로 checkout을 해야 하는데 아직 현재 브랜치에서 작업이 끝나지 않은 경우는 커밋을 하기가 애매합니다. 이런 경우 stash를 이용하면 작업중이던 파일을 임시로 저장해두고 현재 브랜치의 상태를 마지막 커밋의 상태로 초기화 할 수 있습니다. 그 후에 다른 브랜치로 이동하고 작업을 끝낸 후에 작업 중이던 브랜치로 복귀한 후에 이전에 작업하던 내용을 복원할 수 있습니다. (출처 : 생활코딩)

 

 git stash 

현재 branch에서 작업 중이던 내용이 stash list로 들어갑니다.

이 때 git status를 쳐보면 nothing to commit, working tree clean 이라고 작업 상태가 깨끗해진 것을 볼 수 있습니다.

이러면 다른 branch로의 이동이 자유로워집니다.

 

 

 

 

 git stash apply 

다른 branch에서 열심히 작업 후, 다시 그 branch로 돌아왔습니다.

stash list에 저장해놓았던 작업을 불러옵니다.

 

 

 

git stash 했을 때에는 깨끗했던 작업환경이 git stash apply 이후 다시 더러워진 것을(?) 볼 수 있습니다.

 

 

 git stash list 

 

git stash list 를 실행하면

git stash 했던 모든 작업들이 나옵니다.

 

 

 

이때, git stash list는 스택 형식으로 쌓여서 나중에 들어간 것이 먼저 나오는 형태입니다.

따라서 나중에 stash 된 것이 apply할때는 먼저 나오게 되는 것이죠.

 

스택

 

 

 git stash drop 

여기서 주의사항은 git stash apply를 해도 git stash list에는 계속 정보가 남아있다는 것입니다.

그래서 git stash apply 후에 git stash drop 을 해서 list 내의 stash 정보를 따로 지워줘야합니다.

 

 

 git stash pop 

git stash apply 와 git stash drop을 한 번에 처리할 수 있는 명령어 입니다.

 

 

 

6. push, fetch, pull

 push 

지금까지는 local 에서 혼자 작업할 때의 git 이었다면, 이제 remote server로 연결해보자.

 

remote server 중 가장 많이 쓰이는 것은 git!!!

github에서 계정을 생성하고 새로운 repository를 만듭시다.

 

만들면 거기 https주소와 ssh 주소가 있는데 차이점은 다음과 같다.

 

https : git config 명령을 통해 설정을 하면 username/password 입력이 필요없음

ssh : ssh public key를 등록하면 username/password 입력이 필요없음

 

나의 remote 주소와 local git을 연결하는 방법은 다음과 같다.

 

git remote add origin [https or ssh 주소]

 

여기서 git remote add까지는 동일하고 origin 부분에는 remote server의 이름을 지어주고 한 칸 띄고 주소를 적으면 된다.

 

그리고 만든 버전을 remote server로 push 하는 방법은 다음과 같다.

 

git push origin master

 

git push를 적고 remote server의 이름 적고 push할 branch 이름 적으면 된다.

 

 

 

git push 실행 화면

 

 

 

그 후 branch 를 확인하면 다음과 같이 Remote origin master branch 가 생성됩니다.

 

 

 

 

 clone 

 

프로젝트에 참여하거나 git 저장소를 복사하고 싶을 때 git clone 명령어를 사용한다. git clone 을 실행하면 프로젝트 히스토리를 전부 받아온다.

 

git clone <url> 명령으로 저장소를 Clone 한다. libgit2 라이브러리 소스코드를 Clone 하려면 아래과 같이 실행한다.

$ git clone https://github.com/libgit2/libgit2

 

 

 pull


pull 은 협업할 때 다른 사람이 올려놓은 commit을 나의 원격저장소로 내려받을 때 사용한다.

git pull

fetch


fetch는 다른 사람이 올려놓은 commit을 나의 원격저장소로 내려받지만, 나의 작업과 합치지는 않는다.

따라서 뒤에 merge를 따로 해주어야한다.

git pull 과의 관계는 다음과 같다.

git pull = git fetch; git merch origin/master
= git fetch; git merch FETCH_HEAD