# Show GN: GitHub PR을 cherry-pick 해보세요

> Clean Markdown view of GeekNews topic #18433. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=18433](https://news.hada.io/topic?id=18433)
- GeekNews Markdown: [https://news.hada.io/topic/18433.md](https://news.hada.io/topic/18433.md)
- Type: show
- Author: [a1eng0](https://news.hada.io/@a1eng0)
- Published: 2024-12-25T23:24:43+09:00
- Updated: 2024-12-25T23:24:43+09:00
- Original source: [github.com/134130](https://github.com/134130/gh-cherry-pick)
- Points: 11
- Comments: 4

## Summary

사내에서 mono-repository와 trunk-based development 전략을 도입하여 main 브랜치에 커밋하고 release 브랜치에 cherry-pick하는 흐름을 사용 중이며, GitHub Action을 통해 자동화를 시도했지만 충돌 해결은 수동으로 해야 합니다. 이를 보완하기 위해 `gh` 플러그인을 제작하여 PR을 cherry-pick할 때 다양한 옵션을 제공하고, 성공 시 자동으로 remote push를 지원합니다. CLI 프로그램 개발에는 많은 시간이 소요되었으며, 사용자 경험을 개선하기 위한 다양한 노력이 필요했습니다.

## Topic Body

- 사내에서 mono-repository를 사용하기 시작한지 4개월째  
- mono-repository 하면 따라다니는 키워드인 [trunk-based development](https://trunkbaseddevelopment.com/monorepos/) 또한 같이 적용 중  
- trunk-based development 전략에 따라 main 브랜치에 커밋을 하고, release 브랜치에 체리픽을 하는 flow를 사용하고 있음  
- [LinkedIn 기술 블로그](https://www.linkedin.com/blog/engineering/developer-experience-productivity/how-linkedin-automates-cherry-picking-commits-to-improve-develop) 내용을 바탕으로 GitHub Action을 구성하였으나, CONFLICT를 자동으로 해결해주지는 못함. CONFLICT가 발생하는 경우 사용자가 local에서 직접 `git cherry-pick` 명령을 수행해야함  
- 이 `cherry-pick` 명령을 도와주는 `gh` 플러그인을 직접 제작해보았습니다.  
  
##### 사용법  
  
```  
gh cherry-pick -pr <pr_number> -onto <target_branch> [-merge auto|squash|rebase] [-push]  
```  
  
- `-merge` 옵션을 통해 PR merge commit을 cherry-pick 할지, PR의 원본 commit들을 cherry-pick 할지 선택할 수 있음  
  - 지정하지 않거나 `-merge=auto` 옵션을 사용하면, PR이 merge된 전략을 자동으로 inspect 하여 적용해줌  
- `-push` 옵션을 통해 cherry-pick 성공 시 자동으로 remote push를 지원함  
  
##### 후기  
  
- 외부 프로세스 및 상태와 지속해서 상호작용하는 프로그램을 개발하며, 별도의 [테스트 리포지토리](https://github.com/134130/test-cherry-pick)를 만들어 Test Dataset을 생성함  
  - 과거 [libgit2](https://github.com/libgit2/libgit2) 프로젝트 및 [refined-github](https://github.com/refined-github/refined-github)에 기여했던 경험이 도움이 됨  
- CLI 경험을 좋게 하기위한 여러 공부들  
  - docker-cli 를 혼자 만들어보기 위한 공부가 도움이 됨  
- 생각보다 CLI 프로그램을 만드는데에는 많은 공수가 들어감  
  - 파이프라인 형태에서 많은 상태값을 관리하는 것  
  - 사용자에게 직관적인 input interface를 제공하는 것  
  - input validation을 최대한 빠른 시점에 제공하는 것  
  - 사용자 시스템을 원상태로 복구시키는 것 등..  
  - 하루 정도 안에 만들 수 있을 것으로 예상했으나, 만드는데에 약 5일이 걸렸음 (GitHub Actions Workflow 개선을 위한 개발이 병렬로 진행되긴 했으나, 여전히 예상보다 훨씬 많은 시간이 소요됨)

## Comments



### Comment 32984

- Author: qncnxnlrla
- Created: 2025-01-04T20:49:49+09:00
- Points: 1

안녕하세요~ main(trunk) 브랜치에 머지된 커밋을 revert가 필요한 경우에는 어떻게 처리하시나요?   
  
- main 브랜치에 revert하면 release 브랜치도 체리픽 된다?   
- revert를 사용하지 않고 수정 커밋을 추가한다?   
  
커밋이 많이 쌓여있어 컨플릭이 발생하면 체리픽이 어려운 경우가 있을 것 같은데 그런 케이스를 처리하신 경험이 있는지 궁금합니다!

### Comment 32987

- Author: a1eng0
- Created: 2025-01-04T22:51:05+09:00
- Points: 1
- Parent comment: 32984
- Depth: 1

안녕하세요~ 답글 달아주셔서 감사합니다!  
  
> main(trunk) 브랜치에 머지된 커밋을 revert가 필요한 경우에는 어떻게 처리하시나요?  
  
Main 브랜치에 revert PR을 올린거에서 cherry-pick을 지정합니다. 원본 PR링크에 cherry-pick 히스토리가 모두 남아있기 때문에 추적에 어려운건 없습니다. 별도로 기계적인 체크를 수행하는건 없습니다 ㅎㅎ  
  
> 커밋이 많이 쌓여있어 컨플릭이 발생하면 체리픽이 어려운 경우  
  
일단 trunk-based development 를 하게되면 매 PR이 작은 단위이기 때문에 컨플릭이 자주 나지 않습니다. 만약 컨플릭이 발생하는 경우라면 수작업으로 코드를 작성해야합니다. release 를 자주자주 해서 너무 과거 버전의 지원을 빠르게 deprecate 시켜 코드 형상이 크게 달라지는 현상을 피하고 있습니다!

### Comment 32689

- Author: lamanus
- Created: 2024-12-26T09:02:32+09:00
- Points: 2

왜 이게 필요한지 잘 이해가 안가는 전략이네요...

### Comment 32704

- Author: a1eng0
- Created: 2024-12-26T11:32:33+09:00
- Points: 1
- Parent comment: 32689
- Depth: 1

[release-from-trunk](https://trunkbaseddevelopment.com/release-from-trunk/)에 소개되어있는 내용을 읽어보시면 이해해 도움이 되실까 싶습니다 ㅎㅎ