코딩두의 포트폴리오

OSS - 07_Git 고급 본문

Open Source Software

OSS - 07_Git 고급

코딩두 2024. 4. 21. 17:34

Git 고급 명령어

git tag - 커밋을 참조하기 쉽도록 알기 쉬운 이름 붙임

git commit --amend - 같은 브랜치 상에 있는 최종 커밋을 취소하고 새로운 내용을 추가하거나 설명을 덧붙인 커밋을 가능

git revert - 이전에 작성한 커밋을 지움, 특정 커밋의 내용을 지우는 새로운 커밋을 만들어 지운 내역을 모든 사람이 알게끔

git reset - 어떤 커밋을 버리고 이전의 특정 버전으로 다시 되돌릴 때 사용, git revert와의 차이: 지운 커밋 내역 남기지 X

git rebase - git merge처럼 병합 시 사용, 브랜치가 많을 경우 브랜치 이력 확인하면서 병합

git rebase -i - 서로 다른 두 개의 커밋 내역 합침

Git tag: 특정 커밋을 참조하는 이름 붙이기

1. Light weight .태그: 간단하게 버전 이름만 태깅

2. Annotated 태그: 태그 작성자와 간단한 메모를 함께 태깅 가능

 

[Light weigth 태깅] 가장 최근 커밋에 태그 붙이기

 

태그가 붙어졌는지 확인하기: 가장 최근 커밋 1개에 대한 태그 정보 확인

 

현재 저장소에 있는 태그 리스트 확인하기

 

태그와 커밋 SHA-1 체크섬 값 같이 확인하기

 

특정 커밋에 태그 붙이기

커밋 SHA-1 체크섬 값을 알아야 함, 대략 체크셈 앞 4자리를 활용

 

Annotated 태깅의 예

 

 

특정 태그에 대해 누가 어떤 메시지를 입력했는지 확인

 

 

Git commit --amend

최종(가장 최근) 커밋을 대체하는 새로운 커밋 생성

(실습 1) 마지막 커밋과 커밋하지 않은 상태에 있는 변경 내역이 서로 합쳐진 새 커밋 생성

(실습 2) 변경 내역을 만들지 않는다면 커밋 메시지만 변경된 효과

 

(실습 1) hello.py 수정 후 커밋

 

(실습 1) hello.py 수정 후 커밋 - 커밋 수정시 checksum 값 계속 수정

 

Git revert

공개된 커밋의 변경 내역 되돌리기

 

사실은 실제로 되돌리는 것 X, 되돌리는 것 같은 효과를 내는 것

Git revert를 실행한 시점부터, 대상 커밋까지 변경 내역을 거꾸로 적용하여 새 커밋을 만드는 것

 

 

사실은 변경 내역을 거꾸로 적용하여 새 커밋을 생성한 것

이미 공개된 커밋 내역을 이러한 안전한 방법으로 되돌려야, 이후의 새로운 브랜치 생성, 병합 등 작업 가능

 

Git reset

이전 작업 결과를 저장한 상태로 되돌리기

Git revert는 이전 커밋을 남겨두는 명령이지만, git reset은 이전 커밋을 남기지 않고 새로운 커밋을 남김(차이점)

현재 커밋은 HEAD의 위치, 인덱스, 작업하는 저장소 디렉토리 등 선택할 수 있는 모드 지정 가능

< Git reset 명령 모드 >

 

Git reset 명령 옵션

 

Soft 모드 실습: 커밋만 되돌리기 위해 soft 모드를 사용함

  1. git log -5 명령으로 최근 다섯 개의 커밋 내역 확인
  2. git reset --soft HEAD~~~ 실행
  3. git log -3 실행하여 결과 확인
  4. cat hello.py로 파일 내용 확인
  5. git log -5 실행

 

Hard 모드 실습

 

Git checkout HEAD --filename

특정 파일을 최종 커밋 시점으로 되돌리기

 

HEAD 대신 SHA-1 체크섬 값 입력 시 해당 커밋 시점으로 돌아감

 

실습 - README.md 파일 수정

Gir reset 명령은 hard 모드가 아니라면 저장소 디렉토리의 파일 내용은 명령을 실행한 시점 그대로 남음

