[소마 강의] git 초급

 

[1] 깃이 뭔가요?

버전 관리 시스템 ( vcs ) : 누가 언제 무엇을 어떻게 수정했는지 확인 가능.

분산형 버전 관리 시스템 = 깃.

snapshot : 현재 상태 그대로 저장. 깃의 핵심. delta값을 저장하는게 아닌 전체파일 그대로 저장. (snapshot). commit남기는 그 순간에 snapshot을 찍음.

[2] 사용 : mac기준.

자. 깃을 사용하려면 깃을 깔아야겠지? 
http://git-scm.com/downloads

Git - Downloads

git --version으로 확인하자.

 

바탕화면에 git_class를 만들었다. working tree.

터미널로 git_class로 cd해서 git init 명령어 입력. git init은 딱 한번만. 최상노드에서 딱 한번만. 다른곳에서 하면 충돌남 ㅡ.ㅡ

git init을 해주면 staging Area와 Histroy가 생긴다. ls -al로 확인해보자. .git 파일이 생겼으면 성공이다.

 

working Tree에 foo1이라는 파일을 생성해보자. 여기서 working Tree라는건 그냥 작업중인 내용이다. 쉽게 생각하면 댐.

vi foo1
명령어로 편집기를 연 다음 my new file!이라고 작성한 후 :wq로 나오자.

이렇게 해보고 git status명령어 쳐보자. 이러면 Untracked file어쩌구~~ 한다. 새로운 파일이 생성되었고, 추적할건지 여부를 결정해야한다.

추적하려면 git add foo1 명령어 입력. 후에 다시 git status 쳐보면 초록글씨가 나온다. stage에 파일을 올린것이다.
add를 통해서 commit하고싶은 파일들을 stage에 올리고, 다 정리 한 다음 commit으로 그 stage의 snapshot을 찍어서 올리면 되는 것이다. commit하기 위한 첫번째 단계. commit할 파일은 stage에 무조건 올라와 있어야 함.

git commit명령어를 쳐보자.

새롭게 바뀐 파일들이 왜 바뀌어야 하는지 이유를 첫번째 줄에 입력해주고(add new file _ foo1) :wq로 나오면 commit 완료, git log를 이용해서 되었는지 확인 가능하다. 커밋마다 서로 다른 해쉬값을 갖고있기 때문에 이 값으로 버전을 옮기거나 수정할 수 있다.
git log -p명령어로 상세하게 볼 수 있다.

git log

자 이제 foo1 파일을 조금 수정해보자. 마지막 줄에 practicing... 이라고 추가해봤다. 

vi foo1 후 내용 수정

이제 git status로 수정사항을 확인해보자.

git status  빨간 글씨로 아직 스테이지에 올라가 있지 않다고 명시되어있는 것을 확인할 수 있다.

아직 스테이지에 올라가지 않은 파일이 있다고 한다. 이 파일의 수정된 사항을 보고싶으면 git diff명령어를 사용한다. 언제, 어떤 부분이 삭제 되고 추가 되었는지 확인 가능하다. 작업 내역을 처음으로 되돌리고 싶다면? git checkout -- foo1명령어로 되돌리자. 명령어를 치고 git status를 확인하면 working tree가 clean하다는 것을 볼 수 있다. vi foo1로 foo1파일을 확인하면 맨 처음에 썼던 my new file!만 남아있는 것을 확인할 수 있다.

git checkout -- foo1로 되돌린 다음 git status 출력한 내용.

foo1파일을 다시 한번 수정해보자. 마지막줄에 Interesting git!을 추가하고 :wq로 나오자.

vi foo1 후 마지막 줄에 추가.

git diff로 뭐가 달라졌는지를 보자.

git diff로 수정사항을 확인할 수 있다.

 수정사항이 마음에 들면 git add foo1해보자.

초록색 글씨로 바뀌었다. 커밋할 준비가 완료되었다는 것을 뜻한다.

와! 근데 stage에 올려놨는데 갑자기 마음에 안든다. 그럼 add 해놓은것을 다시 롤백하고 싶은 것이다.

우선 git diff --staged로 내 로컬과 stage의 차이를 한번 보자. add로 stage에 올라가 있으니 git diff로 하면 보이지 않고 git diff --staged로 봐야한다.

git diff로는 보이지 않고, git diff --staged로는 보인다.

이 사항을 되돌리고 싶으면 (stage에 올린걸 롤백하고 싶으면) git reset HEAD foo1 해주자.
reset HEAD를 해주면 처음상태가 아닌 수정한 내역이 남아있는 상황으로, 대신 stage에서는 내린 상태가 된다.
(*HEAD는 조금 있다가 branch할 때 다시 설명)

수정중인 상태, 즉 add하기 직전의 상태로 되돌려준다. git diff로 확인 가능하다.

여기서 정리 : 작업하던걸 처음으로(수정 전으로) 되돌리고 싶으면 git checkout -- <filename>, stage에 올린걸 되돌리고 싶으면 git reset HEAD <filename>.

자 그럼 git reset HEAD foo1까지 해봤으면 다시 git status해보자.

빨간 글씨가 다시 살아났다!

다시 빨간글씨로 수정된 사항이 남아있는 것을 볼 수 있다. add하기 바로 직전으로 돌아간 것이다. vi foo1로 확인해봐도 Interesting git!은 그대로 남아있다.

vi foo1로 Interesting git!을 Interesting!!으로 수정한 후 저장한다.

vi foo1 내용 수정

git add foo1로 stage에 추가 한 다음에
git commit -m "interesting" 으로 커밋해준다.

스테이지에 foo1을 올린 후 commit을 한다.

git log으로 확인한다.

아래서부터 보면 된다. 처음에 foo1파일을 만들었다는 커밋이 보이고 그 위에 방금 커밋한 메세지가 보인다.

여기서 정리:
foo1 파일 한개를 staging(스테이지에 올린다)할때는
git add foo1

수정된 모든 파일 staging
git add .

편집기에 들어가지 않고 "메세지"로 바로 커밋하기(자주 씀)
git commit -m "message"
(간단하게 오타수정, 함수이름 수정 이런것들같은 메세지 한줄짜리 커밋할때_)

수정된 모든 파일 staging, "메세지"로 한번에 커밋하기
git commit -a -m "message"

 

[3] 브랜치

브랜치는 뭘까 가지다 가지. 나뭇가지?!

우선 디폴트로 생성된 master 브랜치. master에서 직접 무언가를 하면 큰일날수도 있다.

그래서 브랜치를 따서 해당 브랜치에서 작업을 한 뒤에 확정이 나면 그때 master로 merge를 하면 된다.

일반적으로는 master로 merge는 프로젝트에 책임이 큰 사람 몇명만이 권한을 갖고 있다. 일반 개발자들은 merge request, 즉 병합 요청을 통해 master 브랜치로 병합 해달라고 요청하면 된다.

 

git branch로 깃 폴더(로컬)안에 있는 브랜치 목록을 확인할 수 있다.
*이 붙어 있는 게 지금 우리가 보고있는 브랜치이다.
현재는 * master만 되어있다.

브랜치 목록을 볼 수 있다.

git branch dev로 dev라는 이름의 브랜치를 생성해보자
git branch feature로 feature라는 이름의 브랜치를 생성해보자.

총 2개의 브랜치를 새로 만들었으니 git branch로 확인해보자.

브랜치 두개를 만들었다.

이렇게 되어있는 것을 확인할 수 있다. (두 개의 새로운 브랜치를 만들었고, 현재 내가 보고 있는 브랜치는 master브랜치다.)

 

git checkout dev로 dev브랜치에게 옮겨가보자. 이때 스테이지는 그대로 갖고간다.
(사실 git checkout -b dev를 사용하면 브랜치 생성과 동시에 옮겨갈 수 있다. ㅎ.ㅎ 담부턴 이렇게 하자.)

이때 git log를 하면 HEAD -> dev, master, feature이 추가된 것을 확인할 수 있다.. 여기서 HEAD는 쉽게 생각하면 자신이 작업중인 브랜치를 뜻한다. 같은 브랜치(동기화된 브랜치, 같은 내용을 갖고 있는 브랜치)는 묶어서 표시해준다.

dev 브랜치로 옮겼다. 이제 dev브랜치에서 작업할 수 있다.

슬슬 log 보는게 조금 난잡하다. 조금 축약해서 볼 수 있었으면 좋겠다. 
*중요 git log --all --decorate --online --graph 이걸로 축약한 git log를 볼 수 있다.
alias gloga="git log --all --decorate --oneline --graph" 명령어로 앞으로 gloga로 로그를 볼꺼다. 개꿀~

