Git Cherrypick 사용법

Git Cherrypick 사용법

Git Chrrey Pick

다른 브랜치에 반영한 변경 사항을 현재 브랜치로 가지고 오는 것을 '체리 픽'이라고 합니다.

현재 A라는 기능을 branch-A라는 브랜치를 따서 작업 중 입니다. 이때 갑자기 버그 픽스를 해야 하는 태스크가 들어왔을 때 A라는 기능은 branch-A에 커밋한 후 main브랜치로 전환해서 작업중인 내용은 포함이 안되지만 버그 픽스한 수정사항만 반영 하기 위해 사용할 수 있습니다.

git으로도 충분히 모든 과정을 진행 할 수 있지만 파일 목록들과 변경사항을 확인하면서 Chrrey Pick을 하려면 GUI툴이 있는 것이 도움이 됩니다. 여기에서는 Sublime Merge를 사용합니다. 구매하지 않고도 날짜 제한 없이 모든 기능을 사용해볼 수 있습니다. 

Sublime Merge는 다음 링크를 통해 받을 수 있습니다.

Sublime Merge - Git client from the makers of Sublime Text

소스트리는 체리픽 기능이 있지만 파일 단위로는 되지 않고 브랜치 단위로만 되어서 조금 불편합니다.

과정

 

1.지금까지 작업내역 commit하기

a라는 기능을 작업하던 도중 작업이 끝나지 않은 상황에서 수정사항 b가 들어왔습니다. 먼저 commit을 해야 합니다.

다음은 Sublime Merge의 화면입니다. 왼쪽 브랜치 목록에서 NEO-2397-company-id-auto-insert 라는 브랜치에 지금까지 했던 작업 내용을 commit 합니다. 

commit한 브랜치

2.수정사항에 대한 브랜치 생성

main브랜치로 돌아와 branch-B를 딴 후 수정사항에 대한 작업을 합니다.

 

3.commit뒤에 main브랜치

작업이 끝나면 branch-B에 commit후 main브랜치에 머지 합니다. 머지를 했기 때문에 수정사항이 main브랜치에 반영이 되었고 앞에서 a기능을 작업하던 브랜치는 수정사항 앞에 있습니다.

여기에서 chrrey pic을 해서 main에 머지되지 않은 브랜치에 있는 수정사항을 현재 브랜치로 불러 올 수 있습니다.

다음은 앞에서 commit한 브랜치에서 UserServiceImpl.java에 수정한 내용을 Chrrey Pick하는 과정입니다.

main branch에서 NEO-2397-company-id-auto-insert 브랜치를 선택 합니다. 그러면 오른쪽에 브랜치 NEO-2397~의 변경 내역이 나옵니다.

체리픽 하고 싶은 파일명에 마우스 오른쪽 클릭을 한 후 Cherry Pick File을 선택 합니다.

 

4.체리픽된 변경사항 확인

main브랜치에 앞에서 Chrrey Pick한 변경사항이 들어와 있는 것을 볼 수 있습니다. 이제 작업을 이어나가면 됩니다.

Read more

Claude Code와 Obsidian MCP 연동 가이드

Claude Code와 Obsidian MCP 연동 가이드

소개 Claude Code는 Anthropic의 공식 CLI 도구로, MCP(Model Context Protocol)를 통해 다양한 외부 도구와 연동할 수 있습니다. 이 가이드에서는 Claude Code와 Obsidian을 연동하여 AI 에이전트가 여러분의 노트를 읽고 편집할 수 있도록 설정하는 방법을 소개합니다. MCP(Model Context Protocol)란? MCP는 AI 모델이 외부 데이터 소스 및 도구와 상호작용할

By Kyeongrok.kim
기술뉴스, 2025-09-25

기술뉴스, 2025-09-25

끝없이 수정하다 AI 성과 무너뜨린다··· ‘둠프롬프팅’의 함정최근 LLM과 AI 에이전트 결과물을 무한 반복 수정하는 ‘둠프롬프팅’ 현상이 관찰되고 있다. 이는 성과 저하와 막대한 비용을 초래할 수 있다.CIOGrant Gross초보를 위한 Claude Code 안내서Claude Code의 등장으로 코딩의 패러다임이 완전히 바뀌었습니다. AI 시대의 개발이란? 개발자의 역할은 무엇일까요?Subicura's BlogsubicuraShould we revisit Extreme

By Hyonsok
[Terraform 튜토리얼 1-6] 중복 없애다 망한 썰 – DRY 원칙, 정말 항상 맞을까?

[Terraform 튜토리얼 1-6] 중복 없애다 망한 썰 – DRY 원칙, 정말 항상 맞을까?

개발자라면 한 번쯤 들어봤을 말, "Don't Repeat Yourself", 줄여서 DRY 원칙. 이건 소프트웨어 개발에서 아주 중요한 원칙이에요. 중복을 줄이면 버그도 줄고, 유지 보수도 쉬워지고, 코드도 깔끔해지죠. 그런데… Terraform 같은 IaC 세계에서도 DRY가 무조건 좋을까요? 🤔 DRY가 뭔데? DRY 원칙의 핵심은 딱 하나: "같은 걸 반복해서 쓰지 마." * 상수 값, 로직, 설정

By Chansong