git 정리

git 기본 명령어

git init

• 폴더에서 위 명령어를 실행하면, 해당 폴더가 git 작업영역이 된다.
• init을 하면 폴더에서의 변경감지가 가능하다.

gid add

• 변경이 감지된 파일만 인덱스 영역(tree 목차)로 가지고 온다.
• 즉, tree구조 안에 해당 파일이 포함된다.
• 이때 tree는 폴더이고 변경감지된 파일(예.test1.txt)은 BLOB이다.

git commit

• 위 명령어를 실행하면 영구적으로 기록한다.
• 인덱스 영역에 있는 파일을 영구적으로 기록하고 싶으면 헤더영역에 넣어야 한다.
• 헤더 영역에서는 version으로 관리를 하고, 인덱스 영역에서의 트리구조가 헤더영역에서의 하나의 버전이 된다.

과정 정리
git init -> 작업영역 생성 완료! -> 변경감지 발생 -> git add -> 인덱스 영역(tree 목차)로 이동 -> 영구히 기록하자! -> git commit -> 헤더 영역으로 이동

관련 그림 자료

git Reset (되돌리기)

• git을 통해 파일들의 내용은 잘 commit했지만 commit한 메시지 내용(로그내용)을 바꾸고 싶을 수 있다. 이를 복구하는 명령어가 reset 명령어이다.

reset의 옵션

• soft, mixed, hard
• 사용 방법
  git log를 실행하면 commit 해시값 하고 커밋로그들이 보여진다. 이때 해시값을 이용하여 reset을 실행하면 된다. (이때, 해시값들이 꽤 긴데, 다 복사할 필요는 없고, 다른 commit 해시값들과 구분될 정도로만 값만 복사하면 된다.)

soft

• 헤더 영역에서만 해당 파일을 삭제
• header는 이전의 version을 가리킨다.
• 커밋로그 변경시 사용

-> 명령어 사용예시
이때, 1번째 commit을 하고 두번째 commit을 한 상태라고 가정하자. 그리고 두번째 커밋로그의 내용을 바꾸고 싶은 경우로 가정하자. (두번째 커밋의 해시값 : efla9e0e942715be3e....)
git reset --soft efla
- 이때 efla은 해시값중 일부이다.

git status
- 이 명령어를 실행하면 reset soft가 잘 실행된 것을 알 수 있다. status는 commit을 하기전인 add만 한 상태로 돌아간 것을 알 수 있다. git log로도 reset soft가 적용된 것을 잘 확인할 수 있다.

git commit -m "커밋 메시지"
-> reset soft를 실행하고, commit을 다시 해줘야 원하는 commit 로그 메시지로 바꿀 수 있다.

mixed

• 작업영역을 제외한 모든 영역(인덱스 영역, 헤더 영역)에서 삭제, 작업영역의 파일만 바뀌고 add하지 않은 상태
• 작업 영역의 내용 변경시 필요
• 잘 사용되지는 않는다.
  -> 명령어 사용예시
  이때, 1번째 commit을 하고 두번째 commit을 한 상태라고 가정하자. 그리고 두번째 파일의 내용을 바꾸고 싶은 경우로 가정하자. (두번째 커밋의 해시값 : efla9e0e942715be3e....)

git reset --mixed efla
- 이때 efla은 해시값중 일부이다.

git status
- 위 명령어로 확인하면 reft mixed가 잘 실행된 것을 알 수 있다.
- status는 add를 하기 전 상태로 돌아간 것을 알 수 있다.

hard

• 작업영역, 인덱스 영역, 헤더 영역에서 해당 파일을 완전 삭제
• test2.txt 를 만들기 이전인 test1.txt상태로 돌아가길 원할때 사용
• 한번 삭제하면 다시 복구할 수 없다. -> 신중한 사용이 요구됨
  -> 명령어 사용예시
  이때, 1번째 commit을 하고 두번째 commit을 한 상태라고 가정하자. 그리고 두번째 파일을 만들기 전으로 돌아가고 싶은 경우로 가정하자. (두번째 커밋의 해시값 : efla9e0e942715be3e....)

git reset --hard efla

• 이때 efla은 해시값중 일부이다.

git status
- 위 명령어로 확인하면 reft mixed가 잘 실행된 것을 알 수 있다.
- status는 2번째 파일이 만들어지기 전으로 돌아갔다는 것을 알 수 있다.

• hard가 가장 깔끔하고, 가장 많이 쓰이는 옵션이다.
• hard로 값을 잘못 날렸을떄 reflog로 복구할 수 있다.

git Reflog (git log에서 삭제한 내용을 복구)

• 그런데 log에 남아있지 않는 commit (해시값) 으로 돌아가야 할때는 어떻게 해야 할까?
  -> reflog를 사용하자.

