Medium - Use Git More Efficiently; A Simple Git Workflow
in Trend
Trend 파악을 Medium 기고문 요약 포스팅 - 깃을 더 효율적으로 사용하세요: 간단한 깃 작동방식
깃은 의심할 여지없이 모든 개발자에게 필수적인 도구입니다. 깃이 도움이 되는만큼 좋은 사례를 따르지 않는 것은 깃을 사용하는 의미가 없게 만듭니다. 그래서 깃의 멋진 특성들을 최대로 활용하는 다양한 작업방식 표준들이 있는 것입니다.
오랫동안 깃과 깃허브에 대한 제 인식은 코드에 대한 백업과 온라인에 접근할 수 있게해주는 도구였습니다. 완전히 틀린건 아니지만 제가 YasnaTeam에서 일을 하면서 제가 모르는 더욱 많은 것이 있다는 것을 알게 되었습니다.
우리팀에서는 10명의 개발자가 같은 저장소에서 작업을 하고 있습니다. 문화라고 불리는 같은 습관을 가지는 것은 충돌과 혼돈을 막기위해서 필수적입니다. 하루에 100회가 넘는 커밋이 이뤄지기 때문에 사소한 것이라도 겉잡을 수 없게 되버릴 수 있습니다. 이런 문제를 피하기 위해 우리는 수정된 깃플로우 버전을 구현했습니다.
How it works
하나의 마스터 브랜치를 가지는 것 대신에 우리는 dev라는 추가적인 브랜치가 있습니다. 이 브랜치들은 잠궈져있어서 누구도 거기에 직접적으로 푸시를 할 수 없습니다.
master는 생산을 위해서만 사용됩니다. 새로운 피처의 테스트가 끝나면 저장소의 주인이 각 릴리즈 전에 master를 업데이트 합니다.
dev는 모든 개발자들이 브랜치를 따고 머지를 하는 기본 브랜치입니다. dev브랜치는 항상 마스터의 앞에 있으며 그래서 주기적으로 마스터 브랜치에 머지될 수만 있습니다.
Naming Branches
우리는 브랜치에 작명 패턴이 있습니다.
[Module Name]-[Type]-[Detail]
//Example
users-fix-attach-roles-issue#765
Module Name
우리의 코드에는 모듈 기반 구조가 있으므로 연관된 각 모듈을 수정하면 모듈이름을 가진 분산된 브랜치에 커밋을 해야합니다. 이 부분은 여러분의 프로젝트에 이런 구조가 없다면 제거하셔도 됩니다.
Type
작업의 타입에 따라 아래의 종류에서 하나를 선택해야 합니다.
- feature
- enhance
- cleanup
- refactor
- fix
- hotfix 핫픽스는 매우 긴급한 수정으로 마스터브랜치에서 이뤄지지만 자주 사용되지는 않습니다.
Detail
디테일은 브랜치에서 어떤 작업이 수행되었는지 짧게 설명하는 것입니다.
이 브랜치 룰은 우리팀에게 의미있는 덩어리로 작업을 쪼개도록 강제하고 dev 브랜치에 수시로 머지하고 항상 비어있는 브랜치를 갖게 합니다. 이 접근방식의 큰 부작용으로는 minimize conflicts가 있습니다.
Commit Messages
깔끔하고 서술적인 커밋리스트를 가지기 위해 우리는 다음과 같은 커밋 메시지 작명 규칙을 가지고 있습니다.
[[Module Name]] [Commit Message]
//Example
[users] add fetch users endpoint
우리팀이 이미 브랜치에서 모듈 네임이 명시되어 있으므로 각 커밋메시지에 모듈이름을 포함하는게 과잉되어 보일 수 있습니다만 모든 브랜치가 dev나 master로 머지되고 나서 커밋 히스토리를 보면 각 커밋들이 어떤 브랜치에 속했는지 알 수 없습니다. 왜냐하면 현재 그들은 모두 dev나 master 브랜치에 속해있기 때문입니다. 모든 커밋들의 필터를 쉽게하기 위해서 커밋 메시지 안에도 모듈네임을 넣게 되었습니다.
커밋 메시지는 자체적으로 완전한 문장이 되어야 합니다. “This commit will…” 문법적으로 말이죠.
Pull Requests
Title
풀리퀘스트의 타이틀은 브랜치이름을 이용하여 자동적으로 채워집니다. 브랜치 이름이 너무 일반적인 경우 더욱 자세한 내용이 추가됩니다.
Body
PR의 본문은 자세한 정보를 담아야 합니다. 우리의 작업흐름에서 PR은 대개 존재하는 이슈와 연관됩니다. 우리는 이슈를 각 버그나 피처에대해 만듭니다. 그래서 우리는 연관된 이슈를 PR의 내용에 연결시킵니다. 또한 우리는 bullet points를 이용하여 pull 내부에 변경사항에 대해 강조를 합니다. 우리는 작업을 수월하게 하기 위해서 PR 템플릿을 만들었습니다.
Review
코드리뷰는 우리의 업무 중 가장 중요한 부분중에 하나입니다. PR이 생성되면 생성자는 코드 리뷰를 하기위해 자격이 있는 2명의 peer를 선택해야 합니다.
리뷰어에 의해 pull이 승인되면 생성자는 dev에 머지를하고 브랜치를 삭제합니다.
Summary
- 개발팀에서 깃을 활용하는 방법
- dev 브랜치에서 피처, 버그와 같이 이슈와 관련된 브랜치를 생성하고 작업 후 peer를 선택하여 PR을 날린다
- 코드리뷰 후 승인이 되면 dev에 머지를 하고 작업했던 브랜치를 삭제한다
- 커밋메시지 및 브랜치 이름은 팀 내부의 작업구조와 규칙을 따른다
- 커밋 리스트들을 나중에 편하게 필터링해서 보려면 이러한 규칙을 따르는 것이 매우 중요하다.
