Vamos ser Programador com Devfon

지옥에서 온 Git(3)

branch 만들기

• branch는 작업을 분기해서 처리하기 위한 명령어
• 브랜치의 목록을 볼 때

git branch

• 브랜치를 생성할 때

git branch "새로운 브랜치 이름"

# 새로운 브랜치를 생성하면 생성 시기에 속해 있던 브랜치의 상태를 그대로 복사해서 가져감

• 브랜치를 전환 할 때

git checkout "전환하고자 하는 브랜치 이름"

• 브랜치를 삭제할 때

git branch -d "삭제하고자 하는 브랜치 이름"

# 병합되지 않은 브랜치를 강제 삭제할 때
git branch -D "삭제하고자 하는 브랜치 이름"

• 브랜치를 생성하고 바로 전환하고자 할 때

git checkout -b "생성 및 전환할 브랜치 이름"

branch 정보 확인

• 브랜치 간에 비교할 때

git log "비교할 브랜치 A".."비교할 브랜치 B"

# 브랜치 A에는 없고 브랜치 B에는 있는 것들을 표기 

• 로그에 모든 브랜치와 브랜치 명을 표시

git log --all
or 
git log --branches

# --decorate는 기본 옵션으로, 브랜치 명을 표시하지 않기 위해서는 --no-decorate 옵션을 붙여주어야 함

• 로그에 나타는 모든 브랜치들을 그래프화 하고자 할 때

git log --all --graph

# --oneline 옵션을 추가해주어 더 간략하게 볼 수도 있음

• 브랜치 간의 현재 상태를 비교할 때

git diff "비교할 브랜치 A".."비교할 브랜치 B"

branch 병합

• A 브랜치로 B 브랜치를 병합할 때 (B -> A)

git checkout A
git merge B

• merge 이후에는 -d 옵션으로 브랜치의 삭제가 가능
  • 이미 모든 수정 정보를 얻었기 때문

branch와 merge

1. Fast-Forward: 별도의 commit을 생성하지 않고, master가 가리키는 commit을 바꾸는 방식
2. Recursive startegy: 같은 조상에서 분기된 브랜치 A가 조상 commit으로 부터 변화가 생겼으면 'Fast-Forward'방식을 사용할 수 없음. 따라서 별도의 commit을 생성하여 merge하게 됨

• cf. A가 가리키는 commit + B가 가리키는 commit + 공통의 조상 commit. 총 3개의 commit이 3-way Merge를 수행

branch 충돌 해결

• 같은 파일임에도 수정한 위치가 다르다면 자동으로 합쳐버림
  • 즉, 브랜치 A에서 소스코드 상단을. 브랜치 B에서 하단을 수정하여 Merge하게 되면 Auto-Merging이 가능
• 그러나, 수정한 위치가 같으면 충돌이 발생

• 충돌난 소스코드 부분을 사용자가 직접 수정하여 충돌의 해결이 가능

stash

• branch를 이용하여 작업을 하던 중 현재 branch에서 작업이 끝나지 않았는데 다른 branch로 checkout을 해야 하는 경우에 사용
  • commit을 해주지 않고 checkout을 할 경우 branch에서의 작업이 이동한 branch에 까지 영향을 미침. 그러나, 아직 작업 중인 것을 commit 하기에는 애매하기 때문
• git stash의 적용

• stash 해두었던 변경 사항 불러오기

git stash apply

• stash list에 있는 stash 기록은 사용자가 명시적으로 삭제하지 않는 한 계속 존재함
  • 즉, git reset --hard를 통해 stash가 적용된 상황으로 돌아가더라도 stash 해두었던 기록은 계속 남아있음
  • git stash list를 통해 stash 한 기록을 볼 수 있음
• git stash apply는 stash list 중 항상 가장 위에 있는 stash를 불러옴
  • 따라서, stash를 불러온 후 다음 stash를 불러오기 위해서는 이미 불러온 stash를 삭제해 주어야 함

git stash apply; git stash drop
or
git stash pop 

• stash는 최소한 버전 관리가 되고 있는 파일에 대해서만 적용이 가능함
  • 즉, add 되지 않은 파일에 대해서는 stash의 적용이 불가

지옥에서 온 Git (2)

git add의 원리

• 모든 file의 이름은 index에 담겨 있음

• 각각의 file 내용은 object에 담겨 있음
• Git에서는 file의 이름이 달라도 같은 내용을 담고 있는 경우, 같은 object를 참조(하단 설명 참고)

objects 파일명의 원리

• Git은 파일의 내용을 기반으로 object 파일의 이름을 생성
• 이는 중복 데이터를 저장하는데 매우 효율적으로 작동
  • 같은 내용을 가진 파일에 대한 object를 생성하지 않기 때문
• 파일의 내용 + additional information으로 이루어진 값을 "sha1"에 통과시키기 때문에 같은 내용을 지닌 파일은 결국 같은 object명 사용하게 됨

commit의 원리

• commit message 또한 object화 되어 생성됨

• commit message에는 현재 version이 참조하는 object들이 tree 형태로 담겨 있음(각각의 버전에 대한 Snap shot)

• 최초 commit 이후에는 parent commit을 제공하며, 이는 이전 version의 commit message를 참조

