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

Rebasing 과 Merging Rebasing을 Merging과 비교하는 것은 의미가 있습니다. 두 명령의 목표는 같지만 이를 달성하는 방법이 다릅니다. 중요한 차이점은 Rebasing이 프로젝트의 히스토리를 재작성한다는 것입니다. 깔끔하고 이해하기 쉬운 프로젝트 히스토리를 중요시하는 프로젝트에 적합합니다. 반면, Merging은 새로운 병합 커밋을 생성하여 두 브랜치의 히스토리를 유지합니다.   Squashing Git Squashing은 여러 커밋을 하나의 통합된 커밋으로 압축하는 데 사용됩니다. Cherry-picking Cherry-picking은 특정 브랜치의 변경 사항을 선택적으로 다른 브랜치에 통합할 때 유용합니다. 전체 브랜치를 병합하는 것이 바람직하지 않거나 불가능한 경우에 특히 유용합니다. 그러나 Cherry-picking을 신중하게 사용해야 하며, 잘못 사용할 경우 중복된 커밋과 분기된 히스토리를 초래할 수 있습니다. Signing commits Signing commits는 Git에서 커밋의 진위와 무결성을 검증하는 방법입니다. GNU Privacy Guard(GPG) 키를 사용해 커밋에 암호화 서명을 추가함으로써, 커밋 작성자가 본인임을 보장할 수 있습니다. GPG 키를 생성하고 Git이 커밋할 때 이 키를 사용하도록 설정할 수 있습니다. Git Reflog 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)해야 합니다.   Conflicts 브랜치를 병합하거나 리베이스할 때 충돌이 발생해도 당황하지 마세요. 이는 저장소의 동일 파일 또는 여러 파일의 다른 버전 사이에 충돌하는 변경 사항이 있음을 의미하며, 대부분의 경우 쉽게 해결할 수 있습니다.   Feature Branch Workflow 각 새로운 기능이나 버그 수정은 별도의 브랜치에서 개발되고 완료된 후 메인 브랜치로 병합됩니다. * 장점: 변경 사항의 격리 및 충돌 감소 * 단점: 복잡해질 수 있으며 철저한 브랜치 관리가 필요 Gitflow Workflow Gitflow는 다양한 개발 작업을 위한 사전 정의된 브랜치를 포함하는 엄격한 브랜칭 모델을 정의합니다. * 메인, 개발, 기능, 릴리스, 핫픽스 브랜치와 같은 장기 브랜치를 포함합니다. * 장점: 정기 릴리스 및 장기 유지보수가 필요한 프로젝트에 적합 * 단점: 소규모 팀에는 너무 복잡할 수 있음 Forking Workflow 이 워크플로우에서는 각 개발자가 메인 저장소를 복제(clone)하지만, 변경 사항을 메인 저장소에 직접 푸시하는 대신 자신의 포크에 푸시합니다. 이후 메인 저장소로 변경 사항을 제안하는 풀 리퀘스트를 생성하여 병합 전에 코드 리뷰 및 협업이 이루어집니다. * 이 워크플로우는 오픈 소스 Glasskube 저장소에서 협업하는 데 사용합니다. * 장점: 외부 기여자의 협업을 장려하면서 메인 저장소에 대한 직접적인 쓰기 권한 부여를 방지 * 단점: 포크와 메인 저장소 간의 동기화 유지가 어려울 수 있음 Pull Request Workflow 포크 워크플로우와 유사하지만, 개발자가 메인 저장소에 직접 기능 브랜치를 생성합니다. * 장점: 코드 리뷰, 협업, 팀원 간의 지식 공유 촉진 * 단점: 사람에 의존한 코드 리뷰로 인해 개발 과정에서 지연이 발생할 수 있음 Trunk-Based Development 빠른 반복 및 지속적 배포에 집중하는 팀이라면 메인 브랜치에서 직접 개발하고 작은 변경 사항을 자주 커밋하는 트렁크 기반 개발을 사용할 수 있습니다. * 장점: 빠른 반복, 지속적 통합, 소규모 자주 변경을 프로덕션에 배포하는 데 집중 * 단점: 메인 브랜치의 안정성을 보장하기 위해 강력한 자동화 테스트 및 배포 파이프라인이 필요하며, 릴리스 일정이 엄격하거나 복잡한 기능 개발이 필요한 프로젝트에는 적합하지 않을 수 있음   Git Cheatsheet   # Clone a Repository git clone # Stage Changes for Commit git add # 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 # Switch to a Different Branch git checkout # Merge Changes from Another Branch git merge # Rebase Changes onto Another Branch (use with caution) git rebase # 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 # Retrieve Lost Commit References git reflog # Interactive Rebase to Rearrange Commits git rebase --interactive HEAD~3   번역: [https://ducktopia.tistory.com/134] 원문: