hyun9iOS

Issue 다루기 make project, issue, milestone make feature branch merge #1 pull request 되면 자동으로 close 된다.(default branch 에 merge 할 경우만 가능) local #1 branch 에서 commit 과 push 를 remote #1 로 하고 깃허브에서 풀리퀘를 통해 코드리뷰하고 develop remote branch 를 선택해서 merge 하면된다. 그렇지 않고 develop remote branch 로 push 하면 풀리퀘없이 머지 되었다. Fork 프로그램을 사용할 경우에도 동일하게 진행하였다. 이와 같은 방식으로 해줘야 pull request가 등장한다. 졸작 포포 협업을 연습하기 위해서 한동안 깃허브에 프로젝트..

Commit,Issue,PR Commit Type feat: 새로운 기능 추가 (new feature) fix: 버그 수정 (bug fix) docs: 문서 작성, 수정 (documentation) style: 코드 포맷팅, 세미콜론 누락 등 코드 변경이 없는 경우 refactor: 코드 리팩토링 (refactoring) test: 테스트 코드, 리팩토링 테스트 코드 추가 chore: 빌드 업무 수정, 패키지 매니저 수정 등 (production code 변경이 없는 경우) perf: 성능 개선 issue title [Commit Type] 이슈 제목 Commit type label 과 개발자 각자의 label 추가하기로 함. issue body 는 checklist type 으로 작성하기로 함. com..

Code Convention style share(https://github.com/StyleShare/swift-style-guide) 를 기초로 필요한 부분만 수정. function naming 만 수정이 필요하다고 판단함. 서버통신 서비스함수명 + WithAPI IBAction 동사원형 + 목적어 ex) touchBackButton 뷰 전환 pop, push, present, dismiss 동사 + To + 목적지 뷰 (다음에 보일 뷰) ( dismiss는 dismiss + 현재 뷰 ) 데이터 다루기? 데이터 파싱 - parse + 모델 + 결과물 parseDiaryUserID 초기세팅 init + 목적어 ex) initPickerView hidden unhidden show + 목적어 hide +..

Branch develop 다음 출시 버전을 개발하는 브랜치 기능 개발을 위한 브랜치들을 병합하기 위해 사용. 즉, 모든 기능이 추가되고 버그가 수정되어 배포 가능한 안정적인 상태라면 develop 브랜치를 ‘master’ 브랜치에 병합(merge)한다. 평소에는 이 브랜치를 기반으로 개발을 진행한다. feature 기능을 개발하는 브랜치 feature 브랜치는 새로운 기능 개발 및 버그 수정이 필요할 때마다 ‘develop’ 브랜치로부터 분기한다. 개발이 완료되면 ‘develop’ 브랜치로 병합(merge)하여 다른 사람들과 공유한다. release 출시 버전을 준비하는 브랜치 ‘develop’ 브랜치에서 배포할 수 있는 수준의 기능이 모이면 또는 정해진 배포 일정이 되면, release 브랜치를 분기..

Branch rules git-flow 사용 feature 브랜치에는 이슈번호로만 작성 featrue/#1 main develop featrue/#(issue_number) release/(version_number) hotfix/#(issue_number) fork, xcode 에서 .../#(issue_number) 로 브랜치를 만들게 되면 자동으로 트리가 만들어짐.

Automated kanban 을 사용하여 project 생성 'Automated kanban' 으로 프로젝트 템플릿을 설정해주어야 close 된 issue 가 자동으로 'Done' 으로 이동한다.