전체 글

Git을 사용하다 보면 한 프로젝트에서 여러 개의 저장소를 함께 관리해야 하는 상황이 생긴다.예를 들어, 대규모 프로젝트, MSA(Microservices Architecture), 서드파티 라이브러리 직접 관리 등이 해당된다.이때, 여러 저장소를 하나의 프로젝트에서 깔끔하게 유지할 수 있도록 도와주는 기능이 바로 Git Submodule이다. 하지만 막상 사용해보려 하면 Git Submodule이 정말 필요한가? 라는 고민이 들 수 있다.Subtree, 패키지 매니저(npm, pip, maven) 같은 대안도 있기 때문이다.🤔 이 글에서는 Git Submodule이 무엇인지, 언제 사용해야 하는지, 그리고 실제로 어떻게 활용하는지 알아본다. Git Submodule vs Git Subtree vs 패..

📌 Fork 기반 협업에서 Merge Conflict, 피할 수 없다면 빠르게 해결하자! Git을 이용한 협업에서 Fork된 레포와 메인 레포를 동기화할 때 Merge Conflict가 발생하는 것은 흔한 일이다.하지만 빠르고 효율적인 해결 방법을 익히면, 개발 생산성을 크게 향상시킬 수 있다. 오늘은 Fork한 레포를 메인 레포와 동기화하면서 발생한 Merge Conflict를 한 번에 해결하는 방법을 정리해보자. 🚀🛠 Merge Conflict 해결 과정 1️⃣ Fork된 레포 클론git clone https://github.com/my-github-id/my-forked-repo.git✅ 내 GitHub 계정의 Fork된 레포를 로컬로 복제 2️⃣ 작업할 브랜치로 전환git switch my-..

Git을 사용하다 보면 작업 중인 코드가 있는데 급하게 브랜치를 변경해야 하는 상황이 발생할 수 있다.이럴 때 단순히 git checkout(또는 git switch)을 사용하면 작업 중이던 변경 사항이 사라질 위험이 있다. 또한, 아직 커밋하기 애매한 변경 사항을 임시로 저장하고 싶을 때도 있다.이럴 때 불필요한 커밋을 만들지 않고 변경 사항을 저장하는 방법이 바로 git stash다. 이번 글에서는 Git Stash를 활용하는 다양한 방법을 정리해보자.📌 Git Stash란? ✅ 작업 중인 변경 사항을 임시로 저장하고 나중에 다시 불러올 수 있는 기능✅ 브랜치를 변경하거나 다른 작업을 먼저 수행할 때 유용✅ 커밋을 남기지 않고 변경 사항을 보관할 수 있음 📌 Git Stash가 필요한 상황 예시 ..

Git을 사용하다 보면 변경 사항을 되돌려야 하는 상황이 자주 발생한다.하지만 Reset, Revert, Checkout, Restore 등 비슷해 보이는 여러 명령어가 있어,어떤 상황에서 어떤 명령어를 사용해야 하는지 혼란스러울 수 있다. 이번 글에서는 각 명령어의 차이점과 사용법을 정리하고,실제 협업 환경에서 안전하게 사용할 수 있는 방법을 살펴본다.🔹 Git에서 변경 사항을 되돌리는 4가지 방법 Git에서는 변경 사항을 되돌리는 방법이 크게 4가지가 있다.각각의 차이점을 아래 표로 정리했다.비교 항목Reset (git reset)Revert (git revert)Checkout (git checkout)Restore (git restore)목적커밋을 되돌리고 이력을 변경새로운 커밋을 만들어 변경 ..

🔹 GitHub PR 생성 시 리뷰어 자동 지정하는 법 🚀1️⃣ 매번 리뷰어를 직접 추가하는 것이 번거롭다면?GitHub에서 PR을 생성할 때 매번 리뷰어를 직접 추가하는 것이 귀찮거나 까먹는다면CODEOWNERS 기능을 활용하여 리뷰어를 자동으로 배정할 수 있다. “내가 작업한 파일에 대해 자동으로 코드 리뷰어를 지정할 수 있을까?”“매번 수동으로 리뷰어를 추가하는 과정이 번거로운데, 자동화하는 방법이 있을까?” ✅ 그 해답이 바로 GitHub의 CODEOWNERS 기능이다. 이 글에서는 CODEOWNERS 파일을 설정하여 PR 생성 시 리뷰어를 자동으로 추가하는 방법을 정리한다.2️⃣ CODEOWNERS란? GitHub의 CODEOWNERS 파일은 특정 디렉토리나 파일에 대해PR이 생성될 때 자동..

🔹 GitHub에서 리뷰어 요청하는 법과 효과적인 코드 리뷰 요청 가이드 🚀1️⃣ 리뷰어 요청이 중요한 이유GitHub에서 PR(Pull Request)을 생성한 후 코드 리뷰를 요청하는 것은 팀 협업의 필수 과정이다.리뷰어의 피드백을 통해 코드 품질을 개선하고, 버그를 사전에 방지할 수 있다. 그렇다면, 효과적으로 리뷰어를 요청하는 방법은 무엇일까?단순히 “리뷰 요청” 버튼을 누르는 것만으로 끝나는 것이 아니다.어떻게 요청하느냐에 따라 코드 리뷰의 질이 달라진다. 이 글에서는 GitHub에서 리뷰어를 요청하는 방법과, 효과적인 코드 리뷰 요청 가이드를 정리한다.2️⃣ GitHub에서 리뷰어 요청하는 방법(1) PR 생성 후 리뷰어 지정GitHub에서 PR을 생성한 후, 리뷰어를 직접 지정하는 방법이..

