Data Mastery: From Analysis to System De

git cherry-pick은 말 그대로 특정 커밋만 골라서 다른 브랜치에 적용하고 싶을 때 사용하는 명령어브랜치 전체를 합치는 merge나 rebase와 달리, **딱 필요한 커밋 하나(또는 여러 개)**만 선택적으로 가져올 수 있다는 게 핵심! 언제 쓰면 좋을까?다른 브랜치에 있는 특정 기능이나 버그 수정 커밋만 따로 가져오고 싶을 때긴급 패치가 필요한데, 개발 브랜치에서만 작업되어 있는 경우실수로 잘못된 브랜치에서 커밋했을 때 사용 방법 먼저 적용하고 싶은 커밋의 해시 확인git log --oneline 예: a1b2c3d Fix login buge4f5g6h Add new feature  cherry-pick 실행git cherry-pick a1b2c3d 해당 커밋만 현재 브랜치에 그대로 적용된다..

가끔 우리는 의도하지 않은 브랜치에서 작업을 시작하는 실수를 한다.예를 들어, main 브랜치에서 코딩을 시작했는데, 사실은 feature/login 브랜치에서 했어야 했다면?이럴 때 git stash를 활용하면, 작업 내용을 안전하게 임시 저장하고 다른 브랜치로 옮길 수 있다.그리고 원하지 않게 stash stack에 쌓이는 걸 방지하고 싶다면, drop을 곁들이면 깔끔하게 정리까지 가능하다.상황 예시현재 브랜치: main작업 내용 있음 (커밋 전 상태)원래 작업해야 할 브랜치: feature/loginStep-by-Step 1. 작업 내용 임시 저장 (stash)git stash 변경사항이 stash stack에 저장된다. 이때 작업 디렉토리는 깨끗한 상태로 돌아간다.  2. 원하는 브랜치로 이동gi..

Git을 쓰다 보면 이런 상황, 다들 한 번쯤 겪어봤을 거예요.“아직 작업 다 안 끝났는데… 다른 브랜치로 잠깐 이동해야 해!”“커밋하기엔 이른데, 코드는 날리고 싶지 않아…”이럴 때 등장하는 강력한 기능이 바로 **git stash**입니다. git stash란?stash는 현재 작업 중인 변경사항(커밋 안 된 것들)을 임시로 저장해두는 Git의 기능이에요.말 그대로 “작업 내용을 잠깐 보관하는 바구니”라고 생각하면 됩니다! 기본 사용법🔹 변경사항 임시 저장git stash tracked 파일의 변경사항만 저장됨워킹 디렉토리는 깨끗한 상태로 돌아감 🔹 저장한 작업 다시 꺼내기 git stash pop  가장 최근 stash 내용을 꺼내서 적용하고, stash에서 제거함git stash apply 적..

Git을 조금 써본 개발자라면 merge와 rebase라는 두 가지 병합 방식에 대해 들어봤을 거예요. 둘 다 브랜치를 통합하는 방법이지만, 커밋 히스토리의 결과는 완전히 다릅니다.이번 포스팅에서는 git rebase가 무엇인지, 언제 어떻게 써야 하는지를 쉽게 설명해드릴게요. Rebase란?rebase는 한 브랜치의 커밋들을 다른 브랜치의 최신 커밋 위로 다시 쌓는 것입니다.쉽게 말하면:“내가 작업한 커밋들을, 마치 최근 브랜치에서 막 시작한 것처럼 다시 재배열한다!”  예시로 이해하는 Rebase상황:main 브랜치와 feature 브랜치가 아래처럼 나뉘어 있다고 해볼게요.A---B---C (main) \ D---E (feature) 여기서 feature 브랜치를 m..

Git을 사용하다 보면 브랜치가 많아지고 병합(merge)이 자주 일어나면서, 커밋 히스토리를 파악하기가 어려워질 때가 있습니다. 이럴 때 유용하게 쓸 수 있는 Git의 숨겨진 꿀기능 중 하나가 바로 --graph 옵션입니다. --graph란?git log 명령어에 붙여 사용하는 옵션으로, 커밋의 흐름을 아스키(ASCII) 그래프로 시각화해서 보여줍니다. 브랜치 간의 병합, 분기 등을 한눈에 파악할 수 있어 히스토리를 분석할 때 매우 유용합니다. 사용법가장 기본적인 사용법은 다음과 같습니다:git log --graph 하지만 이렇게만 쓰면 커밋 메시지나 브랜치 정보가 생략되어 조금 불편할 수 있습니다. 보통은 다음과 같이 함께 사용하는 게 일반적이에요:git log --graph --oneline --a..

