깃헙 활용
TRANSCRIPT
GitHub 활용송헌용
• GitHub 를 활용하기 위한 전제 조건• Master 브랜치에 곧바로 작업하지 않는다 .
• 개인이 개발 브랜치를 만들어 Pull Request
• GitHub 를 활용하기 위한 전제 조건• 메신저 혹은 오프라인 대화로 진행하지 않는다 .
• Issue 탭에서 담당자들끼리 댓글로 이야기• 가능한 모든 것을 기록화
목차• Code• Issues• Pull Requests• Projects• Pulse• Graphs
Code
• 브랜치 별로 코드를 확인• 불필요한 브랜치 삭제 가능• History: 커밋 히스토리를 확인• Blame: 라인 별로 수정 내역 확인• 원격에서 바로 코드 수정 ( 긴급 상황에서만 )
Issue
• 개발 과정에서 생기는 이슈 관리• 마일스톤 지정 ( 개발 목표 , 기한 )• 라벨 지정 ( 다중 선택 )• 담당자 지정 ( 다중 선택 )
• 글 / 댓글에 해쉬태그로 다른 이슈 참조 (#123)• 글 / 댓글에 해쉬태그로 다른 PR 참조 (#234)
• 이슈 추적 or 역추적 가능• 글 / 댓글에 커밋 해쉬 ID 참조• 글 / 댓글에 골뱅이로 담당자 맨션 (= 메일 전송 )• 마크다운을 알면 조금 더 깔끔하게 작성
Pull Requests
• 개인이 개발 브랜치를 만들어 Pull Request• 타겟 브랜치를 대상으로 merge 요청
• 글에는 PR 한 이유 , 커밋들에 대한 전반적인 설명• 마일스톤 지정• 라벨 지정 ( 다중 선택 )• 담당자 지정 ( 다중 선택 )
• diff 를 통해 대화 가능 ( 코드리뷰 )• 가능한 서로를 배려하는 마음의 대화
• 대화 결과에 따라 새로운 커밋 & 푸쉬 반복• 운영 정책에 따라 머지 조건
• ex) 팀원 모두 동의 + 마지막 리뷰어가 머지• ex) 팀원의 절반 동의 + 본인이 머지
브랜칭 전략
• 새로운 브랜치를 만들 때의 이름• 브랜치의 이름만 보고도 어떤 것인지 알 수 있게
• 새로운 개발 건 : ex) feat/newFeature• 수정에 대한 건 : ex) fix/BTS-1234
• master 는 real 서버 배포용• develop 브랜치는 qa 서버 배포용
• qa 검수가 완료된 이후에 master 에 머지• 개인 브랜치에 최신 내용을 반영할 때에는 리베이스• 머지 , 리베이스 = 브랜치끼리 합칠 때 사용하는 것
• 머지와 리베이스의 차이점• 머지 : 별도의 커밋을 생산한다 .
• ex) Merge branch ~~~~• 리베이스 : Re + Base: base 커밋을 re 한다 .
• 개발 브랜치의 베이스 커밋을 다시 잡는다 .
• 머지와 리베이스의 활용 예• 머지 : PR 을 통해서만 머지 커밋 생산• 리베이스 : 개인 브랜치를 최신화 할 때 이용
Projects
• 마일스톤을 모아놓는 곳으로 활용• 이슈를 큰 그림에서 확인 가능• 주로 관리자 (PL) 가 많이 사용할듯• 실제로 사용한 예는 많지 않음
Pulse
• 기간 별로 프로젝트의 변동을 텍스트로 확인• 24hours, 3days, 1week, 1month• 최신 기준으로 PR, Commit, Issue 흐름 확인
Graphs
• 소스의 변동을 그래프로 확인• 어떤 이들이 참여했었는지• 어떤 년 / 월에 커밋이 제일 많았는지• 요일 별 , 시간 별 커밋 양 비교
유즈케이스로 시연
• 마일스톤 ( 대분류 ) 을 지정• 마일스톤이란 ? 개략적인 할 일 + 기한
• 마일스톤에 따른 세부 업무들을 이슈로 등록• 각 이슈에는 간단한 설명 혹은 투두리스트 형태• 담당자 , 라벨 (FE, BE, BTS, ETC..) 지정• 포함하고 있는 마일스톤 지정
• 로컬에서 개발 브랜치를 생성• ex) fix/BTS-1234 or feat/newFeature
• 커밋이 적당히 쌓인 후 , 개발 완료• 개발 브랜치를 원격으로 푸쉬• 해당 브랜치를 타겟 브랜치로 PR• 다른 개발자들과의 코드리뷰 후 머지
개인적인 생각
• 정착 되기까지 시간이 걸릴듯• 개발자들의 철학이나 인식이 달라져야하기 때문에• 새로운 툴을 배우는 건 개발자들에게 언제나 스트레스• 하지만 나름대로의 재미가 분명히 있을 것• 약간 SNS 를 한다는 기분으로……