Git checkout 명령은 완전하게 대상 커밋의 시점으로 되돌림

Git reset 명령은 hard 모드를 실행한 것처럼 인덱스와 작업 전부를 되돌림

 

Git checkout vs Git reset (soft) 명령의 차이

 

Git rebase

브랜치 이력을 확인하면서 병합

커밋 내역 수정 가능, 이미 원격 저장소에 푸시가 끝난 커밋 내역을 수정하는 것을 권장하지는 X

로컬 저장소에 있는 커밋을 깔끔하게 정리해서 푸시하는 것이 좋음

일반적인 작업 흐름

3개 이상의 브랜치

 

Hotfix1 브랜치 병합

Hotfix2 브랜치 병합

Hotfix3 브랜치 병합

 

Master 브랜치와 hofix 브랜치 구조

git_merge 디렉토리 만들고 아래의 브랜치, 파일 생성

 

git_merge 디렉토리의 실습환경 완료 후 복사해 두기

각 브랜치의 코드를 master에 병합하면 커밋 그래프가 복잡해짐

 

rebase 사용하기

1. HEAD와 대상 브랜치의 공통 조상을 찾기 (C2)

2. 공통 조상 이후에 생성된 커밋들(C4, C5 커밋)을 대상 브랜치 뒤로 재배치


Git rebase 실습

master 브랜치, hotfix 브랜치 구조 재생성 - git_rebase 디렉토리 만들고 아래의 브랜치와 파일을 다시 생성

만약 git_merge를 미리 복사해 놓았으면 해당 디렉토리 사용

 

최종 커밋 그래프

 

Hotfix 1 브랜치 정리하기

Hotfix1 브랜치를 master 브랜치 앞으로 이동

  • git checkout hotfix1 실행
  • git rebase master 실행
  • 충돌 발생한 코드 수정 후,
  • git add "수정한 파일명" 실행
  • git rebase --continue 실행

 

충돌상태 해결하기 위한 git rebase의 3가지 옵션

git rebase --continue: 충돌 상태를 해결한 후 계속 작업을 진행할 수 있게 함

git rebase --skip: 병합 대상 브랜치의 내용으로 강제 병합을 실행, 여기서 명령을 실행하면 master 브랜치를 강제로 병합한 상태가 됨. 또한, 해당 브랜치에서는 다시 git rebase 명령을 실행할 수 X

git rebase --abort: git rebase 명령을 실행을 취소함, git rebase hotfix2 명령을 실행할 수 있음

 

 

현재 작업 중인 브랜치의 base를 master로 다시 설정하라는 의미

  • 첫 번째 gtr rebase 명령을 실행했을 때의 작업흐름 이동
  • master 뒤에 hotfix1 브랜치가 늘어선 모양이 됨

다음 작업으로, 병합해야만 비로소 master 브랜치에 hotfix1 브랜치가 반영됨

git checkout master 실행

git merge hotfix1 -no-ff 실행

 

Hotfix2, hotfix3 브랜치도 동일한 방법으로 git rebase 명령 실행

최종 커밋 그래프

 

Git rebase -i

커밋 내역 합하기

i는 interactive의 의미

 

실습 - Git_rebase 디렉토리의 가장 최근 커밋 내역 2개 합하기

코밋의 요약 정보와 어떤 접두어에 어떤 효과가 있는지 간단한 설명 표시

  • 남기는 커밋 메시지 앞에는 접두어로 pick 을 붙임
  • 없애는 커밋 메시지 앞에는 접두어로 fixup을 붙임
  • 커밋 SHA-1 체크셈 값은 꼭 남겨두어야 함
  • 기존의 커밋 메시지를 새롭게 수정할 수는 없음

 

'Open Source Software' 카테고리의 다른 글

OSS - 10_CoLab 사용하기  (0) 2024.05.11
OSS - 09_GitHub로 협업하기  (0) 2024.04.21
OSS - 05_원격 저장소와 GitHub & Git  (0) 2024.04.14
OSS - 04_Git 설치 & 기본  (0) 2024.04.13
OSS - 03_버전관리시스템과 Git  (0) 2024.04.07