2024-07-11-TIL

2024-07-11-TIL

Today I Learned

Branch Strategy for Multiple Releases

• https://softwareengineering.stackexchange.com/questions/388681/git-branches-merging-issues-while-having-multiple-release-branches
• https://levelup.gitconnected.com/better-git-branching-strategy-multi-apps-monorepos-and-multiple-teams-in-focus-cd17b56962f2
• https://medium.com/@kushshiv/git-branching-strategy-4f01f48a8e2c

릴리스가 하나뿐이면 브랜치 전략이 단순하다. 문제는 이미 나간 버전을 유지보수하면서 다음 버전을 개발할 때 생긴다. 같은 버그 수정을 여러 릴리스 브랜치에 넣어야 하고, 어느 브랜치에 무엇이 들어갔는지 추적하기가 어려워진다.

git-flow를 제안한 Vincent Driessen은 2020년에 덧붙인 글에서, 지속적으로 배포하는 웹 앱이라면 git-flow보다 단순한 흐름이 낫다고 썼다. 반대로 버전을 명시해서 내보내거나 여러 버전을 동시에 지원해야 한다면 git-flow가 여전히 잘 맞을 수 있다고 했다. 여러 릴리스를 운영하는 상황이 바로 후자다.

Git 공식 문서의 gitworkflows는 Git 프로젝트 자신이 쓰는 방식을 설명하는데, 여러 버전을 다루는 데 참고할 규칙이 있다.

• 브랜치를 안정성 순서로 둔다. maint는 마지막으로 나간 안정 버전의 유지보수 릴리스에 들어갈 커밋을, master는 다음 기능 릴리스에 들어갈 커밋을 추적한다.
• Merge upwards : 수정은 가장 오래된(안정적인) 브랜치에 먼저 커밋하고, 위쪽 브랜치로 병합해 올린다. 반대로 불안정한 브랜치를 안정 브랜치로 병합하면 그 브랜치의 모든 변경이 딸려 들어가기 때문이다.
• 이 규칙을 지키면 master는 항상 maint의 상위 집합이 된다. 실수로 master에 먼저 넣은 수정은 cherry-pick으로 아래로 가져오되, 이 일이 잦아지면 흐름을 다시 봐야 한다.
• 기능이나 버그 수정은 토픽 브랜치에서 작업하고, 필요한 통합 브랜치에 병합한다. 버그 수정을 먼저 다음 버전 쪽에 넣어 시험해 본 뒤 안정되면 maint에도 병합할 수 있다.

여러 릴리스 브랜치에서 생기는 병합 문제의 상당 부분은 수정 방향이 뒤섞이는 데서 온다. 수정은 가장 오래된 지원 브랜치에서 시작해 위로 올린다는 규칙 하나만 정해도 추적이 훨씬 쉬워진다.

---

AI 키워드: AlphaFold 3

Google DeepMind와 Isomorphic Labs가 5월 8일 AlphaFold 3를 발표했다. 단백질뿐 아니라 DNA, RNA, 리간드 같은 분자의 구조와 이들이 서로 어떻게 결합하는지를 예측하는 모델이다. 세포 안의 분자는 혼자 작동하지 않기 때문에, 상호작용까지 예측하는 것이 신약 개발에 의미가 크다고 설명한다. 언어 모델 말고도 과학 연구 쪽에서 AI가 쓰이는 대표 사례라는 말이구나.

참고한 자료외부 출처 3

외부 출처

• gitworkflowsGit Documentation
• A successful Git branching model - Vincent Driessennvie.com
• AlphaFold 3 predicts the structure and interactions of all of life’s moleculesGoogle