gloga를 한번 해보자.

아래서부터 읽으면 된다. 지금까지 어떻게 진행되고 있는지 한 눈에 알아볼 수 있다.
우선 add new file _ foo1은 아까 맨 처음에 했던 커밋이다.
그 위에 HEAD -> dev, master, feature은 살짝 무시해주고 interesting은 최근에 했던 커밋이다.

 

자 git status으로 지금 어디 브랜치에 있는지 확인하자.

On branch dev 라고 뜬다.
dev branch에 있는거니깐 여기서 vi foo1 하고 내용을 수정해보자(마지막 줄에 dev branch문장 하나 추가하고 저장.)

마지막 줄을 수정했다.

수정하고 git add foo1 해서 stage로 올리자.

커밋 함 해볼까? : git commit -m "add dev branch" 으로 메세지와 함께 커밋해보자.
gloga로 확인해보자. 커밋 되었다.

커밋 완료.

자 그럼 마스터브랜치로 옮겨가볼까?
git checkout master해보자. 여기서 foo1의 내용을 확인 해보면 허거덩! 수정이 안되어있다. ㅎㅎ 정상이다.

master 브랜치로 옮겼다. cat 명령어는 파일의 내용을 출력하는 명령어다.

gloga를 하면

add dev branch라는 커밋이 새로 생겼고, 그 앞에는 (dev)라고 브랜치를 명시해줬다.

HEAD가 master, feature로 이동되어있는 것을 확인할 수 있고 dev 브랜치는 따로 떨어져 나가서 add dev branch와 함께 커밋을 쌓았다는 것을 알 수 있다.

 

이제 merge를 해보자
헤드가 master로 되어있는거 확인하고 (git status, 또는 gloga로 확인)
git merge dev으로 dev브랜치에 있는 커밋을 master로 끌어온다.

자 그럼 foo1의 내용을 확인 해보자. 바뀌어있다. ㅎㅎㅎ

gloga하면

master 브랜치와 dev 브랜치를 merge(합병)했다.

이제 HEAD -> master, dev로 되어있다. HEAD는 master, dev를 가리키고 있고, 두 브랜치 master, dev가 싱크(동기화)되어있다는 뜻이다.

 

feature 브랜치에서도 수정해보자

git checkout feature 로 브랜치를 옮기자.

feature 브랜치로 옮겼다.

vi foo1 해서 feature branch라고 더 써준 담에 add 하고 커밋하자.
git add foo1
git commit -m "add feature branch"로 커밋하면 된다.

foo1의 내용을 바꾸고, 스테이지에 올린 후 커밋까지 한다.

자 이렇게 하고 다시 master브랜치로 이동하자. git checkout master 이동 후 gloga해보자.
이동 하지 않고 master브랜치에서 gloga를 하면 HEAD -> feature로 되어있을 것이다. 확인할때는 상관 없다.

브랜치를 옮기기 전과 옮긴 후의 gloga 차이.

지금 상태를 설명하자면, HEAD는 master, dev를 가리키고 있고, master, dev 브랜치들은 싱크가 되어있다.(merge완료)
feature브랜치는 아예 따로 떨어져서 다른 커밋을 한 상태다.(아직 merge 안됨)
git branch --merged 명령어로도 확인 가능. ( HEAD가 가리키고 있는 곳의 merge상태를 볼 수 있음)

우선 master과 dev는 싱크 완료되었으니 dev에 있는 모든 내용은 master에 있다는 것이다. 따라서 dev는 이제 필요가 없다.
dev branch를 삭제하자. => git branch -d dev   로 dev를 삭제하자.

dev 브랜치를 삭제했다.

정들었던 dev 브랜치가 사라지고 master브랜치만 남았다..ㅠㅠ

master 브랜치와 feature 브랜치의 작업내역을 합쳐볼까?
합쳐보기 전에 우선 현재 master브랜치에 있는지 확인 해주고 (checkout을 마스터로 해주고 (HEAD -> master이 되도록))
git merge feature 해볼까?

ㅋㅋㅋㅋconflict! 충돌이 일어났다.
git merge --abort로 병합(merge)취소 가능하다. 취소 해보자.

