Show GN: GitHub PR을 cherry-pick 해보세요
(github.com/134130)- 사내에서 mono-repository를 사용하기 시작한지 4개월째
- mono-repository 하면 따라다니는 키워드인 trunk-based development 또한 같이 적용 중
- trunk-based development 전략에 따라 main 브랜치에 커밋을 하고, release 브랜치에 체리픽을 하는 flow를 사용하고 있음
-
LinkedIn 기술 블로그 내용을 바탕으로 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를 지원함
후기
- 외부 프로세스 및 상태와 지속해서 상호작용하는 프로그램을 개발하며, 별도의 테스트 리포지토리를 만들어 Test Dataset을 생성함
- 과거 libgit2 프로젝트 및 refined-github에 기여했던 경험이 도움이 됨
- CLI 경험을 좋게 하기위한 여러 공부들
- docker-cli 를 혼자 만들어보기 위한 공부가 도움이 됨
- 생각보다 CLI 프로그램을 만드는데에는 많은 공수가 들어감
- 파이프라인 형태에서 많은 상태값을 관리하는 것
- 사용자에게 직관적인 input interface를 제공하는 것
- input validation을 최대한 빠른 시점에 제공하는 것
- 사용자 시스템을 원상태로 복구시키는 것 등..
- 하루 정도 안에 만들 수 있을 것으로 예상했으나, 만드는데에 약 5일이 걸렸음 (GitHub Actions Workflow 개선을 위한 개발이 병렬로 진행되긴 했으나, 여전히 예상보다 훨씬 많은 시간이 소요됨)
안녕하세요~ main(trunk) 브랜치에 머지된 커밋을 revert가 필요한 경우에는 어떻게 처리하시나요?
- main 브랜치에 revert하면 release 브랜치도 체리픽 된다?
- revert를 사용하지 않고 수정 커밋을 추가한다?
커밋이 많이 쌓여있어 컨플릭이 발생하면 체리픽이 어려운 경우가 있을 것 같은데 그런 케이스를 처리하신 경험이 있는지 궁금합니다!
안녕하세요~ 답글 달아주셔서 감사합니다!
main(trunk) 브랜치에 머지된 커밋을 revert가 필요한 경우에는 어떻게 처리하시나요?
Main 브랜치에 revert PR을 올린거에서 cherry-pick을 지정합니다. 원본 PR링크에 cherry-pick 히스토리가 모두 남아있기 때문에 추적에 어려운건 없습니다. 별도로 기계적인 체크를 수행하는건 없습니다 ㅎㅎ
커밋이 많이 쌓여있어 컨플릭이 발생하면 체리픽이 어려운 경우
일단 trunk-based development 를 하게되면 매 PR이 작은 단위이기 때문에 컨플릭이 자주 나지 않습니다. 만약 컨플릭이 발생하는 경우라면 수작업으로 코드를 작성해야합니다. release 를 자주자주 해서 너무 과거 버전의 지원을 빠르게 deprecate 시켜 코드 형상이 크게 달라지는 현상을 피하고 있습니다!