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