commit, issue, project, milestone의 관계 설정

[Bartleby2718]

@gongdo
아마 몇 년 전에도 여쭤봤을 것 같긴 한데, commit과 issue의 관계를 어떻게 설정하세요? 모든 커밋에서 이슈를 언급해서 many-to-one 관계를 맺으시나요? 그리고 이슈 트래킹을 요즘 뭘로 하시는지는 모르겠는데, 만약 GitHub으로 하신다면 project나 milestone은 issue랑 어떻게 관계를 맺으시나요? 예전에 브랜칭 관련 조언 주신 건 메모에 적어놨는데 이건 없네요.

[gongdo]

이슈는 프로젝트와 관련된 모든 사항: 질문, 버그리포트, 제안, 할일, 계획...
커밋은 어떤 이슈를 해결하기 위한 코드 수정.

따라서 커밋에는 반드시 관련 이슈가 붙는 것이 원칙이죠.
이상적으로는 하나의 이슈를 하나의 커밋이 해결하는게 맞고 가급적 이슈를 작게 쪼개는게 좋지만 현실적으로 그렇지 못할 경우가 있죠.

예를 들어,

1. 이슈는 하나인데 커밋을 여러번 하는 경우
2. 커밋은 하나인데 관련된 이슈가 여러개인 경우

1)의 해소 방법은,

• squash 기법: 현재 커밋에서 특정 시점의 커밋으로 돌아간 후 그 이후에 발생한 커밋을 하나의 커밋으로 합친 후 리포에 강제로 반영(push)하는 방법. 실수로 커밋에서 놓친게 있었거나 자잘한 커밋인데 굳이 나눌 필요가 없을 경우 제한적으로 사용합니다. 아직 push하지 않고 local에만 있었다면 아무때나 상관없이 쓸 수 있는 방법이지만, push를 해버린 상태라면 squash후 강제로 push해야 하므로 아주 조심스럽게 사용해야 하며 특히 master 브랜치에 대한 squash는 세번 더 생각합니다.

• PullRequest 활용: 단번에 커밋하여 이슈를 해결하지 못하고 리뷰가 필요하거나 비교적 장기적으로 해결해야 할 경우 PR에 커밋을 쌓는 방법이 있습니다. 이 경우에도 일부 squash 기법을 사용할 수 있습니다. Github에서 협업을 한다면 이쪽이 더 좋은 방법입니다.

2)의 해소 방법은, 그냥 단순하게 이슈 하나를 새로 만들고 이 이슈가 해결해야 할 다른 이슈들을 링크하는게 현실적으로 유용해요. 복잡하게 가자면 롤백하고 커밋을 이슈별로 쪼갤 수도 있지만... 아주 엉망인 상태가 아닌 이상 추천하진 않습니다.

지금 회사에서 이슈트래킹은 지라와 유트랙이 뒤섞인 엉망인 상태ㅋ

milestone은 깃헙에서는 출시 목표 버전을 나타내는 특수 레이블이라고 보면 돼요. 적절한 개발/배포 사이클을 가진 프로젝트에서 유용하고 끊임없이 자잘하게 바뀌는 프로젝트에는 적합하지 않을 수도 있어요. agile의 sprint와 같거나 보다 긴 주기를 가질 수 있죠.

어떤 이슈가 나왔을 때 이것을 해결해야겠다고 결정하면 backlog 레이블을 붙이고, 목표 기한이나 수정할 수 있는 예상 버전이 나왔다면 해당 milestone 레이블을 붙이는거죠.

깃헙의 Project 기능은 안써봤는데 레이블 기반으로 관리하지 않는게 좀 의외고요, 모양을 봤을 땐 kanban 스타일과 유사하지만 프로젝트 자체에 '완료'라는 개념이 있는 걸로 봐서는 마일스톤과 동일하게 쓸수도 있을것 같네요. 또는 epic처럼 특정 주제를 비교적 장기적으로 관리하는 용도가 될 수도 있고요. 어쨌든 이런 스타일을 운용할때 프로젝트의 주제를 적당한 기간동안 '완료'할 수 있는 단위로 잡는게 중요하겠네요. 그렇지 않으면 'done'에 쌓인 항목이 너무 많아져서 의미가 별로 없어지는 경우가 많아요.

[gongdo]

브랜칭 전략은 크게 gitflow 전략 및 그 아류와 github-flow 전략이 있는것 같고 이외에 구글 같은 single branch 전략도 있긴한데 쉽게 흉내내긴 어렵고 오픈소스용으로 운용하기에 적합한 구조도 아니죠.

저는 github-flow를 선호하는데 대부분의 조직이 (유사)gitflow를 쓰는게 현실.