• local에서의 폴더 정보 역시 'tree' 자료형으로 저장됨
• 즉, object는 tree(directory), blob(file), commit(commit message) 중에 하나의 자료형을 가짐

status의 원리

• index 내 파일들과 local 파일들을 비교하여 add 필요 여부 판단
• index 내 파일들과 최신 commit message의 tree 내 파일들의 차이를 비교하여 commit 대기 상태 여부 판단

지옥에서 온 Git (1)

수업 소개

• git은 버전 관리를 위한 시스템이자 프로그램
• 우리는 report.doc, report_final.doc, report_final_real_final.doc과 같이 여러 개의 버전(네이밍)으로 이미 버전 관리를 경험한 적이 있음
• What is the Version Control System?
  • 여러 가지 역할과 의미를 가지고 있기 때문에 한 번에 이해하기는 힘듦
  • 가장 핵심은 고정된 파일의 이름으로 버전 관리가 가능하다는 것
  • 그 외에도 Backup, Recovery, Collaboration의 기능을 사용할 수 있도록 도와줌
• 여러 가지 버전 관리 시스템들이 존재
  • CVS - SVN - GIT 의 순서로 발전한 버전 관리 시스템
  • Dropbox, Google Drive 등도 버전 관리 시스템의 일종
• git은 많은 기능 때문에 복잡할 수 있음
  • 그러나 복잡한 프로젝트일수록 git의 도움으로 Complexity를 줄일 수 있음
  • 따라서 git을 아는 것은 실무 프로젝트의 복잡성을 줄여주는데 큰 도움이 됨

저장소 만들기

# 프로젝트 디렉토리 생성
mkdir git_devfon

# 프로젝트 디렉토리로 이동
cd git_devfon

# 현재 디렉토리를 git의 버전 저장소로 초기화
git init 

• .git 디렉토리에 버전 관리 정보가 저장되기 때문에 중요한 디렉토리!

git이 관리할 대상으로 파일 등록

• git은 기본적으로 새로운 파일을 관리하지 않음
• 파일을 관리하기 위해서는 관리 대상으로 따로 등록을 해주어야 함
• 파일을 이렇게 선택적으로 관리하는 이유는 프로젝트를 진행함에 있어 주가 되는 파일과 임시 파일 등이 있기 때문
  • 임시 파일의 경우 굳이 버전 관리 해줄 필요가 없음

# 새로운 파일을 생성
vim test.txt

# git이 파일을 추적하도록 명령
git add test.txt

# 프로젝트 디렉토리의 상태를 확인
git status

버전 만들기 (commit)

# git 닉네임 설정
git config --global user.name "자신의 닉네임"

# git 이메일 설정
git config --global user.email "자신의 이메일"

# commit message 작성 in Vim
git commit

# log 확인으로 committer와 committer의 이메일, commit 날짜 확인 가능 
git log

• 닉네임과 이메일 설정은 최초 1번만 해주면 됨
• 파일 생성 및 수정 후, 버전 만들기 전 add를 재설정해주어야 함
  • add만 사용하면 선택적으로 파일에 대한 commit 수행 가능
  • add로 디렉토리를 추적시키면, 해당 디렉토리는 commit 대기 상태(stage area)가 됨
  • commit이 된 결과가 저장되는 곳이 repository
  • git commit -a 로 수정된 모든 파일에 대한 commit 수행할 수도 있음(add된 파일에 한해서만)
  • git commit -m 'message' 통해 vim editor 들어가지 않고 commit message 바로 전달 가능

변경사항 확인하기

• 버전 간 소스 코드의 차이점과 과거 내용을 알 수 있음
• 과거 버전으로 돌아갈 수 있음

# 버전 간의 코드 차이를 출력하고 싶을 때
git log -p

• 빨간색 네모는 version 4에서의 test3.txt
• 파란색 네모는 version 5에서의 test3.txt

# 버전 간 차이점을 비교할 때
git diff 'version id'..'version id2'

• 각각의 commit id는 중복되지 않는 고유한 것
• 버전 간 비교를 할 때 이전 버전에서 없었던 파일은 /dev/null 과 같이 표기됨

# git add 하기 전 자신의 수정 내용을 이전 버전의 것과 비교할 때
git diff 

• 모든 수정 파일들의 add 후에는 아무 것도 출력하지 않음
  • 새로운 파일의 생성 이후에는 비교값이 없으므로 작동 X

과거 버전으로 돌아가기

# 해당 버전 id로 돌아가는 명령어
git reset --hard "commit id"

• second commit 이후 정보들이 log에 나타나지 않는 것을 볼 수 있음
• --hard 옵션 외에도 --soft, --mixed 옵션 등이 있음
• git은 어떠한 정보도 잘 삭제하지 않음. 따라서 눈에는 해당 버전 id 이후의 log가 보이지 않지만, commit 내용은 사실 남아있음(차후 다시 공부)
• repository를 공유한 이후부터는 절대 reset 명령어를 사용하면 안 됨. 자신의 local에서 작성할 때 까지만 reset 명령어의 사용 가능

# 해당 버전 id의 commit을 취소한 내용으로 새로운 버전을 만드는 명령어
git revert "commit id"

• second commit에서 'test for github'를 'test for github2'으로 수정
• second commit을 revert한 결과 'test for github2'로 수정한 commit이 취소되고 다시 'test for github'으로 변경되어 저장되는 것을 확인 가능