🔹 Rebase 중 발생하는 충돌 해결법Git을 사용하면서 Merge Conflict(병합 충돌)은 한 번쯤 겪어봤을 것이다.그러나 Git을 더욱 깔끔하게 사용하기 위해 Rebase를 진행하는 과정에서 충돌이 발생할 수도 있다. 💡 “Merge 충돌과 Rebase 충돌의 차이는 무엇일까?”💡 “Rebase 중 충돌이 발생하면 어떻게 해결해야 할까?” 이 글에서는 Rebase 중 충돌이 발생하는 이유와 이를 해결하는 방법을 단계별로 정리한다.1️⃣ Rebase란?git rebase는 한 브랜치의 기반(base)을 변경하여 최신 커밋 위로 재배치하는 과정이다.즉, 기존 브랜치의 커밋을 다른 브랜치의 최신 상태를 반영한 후 다시 적용하는 방식이다.🔹 Merge와 Rebase의 차이비교 항목MergeRe..

📌 Git Merge Conflict란? Git을 사용하여 협업을 진행하다 보면, Merge Conflict(병합 충돌)이 발생할 수 있다.이는 Git이 자동으로 병합할 수 없는 경우 발생하며,개발자가 직접 코드 충돌을 해결해야 한다.Merge Conflict는 언제 발생할까? 🤔 • 같은 파일의 같은 줄을 두 명 이상의 개발자가 수정했을 때 • 한 브랜치에서 삭제된 파일이, 다른 브랜치에서 수정된 경우 • Rebase 도중 동일한 파일의 변경 사항이 충돌한 경우 Git은 자동 병합이 불가능한 경우 개발자에게 충돌을 해결하라고 알린다.이제 Merge Conflict 해결 방법을 단계별로 살펴보자.🛠 Merge Conflict 해결 방법  1️⃣ 충돌이 발생한 파일 확인git status✅ 충돌이 발..

Fork된 레포와 메인 레포 동기화하는 법 GitHub에서 협업을 하다 보면, Fork한 레포를 메인 레포와 동기화해야 하는 상황이 자주 발생한다.Fork는 원본(메인) 레포의 복사본이지만, 메인 레포는 계속 업데이트되기 때문에 시간이 지나면 Fork한 레포와 차이가 발생할 수 있다.따라서, 최신 상태를 유지하기 위해 Fork된 레포를 메인 레포와 동기화하는 과정이 필요하다. 이 글에서는 Fork한 레포를 최신 상태로 유지하는 방법을 단계별로 정리한다.📌 Fork와 메인 레포의 관계 GitHub에서 Fork는 다른 사람의 레포를 내 계정으로 복사하는 과정이다.Fork한 레포는 원본 레포와 연결되어 있지 않으므로, 메인 레포에서 변경 사항이 발생해도 자동으로 반영되지 않는다.그렇다면, 어떻게 최신 상태로..

Git 브랜치는 독립적인 작업을 진행하고 협업을 효율적으로 관리하기 위해 사용하는 핵심적인 기능이다. 이번 글에서는 로컬 Git에서 브랜치를 생성하고 GitHub로 푸시하여 활용하는 과정을 설명한다.1. 브랜치란 무엇인가? 브랜치는 특정 작업을 독립적으로 진행할 수 있는 공간을 제공하며, 다음과 같은 이유로 활용된다: • 기능 개발 분리: 메인 브랜치에 영향을 주지 않고 새로운 기능을 개발할 수 있다. • 협업 용이성: 팀원들과 독립적으로 작업한 후 병합하여 효율적으로 협업할 수 있다. • 변경 이력 관리: 브랜치를 통해 변경 이력을 분리하여 관리할 수 있다.2. 로컬에서 브랜치 생성 및 이동하기 Git에서는 branch, checkout, switch 명령어를 사용하여 브랜치를 관리한다.switch 명..

Git의 탄생 이야기: 리누스 토발즈와 Git의 시작 Git은 현재 전 세계에서 가장 널리 사용되는 GOAT 버전 관리 도구이다. 하지만 이 강력한 도구가 어떻게 탄생했는지에 대한 이야기는 의외로 잘 알려져 있지 않다.이번 글에서는 Git의 탄생 배경, 리누스 토발즈가 설계한 Git의 철학, 그리고 독특한 이름의 유래를 살펴본다.1. Git을 만든 사람: 리누스 토발즈 Git은 리눅스 운영체제를 만든 리누스 토발즈(Linus Torvalds)에 의해 개발되었다.원래 리누스는 BitKeeper라는 버전 관리 도구를 사용해 리눅스 커널의 각 버전을 관리하고 있었다. 하지만 리눅스 커뮤니티와 BitKeeper 간의 갈등으로 인해 BitKeeper가 유료화되었다. 리누스는 대체 도구를 찾아봤지만 마음에 드는 도..

GitHub에서 PR(Pull Request)은 협업을 위한 가장 중요한 도구 중 하나다.PR은 코드 변경 사항을 팀원들에게 공유하고, 코드 리뷰를 요청하며, 안정적으로 병합(Merge)할 수 있도록 돕는다. 이번 글에서는 PR의 개념, 작성 방법, 그리고 PR 템플릿을 활용한 효율적인 협업 방법에 대해 알아보자.PR이란? PR은 변경 사항을 팀원들에게 공유하고, 코드 리뷰를 요청하며, 병합을 진행하는 과정이다. PR의 주요 목적: 1. 변경 사항 공유: 팀원들에게 작업 내용을 알린다.2. 코드 리뷰 요청: 변경 사항에 대한 피드백과 개선점을 논의한다.3. 안전한 병합: 문제를 사전에 발견하고, 안정적으로 병합한다.PR 작성 방법1. 브랜치 생성 및 작업git checkout -b feature-logi..