일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- OSLog
- dart
- it
- UIAccessibility
- pubspec
- pubspec.yaml
- Widget
- Equatable
- ToDoRim
- github
- reetcode
- swiftlint
- Extentsion
- COMMIT
- basic
- SwiftGen
- GIT
- designPattern
- toyproject
- tip
- Swift
- IOS
- flutter
- listview
- Leetcode
- enumerations
- protocol
- xcode
- keyWindow
- algorithm
- Today
- Total
목록Git (6)
수니의 개발새발
📌 이번 글은 Github Commit에 issue를 연결하는 방법입니다. Commit issue 연결 Commit 내용에 #[issue번호] 추가. #323 - 기능에 대하여 수정. Commit 과 함께 issue close 하기 close #[issue번호] close #232 - 기능 해결 resolved #122 - 기능 해결 Close 키워드 close closes closed fix fixes fixed resolve resolves resolved
📌 이번 글은 Commit Convention은 개발팀에 따라 다르지만, 제가 혼자 개발하고 형상관리하면서 정한 Commit Convention 정리 포스팅입니다. Message 구조 type : 제목 내용 꼬리말 Type feat - 새로운 기능 추가 fix - 버그 수정 docs - 문서 수정 sytle - 코드 포맷팅, 세미콜론 누란, 코드 변경이 없는 경우 refactor - 코드 리팩토링 test - 테스트 코드 chore - 빌드 업무 수정, 패키지 매니저 수정 제목 50자를 넘기지 않는다. 마침표를 붙이지 않는다. 내용 선택사항 부인 설명이 필요하거나 커밋의 이유를 설명할 경우 작성한다. 72자를 넘기지 않는다. 제목과 구분하기 위해 한 칸 띄어 작성한다. 꼬리말 선택사항 issue trac..
📌 이번 글은 Github 작업 관리 2탄 Project 정리입니다. Github 작업 관리 1탄, issue 보러 가기 [Git] Github 작업 관리(1) Issue 📌 이번 글은 Github 작업 관리 1탄 Issue 사용기입니다. 기존에 구글 스프레드 시트, 노션으로 작업 관리를 해왔는데, 스터디에서 작업 관리를 Github Projects로 선정하게 되면서 개인 프로젝트에 적 sunidev.tistory.com Github Project 프로젝트가 진행될 때에, 관련 issue들과 Pull Reqeust를 한눈에 볼 수 있도록 도와줍니다. 현재 프로젝트가 어느 단게에서 어느 문제가 있는지 확인할 수 있습니다. 세 개의 열로 구성 : To Do(해야 할 작업), In Progress(진행 중),..
📌 이번 글은 Github 작업 관리 1탄 Issue 정리입니다. 기존에 구글 스프레드 시트, 노션으로 작업 관리를 해왔는데, 스터디에서 작업 관리를 Github Projects로 선정하게 되면서 개인 프로젝트에 적용을 해보며 공부하게 되었어요. :) Github 작업 관리 프로세스 제가 선정한 Github 작업 관리 프로세스입니다. Project 생성 issue 생성 (Project, MileStone 지정) issue 해결 작업 Pull Request -> Code Review PR Merge -> Issue 반영 -> Cloes Github issue 이슈 노트, 이슈를 관리하는 공간 일반적으로 오픈 소스에서는 사용자들의 건의사항, 오류 내용을 업로드하는 공간으로 사용됩니다. 오픈 소스 관리자들은 ..
📌 이번 글은 Git 브랜칭 전략 2탄 Github-flow 정리입니다. Git 브랜칭 전략 1탄 보러 가기 [Git] Git 브랜칭 전략(1) Git-flow 📌 이번 글은 Git 브랜칭 전략 1탄 Git-flow 정리입니다. Git 브랜칭 전략이란? Git 브랜치를 효과적으로 나누고, 관리하는 전략 Git-flow 브랜치를 5가지로 나누어 개발하는 전략 (1) feature (2) develop (3) r sunidev.tistory.com Github-flow Git-flow 전략보다 단순한 브랜치 전략. master 브랜치 하나만을 가지고 진행하는 방식. master 브랜치 master 브랜치는 기능 구현, 오류 수정 사항 모두 master에 머지되어 항상 최신 상태를 유지합니다. Github-f..
📌 이번 글은 Git 브랜칭 전략 1탄 Git-flow 정리입니다. Git 브랜칭 전략이란? Git 브랜치를 효과적으로 나누고, 관리하는 전략 Git-flow 브랜치를 5가지로 나누어 개발하는 전략 (1) feature (2) develop (3) release (4) master (5) hofix (1) feature 기능 구현을 담당하는 브랜치. 브랜치명 : feature/{구현기능명}로 지정. ex) feature/login 은 login 기능을 구현하는 브랜치. feature 브랜치는 develop 브랜치에서 생성되고, develop 브랜치로 merge 됩니다. feature 브랜치는 보통 개발자 저장소에만 있고, origin에는 push 하지 않습니다. merge 된 후에 해당 브랜치는 삭제합니..