TIL - 20250515

juni·2025년 5월 15일

TIL

목록 보기

8/317

1. Git Rebase

Git Rebase vs. Git Merge

Git Merge
Git Merge는 두 브랜치의 작업 내역을 하나의 새 커밋으로 합치는 방법입니다.

작동 방식:
- 현재 브랜치와 대상 브랜치의 공통 조상(commit)을 찾아 그 이후의 모든 커밋을 하나의 새로운 커밋으로 병합합니다.
- 기존 커밋 히스토리는 그대로 유지됩니다.
장점:
- 히스토리 보존: 모든 브랜치의 커밋 히스토리를 그대로 유지하므로, 누가 언제 어떤 작업을 했는지 명확하게 추적할 수 있습니다.
- 간단한 충돌 해결: 충돌이 발생하면 merge 커밋에서 이를 해결할 수 있습니다.
단점:
- 복잡한 히스토리: 다수의 브랜치가 병합될 경우, 커밋 히스토리가 복잡해질 수 있습니다.

Git Rebase
Git Rebase는 브랜치의 커밋을 다른 브랜치의 끝으로 옮기는 방법입니다.

작동 방식:
- 대상 브랜치의 최신 커밋 위로 현재 브랜치의 커밋을 재적용(reapply)합니다.
- 현재 브랜치의 커밋 히스토리를 다시 작성합니다.
장점:
- 선형 히스토리: 히스토리가 단순하고 직관적입니다. 한 줄로 이어진 커밋 히스토리는 분석과 디버깅이 용이합니다.
- 깊은 이해: 커밋 히스토리를 통해 개발 흐름을 명확하게 이해할 수 있습니다.
단점:
- 위험 요소: 공개된 브랜치에서 rebase를 사용하면 히스토리가 변경되어 다른 팀원들에게 혼란을 줄 수 있습니다.
- 복잡한 충돌 해결: 여러 커밋에서 발생한 충돌을 순차적으로 해결해야 할 수 있습니다.

Merge에 비해 Rebase의 장점

더 깨끗한 프로젝트 히스토리
리뷰와 디버깅 용이
공동 작업의 효율성

Rebase를 사용하면 안되는 상황

공개된 브랜치에서의 Rebase
협업 브랜치에서의 Rebase

2. Git Interactive Rebase (중요)

Interactive Rebase란?

정의: Git의 interactive rebase는 커밋 히스토리를 세밀하게 수정, 재정렬, 합치기, 삭제할 수 있는 강력한 도구입니다.
목적: 깔끔한 커밋 히스토리를 유지하거나, 불필요한 커밋을 정리하고자 할 때 사용됩니다.

기본 사용법

명령어 : git rebase -i <commit 또는 브랜치>
예시: 최근 5개의 커밋을 대상으로 사용할 때
```
git rebase -i HEAD~5
```
작동:
- 해당 명령어를 실행하면, 기본 텍스트 편집기가 열리고, 대상 커밋 리스트가 표시됩니다.
기본 명령어 설명:
- pick: 커밋을 그대로 유지
- reword: 커밋 메시지를 수정
- edit: 커밋 내용을 수정
- squash: 커밋을 이전 커밋과 합침 (메시지 병합 가능)
- fixup: 커밋을 이전 커밋과 합침 (메시지 무시)
- drop: 커밋을 삭제

결론 :

혹시 가장 최근 커밋의 메시지나 내용을 수정하실 때에는 interactive rebase를 사용하셔도 되지만 그냥 이전에 배운 git commit --amend 옵션을 사용하시는게 편리하겠죠.
이렇게 깃허브에 푸시하기 전이나 풀 리퀘스트 전에 커밋을 정리하는 습관을 들여보세요!!

3. Git Cherry-pick

다른 브랜치에 있는 커밋을 복사해서 다른 브랜치에 붙일 수 있음.

Cherry-Pick은 다음과 같은 상황에서 특히 유용합니다:

다른 브랜치에서 발견된 버그 수정을 현재 작업 중인 브랜치에도 적용하고 싶을 때
이전 버전에서 특정 기능만 현재 버전에 추가하고 싶을 때
여러 커밋 중에서 필요한 변경사항만 선택적으로 적용하고 싶을 때
다른 팀원이 작업한 특정 커밋만 내 브랜치에 적용하고 싶을 때

