[Medium] 내가 원했던, Git 가이드 (2)

히스토리 조작

---

히스토리 조작에는 몇 가지 강력한 명령이 포함됩니다. Rebase는 커밋 기록을 재작성하고, Squashing은 여러 커밋을 하나로 결합하며, Cherry-picking은 특정 커밋만 선택합니다.

Rebasing 과 Merging

---

Rebasing을 Merging과 비교하는 것은 의미가 있습니다. 두 명령의 목표는 같지만 이를 달성하는 방법이 다릅니다. 중요한 차이점은 Rebasing이 프로젝트의 히스토리를 재작성한다는 것입니다. 깔끔하고 이해하기 쉬운 프로젝트 히스토리를 중요시하는 프로젝트에 적합합니다. 반면, Merging은 새로운 병합 커밋을 생성하여 두 브랜치의 히스토리를 유지합니다.

 

Rebase를 수행하는 동안, 기능 브랜치의 커밋 기록은 메인 브랜치의 HEAD로 이동하면서 재구성됩니다.

여기서 워크플로우는 비교적 간단합니다.

 

Rebase할 브랜치에 있는지 확인하고 원격 저장소에서 최신 변경 사항을 가져옵니다:

git checkout your_branch
git fetch

 

Rebase할 브랜치를 선택한 후 다음 명령을 실행합니다:

git rebase upstream_branch

 

 

 

Rebase 후 이미 원격 저장소에 푸시된 브랜치라면 변경 사항을 강제로 푸시해야 할 수 있습니다:

git push origin your_branch --force

Squashing

---

Git Squashing은 여러 커밋을 하나의 통합된 커밋으로 압축하는 데 사용됩니다.

Cherry-picking

---

Cherry-picking은 특정 브랜치의 변경 사항을 선택적으로 다른 브랜치에 통합할 때 유용합니다. 전체 브랜치를 병합하는 것이 바람직하지 않거나 불가능한 경우에 특히 유용합니다. 그러나 Cherry-picking을 신중하게 사용해야 하며, 잘못 사용할 경우 중복된 커밋과 분기된 히스토리를 초래할 수 있습니다.

 

먼저 git log를 사용해 선택하려는 커밋의 해시를 식별해야 합니다. 커밋 해시를 식별한 후 다음 명령을 실행합니다:

git checkout target_branch
git cherry-pick <commit-hash> # 여러 커밋이 필요한 경우 여러 번 실행
git push origin target_branch

 

 

 

Signing commits

---

Signing commits는 Git에서 커밋의 진위와 무결성을 검증하는 방법입니다. GNU Privacy Guard(GPG) 키를 사용해 커밋에 암호화 서명을 추가함으로써, 커밋 작성자가 본인임을 보장할 수 있습니다. GPG 키를 생성하고 Git이 커밋할 때 이 키를 사용하도록 설정할 수 있습니다. 다음은 단계별 가이드입니다:

# GPG 키 생성
gpg --gen-key
# Git에 GPG 키 설정
git config --global user.signingkey <your-gpg-key-id>
# GitHub 계정에 공개 키 추가
# -S 플래그로 커밋 서명
git commit -S -m "Your commit message"
# 서명된 커밋 보기
git log --show-signature

 

 

Git Reflog

---

Git references에 대해 살펴보지 않았던 주제가 있는데, 이는 주로 커밋, 태그, 브랜치 등 저장소 내 여러 객체를 가리키는 포인터입니다. Git references는 Git 히스토리의 명명된 지점으로, 사용자가 저장소의 타임라인을 탐색하고 프로젝트의 특정 스냅샷에 접근할 수 있게 합니다. Git references를 탐색하는 방법을 알고 있으면 유용하며, 이를 위해 git reflog를 사용할 수 있습니다. 다음과 같은 장점이 있습니다:

• 잃어버린 커밋 또는 브랜치 복구
• 디버깅 및 문제 해결
• 실수 취소

Interactive rebase

---

인터랙티브 리베이스는 커밋 히스토리를 대화형으로 재작성할 수 있는 강력한 Git 기능입니다. 커밋을 적용하기 전에 수정, 재정렬, 결합, 삭제할 수 있습니다.

Origin vs Upstream

---

origin은 로컬 Git 저장소와 연관된 기본 원격 저장소입니다. 저장소를 복제(clone)하면 해당 복제본이 기본적으로 origin 원격 저장소로 설정됩니다. 저장소를 포크(fork)했다면, 그 포크가 기본적으로 origin 저장소가 됩니다.

 

반면, upstream은 저장소가 포크된 원래 저장소를 가리킵니다.

 

포크된 저장소를 원래 프로젝트의 최신 변경 사항과 동기화하려면 upstream 저장소에서 변경 사항을 가져와(git fetch) 로컬 저장소에 병합(merge)하거나 리베이스(rebase)해야 합니다.

 