Git에서 실수로 커밋을 되돌렸을 때, 혹은 리셋을 진행했을 때 "내가 했던 작업들 다 사라진 거 아냐?" 하고 걱정한 적 있으신가요? 이럴 때 빛을 발하는 Git의 비밀병기가 있습니다. 바로 reflog입니다. Git reflog란?reflog는 HEAD가 지나간 모든 커밋 기록을 추적하는 로그입니다.우리가 브랜치를 옮기거나, reset, commit, merge, checkout 등의 작업을 할 때마다 HEAD가 어떤 커밋을 가리켰는지를 기록으로 남겨줍니다.쉽게 말해, Git 타임머신 같은 존재예요.실수로 git reset --hard를 했어도, 이전 커밋으로 돌아갈 수 있는 히스토리가 남아 있는 거죠! 예시 상황작업을 쭉 이어가며 여러 번 커밋실수로 git reset --hard로 예전 커밋으로 돌..

Git을 활용한 협업에서는 브랜치 관리뿐만 아니라 원격 저장소와의 동기화, 코드 변경 추적, 롤백 기능이 중요합니다.이번 글에서는 Git 협업에서 꼭 알아야 할 커맨드 3가지를 정리해보겠습니다. git fetch: 원격 저장소의 최신 변경 사항 가져오기 git fetch란?원격 저장소(remote)의 최신 변경 사항을 가져오기만 하는 명령어로컬 브랜치에는 영향을 주지 않음git pull과 다르게 병합(merge)까지 자동으로 진행되지 않음 사용 예시먼저 원격 저장소의 최신 커밋을 가져오려면 아래 명령어를 실행합니다.git fetch originorigin은 기본 원격 저장소 이름입니다.이 명령어를 실행하면 원격 저장소의 최신 상태가 로컬에 다운로드되지만, 직접 코드에는 반영되지 않습니다. git fetc..

Git을 사용하다 보면, 여러 브랜치를 활용하게 되고 결국 브랜치를 병합(merge)해야 하는 순간이 옵니다. 그런데 Git Merge를 하면 새로운 커밋이 항상 생성될까요? 아닙니다! 머지 방식에 따라 다릅니다.이번 글에서는 Fast-forward Merge와 3-way Merge의 차이점과 내부 동작 원리를 그림과 함께 설명하겠습니다.  기본 개념: Merge란?Git에서 **머지(Merge)**는 하나의 브랜치에서 다른 브랜치의 변경 사항을 가져와서 하나로 합치는 과정입니다.이를 통해 협업 중에 분리된 개발 흐름을 다시 하나로 합칠 수 있습니다.머지를 실행하면 보통 다음과 같은 과정이 진행됩니다:현재 브랜치에서 다른 브랜치의 커밋을 가져옴병합할 수 있으면 자동으로 병합충돌(Conflict)이 나면 ..

Git을 사용하다 보면 reset과 checkout을 자주 사용하게 됩니다. 하지만 이 두 개념을 헷갈리는 경우가 많습니다. 이번 글에서는 git reset과 git checkout의 동작 원리를 그림과 함께 쉽게 설명하겠습니다.  Git에서 HEAD와 브랜치의 관계Git에서 **브랜치(branch)**는 특정 커밋을 가리키는 포인터입니다. 그리고 HEAD는 보통 브랜치를 가리키며, 이를 통해 특정 커밋을 간접적으로 가리키는 구조입니다. 아래 그림처럼 HEAD는 보통 master 브랜치를 통해 최종 커밋을 가리킵니다.  git reset을 실행하면? 지금 4개의 커밋이 있고, HEAD는 master 브랜치를 통해 마지막 커밋(43kf)을 가리키고 있다고 가정해 봅시다.git reset 9033 이 명령어..

Git을 사용하다 보면 실수로 커밋을 잘못했거나, 특정 커밋으로 돌아가야 하는 경우가 생깁니다. 이럴 때 유용한 명령어가 git reset이죠. 하지만, git reset이 정확히 어떻게 동작하는지 헷갈릴 때가 많습니다. 이번 글에서는 git reset의 동작 원리를 그림과 함께 자세히 알아보겠습니다.  Git에서 HEAD와 브랜치는 어떻게 동작할까?우리는 이전에 **브랜치(branch)**는 특정 커밋을 가리키는 포인터이고, HEAD는 특정 브랜치를 가리키는 포인터라는 것을 배웠습니다. 즉, HEAD는 브랜치를 통해 커밋을 간접적으로 가리키고 있는 것이죠. 이를 이해하면 git reset이 왜 특정 커밋을 가리키도록 HEAD를 변경하는지 쉽게 알 수 있습니다.   git reset을 실행하면 HEAD는..