취소를 하면 merge하기 전 상태 그대로 돌아간다. 하지만 우린 연습단계이니 충돌을 일부러 내보자.

자 다시 git merge feature로 merge시도를 해보자. 역시 마찬가지로 충돌이 일어났다.
gloga를 해도 아까 그 상태 그대로이다.
이걸 어떻게 해결할 수 있을지 보자.

 

이번에는 abort를 하지 말고 그냥 충돌난 그 상태에서 foo1파일을 vi foo1로 살펴보자.

난 분명 수정한 적이 없는데 이상한 기호들이 추가되었다.

<<<<<<< HEAD

=======

>>>>>>> feature

이렇게 생긴 표시가 새로 생겨난 것을 볼 수 있다.

=======를 기준으로 위에 <<<<<<HEAD가 있고 >>>>>>>feature가 있다.
=======위는 원래 있던 내용 (마스터 브랜치에 있던 내용), 아래는 수정내용(feature 브랜치에 있던 내용)이라고 간단하게 생각하면 된다.
=, <, > 이런 기호는 그냥 표시일 뿐이니 충돌 해결 후에 표시들은 다 지워주자.
어떻게 병합할건지 수정하고 다시 병합하자.

기호들을 다 지워주고 마지막에 한 줄을 더 추가해봤다. 오타가 있네..?

위와 같이 수정 후 git add foo1로 스테이지에 올리고
git commit -m "sloved conflict" 해보자.

solved conflict 커밋을 추가했다.

지금 상태에서 gloga를 보면 어떻게 될까?

master 브랜치에서 커밋이 하나 추가되었다. feature 안의 내용은 아까 그대로다.

다시 git merge feature해보자.
이때는 Already up to date라는 메세지를 띄운다.
깔끔하게 합쳐지지는 않았지만 feature의 내용이 master안에 들어가 있다.

성공!

<참고>

브랜치 이름을 바꾸려면?
git branch -m <oldbranch> <newbranch>

브랜치 이름을 그룹으로 묶어보려면?(grouping)
group1/foo group2/foo
group1/bar group2/bar

 

[4] git remote

지금까지 한건 로컬에서만 한거다. 인터넷 연결하지 않아도 할 수 있는 것이다.
인터넷에 연결한 다음 원격으로 수정하고 싶으면 git remote를 사용해야한다.

 

gitlab을 사용해본다.

git lab이랑 연동할 때 아까 working tree, staging area, history가 생겼다고 했었는데 remote라는게 하나 더 생긴다.
remoted에 있는걸 history에 fetch 한 후 working tree에 merge하면 되는데 그냥 pull한방으로 working tree로 옮겨올 수 있다.
remote에 push할 때는 add, commit단계를 거친 다음에야 push를 할 수 있다.

 

gitlab에 로그인 한 후 new project 클릭
프로젝트 이름은 git_class_part1로.
public으로 설정 후 프로젝트 하나 생성완료.

Clone 클릭 후 clone with HTTPS의 링크를 복사해두자.

연결은 git remote add origin <url> // origin은 이름 변경 가능. 근데 왠만하면 origin으로 해주자.
여기 <url>부분에 복사한 링크를 붙여넣자.
git remote -v으로 확인

자 이제 연결"만" 했으니 push를 해봐야겠죠?

git push -u origin master로 push해주자.
아이디 패스워드 쳐주면 완료.

반대로 git에 있던 내용을 내 로컬로 불러들이는거는?
git pull origin master
쉽다.

web ide를 한번 둘러볼까? 수정 후 add, commit, push, pull 다 할 수 있다. 자동으로 브랜치 생성 후 올리는것도 가능하다.

 

remote list확인하고 싶으면
git remote -v

remote(ex. upstream)삭제
git remote remove upstream

remote branch 확인(로컬과 연결된 remote branch만 보여짐)
git branch -r

remote branch(ex. issue_1)삭제
git push origin --delete issue_1
git push origin :issu_1

 

clone이란? 누군가가 이미 만들어 놓은걸 내 workingtree로 옮길 수 있다.
git clone <url> 해주면 끝!

 

<참고>

git config --global alias.co checkout
git config --global alias.gs git status

.gitignore 파일에 git이 무시할 파일을 설정할 수 있다.

<미션>

markdown resume만들기(이력서)
TIL(Today I Learned) 정리
Learn Git Branching게임 정복하기.