마치 친구들과 함께 여행 계획을 세울 때, 모든 일정을 그대로 따르기보다 나에게 맞는 활동만 골라서 내 일정에 넣는 것과 비슷합니다.

장점:

필요한 변경사항만 선택적으로 적용할 수 있어 유연함
다른 브랜치의 모든 내용을 병합하지 않고도 특정 변경사항만 가져올 수 있음
다양한 브랜치에서 작업된 코드를 통합하는 데 효과적

단점:

동일한 변경사항에 대해 서로 다른 커밋 해시가 생성되어 히스토리가 복잡해질 수 있음
여러 커밋을 Cherry-Pick하면 충돌이 발생할 가능성이 높아짐
팀 협업 시 커뮤니케이션 없이 사용하면 코드 중복이나 혼란을 초래할 수 있음

Cherry-Pick vs Merge vs Rebase

각 방식의 특징을 비교해보겠습니다:

Cherry-Pick:

특정 커밋만 선택적으로 적용
새로운 커밋 해시 생성
부분적인 변경사항 통합에 적합

Merge:

브랜치 전체를 통합
모든 커밋 히스토리 유지
병합 커밋 생성

Rebase:

커밋 히스토리를 깔끔하게 정리
선형적인 히스토리 생성
커밋 순서 재배열 가능

상황에 따라 적절한 방식을 선택하는 것이 중요합니다. Cherry-Pick은 특정 변경사항만 필요할 때, Merge는 전체 기능을 통합할 때, Rebase는 히스토리를 깔끔하게 유지하고 싶을 때 사용하면 좋습니다.

4. Git Tag

브랜치랑 똑같은데 v1.0버전처럼 숫자로 된 태그

Semantic Versioning (시맨틱 버저닝) = SemVer
구조 : MAJOR(주 버전) . MINOR(부 버전) . PATCH(수 버전)

annotated tag : 설명이 들어간 태그

tag는 브랜치를 push한다고 자동 푸시되지 않기에 명령어를 쳐줘야함
git push origin # 한 개의 태그 푸시
git push origin --tags # 전체 태그 모두 푸시

5. Git Alias

1. Git Alias란?

Git alias는 자주 사용하는 Git 명령어에 대해 짧고 기억하기 쉬운 별칭을 설정하는 기능입니다.

cd ~에서 .gitconfig를 code실행하여 공유가능

5. GitHub에 푸시된 민감한 파일을 완전히 삭제하기

git ignore을 통해 사전방지하기

교안참조

6. Git reflog

git reflog는 Git에서 로컬 저장소의 모든 참조(브랜치 이동, 커밋, 머지 등) 이력을 기록하고 보여주는 명령어입니다.

주요 기능 및 사용 상황

과거 커밋 복구: 만약 브랜치를 잘못 리셋하거나, 커밋을 실수로 삭제한 경우, git reflog를 사용하여 해당 커밋의 해시를 찾고 복구할 수 있습니다. 예를 들어, HEAD가 어느 커밋을 가리키고 있었는지 추적할 수 있습니다.
브랜치 위치 추적: 이전에 어떤 브랜치에 있었는지, 특정 브랜치가 어느 커밋을 가리키고 있었는지를 확인할 수 있습니다.
실수로 이동한 HEAD 복구: 잘못된 리베이스나 리셋으로 인해 HEAD가 예상치 못한 위치로 이동했다면, reflog를 통해 이전 위치를 확인하고 되돌릴 수 있습니다.
커밋 히스토리 확인: git log에 기록되지 않은(예: 재작성된 커밋) 최근 활동을 추적할 수 있습니다.

reflog의 한계
1. 지역적인 특성 : 로컬에서만 유효
2. 영구적이지 않음 : 자동삭제(90일), 제한된 유지 기간

결론

git reflog는 강력한 도구로, 로컬에서 발생한 모든 참조 변경 이력을 추적하고 복구하는 데 매우 유용합니다. 그러나 이 기록은 로컬에만 존재하며, 일정 기간 후 삭제되기 때문에, 중요한 작업을 영구적으로 보존하려면 주기적인 백업이나 적절한 브랜치 관리가 필요합니다. reflog의 특성을 이해하고 적절히 활용하면 Git에서 실수로 인한 데이터 손실을 방지하고 효과적으로 작업을 관리할 수 있습니다.