• reflog : 백업에 대한 데이터들로, 한번이라도 커밋한 로그들의 정보가 들어있다.

git reflog

• 위 명령어를 실행하면 한번이라도 커밋한 로그들의 정보가 다 나온다. 이때 commit 해시값들도 나오는데 복구하고 싶은 해시값을 이용해 아래와 같은 reset hard 명령어로 이전 내용을 복구할 수 있다.

git reset --hard efla6h

• 이때 efla은 해시값이다.
• 이 명령어들로 이전내용을 복구할 수 있다.

git 최종 커밋 로그 변경하기

• 필요 상황: git log를 실행했을때 commit 로그가 한번밖에 없는 경우, reset soft 를 이용해 이전 commit 상태로 돌아가지 못한다. 즉, git reset soft 명령어를 사용하지 못한다. 대신 아래 명령어를 이용해서 commit 로그를 변경한다.

git commit --amend -m "바꾸고 싶은 커밋 로그 메시지"

• 가장 최근의 commit 메시지를 수정할 수 있다.
• 위 명령어를 실행하고, git status로 status를 확인하면 commit 로그가 변경된 것을 알 수 있다.

정리 (로그를 변경하고 싶은 경우)

1. git commit --amend -m "commit message"

2. git reset --soft 해시값
   git commit -m "commit message"

3. git rebase -i (HEAD ~3)

• 헤더의 로그들을 합치고 싶은 경우, 합치고 싶은 헤더의 version들을 -i 뒤에 적어준다. rebase는 branch들을 정리할때 주로 쓴다.

git branch

• three-way merge
• 형상이 다를때 사용
  
  

• fast-forward merge
• 형상이 같을때 사용
  
  

git branch 명령어

git branch

• 현재 존재하는 branch들을 조회

git branch 브랜치이름

• '브랜치이름'을 가진 새로운 branch 생성

git checkout 이동할브랜치이름

• '이동할브랜치이름'으로 branch 이동

git checkout -b 브랜치이름

• checkout을 하면서 '브랜치이름'을 가진 새로운 branch 생성

fast-forward merge

git checkout main
git merge 머지할브랜치이름(topic)
-> 위 두 명령어를 실행하면 fast-forward merge로 merge할 수 있다.

three-way merge

fast-forward merge는 두개의 branch만 생각해서 main에서 새로운 branch를 merge해주면 되는데 three-way merge에서 fast-forward merge와 같이 하면 main에서 새로 만든 내용이 그냥 날라가게 된다. 그래서 나뉜 브랜치에서 새로 추가된 것 2개와 이 2개의 공통조상인 것 1개를 이용해 three-way merge를 해야 한다.

git checkout main
git merge main이아닌브랜치이름(topic)
-> vi 에디터가 뜨는데 esc를 치고 :wq를 치고 종료한다.
-> 위 과정을 실행하면 three-way merge가 실행된다.

위 두개의 실행방법은 같다 ?? 과정만 다를뿐 같은 명령어로 다르게 실행이 될 수 있나 ??

merge 충돌해결

다른 branch에서 같은 파일을 수정하고 commit하면 merge 충돌이 발생할 수 있다. merge 충돌이 발생하면, 어떤 내용으로 최종 commit을 할건지 결정해야 한다.

파일 생성과 삭제

touch 파일이름

• '파일이름'을 가진 파일 생성

rm 파일이름

• '파일이름'을 가진 파일 삭제

git rebase (로그 관리)

rebase:
코드에 대한 로그를 깔끔하게 정리한다.

상황: 남긴 로그가 마음에 들지 않아 다시 수정하고 싶다.

squash
rebase를 하려면 squash의 개념을 알아야 한다. squash는 찌그러트린다는 의미이다. 찌그러트리는 방향은 최근에서 과거로 찌그러트려야 한다. 즉, 최근의 코드들을 예전의 코드로 모으는 것이다. 아래 그림에서 올바른 방향은 아래에서 위로 방향이다.
<관련 그림>

<rebase 명령어 실행 과정>

git rebase -i HEAD~찌그러트리고싶은개수

• 몇개를 rebase할 것인지 정하고 위 명령어를 실행한다.
  3개인 경우, git rebase -i HEAD~3와 같이 쓴다.

-> 위 명령어를 실행하면 vi에디터가 나온다.
i를 누르면 입력이 가능해지는데,pick으로 되어있는 최근 2개의 로그들을 s로 바꿔준다.

-> 위 내용들을 실행한 결과, 수정한 내용들은 그대로 유지하고 로그들만 삭제하는 것과 같다. 즉, 최근 2개의 수정내용들을 2개전의 로그에 합쳐준다고 할 수 있다.