*** 일반적으로 1개의 레포지토리에 1개의 app
*** gitignore : 환경변수 등 필요없는 파일 지정하면 안올릴 수 있음
*** Choose a license : 라이선스 지정 가능 ex)mit license
*** 소스트리 : 9:28
- 소스트리에서 로컬은 개인pc, 원격은 레포에 있는 파일
- 클론해서 복사하기
*** commit
- 소스트리에서 'commit - push'해야 깃허브site에 올라감
- 'pull' : A개발자가 수정한 코드를 B개발자가 로컬pc로 이동
- 깃헙 'history' 누르면 수정내역 다 볼 수 있음
- 예전시점으로 돌아가는 방법 : '코드뭉치 되돌리기'
*** commit rule
- 커밋 주기정하기 - 기능별, 오전 오후별, 일별
- commit 카테고리 관리
- [INNITIAL] : 레포를 생성하고 최초에 파일을 업로드할 때
- [ADD] : 신규 파일 추가
- [UPDATE] : 코드 변경이 일어날 때
- [REFACTOR] : 코드를 리팩토링 했을 때
- [FIX] : 잘못된 링크 정보 변경, 필요한 모듈 추가 및 삭제
- [REMOVE] : 파일 제거
- [STYLE] : 디자인 관련 변경사항
- 설명 어떻게 할지 정하기8
*** GitFlow전략
- 소프트웨어의 소스코드를 관리하고 출시하기 위한 '브랜치 관리전략' 중 하나
- 이외에도 githut flow, gitlabflow 전략 등이 있으나 Gitflow가 제일 좋음
- 항상 유지되는 메인 브랜치
- Master : 제품으로 출시되는 브랜치
- Develop : 다음 출시 버전을 개발하는 브랜치
- 일정 기간 유지되는 보조 브랜치
- Feature : 기능을 개발하는 브랜치
- Realease : 이번 출시 버전을 준비하는 브랜치
- Hotfix - 출시 버전에서 발생한 버그를 수정하는 브랜치,
Master브랜치에서 직접 땀(Master와 Develop에 둘다 반영시켜야 함)
- 깃헙에서 레포 생성하면 기본적으로 Master브랜치로 생성됨
새로운 브랜치를 만들면 참조한 브랜치(Master)를 그대로 가져옴
- ex) Feature(name_edit)브랜치를 Develop브랜치로 pull하는 방법
- 깃헙 'Pull requests' - 'Compare & pull request'버튼 클릭
- base: develop <- compare: name_edit V Able to merge 확인
- Create pull request 클릭
- 개발리더가 코드 확인 후, 잘못되었으면 comment
문제가없다면 'Merge pull request' - 'Confirm merge' 버튼 클릭
- Develop브랜치에 들어가서 정상적으로 반영되었는지 확인 후,
Feature브랜치 삭제(branches 들어가서 휴지통 버튼)
- Default branch를 Develop으로 변경하기 : 'Change default branch' - 'branches' - 변경가능
*** 이슈관리(Issues) : Message 대신에 사용, e-mail로 모든 것을 소통할 수 있음
- to do : 체크박스 만들어서 사용하기
*** 개발진행관리 : 'Projects' 에서 '개발목록', '개발진행중', '개발완료', '테스트완료', '최종개발완료' 로 나누어서 해도 좋음
*** 문서관리 : 깃헙에서 모두 가능
*** 동일한 파일 수정하면서 충돌했을 때 문제 발생하는 것들도 더 배워야 함