로컬 Git 저장소에 연결된 원격 저장소를 보려면 다음 명령을 실행하세요:

git remote -v

 

 

 

Conflicts

---

브랜치를 병합하거나 리베이스할 때 충돌이 발생해도 당황하지 마세요. 이는 저장소의 동일 파일 또는 여러 파일의 다른 버전 사이에 충돌하는 변경 사항이 있음을 의미하며, 대부분의 경우 쉽게 해결할 수 있습니다.

 

 

Git 병합 충돌은 보통 영향을 받는 파일에 표시되며, Git은 <<<<<<<, =======, >>>>>>>와 같은 충돌 마커를 삽입하여 충돌 구간을 강조합니다. 유지할, 수정할, 또는 제거할 변경 사항을 결정하고, 결과 코드가 의미 있고 의도한 기능을 유지하는지 확인하세요.

 

충돌 파일에서 충돌 마커(<<<<<<<, =======, >>>>>>>)를 제거하고 코드의 조정을 완료한 후 만족스러운 경우 변경 사항을 저장합니다.

 

Feature Branch Workflow

---

 

각 새로운 기능이나 버그 수정은 별도의 브랜치에서 개발되고 완료된 후 메인 브랜치로 병합됩니다.

• 장점: 변경 사항의 격리 및 충돌 감소
• 단점: 복잡해질 수 있으며 철저한 브랜치 관리가 필요

Gitflow Workflow

---

Gitflow는 다양한 개발 작업을 위한 사전 정의된 브랜치를 포함하는 엄격한 브랜칭 모델을 정의합니다.

• 메인, 개발, 기능, 릴리스, 핫픽스 브랜치와 같은 장기 브랜치를 포함합니다.
• 장점: 정기 릴리스 및 장기 유지보수가 필요한 프로젝트에 적합
• 단점: 소규모 팀에는 너무 복잡할 수 있음

Forking Workflow

---

이 워크플로우에서는 각 개발자가 메인 저장소를 복제(clone)하지만, 변경 사항을 메인 저장소에 직접 푸시하는 대신 자신의 포크에 푸시합니다. 이후 메인 저장소로 변경 사항을 제안하는 풀 리퀘스트를 생성하여 병합 전에 코드 리뷰 및 협업이 이루어집니다.

• 이 워크플로우는 오픈 소스 Glasskube 저장소에서 협업하는 데 사용합니다.
• 장점: 외부 기여자의 협업을 장려하면서 메인 저장소에 대한 직접적인 쓰기 권한 부여를 방지
• 단점: 포크와 메인 저장소 간의 동기화 유지가 어려울 수 있음

Pull Request Workflow

---

포크 워크플로우와 유사하지만, 개발자가 메인 저장소에 직접 기능 브랜치를 생성합니다.

• 장점: 코드 리뷰, 협업, 팀원 간의 지식 공유 촉진
• 단점: 사람에 의존한 코드 리뷰로 인해 개발 과정에서 지연이 발생할 수 있음

Trunk-Based Development

---

빠른 반복 및 지속적 배포에 집중하는 팀이라면 메인 브랜치에서 직접 개발하고 작은 변경 사항을 자주 커밋하는 트렁크 기반 개발을 사용할 수 있습니다.

• 장점: 빠른 반복, 지속적 통합, 소규모 자주 변경을 프로덕션에 배포하는 데 집중
• 단점: 메인 브랜치의 안정성을 보장하기 위해 강력한 자동화 테스트 및 배포 파이프라인이 필요하며, 릴리스 일정이 엄격하거나 복잡한 기능 개발이 필요한 프로젝트에는 적합하지 않을 수 있음

 

Git Cheatsheet

---

 

 

 

# Clone a Repository
git clone <repository_url>

# Stage Changes for Commit
git add <file(s)>

# Commit Changes
git commit -m "Commit message"

# Push Changes to the Remote Repository
git push

# Force Push Changes (use with caution)
git push --force

# Reset Working Directory to Last Commit
git reset --hard

# Create a New Branch
git branch <branch_name>

# Switch to a Different Branch
git checkout <branch_name>

# Merge Changes from Another Branch
git merge <branch_name>

# Rebase Changes onto Another Branch (use with caution)
git rebase <base_branch>

# View Status of Working Directory
git status

# View Commit History
git log

# Undo Last Commit (use with caution)
git reset --soft HEAD^

# Discard Changes in Working Directory
git restore <file(s)>

# Retrieve Lost Commit References
git reflog

# Interactive Rebase to Rearrange Commits
git rebase --interactive HEAD~3

 

원문

• https://medium.com/@jake.page91/the-guide-to-git-i-never-had-a89048d4703a