├── About-Git-Project.md ├── Git-Github-Collaborating.md ├── Github-Issue.md ├── Github-Issues-Imgs ├── 기본이슈생성.png ├── 라벨1.png ├── 라벨생성.png ├── 레포이슈생성.png ├── 마일스톤리스트.png ├── 마일스톤생성.png ├── 이슈리스트.png ├── 이슈리스트_후.png ├── 이슈상세페이지_라벨지정.png ├── 이슈상세페이지_라벨지정결과.png ├── 이슈상세페이지_마일스톤지정.png ├── 이슈상세페이지_마일스톤지정결과.png ├── 이슈상세페이지_책임자지정.png ├── 이슈상세페이지_책임자지정결과.png ├── 이슈상세페이지_클로즈.png ├── 이슈상세페이지_클로즈후.png ├── 이슈완료후마일스톤.png ├── 코드이슈생성.png ├── 코멘트이슈생성.png └── 풀리퀘스트_이슈지정가능.png ├── Github-Marketplace-Explore.md ├── Github-blog-posting.md ├── Pull-Request.md ├── QnA.md ├── README.md ├── Repository-Settings.md └── _config.yml /About-Git-Project.md: -------------------------------------------------------------------------------- 1 | # About Project Boards 2 | 3 | Github에서 제공하는 project탭에 대해 차근차근 알아보는 시간을 가지도록 합시다! 4 | 5 | 처음 project 탭에 들어가게 되면 Project에 대한 설명이 간단하게 되어있는데요. 6 | 7 | 8 | 9 | 1. 작업 정리 : 우리들의 Project Board에 issue와 pull request들을 더하고, 우선 순위대로 노트카드 안에 idea와 업무 리스트를 정리 합니다. 10 | 2. 프로젝트 계획 : "To Do" , "In Progress", "Done"와 같은 기준을 정해 작업을 상태를 정렬합니다. 11 | 3. Workflow의 자동화 : 트리거를 설정해 프로젝트 관리 시간을 절약할 수 있습니다, 12 | 4. 진행 상황 추적 : 프로젝트에서 일어나는 모든 일을 추적할 수 있고, 마지막으로 본 이후에 어떤 일이 생겼는지 확인이 가능합니다. 13 | 5. 상태 공유 : 카드마다 각각 고유한 URL이 있기 때문에 팀과 개별 작업을 공유하고 논의가 가능해집니다. 14 | 6. 프로젝트 마무리 : 프로젝트를 닫고 마무리합니다. 15 | 16 | 와 같은 기능을 하는 Project에 대해 하나하나 알아가보도록 하겠습니다. 17 | 18 | ---- 19 | 20 | ## Project 21 | 22 | ### project 23 | 24 | 프로젝트 보드를 만들수 있는 공간은 3군데가 있습니다. 25 | 26 | 1. User 27 | 28 | 29 | 30 | 사용자의 repo를 이용해 프로젝트를 생성할 수 있습니다. 31 | 32 | 2. organization 33 | 34 | 35 | 36 | 해당 조직에 속한 repo만을 이용해 프로젝트를 생성할 수 있습니다. 37 | 38 | 3. repo 39 | 40 | 41 | 42 | repo하나로 범위가 한정되고 단일 repo에 속한 요청만을 끌어옵니다. 43 | 44 | 또한, user와 organization의 프로젝트 보드는 최대 25개의 저장소만을 연결할수가 있습니다. 45 | 46 | --- 47 | 48 | ### Board 만들기 49 | 50 | 프로젝트를 만드는 것은 생각보다 간단합니다! 51 | 52 | 이름, 설명(optional), 프로젝트의 템플릿만을 설정 하면되는데요! 53 | 54 | 템플릿에는 None, Basic kanban, Automated kanban, Automated kanban with reviews, Bug triage 5가지가 있습니다. 55 | 56 | 1. None : 말 그대로 프로젝트만 생성이 됩니다 57 | 58 | 59 | 60 | 61 | 62 | 2. Basic kanban : To Do, In Progress, Done 컬럼이 같이 생성됩니다. 63 | 64 | 65 | 66 | 3. Automated kanban : To Do, In Progress, Done 컬럼이 같이 생성됩니다. 67 | 68 | 69 | 70 | 71 | 72 | 4. Automated kanban with reviews : To Do, In Progress, Review In Progress, Reviewer Approved, Done 컬럼이 같이 생성됩니다. 73 | 74 | 75 | 76 | 5. Bug triage : Needs triage, High priority, Low priority, Close 컬럼이 같이 생성이 됩니다. 77 | 78 | 79 | 80 | 기본적인 kanban에 대한 기본적인 구성은 비슷하고 자동화가 적용이 되어 있나, 리뷰를 진행하는 프로젝트의 progress에서 포함이 되어있는지에 대한 차이점이 있을 뿐입니다. 81 | 82 | --- 83 | 84 | ### 컬럼 안에 넣기 85 | 86 | 컬럼안에 넣을수 있는 항목들은 노트, 이슈, 풀 리퀘스트 3가지 입니다. 87 | 88 | 노트의 경우에는 89 | 90 | 91 | 92 | 와 같은 방법으로 컬럼의 add 버튼을 누르고 만들면 됩니다. 93 | 94 | 95 | 96 | 와 같은 방법으로 노트를 만들고 issue로 변환 시키는 방법도 있습니다. 97 | 98 | 99 | 100 | 하지만 이슈에 대해서 지정해 줄수있는 것은 name과 body뿐이기 때문에 이슈를 만들때는 이슈탭에서 만드는것을 추천합니다. 101 | 102 | 103 | 104 | 이슈와 풀 리퀘스트의 경우에는 표시된 부분에서 원하는 프로젝트에 할당시킬 수있습니다. 그리고 할당시키는 경우에는 프로젝트에 할당되어있는 자동화 설정에 따라서 자동으로 할당이 됩니다. 105 | 106 | --- 107 | 108 | ### 자동화 109 | 110 | 자동화란 깃헙 프로젝트에서 기본적으로 제공하는 To Do, In Progress, Done 에 맞춰서 이슈, 풀 리퀘스트가 생성되거나 닫힐 경우 프로젝트 내에서 알아서 이동을 해주는 것을 의미합니다. 111 | 112 | 물론 이름을 해당하는 프리셋에 맞춰서 설정할 필요는 없고, 프리셋 하나만 할당 한 뒤에 원하는 자동화 옵션을 선택해주시면 됩니다. 113 | 114 | 115 | 116 | To do 117 | 118 | 1. Issue 119 | - Newly added : 새로운 이슈를 생성하고 해당 프로젝트에 설정할 경우 해당 옵션을 선택한 컬럼에 할당됩니다. 120 | - Reopened : 닫혀 있던 이슈를 다시 오픈시키는 경우 해당 옵션을 선택한 컬럼에 할당됩니다. 121 | 2. Pull request 122 | - Newly added : 새로운 풀 리퀘스트를 생성하고 해당 프로젝트에 설정할 경우 해당 옵션을 선택한 컬럼에 할당됩니다. 123 | - Reopened : 닫혀 있던 풀 리퀘스트를 다시 오픈시키는 경우 해당 옵션을 선택한 컬럼에 할당됩니다. 124 | 125 | 126 | 127 | 1. Issue 128 | - Reopened : 닫혀 있던 이슈를 다시 오픈시키는 경우 해당 옵션을 선택한 컬럼에 할당됩니다. 129 | 2. Pull request 130 | - Newly added : 새로운 풀 리퀘스트를 생성하고 해당 프로젝트에 설정할 경우 해당 옵션을 선택한 컬럼에 할당됩니다. 131 | - Reopened : 닫혀 있던 풀 리퀘스트를 다시 오픈시키는 경우 해당 옵션을 선택한 컬럼에 할당됩니다. 132 | - Approved by reviewer : 리뷰어들의 최소 승인 검토 횟수를 충족한 경우 해당 옵션을 선택한 컬럼으로 할당됩니다. 133 | - Pending approval by reviewer : 리뷰어들이 코드 변경을 요청하거나 최소 승인 검토 횟수를 충족하지 못한 경우 해당 옵션을 선택한 컬럼으로 할당됩니다. 134 | 135 | 136 | 137 | 1. Issue 138 | - Closed : 이슈가 닫히는 경우 해당 옵션을 선택한 컬럼에 할당됩니다. 139 | 2. Pull request 140 | - Merged : 풀 리퀘스트가 머지 된 경우 해당 옵션을 선택한 컬럼에 할당됩니다. 141 | - Closed with unmerged commits : 경우 해당 옵션을 선택한 컬럼에 할당됩니다. 142 | - Approved by reviewer : 리뷰어들의 최소 승인 검토 횟수를 충족한 경우 해당 옵션을 선택한 컬럼으로 할당됩니다. 143 | - Pending approval by reviewer : 리뷰어들이 코드 변경을 요청하거나 최소 승인 검토 횟수를 충족하지 못한 경우 해당 옵션을 선택한 컬럼으로 할당됩니다. 144 | 145 | 해당하는 자동화 옵션들을 상황에 맞게 설정해놓으면 좀 더 편하게 사용할수있겠죠?? 146 | 147 | --- 148 | 149 | ### URL 공유 150 | 151 | 프로젝트에 속한 컬럼, 카드를 URL로 공유할 수 있습니다. 152 | 153 | 154 | 155 | 156 | 157 | 158 | 159 | ---- 160 | 161 | ## 참고 162 | 163 | - [Git reference](https://help.github.com/en/github/managing-your-work-on-github/managing-project-boards) 164 | - 오픈소스 라이브러리 [YPImagePicker](https://github.com/Yummypets/YPImagePicker/projects/2) 에서 사용하고 있는 프로젝트 사용 예시 165 | 166 | -------------------------------------------------------------------------------- /Git-Github-Collaborating.md: -------------------------------------------------------------------------------- 1 | # Git의 다양한 협업 워크플로우 2 | 3 | **Git 그 자체**를 놓고 보면, **유연성**에 초첨이 맞춰져 있다. 따라서, Git을 어떻게 사용하는지에 대해서는 **표준화 된 것이 없다**. 4 | 5 | 그래서 우리는 **Git 으로 협업을 할 때**, **일관되고 생산적인 방식**으로 작업을 하기 위하여 몇가지 **권장되는 워크플로우 방식**을 따를 수 있다. 6 | 7 | 이러한 워크플로우는 **구체적인 규칙보다는 지침 정도로만 설계**되어 있고, 우리는 프로젝트의 **다양한 측면에서 필요에 맞게 선택**할 수 있다. 8 | 9 | 10 | 11 | # Feature Branch Workflow 12 | 13 | - Feature Branch Workflow의 핵심 아이디어는 **모든 기능 구현을 기능(feature) 브랜치에서 작업**하는 것이다. 14 | - **다수의 팀 구성원**이 **메인 코드 베이스(master)를 중심**으로 해서 안전하게 **새로운 기능을 개발**할 수 있다. 15 | - Feature Branch Workflow와 풀 리퀘스트(Pull Request)를 결합하면 팀 구성원 간에 **변경 내용에 대한 소통을 촉**진해서 **코드 품질을 높일 수 있다**. 16 | 17 | - **소규모 인원의 프로젝트**에서 사용하는 워크플로우이다. 18 | - 여러 워크플로우들이 Feature Branch Workflow를 기본 모델로 한다. 19 | 20 | 21 | 22 | ### 원격(remote) 저장소와, 로컬(local) 저장소 23 | 24 | 우선 Feature Branch Workflow는 중앙 원격(remote) 저장소(repository)를 기준으로 한다. 25 | 26 | 중앙 원격 저장소를 기준으로 각자의 로컬(local) 저장소에 클론을 하여 작업을 수행한다. 27 | 28 | ```bash 29 | # 터미널에서 자신의 원하는 디렉터리 이동한 후 아래의 명령어를 입력 30 | # 해당 디렉터리 31 | # --하위--> remote repository와 동일한 이름의 디렉터리 생성 32 | $ git clone [중앙 remote repository URL] 33 | ``` 34 | 35 | - git clone 명령은 아래의 명령들을 포함한 작업이다. 36 | 37 | ```bash 38 | # 해당 디렉터리를 빈 Git 저장소로 만드는 작업 39 | $ git init 40 | # 현재 작업 중인 Git 저장소에 팀의 중앙 원격 저장소를 추가한다. 이름을 origin으로 짓고 긴 서버 주소(URL) 대신 사용한다. 41 | $ git remote add origin [중앙 remote repository URL] 42 | # 중앙 원격 저장소(origin)의 master 브랜치 데이터를 로컬에 가져오기만 하는 작업 43 | $ git fetch origin master 44 | ``` 45 | 46 | ### 기능 브랜치(feature branch) 생성 47 | 48 | ![new-feature](https://wac-cdn.atlassian.com/dam/jcr:223f5106-2191-4450-8916-e5c80d7d907a/02.svg?cdnVersion=912) 49 | 50 | 같은 프로젝트의 팀원들은 각자의 맡은 기능 구현에 대해 마스터 브랜치에서 작업하지 않고, 마스터 브랜치를 기준으로 한 브랜치를 만든다. 이를 Feature Branch라고 한다. 51 | 52 | ```bash 53 | $ git checkout -b new-feature master 54 | 55 | # 위의 명령어는 아래의 두 명령어를 합한 것 56 | $ git branch [branch name] 57 | $ git checkout [branch name] 58 | ``` 59 | 60 | ### 기능 구현, 커밋, 원격 저장소에 푸시(push)하기 61 | 62 | 프로젝트 요구사항에 따라 각자 정해진 기능을 해당 기능 브랜치에서 구현하고, 현재 작업 진행에 따라 커밋을 한다. 63 | 64 | ```bash 65 | $ git status 66 | $ git add 67 | $ git add . 68 | $ git commit -m "new feature" 69 | 70 | # 위의 과정을 아래에 명령어로 통합할 수 있다. 71 | $ git commit -a -m "new feature" 72 | ``` 73 | 74 | push-origin 75 | 76 | 기능 구현이 완료 되었다면 현재까지 진행된 모든 변경사항을 원격 저장소에 올려야한다. 77 | 78 | 다른 팀원과 협업할 때 백업 역할을 하며, 새 기능의 커밋을 볼 수 있는 접근 권한을 부여할 수 있다. 79 | 80 | 마스터 브랜치와 별개로 업데이트 되는 것이므로, 얼마든지 기능 브랜치를 올릴 수 있다. 81 | 82 | ```bash 83 | $ git push -u origin new-feature 84 | # -u 플래그는 해당 브랜치를 원격 추적 브랜치로 만든다. 85 | # 이 플래그를 사용하면 해당 작업 이후부터 브랜치 이름을 명시하지 않아도 된다. 86 | $ git push 87 | ``` 88 | 89 | ### 풀 리퀘스트(Pull Request) 생성 90 | 91 | ![pull-request](https://wac-cdn.atlassian.com/dam/jcr:2119c2a3-7dff-43ad-bf98-77672d93242f/05%20(1).svg?cdnVersion=912) 92 | 93 | 자신이 새로 구현한 기능에 대해 풀 리퀘스트를 생성한다. 풀 리퀘스트를 활용하면 다른 팀원에게 자신의 구현한 기능에 대한 코멘트를 받을 수 있다. 이 과정은 협업 과정에서 아주 중요한 역할을 할 수 있다. 다른 팀원을 명시하여 풀 리퀘스트를 생성하고 해당 기능에 대해 리뷰를 요청할 수 있다. 풀 리퀘스트에 대한 자세한 고찰은 나중에 다룰 것이다. 94 | 95 | 풀 리퀘스트는 Github, Bitbucket 등의 원격 저장소 서비스를 활용해야 한다. 96 | 97 | ### 풀 리퀘스트 병합(merge) 98 | 99 | 새로운 기능 브랜치가 이상이 없다면 풀 리퀘스트를 병합한다. 100 | 101 | - 이 때 만약 병합 충돌(merge conflict)이 생겨 자동 병합이 안된다면 해당 충돌을 반드시 해결해야 한다. 102 | 103 | ![merge](https://wac-cdn.atlassian.com/dam/jcr:09308632-38a3-4637-bba2-af2110629d56/07.svg?cdnVersion=912) 104 | 105 | 문제 없이 병합이 완료 되었다면 마스터 브랜치에 해당 기능이 반영 완료된 것이다. 106 | 107 | 이제 원격 저장소의 마스터에 생긴 변경 사항을 로컬에도 최신화해야 한다. 108 | 109 | ```bash 110 | $ git checkout master 111 | $ git pull origin master 112 | ``` 113 | 114 | 만약 다른 팀원의 기능 브랜치에 기여를 하고 싶다면 로컬로 가져와 작업을 할 수 있다. 115 | 116 | ```bash 117 | $ git pull origin new-feature 118 | ``` 119 | 120 | 해당 작업은 여럿 충돌을 야기할 수 있기 때문에, 고려하여 작업해야 한다. 121 | 122 | 123 | 124 | # Gitflow Workflow 125 | 126 | - 빈센트 드리센(Vincent Drissen)이 고안한 [Gitflow](https://nvie.com/posts/a-successful-git-branching-model) Workflow는 **더 큰 프로젝트를 관리하기 위해 설계**되었다. 127 | - 프로젝트 **릴리스(release)를 중심으로 설계**된 엄격한 브랜치 모델을 정의하고 있다. 128 | - Gitflow는 **릴리즈 사이클이 예정된 프로젝트에 이상적으로 적합**하다. 129 | - Gitflow Workflow도 [Feature Branch Workflow](#feature-branch-workflow)와 같이 팀 구성원 간의 협업을 위해 중앙 원격 저장소를 사용한다. 즉, 로컬 브랜치에서 작업하고 중앙 원격 저장소에 푸시한다. 130 | 131 | ### git-flow 설치하기 132 | 133 | Gitflow는 Git Workflow에 대한 추상적인 아이디어일 뿐이다. 이 개념을 툴로 만든 git의 확장 패키지인 **git-flow**가 있다. 134 | 135 | 만약 macOS 환경이라면 `brew install git-flow` 을 통해 설치가 가능하다.(homebrew 사용 가정) 136 | 137 | git-flow를 설치한 후에는 `git flow init`를 실행하여 프로젝트에서 사용할 수 있다. 이 명령은 `git init` 을 포함한 확장된 명령이고, 저장소에서 사용자를 위한 브랜치를 자동으로 생성해주는 것 외에는 다른 점은 없다. 138 | 139 | 140 | 141 | ### Master와 Develop 브랜치 142 | 143 | Gitflow는 단일 마스터 브랜치 대신에 두 개의 브랜치를 사용한다. 144 | 145 | - 마스터(master) 브랜치는 공식 릴리즈 이력을 저장한다. 즉, 실제 출시한 소프트웨어의 한 버전(version)을 의미한다. 146 | - 개발(develop) 브랜치는 기능들의 통합 브랜치 역할을 한다. 이 브랜치를 기반으로 모든 구현이 이루어진다. 147 | 148 | 첫번째 단계는 마스터 브랜치로 부터 개발 브랜치를 생성하고 원격 저장소에 푸시하는 것에서 시작된다. 149 | 150 | ```bash 151 | $ git branch develop 152 | $ git push -u origin develop 153 | ``` 154 | 155 | 다른 개발자들은 이제 중앙 저장소를 클론하여 로컬 저장소를 만들고 모든 브랜치를 체크아웃한다. 156 | 157 | 바로 직전에 우리는 `git-flow`에 대해 소개하였다. 방금 진행한 일련의 과정을 `git-flow` 가 도와준다. 158 | 159 | ```bash 160 | $ git flow ini 161 | No branches exist yet. Base branches must be created now. 162 | Branch name for production releases: [master] 163 | Branch name for "next release" development: [develop] 164 | 165 | How to name your supporting branch prefixes? 166 | Feature branches? [feature/] 167 | Release branches? [release/] 168 | Hotfix branches? [hotfix/] 169 | Support branches? [support/] 170 | Version tag prefix? [] 171 | $ git branch 172 | * develop 173 | master 174 | ``` 175 | 176 | 177 | 178 | ### Feature 브랜치 179 | 180 | 기능(Feature) 브랜치는 [Feature Branch Workflow](#feature-branch-workflow)와 마찬가지로 실질적인 기능 구현이 이루어진다. 181 | 182 | 가장 최신의 개발 브랜치로부터 생성되며 마스터 브랜치와는 절대로 상호작용해서는 안된다. 183 | 184 | feature-branch 185 | 186 | - `git-flow` 없이 생성 187 | 188 | ```bash 189 | $ git checkout develop 190 | $ git checkout -b feature_branch 191 | ``` 192 | 193 | - `git-flow` 를 이용하여 생성 194 | 195 | ```bash 196 | $ git flow feature start feature_branch 197 | ``` 198 | 199 | 기능 구현이 완료되면 개발 브랜치로 병합한다. 200 | 201 | - `git-flow` 없이 병합 202 | 203 | ```bash 204 | $ git checkout develop 205 | $ git merge feature_branch 206 | ``` 207 | 208 | - `git-flow` 를 이용하여 병합 209 | 210 | ```bash 211 | $ git flow feature finish feature_branch 212 | ``` 213 | 214 | 만약, 구현이 완료된 기능 브랜치를 풀 리퀘스트를 통해 개발 브랜치에 병합하고 싶다면 [Feature Branch Workflow](#feature-branch-workflow)와 같은 방식으로 하면 된다. 215 | 216 | ### Release Branch 217 | 218 | 개발이 실제 출시를 위한 충분한 기능 구현이 완료되었다면, 개발 브랜치로 부터 릴리즈(release) 브랜치를 생성한다. 219 | 220 | 릴리즈 브랜치에서는 버그 수정, 문서 생성 및 기타 릴리즈 준비를 위한 작업들을 수행한다. 221 | 222 | 릴리즈(실제 소프트웨어의 출시)가 완료 되었다면, 223 | 224 | - 릴리즈 브랜치는 마스터 브랜치로 병합되고 버전 번호를 태그로 부여한다. 225 | 226 | - 또한, 개발 브랜치에도 병합이 이루어 진다. 227 | 228 | ![release](https://wac-cdn.atlassian.com/dam/jcr:a9cea7b7-23c3-41a7-a4e0-affa053d9ea7/04%20(1).svg?cdnVersion=913) 229 | 230 | 릴리즈 브랜치를 사용하면 한 팀이 현재 릴리즈 브랜치를 수정할 수 있고, 다른 팀은 다음 릴리즈의 기능을 계속 개발할 수 있다. 231 | 232 | 233 | 234 | 릴리즈 브랜치를 생성하는 작업은 간단하다. 기능 브랜치와 마찬가지로 개발 브랜치로 부터 생성하면 된다. 235 | 236 | - `git-flow` 없이 생성 237 | 238 | ```bash 239 | $ git checkout develop 240 | $ git checkout -b release/0.1.0 241 | ``` 242 | 243 | - `git-flow` 를 이용하여 생성 244 | 245 | ```bash 246 | $ git flow release start 0.1.0 247 | 새로 만든 'release/0.1.0' 브랜치로 전환합니다 248 | 249 | Summary of actions: 250 | - A new branch 'release/0.1.0' was created, based on 'develop' 251 | - You are now on branch 'release/0.1.0' 252 | 253 | Follow-up actions: 254 | - Bump the version number now! 255 | - Start committing last-minute fixes in preparing your release 256 | - When done, run: 257 | 258 | git flow release finish '0.1.0' 259 | ``` 260 | 261 | 릴리즈가 완료 되었다면, 마스터와 개발 브랜치로 병합하고 해당 릴리즈 브랜치는 삭제된다. 262 | 263 | 릴리즈 과정에서 새롭게 수정된 사항들이 새로운 기능 구현에 필요할 수 있기때문에 다시 개발 브랜치로 병합되는 것은 중요하다. 264 | 265 | 만약, 우리의 팀이 코드 리뷰를 강조하고 있다면, 이 과정에서 풀 리퀘스트를 사용할 수 있다. 266 | 267 | - `git-flow` 없이 릴리즈 완료 268 | 269 | ```bash 270 | $ git checkout master 271 | $ git merge release/0.1.0 272 | ``` 273 | 274 | - `git-flow` 를 이용하여 릴리즈 완료 275 | 276 | ```bash 277 | $ git flow release finish '0.1.0' 278 | ``` 279 | 280 | ### Hotfix Branches 281 | 282 | 핫픽스(hotfix) 브랜치는 현재 릴리즈 완료되어있는 소프트웨어에서 결함이 발견되었을 시, 신속한 대응을 하기 위해 사용된다. 283 | 284 | Gitflow 워크플로우에서 유일하게 마스터 브랜치를 기반으로 생성되는 브랜치이다. 285 | 286 | 결함 수정이 완료되었다면 즉시 개발, 마스터 브랜치로 병합되어야 하고, 마스터 브랜치는 새로운 버전 번호가 태그된다. 287 | 288 | 핫픽스 브랜치 라인을 갖추고 있는 소프트웨어는 나머지 워크플로우를 중단하거나 다음 릴리즈를 기다리지 않고 빠르게 결함을 수정할 수 있다. 289 | 290 | ![hotfix](https://wac-cdn.atlassian.com/dam/jcr:61ccc620-5249-4338-be66-94d563f2843c/05%20(2).svg?cdnVersion=913) 291 | 292 | - `git-flow` 없이 생성 293 | 294 | ```bash 295 | $ git checkout master 296 | $ git checkout -b hotfix_branch 297 | ``` 298 | 299 | - `git-flow` 를 이용하여 생성 300 | 301 | ```bash 302 | $ git flow hotfix start hotfix_branch 303 | ``` 304 | 305 | 릴리즈 브랜치와 마찬가지로, 핫픽스가 완료되고 나면 개발, 마스터 브랜치에 병합된다. 306 | 307 | - `git-flow` 없이 핫픽스 완료 308 | 309 | ```bash 310 | $ git checkout master 311 | $ git merge hotfix_branch 312 | $ git checkout develop 313 | $ git merge hotfix_branch 314 | $ git branch -D hotfix_branch 315 | ``` 316 | 317 | - `git-flow` 를 이용하여 릴리즈 완료 318 | 319 | ```bash 320 | $ git flow hotfix finish hotfix_branch 321 | ``` 322 | 323 | ### 요약 324 | 325 | Gitflow의 전체 흐름을 요약하면 다음과 같다. 326 | 327 | 1. **마스터(master) 브랜치**로 부터 **개발(develop) 브랜치가 생성**된다. 328 | 329 | 2. **개발 브랜치**로 부터 **릴리즈(release) 브랜치가 생성**된다. 330 | 3. **개발 브랜치**로 부터 **기능(feature) 브랜치가 생성**된다. 331 | 4. **기능 구현이 완료**되면 **개발 브랜치로 병합**된다. 332 | 333 | 5. **릴리즈가 완료**되면 **개발, 마스터 브랜치로 병합**된다. 334 | 6. 만약 **마스터에서 결함이 발견**되면, 마스터 브랜치로 부터 **핫픽스(hotfix) 브랜치가 생성**된다. 335 | 336 | 7. **핫픽스가 완료**되면 **개발, 마스터 브랜치로 병합**된다. 337 | 338 | 339 | 340 | # Forking Workflow 341 | 342 | - Forking Workflow는 앞서 설명한 워크플로우와 근본적으로 다르다. 앞선 두개의 워크플로우는 중앙 원격 저장소는 하나 이고 자신의 로컬 저장소로 클론을 하여 협업을 하였다면, Forking Workflow는 **공식적으로 기준이 되는 원격 저장소와 더불어 모든 참여자가 개인 원격 저장소를 지닌다**. 343 | 344 | - Forking Workflow의 장점은 **모든 참여자가 단일 중앙 저장소에 통합할 필요가 없다**는 것이다. 345 | - 각각의 참여자는 **자신의 원격 저장소에 모든 변경사항을 푸시**하고, **해당 프로젝트의 관리자만이 기준 원격 저장소에 변경사항을 반영**할 수 있다. 346 | - 이를 통해 관리자는 **공식 프로젝트 베이스에 대한 쓰기 권한을 부여하지 않고 참여자들의 변경사항을 제어**할 수 있다. 347 | - 아주 **큰 규모의 분산된 팀(신뢰할 수 없는 제 3자를 포함)**에서도 안전하게 협업하기에 좋은 협업 방법이다. 348 | - **오픈 소스 프로젝트에 이상적인 워크플로우**이다. 349 | 350 | > ### 포크(Fork) vs 클론(Clone) 351 | > 352 | > Forking Workflow에서 말하는 포크(fork)라는 개념은 특별한 것이 아니다. 원격 저장소를 포크한다는 것은 표준 `git clone` 명령어를 통해 이루어진다. 포크된 저장소는 일반적으로 Github, Bitbucket과 같은 서비스의 원격 저장소를 의미한다. fork된 레포지토리를 생성하기 위한 고유한 Git 명령어는 없다. 본질적으로, 클론(clone)은 저장소와 그 기록을 복사하는 것을 의미한다. 353 | > 354 | > ### Forking Workflow에서의 브랜치 나누기 355 | > 356 | > Forking Workflow에서 모든 개인 원격 저장소는 프로젝트의 다른 참여자들과 브랜치를 공유하는 편리한 방법일 뿐이다. [Feature Branch Workflow](#feature-branch-workflow)와 [Gitflow Workflow](#gitflow-workflow) 처럼 모든 참여자가 브랜치를 사용하여 개별 기능을 분리해야 한다. 유일한 차이점은 그 브랜치들이 ''어떻게 공유되는지'' 이다. 357 | 358 | 359 | 360 | ### 중앙 원격 저장소로 부터 포크(fork)를 하여 개인 원격 저장소 생성 361 | 362 | ![fork](https://www.atlassian.com/dam/jcr:642c56e3-ddc6-43ff-ab86-c5cd845afd05/03.svg) 363 | 364 | 다른 Git Workflow와 마찬가지로, Forking Workflow도 기준이되는 원격 저장소에서 시작한다. Github이나 Bitbucket 같은 원격 저장소 호스팅 서비스에서 지원하는 포크기능으로 자신의 개인 원격 저장소를 생성한다. 365 | 366 | ### 개인의 원격 저장소를 로컬 저장소로 클론 367 | 368 | 각 참여자는 포크된 자신의 원격 저장소를 로컬저장소로 클론한다. 369 | 370 | ```bash 371 | # Github 서비스 기준으로 한다. 372 | $ git clone https://github.com/[유저닉네임]/Github-Cookbook.git 373 | ``` 374 | 375 | ### 원격(remote) 추가 376 | 377 | 다른 워크플로우에서는 중앙 원격 저장소를 가리키는 단일 origin remote를 사용하는 반면, Forking Workflow에서는 공식 기준 원격 저장소와 참여자의 개인 원격 저장소, 각각 두 개의 remote가 필요하다. 378 | 379 | 두 개의 remote에서 최신 변경사항을 적용할 수 있지만, 일반적으로 포크된 개인 원격 저장소를 origin remote로 사용하고(이 것은 git clone을 수행할 때 자동으로 생성된다.), 공식 기준 원격 저장소를 upstream remote로 사용한다. 380 | 381 | ```bash 382 | # 이 문서의 작성자의 원격 저장소를 기준 저장소로 한다. 383 | $ git remote add upstream https://github.com/soogoon/Github-Cookbook.git 384 | ``` 385 | 386 | 387 | 388 | ### 브랜치에서 기능 구현, 커밋, 개인 원격 저장소에 푸시하기 389 | 390 | 각 참여자의 로컬 저장소에서 다른 워크플로우와 마찬가지로 브랜치를 생성하고 코드를 편집하고 변경 사항을 커밋한다. 391 | 392 | ```bash 393 | $ git checkout -b some-feature 394 | # 기능 구현 395 | $ git commit -a -m "Add first draft of some feature" 396 | ``` 397 | 398 | 모든 변경 사항은 프로젝트의 기준 원격 저장소로 반영되기 전까지는 각 참여자에게만 적용되어 있을 뿐이다. 399 | 400 | 만약 다른 참여자의 기능 구현이 공식 프로젝트에 반영되었다면, 각 참여자는`git pull` 로 새로운 커밋을 적용할 수 있다. 401 | 402 | ```bash 403 | $ git pull upstream master 404 | ``` 405 | 406 | 각 참여자들은 개인 전용 기능 브랜치에서 작업을 하므로, 기능 구현의 단위는 작게, 변경사항을 병합하는 시간은 짧게 가져가는 것이 좋다. 407 | 408 | ### 풀 리퀘스트 생성 409 | 410 | ![make-pull-request](https://www.atlassian.com/dam/jcr:0de71551-5c08-4fc4-ab6d-dc8a51bfcc5a/05.svg) 411 | 412 | 한 참여자가 자신의 새로운 기능을 프로젝트에 반영하기 위해서는 두가지 작업이 필요하다. 413 | 414 | 첫번째로, 포크된 개인 원격 저장소에 변경 사항을 푸시한다. 다른 참여자들이 자신이 구현한 내용에 접근할 수 있어야 한다. 415 | 416 | ```bash 417 | $ git push origin feature-branch 418 | ``` 419 | 420 | 두번째로, 프로젝트 관리자에게 자신의 기능을 공식 코드베이스에 통합하고 싶다고 통지해야한다. 421 | 422 | 이 과정에서 Github, Bitbucket 같은 서비스는 풀 리퀘스트를 제안한다. 423 | 424 | ### 요약 425 | 426 | Fork Workflow는 **일반적으로 오픈소스 프로젝트에 많이 사용**된다. 포크는 원격 저장소를 복사하는 `git clone` 작업이다. Fork Workflow는 Github, Bitbucket과 같은 Git 호스팅 서비스와 함께 자주 사용된다. 427 | 428 | 전체 흐름을 요약하면 다음과 같다. 429 | 430 | 1. https://github.com/userA/open-source-project 에서 **호스팅 되는 오픈소스 라이브러리에 컨트리뷰터로 참여**하려면, 431 | 2. **오픈소스를 포크**하여 https://github.com/yourName/open-source-project (개인 원격 저장소)를 만든다. 432 | 3. https://github.com/yourName/open-source-project에서 `git clone` 을 실행하여 로컬 저장소를 생성한다. 433 | 4. 로컬에서 새로운 기능 브랜치를 생성, 기능 구현, 커밋이 실행된다. 434 | 5. 그런 다음 **새로운 기능 브랜치를 포크된 원격 저장소에 푸시**한다. 435 | 6. Github를 사용하여 **원래의 저장소(기여하고자하는 오픈소스 라이브러리)로 새로운 브랜치에 대한 풀 리퀘스트를 생성**한다. 436 | 437 | 438 | 439 | ## 참고 문서 440 | 441 | > - https://www.atlassian.com/git/tutorials/comparing-workflows 442 | > - https://gmlwjd9405.github.io/2017/10/27/how-to-collaborate-on-GitHub-1.html 443 | > - https://gmlwjd9405.github.io/2017/10/28/how-to-collaborate-on-GitHub-2.html 444 | > - https://gmlwjd9405.github.io/2018/05/12/how-to-collaborate-on-GitHub-3.html -------------------------------------------------------------------------------- /Github-Issue.md: -------------------------------------------------------------------------------- 1 | # Issue Tracking 2 | 3 | ### Issue가 무엇인가요? 4 | 5 | 프로젝트를 진행하면서 발생하는 모든 이슈를 뜻합니다. 6 | (버그 발생, 개발, 풀 리퀘스트 등등..) 7 | 8 | 9 | 10 | * GitHub 공식문서 [About issues](https://help.github.com/en/github/managing-your-work-on-github/about-issues) 11 | 12 | > Use issues to track ideas, enhancements, tasks, or bugs for work on GitHub. 13 | > 14 | > You can collect user feedback, report software bugs, and organize tasks you'd like to accomplish with issues in a repository. 15 | > 16 | > You can link a pull request to an issue to show that a fix is in progress and to automatically close the issue when someone merges the pull request. 17 | 18 | 19 | 20 | ✔️깃헙에서는 issue 기능을 통해 프로젝트에서 발생하는 모든 문제를 관리할 수 있도록 돕는다. 21 | 22 | 23 | 24 | ### Issue 생성하기 25 | 26 | * 이슈는 유저의 이슈 사용이 허용된 깃헙 레포지토리에서 생성할 수 있다. (이슈를 사용 안하도록 설정할 수도 있다.) 27 | ![레포이슈생성](/Github-Issues-Imgs/레포이슈생성.png) 28 | [Disabling Issues](https://help.github.com/en/github/managing-your-work-on-github/disabling-issues) 29 | 30 | * 이슈는 현재 존재하는 풀 리퀘스트의 코드로도 생성할 수 있다. 31 | 풀리퀘를 하고있는 파일을 View File을 한 후 코드를 선택해서 이슈를 생성할 수 있다. 32 | 33 | ![코드이슈생성](/Github-Issues-Imgs/코드이슈생성.png) 34 | [Opening an issue from code](https://help.github.com/en/github/managing-your-work-on-github/opening-an-issue-from-code) 35 | 36 | * 또한, 하나의 이슈 또는 풀 리퀘스트의 리뷰에 있는 코멘트로부터도 바로 이슈를 생성할 수 있다. 37 | 38 | ![코드이슈생성](/Github-Issues-Imgs/코멘트이슈생성.png) 39 | [Opening an issue from a comment](https://help.github.com/en/github/managing-your-work-on-github/opening-an-issue-from-a-comment) 40 | 41 | * 만약 업무의 우선순위와 추적을 위해 프로젝트를 사용하고 있다면, 프로젝트 보드 노트를 이슈로 바꿀 수도 있다. 42 | 43 | [5anniversary의 project 스터디 자료 참고](https://github.com/soogoon/Github-Cookbook/blob/master/About-Git-Project.md) 44 | [Adding notes to a project board](https://help.github.com/en/github/managing-your-work-on-github/adding-notes-to-a-project-board#converting-a-note-to-an-issue) 45 | 46 | 47 | 48 | 아래는 기본적인 이슈 생성 방법이다. 49 | 50 | ![기본이슈생성](/Github-Issues-Imgs/기본이슈생성.png) 51 | 52 | 이슈를 만들 Repository에서 Issue탭의 New Issue를 클릭한다. 53 | 이슈는 제목과 이슈에 대한 설명을 적을 수 있다. 54 | 55 | 56 | 57 | ![이슈리스트](/Github-Issues-Imgs/이슈리스트.png) 58 | 59 | 생성된 이슈는 리스트 형태로 관리하기 힘들어 보인다. 60 | 이슈가 엄청 많다면? ~~특정 이슈를 찾기 힘들어질 것이다.~~ 61 | 62 | 63 | 64 | ### Label 기능 65 | 66 | ✔️이러한 문제점을 개선하기 위해 우리는 **Label 기능을 사용**한다. 67 | 68 | **각 이슈에 대한 Labeling을 통해 이슈를 검색할 수 있고, 이슈별 주제를 구분할 수 있다.** 69 | 70 | ![라벨1](/Github-Issues-Imgs/라벨1.png) 71 | 72 | Labels 버튼에서 새로운 라벨을 만들 수 있고, 기본으로 있는 라벨을 사용할 수도 있다. (컬러 지정도 가능) 73 | 74 | 75 | 76 | ![라벨생성](/Github-Issues-Imgs/라벨생성.png) 77 | 78 | 라벨을 커스텀하여 생성할 수 있다. 79 | 80 | 81 | 82 | ![이슈상세페이지_라벨지정](/Github-Issues-Imgs/이슈상세페이지_라벨지정.png) 83 | 84 | ![이슈상세페이지_라벨지정결과](/Github-Issues-Imgs/이슈상세페이지_라벨지정결과.png) 85 | 86 | 이슈 상세페이지에서 이슈를 생성한 라벨로 지정할 수 있다. 87 | 88 | ==라벨을 나누는 기준?== 89 | 90 | 라벨은 이슈의 우선순위, 카테고리, 다른 유용한 정보들을 나누는 기준으로 만들어야한다. 91 | (작은 단위일수록 좋다. ) 92 | 93 | 94 | 95 | ### Assignees 부여 96 | 97 | ✔️또한, 해당 이슈에 대해 Assignees(책임자)를 부여할 수 있다. 98 | 99 | ![이슈상세페이지_책임자지정](/Github-Issues-Imgs/이슈상세페이지_책임자지정.png) 100 | 101 | ![이슈상세페이지_책임자지정결과](/Github-Issues-Imgs/이슈상세페이지_책임자지정결과.png) 102 | 103 | 104 | 105 | ![이슈리스트_후](/Github-Issues-Imgs/이슈리스트_후.png) 106 | 107 | 라벨과 책임자를 부여한 후 이슈 리스트를 보면 깔끔하게 정리되어있는 것을 확인할 수 있다. 108 | 지정한 label과 assignee를 통해 Filters 란에서 필터링하여 이슈를 검색할 수 있다. 109 | 110 | 111 | 112 | 하지만, Label과 Assignee를 부여해도 각 기능별 서로 유사한 이슈들이 존재하며, 이와 관련된 이슈를 찾거나 해당 기능들이 얼마나 구현되어 있는지 파악하기 위해서는 일일히 추적해야한다. 113 | 114 | 115 | 116 | ### Milestone 설정 117 | 118 | ✔️이러한 문제점을 해결하는 기능이 **Milestone**이다. 119 | 120 | 마일스톤은 말 그대로 이정표 역할을 하며, **이슈들을 그룹화**한다. 121 | 122 | ![마일스톤생성](/Github-Issues-Imgs/마일스톤생성.png) 123 | 124 | ![마일스톤리스트](/Github-Issues-Imgs/마일스톤리스트.png) 125 | 126 | 이슈 탭의 Milestones에서 마일스톤을 생성할 수 있다. 127 | 128 | 129 | 130 | ![이슈상세페이지_마일스톤지정](/Github-Issues-Imgs/이슈상세페이지_마일스톤지정.png) 131 | 132 | ![이슈상세페이지_마일스톤지정결과](/Github-Issues-Imgs/이슈상세페이지_마일스톤지정결과.png) 133 | 134 | 이슈 상세페이지에서 마일스톤을 지정할 수 있다. 135 | 136 | 137 | 138 | ![이슈상세페이지_클로즈](/Github-Issues-Imgs/이슈상세페이지_클로즈.png) 139 | 140 | ![이슈상세페이지_클로즈후](/Github-Issues-Imgs/이슈상세페이지_클로즈후.png) 141 | 142 | 이슈는 이슈 상세페이지에서 close와 reopen을 할 수 있고, 마일스톤으로 최대 3개의 이슈까지 묶을 수 있다. 143 | 144 | 145 | 146 | ![이슈완료후마일스톤](/Github-Issues-Imgs/이슈완료후마일스톤.png) 147 | 148 | 하나의 이슈가 완료(close)된다면 마일스톤 진행상황이 업데이트된다. 149 | 150 | 또한 이슈 페이지에서 @이름을 통해 다른 사용자를 언급할 수 있고, #num을 통해 커밋, 이슈를 참조하여 소통을 원활하게 할 수 있다. 151 | 152 | 이를 통해 연관된 이슈의 추적과 진행상황을 한 눈에 파악할 수 있다. 153 | 154 | 155 | 156 | ✔️또 다르게, 풀 리퀘스트에서 이슈를 지정할 수 있다. 157 | 158 | ![풀리퀘스트_이슈지정가능](/Github-Issues-Imgs/풀리퀘스트_이슈지정가능.png) 159 | 160 | 161 | 162 | ✔️이슈 발급부터 풀 리퀘스트까지 [참고 자료](https://www.popit.kr/github로-프로젝트-관리하기-part1-이슈-발급-부터-코드리뷰까/) 163 | -------------------------------------------------------------------------------- /Github-Issues-Imgs/기본이슈생성.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soogoon/Github-Cookbook/efbcc1bf4f70f3424f13af5bf6d2b654424a0e4b/Github-Issues-Imgs/기본이슈생성.png -------------------------------------------------------------------------------- /Github-Issues-Imgs/라벨1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soogoon/Github-Cookbook/efbcc1bf4f70f3424f13af5bf6d2b654424a0e4b/Github-Issues-Imgs/라벨1.png -------------------------------------------------------------------------------- /Github-Issues-Imgs/라벨생성.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soogoon/Github-Cookbook/efbcc1bf4f70f3424f13af5bf6d2b654424a0e4b/Github-Issues-Imgs/라벨생성.png -------------------------------------------------------------------------------- /Github-Issues-Imgs/레포이슈생성.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soogoon/Github-Cookbook/efbcc1bf4f70f3424f13af5bf6d2b654424a0e4b/Github-Issues-Imgs/레포이슈생성.png -------------------------------------------------------------------------------- /Github-Issues-Imgs/마일스톤리스트.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soogoon/Github-Cookbook/efbcc1bf4f70f3424f13af5bf6d2b654424a0e4b/Github-Issues-Imgs/마일스톤리스트.png -------------------------------------------------------------------------------- /Github-Issues-Imgs/마일스톤생성.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soogoon/Github-Cookbook/efbcc1bf4f70f3424f13af5bf6d2b654424a0e4b/Github-Issues-Imgs/마일스톤생성.png -------------------------------------------------------------------------------- /Github-Issues-Imgs/이슈리스트.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soogoon/Github-Cookbook/efbcc1bf4f70f3424f13af5bf6d2b654424a0e4b/Github-Issues-Imgs/이슈리스트.png -------------------------------------------------------------------------------- /Github-Issues-Imgs/이슈리스트_후.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soogoon/Github-Cookbook/efbcc1bf4f70f3424f13af5bf6d2b654424a0e4b/Github-Issues-Imgs/이슈리스트_후.png -------------------------------------------------------------------------------- /Github-Issues-Imgs/이슈상세페이지_라벨지정.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soogoon/Github-Cookbook/efbcc1bf4f70f3424f13af5bf6d2b654424a0e4b/Github-Issues-Imgs/이슈상세페이지_라벨지정.png -------------------------------------------------------------------------------- /Github-Issues-Imgs/이슈상세페이지_라벨지정결과.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soogoon/Github-Cookbook/efbcc1bf4f70f3424f13af5bf6d2b654424a0e4b/Github-Issues-Imgs/이슈상세페이지_라벨지정결과.png -------------------------------------------------------------------------------- /Github-Issues-Imgs/이슈상세페이지_마일스톤지정.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soogoon/Github-Cookbook/efbcc1bf4f70f3424f13af5bf6d2b654424a0e4b/Github-Issues-Imgs/이슈상세페이지_마일스톤지정.png -------------------------------------------------------------------------------- /Github-Issues-Imgs/이슈상세페이지_마일스톤지정결과.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soogoon/Github-Cookbook/efbcc1bf4f70f3424f13af5bf6d2b654424a0e4b/Github-Issues-Imgs/이슈상세페이지_마일스톤지정결과.png -------------------------------------------------------------------------------- /Github-Issues-Imgs/이슈상세페이지_책임자지정.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soogoon/Github-Cookbook/efbcc1bf4f70f3424f13af5bf6d2b654424a0e4b/Github-Issues-Imgs/이슈상세페이지_책임자지정.png -------------------------------------------------------------------------------- /Github-Issues-Imgs/이슈상세페이지_책임자지정결과.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soogoon/Github-Cookbook/efbcc1bf4f70f3424f13af5bf6d2b654424a0e4b/Github-Issues-Imgs/이슈상세페이지_책임자지정결과.png -------------------------------------------------------------------------------- /Github-Issues-Imgs/이슈상세페이지_클로즈.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soogoon/Github-Cookbook/efbcc1bf4f70f3424f13af5bf6d2b654424a0e4b/Github-Issues-Imgs/이슈상세페이지_클로즈.png -------------------------------------------------------------------------------- /Github-Issues-Imgs/이슈상세페이지_클로즈후.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soogoon/Github-Cookbook/efbcc1bf4f70f3424f13af5bf6d2b654424a0e4b/Github-Issues-Imgs/이슈상세페이지_클로즈후.png -------------------------------------------------------------------------------- /Github-Issues-Imgs/이슈완료후마일스톤.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soogoon/Github-Cookbook/efbcc1bf4f70f3424f13af5bf6d2b654424a0e4b/Github-Issues-Imgs/이슈완료후마일스톤.png -------------------------------------------------------------------------------- /Github-Issues-Imgs/코드이슈생성.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soogoon/Github-Cookbook/efbcc1bf4f70f3424f13af5bf6d2b654424a0e4b/Github-Issues-Imgs/코드이슈생성.png -------------------------------------------------------------------------------- /Github-Issues-Imgs/코멘트이슈생성.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soogoon/Github-Cookbook/efbcc1bf4f70f3424f13af5bf6d2b654424a0e4b/Github-Issues-Imgs/코멘트이슈생성.png -------------------------------------------------------------------------------- /Github-Issues-Imgs/풀리퀘스트_이슈지정가능.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soogoon/Github-Cookbook/efbcc1bf4f70f3424f13af5bf6d2b654424a0e4b/Github-Issues-Imgs/풀리퀘스트_이슈지정가능.png -------------------------------------------------------------------------------- /Github-Marketplace-Explore.md: -------------------------------------------------------------------------------- 1 | # 📌 사전 준비 사항 2 | upstream 으로부터 소스코드를 동기화하기 위해 clone 한 디렉토리로 이동하여 다음과 같은 절차를 행합니다. 3 | 4 | **1.** 현재 **프로젝트에 등록된 원격 저장소**를 확인할 수 있는 명령어입니다. 5 | ``` 6 | $ git remote -v 7 | ``` 8 | **2.** 아래와 같이 origin 저장소와 **upstream 저장소**가 모두 잘 출력되는지 확인합니다. 9 | ``` 10 | origin https://github.com/ttub-nii/Github-Cookbook.git (fetch) 11 | origin https://github.com/ttub-nii/Github-Cookbook.git (push) 12 | upstream https://github.com/soogoon/Github-Cookbook.git (fetch) 13 | upstream https://github.com/soogoon/Github-Cookbook.git (push) 14 | ``` 15 | **3.** 위와 같이 나타나지 않는다면 upstream 이름으로 **원본 소스코드의 위치를 추가**합니다. 16 | ``` 17 | $ git remote add upstream https://github.com/soogoon/Github-Cookbook.git 18 | ``` 19 | **4.** fetch 명령어로 원본 소스코드의 내용을 **로컬로 내려 받습니다.** 20 | ``` 21 | $ git fetch upstream 22 | ``` 23 | **5.** 내려받은 소스코드를 내 **repository 에 merge** 합니다. 24 | ``` 25 | $ git merge upstream/master 26 | ``` 27 | **동기화가 완료되었습니다. 이제 제가 준비한 2주차 내용을 보실 수 있습니다.** 28 | 29 | # 📌 Contents 30 | 31 | * 👀[Marketplace 는 무엇을 가능하게 하나?](#Marketplace-살펴보기) 32 | * 👃🏻[Explore 탭 살펴보기](#Explore-살펴보기) 33 | * 👄[Repository 환경 제대로 알고 설정하기](#Repository-Setting-살펴보기) 34 | ---- 35 | 36 | Github 페이지를 살펴보면 생각보다 우리가 매번 쓰는 기능만 이용하고 사용하지 않는 기능이 많다는 걸 확인할 수 있습니다. 37 | 38 | 이번 주차에서는 그동안 놓치고 있었던 부분 중에서 평소에 궁금했던 **Marketplace 와 Explore 가 어떤 기능**을 제공하는지, 39 | 40 | 그리고 **Repository 환경을 설정**하는 옵션들에 대해 살펴보려고 합니다. 41 | 42 |

Main page tab menu

43 | 44 |

45 | 스크린샷 2020-03-27 오전 12 16 46 46 |

47 |

Repository Setting

48 |

49 | 스크린샷 2020-03-27 오전 12 18 36 50 |

51 | 52 | 53 | # Marketplace 살펴보기 54 | 55 | * GitHub Marketplace 영상 [시청하기](https://youtu.be/_HjToekoEMk) 56 | * GitHub Marketplace 란? [공식 문서 보기](https://developer.github.com/marketplace/) 57 | 58 | > 깃헙 공식 문서는 다음과 같이 Marketplace 를 설명합니다. 59 | >> GitHub Marketplace 는 당신을 GitHub 워크 플로우를 확장하고 개선하려는 개발자에게 연결시켜줍니다. 60 | 개발자들이 GitHub Marketplace 에서 사용할 수 있도록 무료 또는 유료 도구들을 게시 할 수 있습니다. 61 | GitHub Marketplace 는 개발자에게 GitHub 액션 및 앱이라는 두 가지 유형의 도구를 제공하며, 각 도구를 GitHub Marketplace에 추가하기 위해선 각각 다른 단계를 필요로합니다. 62 | 63 | * 쉽게 말해서, 64 | GitHub 와 연동해서 사용할 수 있도록 개발된 써드파티의 앱이나 액션을 구매할 수 있는 서비스입니다. 65 | Marketplace 에서는 GitHub 기능을 확장하는 App 과 GitHub 액션에서 사용할 수 있는 Action 을 구매할 수 있습니다. 66 | 67 | ## Apps 68 | * **Verified Apps** : 녹색 배지가 있습니다. 구독 등급 별로 제공하는 서비스가 다르고, 무료 또는 유료로 결제하여 사용할 수 있습니다. 69 | 70 | * **Unverified Apps** : 확인 된 앱에 필요한 보안, 테스트 및 확인주기를 거치지 않습니다. 목록 옆에 회색 배지가 있으며 무료 앱으로만 사용할 수 있습니다. 71 | 72 |

73 | 74 |

75 | 76 | ## Actions 77 | 서비스 약관을 충족하는 한 누구나 GitHub Marketplace 에 액션을 게시 할 수 있습니다. 78 | 79 | 앱과 달리 GitHub Marketplace 에 올라와있는 GitHub Actions 는 GitHub 에서 검증하지 않습니다. 80 | 81 |

82 | 83 |

84 | 85 | --- 86 | ### App 설치 방법 87 | 먼저 설치 방법은 굉장히 쉬웠습니다. 88 | 1. 자신이 적용하고자 하는 projects 의 성격에 따라 **Open souce, Individual, Professional 플랜**을 선택하고 **적용할 Organization** 을 선택합니다. 89 | 90 | 2. **Buy with Github** 버튼을 눌러 청구 내용을 확인한 다음 플랜에 따라 알맞은 가격을 지불하고 주문을 완료합니다. 91 | 92 | 3. 이제 설치가 시작되는데, 이때 **Organization 의 모든 Repository 에 적용**할 것인지 **특정 Repository 를 선택하여 적용**할 것인지 설정합니다. 93 | 94 | 4. 설치할 앱이 계정에 **접근할 수 있는 권한을 허용**한다면 설치가 완료됩니다. 95 | 96 | ### App 삭제 방법 97 | 설치한 앱 확인 및 삭제하는 방법은 다음과 같습니다. 98 | 1. 자신의 **account profile** 을 선택하고 **Settings** 로 들어갑니다. 99 | 100 | 2. Personal Settings 의 많은 메뉴 중 **Applications** 를 클릭합니다. 101 | 102 | 3. 해당 메뉴에서 **설치한 Github App** 과 **권한을 부여한 App** 을 확인할 수 있을 뿐만 아니라 Github 계정으로 접근했던 Applications 의 목록을 확인할 수 있습니다. 103 | 104 | ## Reviews 105 | GitHub Marketplace 에서 사용해본 앱 중 제일 괜찮았던 앱을 추천해보겠습니다. 106 | 107 | >### Apps 108 | ### [Imgbot](https://github.com/marketplace/imgbot) 109 | 110 | * Repository( Xcode project 는 보통 Assets ) 에 있는 이미지의 품질은 유지하면서 파일 크기를 줄여 무손실 압축을 시켜주는 앱 111 | > Imgbot 은 본인들의 툴을 사용해야하는 이유에 대해 이미지가 최적화 되어있을수록 더 빨리 로드되고, 페이지가 빠를수록 전환율이 높아지기 때문에 이탈률이 낮아지고 사용자가 더 행복해질 것이라고 어필하면서 자신들의 앱이 이 모든 것을 몇 번의 클릭만으로 가능할 수 있게 한다고 설명합니다. 112 | >> 사용 예시 : https://github.com/GoldenTicketGroup/GoldenTicket-iOS/pull/1 113 | 114 | ### [Codacy](https://github.com/marketplace/codacy) 115 | 116 | 117 | * Codacy 는 자동으로 코드를 분석하여 품질 관리를 해주는 도구로 개발자가 더 나은 소프트웨어를 더 빨리 제공할 수 있도록 도와주는 앱 118 | > Codacy 를 사용하면 모든 commit 과 Pull requests 마다 static 분석, 순환 복잡도, duplication, 코드 unit 테스트 커버리지 변화를 확인할 수 있습니다. 코드 퀄리티를 향상시키고, 코드 리뷰 하는 데에 시간을 절약하고, 보안을 강화하고, 개발자들이 빠르게 온보딩할 수 있도록 합니다. 119 | >> 사용 예시 : https://app.codacy.com/gh/GoldenTicketGroup/GoldenTicket-iOS/dashboard 120 | 121 | --- 122 | >### Actions 123 | ### [Assignee to reviewer](https://github.com/marketplace/actions/github-action-for-assignee-to-reviewer) 124 | 스크린샷 2020-03-27 오후 5 13 01 125 | 126 | * 유저가 assigned 되었든 unassigned 되었든 간에 Pull requests 에 대해 assigned / unassigned 이벤트를 알려주는 액션 127 | 128 | > 팀에서 Pull requests 담당자가 있지만 Review requests 시스템으로 바꾸고 싶을 때, 모든 사람이 워크 플로우를 변경하는 건 어려울 수 있습니다. 이 GitHub Action 은 담당자를 기반으로 Review requests 을 자동으로 작성하고 삭제하여 전환을 용이하게합니다. Review requests 에 의존하는 [Pull Reminders](https://pullreminders.com/) 와 같은 타사 앱을 사용할 때 특히 유용합니다. 129 | 130 | # Explore 살펴보기 131 | **Get email updates** 버튼을 누르면 이메일로 뉴스레터를 구독할 수 있습니다. 132 |

Explore 탭에 들어갔을 때 보이는 상세 메뉴

133 |

134 | 스크린샷 2020-03-27 오후 6 58 22 135 |

136 | 137 | ### Explore 138 | * 들어가면 가장 먼저 보이는 Explore 페이지에는 사용자가 관심있어 할 만한 소식을 보여주는 뷰가 가장 크게 자리잡고 있습니다. 소식들을 보여주는 기준에는 다음과 같은 항목들이 있습니다. 139 | 140 | * **repositories you’ve viewed** 141 | 142 | * **people you follow** 143 | 144 | * **topics you've starred** 145 | 146 | * **recommended by GitHub** (App, Upcoming event, Collection) 147 | 148 | * 가장 좌측에서는 사용자 프로필과 함께 사용자가 starred 한 topics 와 repositories 를 한번에 모아볼 수 있는 리스트가 있습니다. 149 | 150 | * 가장 우측에서는 오늘 하루동안 가장 스타를 많이 받은 repositories 와 스타를 많이 받은 repository 를 소유하고 있는 핫한 개발자를 소개합니다. 이것은 Trending 탭과도 연결되며, 해당 탭에서 보다 자세한 필터링을 할 수 있습니다. 151 | 152 | ### Topics 153 | * 프로그래밍 언어부터 테크닉, 개발 트랜드, 디자인 툴, 개발 환경, IDE, 라이브러리, 서비스까지 GitHub 에서 핫한 주제를 스타하여 소식을 받아볼 수 있습니다. 154 | 155 | ### Trending 156 | * 앞서 언급했던 Explore 메인 페이지 우측에 있는 탭과도 연결되는 부분으로 보다 상세한 필터링을 하여 관심 Repository 나 개발자를 팔로우할 수 있습니다. 157 | 158 | * **Spoken Language, Language, Date range(오늘, 이번주, 이번달)** 와 같은 필터가 있습니다. 159 | 160 | * 여기서 Spoken Language 는 사용자의 **Personal Setting** 에서 Profile 설정에 있는 **Trend setting** 과 연결되는 부분으로, 필터를 변경하고 싶다면 프로필 설정에서 변경하여 적용할 수 있습니다. 161 | 162 |

Profile 클릭 > Settings > Personal Settings > Profile > Trending settings

163 |

164 | 스크린샷 2020-03-27 오후 7 18 13 165 |

166 | 167 | ### Collections 168 | * 급성장하는 산업, 주제 및 커뮤니티 목록과 인사이트를 선별하여 보여줍니다. 169 | 170 | * 해시태그로 분류된 카테고리에 들어가면 해당 콜렉션과 관련된 Repository 및 라이브러리를 볼 수 있습니다. 171 | 172 | * 사용자가 직접 자신이 관심있는 주제에 대해 새로운 콜렉션을 생성할 수도 있습니다. 173 | 174 | * **새 콜렉션을 만들 시 유의 사항** 175 | 176 | * GitHub 커뮤니티에 콘텐츠를 제안할 때는 특정 사례를 제공하는 대신 다른 사람에게도 광범위하게 적용될 수 있는 주제이거나 현재 중요한 정보가 부족한 주제와 같이 가치있는 주제를 고려해야합니다. 177 | 178 | * 새로운 주제 또는 컬렉션을 제안하려면 추가 사항을 Pull requests 합니다. API 문서 및 스타일 가이드는 포함해야하는 정보와 양식에 대한 가이드라인을 제공합니다. 179 | 180 | * 이 저장소에는 추가 context 가 없는 가장 많이 사용되는 GitHub 주제 목록이 포함되어 있습니다. 풀 요청이 이러한 주제 중 하나를 추가하는 경우 주제가 선택 (완료 표시)되도록 주제 -todo.md를 업데이트하십시오. 181 | 182 | * 풀 요청 템플릿을 완전히 작성하십시오. 템플릿을 작성하지 않으면 풀 요청이 종료됩니다. 183 | 184 | * 모든 제안은 GitHub의 커뮤니티 지침 및 서비스 약관을 준수해야합니다. 당사의 서비스 약관에 따라 귀하는 귀하가 제공 한 컨텐츠에 대한 책임이 있으며 이를 사용할 권리가 있습니다. 185 | 186 | 187 | ### Events 188 | * GitHub community 와 함께 전 세계에서 열리는 컨퍼런스, 밋업, 그리고 해커톤에 참가할 수 있습니다. 189 | * 2020년 3월 5일 00시 01분부터 31일 23시 59분까지, 4주간 original GitHub Actions 을 구현하는 해커톤이 열렸었습니다. 190 | * 보너스로 선착순 1,000 개의 유효한 제출물은 무료 GitHub 사용권을 받습니다! 191 |

192 | 스크린샷 2020-03-27 오전 1 35 26 193 | 스크린샷 2020-03-27 오후 9 36 28 194 | 195 |

196 | 197 | ### GitHub Sponsors 198 | 오픈소스를 개발하여 GitbHub 에 공여한 contributors 를 계속해서 Refresh 하여 찾아볼 수 있습니다. 199 | 200 | # Repository Setting 살펴보기 201 | 앞의 내용과 구분하기 위해 따로 작성하여 업로드 하겠습니다. [다음 목차로 이동](Repository-Settings.md)하고 싶다면 202 | -------------------------------------------------------------------------------- /Github-blog-posting.md: -------------------------------------------------------------------------------- 1 | **[깃허브에 개인 블로그 만들기]** 2 | 3 | * GitHub Pages 알아보기 4 | 5 | - GitHub Pages : 저장소에 홈페이지 파일을 올린 뒤 저장소의 주소를 그래로 홈페이지 주소로 사용할 수 있는 기능 6 | 7 | - 장점 : 깃허브 저장소를 웹 서버처럼 활용 가능하기 때문에 무료로 깃허브의 저장소를 블로그나 홈페이지 공간으로 사용 가능 8 | - 정적인 페이지(ex) 포트폴리오 사이트, 기술 정보를 정리하는 블로그 등)를 제공할 때 사용하기 좋음! 9 | - .github.io 라는 이름이 붙음 -> 국내의 한 기업에서 GitHub Pages를 통해 운영하는 기술 블로그 10 | - 반응형 웹 디자인을 만드는 Bootstrap 오픈 소스의 사이트 (https://getbootstrap.com/) -> GitHub Pages를 사요해 만든 홈페이지 11 | - ![image-20200604162835232](https://user-images.githubusercontent.com/19575791/83743888-50da2400-a696-11ea-8066-48015cabd519.png) 12 | 13 | * GitHub Pages를 사용하는 2가지 방법 14 | 15 | 1. 홈페이지 파일이 있는 경우: 16 | 17 | HTML과 CSS, Javascript(또는 jQuery) 등 홈페이지 파일이 있는 경우 -> 직접 준비한 파일을 바로 깃허브 저장소에 올리고 GitHub Pages 기능을 사용해 홈페이지를 열면 됨 18 | 19 | 2. 홈페이지 파일이 없는 경우: 20 | 21 | **깃허브에서 지원하는 지킬 테마(Jekyll theme)를 가져다가 사용하는 방법** 22 | 23 | * 1. 홈페이지 파일이 있을 때 GitHub Pages 사용하기 24 | 25 | -> 추후 준비 예정! 26 | 27 | * 2. 홈페이지 파일이 없을 때 GitHub Pages 사용하기 28 | 29 | * 지킬 테마(Jekyll theme) : GitHub Pages로 블로그나 사이트를 열 때 쓸 수 있는 디자인과 스타일 모음 30 | 31 | https://jekyllrb-ko.github.io/ 32 | 33 | (깃허브에 가입 되어 있다는 전제하에 진행! 34 | 35 | 포스팅은 윈도우 기준!) 36 | 37 | 1) http://jekyllthemes.org/ 에 들어가기 또는 깃허브에 직접 jekyll을 검색해서 사용해도 됨! 38 | 39 | ![image-20200604171142222](https://user-images.githubusercontent.com/19575791/83743986-6e0ef280-a696-11ea-834d-fad16af2913f.png) 40 | 41 | 2) 원하는 테마 고르기-> Homepage 버튼 누르기 42 | 43 | ![image-20200604171442912](https://user-images.githubusercontent.com/19575791/83744030-7d8e3b80-a696-11ea-833d-49234c7bb147.png) 44 | 45 | 3) Fork버튼을 누르고 추가하고 싶은 자신의 저장소로 포크![image-20200604171856927](https://user-images.githubusercontent.com/19575791/83744073-8aab2a80-a696-11ea-83a7-5cda1ba7759c.png) 46 | 47 | ![image-20200604172217750](https://user-images.githubusercontent.com/19575791/83744101-95fe5600-a696-11ea-918e-ffd432498ce5.png) 48 | 49 | 4) Settings에 들어가서 다음과 같이 변경 -> 50 | 51 | 계정을 Repository name에 똑같이 적은 뒤 52 | 53 | **계정.github.io** 이렇게 입력!(**중요! 도메인은 꼭 이렇게 해야함!** 원하는 도메인 명이 있다면 그 도메인을 사야함! ) 54 | 55 | 우측의 Rename버튼 누르기 56 | 57 | ![image-20200604173928415](https://user-images.githubusercontent.com/19575791/83744444-1a50d900-a697-11ea-8636-f79387da3714.png) 58 | 59 | 5) Settings를 눌러서 나온 화면에서 스크롤을 내리면 GitHub Pages에서 초록색으로 경로가 나올 경우 블로그 개설이 완료됬다는 증거! 60 | 61 | 6) 저장소에 있는 파일 목록 중에 ''_config.yml' 파일 선택하여 환경에 맞게 수정하기 62 | 63 | 7) 각 항목마다 주석이 남겨져 있으니 이 내용을 참고 하여 자신과 맞게 수정하기 64 | 65 | 항목들 중에서 name과 description, footer links의 url등 다양한 부분을 수정하기 66 | 67 | 수정한 후에는 간단한 커밋 메시지와 함께 [Commit]을 눌러 커밋하기 68 | 69 | 8) 완성 70 | 71 | * [준비중...] 72 | 73 | 1. 새 저장소 (repository) 만들기 74 | 75 | -계정.github.io가 붙은 이름으로 짓기->도메인 76 | 77 | -프로젝트 별 페이지 만들기 : 계정.github.io/projectname의 url로 접속 78 | 79 | 2. 마음에 드는 Jekyll 테마 찾기 80 | 81 | 3. _config.yml 파일 가져오기 : Jekyll 사이트가 갖고 있는 설정 파일 82 | 83 | -자신의 레포지토리에 똑같이 _config.yml이라는 이름의 파일을 만들고 Raw를 눌러서 복사한 내용을 붙여넣기 84 | 85 | -한 줄 추가하고 두 줄 변경 : 86 | 87 | [한 줄 추가] 88 | 89 | ``` 90 | remote_theme : mmistakes/minimal-mistakes 91 | ``` 92 | 93 | :remote_theme을 지정하는 설정이며 GitHub의 `OWNER/REPOSITORY` 의 형식 94 | 95 | ->mmistakes라는 owner의 minimal-mistakes라는 저장소의 Jekyll 테마를 가져오겠다는 뜻 96 | 97 | [두 줄 변경] 98 | 99 | ``` 100 | url : "https://yourname.github.io" # the base hostname & protocol for your site e.g. "https://mmistakes.github.io" 101 | baseurl : "" # the subpath of your site, e.g. "/blog" 102 | ``` 103 | 104 | 105 | 106 | * 블로그에 포스트 작성하기 107 | 108 | * 블로그 포스트는 _posts디렉터리에 저장됨 109 | 110 | * _posts 디렉터리의 기본 포스트 파일은 '20xx-x-x-파일 이름.md' 형식을 사용 111 | 112 | * 포스트는 마크다운 문법을 사용해 작성 113 | 114 | 1) 기본 포스트 파일 '20xx-x-x-Hello-World.md'를 누르기 115 | 116 | 2) 포스트 형식 117 | 118 | - ---부터 ---까지는 모든 포스트에 꼭 들어가야할 내용 119 | - layout:post는 수정 X 120 | - title부분은 포스트 제목->포스트 작성할 때마다 수정 121 | - 새 포스트 사용하기 위해서는 ---부터 ---까지 선택한 후 복사 122 | 123 | 3) _posts디렉터리에서 [Create new file]을 누르기 124 | 125 | 파일 이름: '2020-06-04-first.md'처럼 오늘 날짜와 파일 이름, 확장자 .md를 입력 126 | 127 | 복사했던 내용을 붙여 넣기 128 | 129 | title: 포스트 제목 130 | 131 | 원하는 내용 입력하기 후 [commit new file]을 누른 후 커밋하기 132 | 133 | 4) _posts 디렉터리에 방금 만든 포스트 파일이 나타남 134 | 135 | **https://dreamgonfly.github.io/2018/01/27/jekyll-remote-theme.html** 136 | 137 | 138 | 139 | 140 | 141 | 142 | 143 | 144 | 145 | 146 | 147 | 148 | 149 | -------------------------------------------------------------------------------- /Pull-Request.md: -------------------------------------------------------------------------------- 1 | > Github help 문서에 있는 [Proposing changes to your work with pull requests](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/proposing-changes-to-your-work-with-pull-requests), [Reviewing changes in pull requests](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/reviewing-changes-in-pull-requests) 의 내용을 참고하여 작성하였습니다. 2 | 3 | 4 | 5 | ## 풀 리퀘스트란? 6 | 7 | 풀 리퀘스트는 깃헙으로 협업을 할 때, 레포지토리의 변경사항을 같이 작업하는 다른 사람에게 알리는 수단이다. 8 | 9 | 풀 리퀘스트가 생성되면 협업하는 사람들과 새롭게 반영할 수 있는 변경사항을 논의하고 검토할 수 있으며 변경 사항이 기본 브랜치로 병합되기 전에 수정을 거친 커밋을 추가할 수 있다. 10 | 11 | > **Note**: 풀 리퀘스트로 작업할 때의 유의점 12 | > - 공유 저장소 모델(여러명과 협업할 때)에서 작업하는 경우, 어떠한 주제(새로운 기능)에 맞는 브랜치를 사용하여 풀 리퀘스트를 생성하는 것이 좋다. 모든 브랜치나 커밋에서 풀 리퀘스트를 생성할 수 있지만, 제안된 변경 사항을 업데이트 해야 할 경우 브랜치를 사용하여 후속 작업을 푸시할 수 있다. 13 | > - 풀 리퀘스트에 대한 푸시 커밋을 할 때, 강제로 푸시하면 안된다. 풀 리퀘스트가 손상 될 수도 있다. 14 | 15 | --- 16 | 17 | ### 풀 리퀘스트를 생성하자 18 | 19 | 풀 리퀘스트를 생성하여 레포지토리에 대한 변경사항을 제안하고 공동으로 작업하자. 이러한 변경은 새로운 브랜치에 적용되며 마스터 브랜치에는 완료된 작업과 승인된 작업만 포함되도록 한다. 20 | 21 | 레포지토리에 대한 읽기 권한이 있는 모든 사용자는 풀 리퀘스트를 생성할 수 있지만 브랜치를 생성하려면 쓰기 권한이 있어야 한다. 풀 리퀘스트에 대한 새로운 브랜치를 만들고 레포지토리의 쓰기 권한이 없는 경우 레포지토리를 포크하면 된다. 22 | 23 | 기본적으로 풀 리퀘스트는 상위 레포지토리(포크한 저장소)의 마스터 브랜치를 베이스로 한다. 24 | 25 | ![브랜치선택](https://user-images.githubusercontent.com/19575791/78851187-24b67400-7a54-11ea-8496-524cdb68c298.png) 26 | 27 | 풀 리퀘스트 생성 화면에서 위의 사진처럼 compare 할 브랜치를 선택할 수 있다. 원하는 브랜치를 선택하여 진행하면 된다. 28 | 29 | ![풀리퀘스트제안](https://user-images.githubusercontent.com/19575791/78851672-5aa82800-7a55-11ea-9178-e7739077ecde.png) 30 | 31 | 만약, 어떤 브랜치에서 새로운 변경사항을 푸시 했다면 깃헙은 이렇게 새롭게 생성할 풀 리퀘스트를 제안해준다. 32 | 33 | 이는 포크된 레포지토리에서 한 작업이라도 똑같이 제안된다. (다만, 포크한 원본의 레포지토리로 병합하기 위한 풀리퀘스트가 제안된다는 점이 다르다.) 34 | 35 | 새로운 풀 리퀘스트 작성을 하거나 생성을 하고나서도 오른쪽 탭을 보면 여러가지 옵션이 있는데 36 | 37 | Reviewers, Assignees, Labels, Projects, Milestone, Linked Issues 가 있다. 38 | 39 | #### Reviewers 40 | 41 | ![reviewers](https://user-images.githubusercontent.com/19575791/78857621-d8bffb00-7a64-11ea-91af-c32b671eccba.png) 42 | 43 | 리뷰어는 말그대로 이 풀 리퀘스트의 리뷰를 요청받은 사람을 의미한다. Reviewers의 톱니바퀴를 눌러보면 현재 레포지토리의 소유자, 공동작업자 또는 팀의 인원이 목록에 나타나고 리뷰를 요청할 수 있다. 뒤에서 더 자세히 다뤄보자. 44 | 45 | - 참고 : [Requesting a pull request review](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/requesting-a-pull-request-review) 46 | 47 | #### Assignees 48 | 49 | ![assignee](https://user-images.githubusercontent.com/19575791/78859312-ed52c200-7a69-11ea-9d90-e037f02f7187.png) 50 | 51 | Assignee 는 담당자를 의미한다. 해당 작업을 담당하는 사람인데 이슈 또는 풀 리퀘스트에 누가 작업하고 있는지 명확하게 하는 역할이다. 52 | 53 | - 참고 : [Assigning issues and pull requests to other GitHub users](https://help.github.com/en/github/managing-your-work-on-github/assigning-issues-and-pull-requests-to-other-github-users) 54 | 55 | > Assignee에 대해서는 꽤나 갑론을박이 있는 것 같다.(작성자 주관적 의견) 링크된 [stackoverflow 질문](https://stackoverflow.com/questions/41087206/on-github-whats-the-difference-between-reviewer-and-assignee)에서 확인해보자. 56 | 57 | #### Labels 58 | 59 | ![label](https://user-images.githubusercontent.com/19575791/78862938-6c002d00-7a73-11ea-8bf9-a397232a29a3.png) 60 | 61 | label을 선택하면 특정 풀 리퀘스트가 어떠한 작업인지 명시할 수 있다. 어떤 종류의 작업인지 필터링하게 되어 직관적으로 사용할 수 있다. 62 | 63 | - 참고 : [About labels](https://help.github.com/en/github/managing-your-work-on-github/about-labels) 64 | 65 | #### Projects 66 | 67 | ![project](https://user-images.githubusercontent.com/19575791/78864690-1a59a180-7a77-11ea-84e9-e6a027cc54d2.png) 68 | 69 | 레포지토리에 Project가 생성되어있다면 해당 풀 리퀘스트를 특정 Project에서의 작업이란 것을 명시할 수 있다. 70 | 71 | Project에 대한 자세한 내용은 다음 챕터에서 확인해보자. 72 | 73 | - 참고 : [About project boards](https://help.github.com/en/github/managing-your-work-on-github/about-project-boards) 74 | 75 | #### Milestone 76 | 77 | ![milestone](https://user-images.githubusercontent.com/19575791/78863303-360f7880-7a74-11ea-85ec-1ae0c8ab38b2.png) 78 | 79 | 마일스톤은 말 그대로 마일스톤이다(...). 마일스톤은 기한을 설정할 수 있고, 이슈와 풀 리퀘스트를 그룹화 할 수 있는데 마일스톤에 연동된 모든 이슈와 풀 리퀘스트가 성공적으로 마무리되면 마일스톤도 완료된다. 80 | 81 | - 참고 : [About milestones](https://help.github.com/en/github/managing-your-work-on-github/about-milestones) 82 | 83 | #### Linked issues 84 | 85 | 현재 오픈되어있는 이슈와 풀리퀘스트를 연동시키는 것이다. 해당 풀리퀘스트가 성공적으로 병합된다면 연동되어있는 이슈가 close된다. 자세한 내용은 다음 챕터에서 확인해보자. 86 | 87 | - 참고 : [Linking a pull request to an issue](https://help.github.com/en/enterprise/2.20/user/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue) 88 | 89 | --- 90 | 91 | 위의 여러 옵션들을 설정하고 나면 커밋 메세지처럼 풀 리퀘스트의 제목과 간단한 본문을 작성할 수 있다. 92 | 93 | ![title](https://user-images.githubusercontent.com/19575791/78865057-e468ed00-7a77-11ea-94bd-bc633f529091.png) 94 | 95 | 제목은 풀 리퀘스트를 생성하려는 브랜치의 이름이나 마지막 커밋메세지로 자동 생성된다. 원하는 제목으로 바꾸면 된다. 96 | 97 | --- 98 | 99 | ### 풀 리퀘스트의 4가지 탭 100 | 101 | 이제 풀 리퀘스트가 생성되었다. 102 | 103 | 풀 리퀘스트를 생성하고 나면 총 4가지 탭이 있다. 104 | 105 | - Conversation 106 | - Commits 107 | - Checks 108 | - Files changed 109 | 110 | #### Conversation 111 | 112 | ![conversation](https://user-images.githubusercontent.com/19575791/78868487-fb124280-7a7d-11ea-8b78-b259a2af4829.png) 113 | 114 | 풀 리퀘스트의 모든 작업들이 이 Conversation에 표기된다. 위에서 살펴본 Labels, Assignees, Projects, Milestone, Linked issues 를 설정한 경우, 새로운 커밋을 푸시한 경우, 새로운 코멘트를 작성한 경우, 풀 리퀘스트에서 가장 중요한 리뷰와 리뷰 코멘트 등 모든 내용이 시간 순서에 따라 나열된다. 115 | 116 | #### Commits 117 | 118 | ![commits](https://user-images.githubusercontent.com/19575791/78868944-ba66f900-7a7e-11ea-86fa-fd1f5e46073f.png) 119 | 120 | 해당 풀 리퀘스트에서 해당하는 브랜치의 모든 커밋이 표기되는 곳이다. 해당 커밋을 선택하여 그 커밋에서 어떠한 코드 수정이 있었는지 확인하고 코멘트할 수 있다. 121 | 122 | #### Checks 123 | 124 | Checks 탭은 현재 레포지토리에 설정된 [Github Actions](https://help.github.com/en/actions)으로 할 수 있는 작업 중 하나 같은데... 여기서는 다루지 않겠다. (단호) 125 | 126 | #### Files Changed 127 | 128 | ![files changed](https://user-images.githubusercontent.com/19575791/78869500-a66fc700-7a7f-11ea-8148-b3558bb681ee.png) 129 | 130 | 현재 풀 리퀘스트의 모든 파일의 변경사항이 한번에 나열 되는 곳이다. 이곳에서 풀 리퀘스트의 꽃이라 할 수 있는 코드 리뷰를 진행할 수 있다. 131 | 132 | ### 풀 리퀘스트에 대한 리뷰 요청하기 133 | 134 | 풀 리퀘스트 생성이 끝났다면 특정 사용자(공동 작업자 또는 원본 소스코드 관리자)에게 변경 사항에 대해 리뷰를 요청할 수 있다. 135 | 136 | 또한, 레포지토리의 소유자 또는 공동작업자는 읽기 권한을 부여받은 모든 사용자에게 풀 리퀘스트 리뷰를 할당할 수도 있다. 137 | 138 | - 참고 : [Requesting a pull request review](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/requesting-a-pull-request-review) 139 | 140 | 리뷰가 이루어지는 과정은 아래에서 더 자세히 다루어 보자. 141 | 142 | --- 143 | 144 | ## 풀 리퀘스트 리뷰란? 145 | 146 | 리뷰에서는 공동작업자가 풀 리퀘스트에서 제안된 변경사항에 대해 의견을 나누거나, 변경사항을 승인하거나, 풀 리퀘스트가 병합되기 전에 추가 작업을 요청할 수 있다. 147 | 148 | 리뷰어는 한번에 한 파일씩 풀 리퀘스트의 변경 사항을 리뷰할 수 있다. 특정한 변경사항에 대해서 개인 코멘트를 남길 수도 있고, 파일은 리뷰하고 나서 확인했다고 표시할 수 있다. 아래 과정에서 어떻게 이루어지는지 살펴보자. 149 | 150 | ### 리뷰하기 151 | 152 | 1. 풀 리퀘스트의 **Files changed** 탭으로 들어간다. 153 | 154 | ![files changed tab](https://help.github.com/assets/images/help/pull_requests/pull-request-tabs-changed-files.png) 155 | 156 | 2. 코멘트를 추가할 코드 줄 위에 마우스를 놓고 파란색 + 아이콘을 누르거나, 여러 줄에 대한 코멘트를 남기고 싶다면 해당 영역을 드래그하여 추가할 수 있다. 157 | ![add comment](https://help.github.com/assets/images/help/commits/hover-comment-icon.gif) 158 | 159 | 3. 코멘트를 추가한다. 160 | 161 | ![add commect field](https://help.github.com/assets/images/help/pull_requests/comment-field.png) 162 | 163 | 4. 만약 해당 라인의 코드를 제안하고 싶다면 `+` 버튼이나 아래 사진처럼 할 수 있다. 164 | 165 | ![suggestion](https://help.github.com/assets/images/help/pull_requests/suggestion-block.png) 166 | 167 | 5. 코멘트 작성을 완료하였다면, `Start a review`를 누른다. 168 | 169 | ![start a review](https://help.github.com/assets/images/help/pull_requests/start-a-review-button.png) 170 | 171 | 6. 리뷰를 제출하기 전까지는 해당 코멘트는 해당 사용자에게만 표시된다. 리뷰를 제출하기 전까지는 언제든지 보류 중인 코멘트를 편집할 수 있다. 172 | 173 | ### 해당 파일을 확인했다는 `Viewed` 누르기 174 | 175 | 파일 리뷰가 끝나고 파일을 본 것으로 표시하면 파일이 축소된다. 만약 해당 파일에 다시 변경 사항이 생긴다면 `Viewed`가 취소 된다. 176 | 177 | ![viewed](https://help.github.com/assets/images/help/pull_requests/viewed-checkbox.png) 178 | 179 | ### 리뷰 제출하기 180 | 181 | 모든 파일에 대해 리뷰가 끝났다면, 최종 리뷰를 제출하여야 한다. 182 | 183 | 1. 모든 리뷰, 피드백에 대한 요약을 입력한다. 184 | 185 | ![review changes](https://help.github.com/assets/images/help/pull_requests/review-summary-comment-window.png) 186 | 187 | 2. 리뷰 결과는 총 세가지 타입이 존재한다. 188 | 189 | ![review type](https://help.github.com/assets/images/help/pull_requests/pull-request-review-statuses.png) 190 | 191 | - **Comment**: 명시적으로 변경을 승인하거나 추가 변경을 요청하지 않는 일반 피드백 192 | - **Approve** : 피드백을 제출하고 풀 리퀘스트의 제안된 변경사항을 병합하는 경우 193 | 194 | - **Request changes** : 병합되기 전에 반드시 개선되어야하는 변경 사항을 새롭게 요청하는 경우 195 | 196 | 3. 리뷰를 제출한다. 197 | 198 | ### 나는 리뷰 말고 코멘트 남길래 199 | 200 | 방금 전까지 각 코드에 대한 리뷰를 남기는 과정을 확인해 보았다. 만약, 그 코드에 대한 단순 코멘트만 남기고 싶다면 201 | 202 | ![single comment](https://help.github.com/assets/images/help/commits/inline-comment.png) 203 | 204 | 이렇게 `Add single comment` 를 선택하면 된다. 205 | 206 | **single comment** 에서는 해당 코드에 대해 다른 사용자들과 여러 의견을 나눌 수 있으며 그 의견이 해결되었다면 207 | 208 | ![resolve conversation](https://help.github.com/assets/images/help/pull_requests/conversation-with-resolve-button.png) 209 | 210 | `Resolve conversation` 을 클릭하면 된다. 211 | 212 | ### 나는 풀 리퀘스트에 대해 코멘트 남길래 213 | 214 | 만약 해당 풀 리퀘스트에 대해 코멘트를 남기고 싶다면 **Conversation** 탭에서 남길 수 있다. 215 | 216 | ![conversation comment](https://help.github.com/assets/images/help/pull_requests/conversation.png) 217 | 218 | 이렇게 작성 한 코멘트가 시간 순으로 표기된다. 219 | 220 | ### 리뷰에 제안된 피드백이 포함되었다면? 221 | 222 | 리뷰어들은 풀 리퀘스트에 대해서 구체적인 피드백을 제시할 수 있고, 레포지토리에 대해 쓰기 권한이 있는 경우엔 직접 적용하는 것까지 가능하다. 포크에서 풀 리퀘스트가 생성되고 작성자가 관리자의 편집을 허용한 경우, 업스트림에 대한 쓰기 권한이 있는 경우 제안된 변경 사항을 적용할 수도 있다. (영어 그대로 해석했는데 말이 되게 어렵게 써져있네요...) 223 | 224 | 제안된 피드백들을 적용한 것들은 모두 단일 커밋에 통합된다. 각 변경 사항을 제안한 리뷰어는 커밋의 공동 저자가 된다. 제안된 변경 사항을 적용하는 사람은 공동 저자와 커밋의 커밋자(?)가 된다. 225 | 226 | 1. 변경 내용을 커밋에 적용하려면 `Commit suggestion` 을 누른다. 227 | 228 | ![commit suggestion](https://help.github.com/assets/images/help/pull_requests/commit-suggestion-button.png) 229 | 230 | 2. 제안된 변경사항에 새로운 제안을 추가하려면 `Add suggestion to batch` 를 누르고, 변경사항을 추가한다. 231 | 232 | ![Add suggestion](https://help.github.com/assets/images/help/pull_requests/add-suggestion-to-batch.png) 233 | 234 | 3. 제안된 변경사항을 커밋할 때, 커밋 메세지를 입력하듯이 제목과 내용을 입력할 수 있다. 235 | 236 | ![commit message](https://help.github.com/assets/images/help/pull_requests/suggested-change-commit-message-field.png) 237 | 238 | 4. 커밋을 한다. 239 | 240 | ![commit changes](https://help.github.com/assets/images/help/pull_requests/commit-changes-button.png) 241 | 242 | 243 | 244 | ## 풀 리퀘스트 마무리 245 | 246 | 기본적으로 통합하려는 HEAD 브랜치와 마스터 브랜치가 충돌하지 않는 한, 풀 리퀘스트는 언제든지 병합할 수 있다. 247 | 248 | 만약 병합 충돌이 있거나 병합하기 전에 변경 사항을 테스트하려는 경우에는 로컬에서 풀 리퀘스트를 체크아웃하고 커맨드라인을 사용하여 병합을 진행할 수 있다. 249 | 250 | 또한, 풀 리퀘스트가 병합된 후에 HEAD 브랜치를 자동으로 삭제하도록 할 수 있다. 251 | 252 | 병합하지 않으려면 풀 리퀘스트를 닫을 수도 있다. 253 | 254 | ### 풀 리퀘스트 병합하기 255 | 256 | 1. `Merge pull request` 를 눌러 병합을 진행 한다. 만약 `Merge pull request` 옵션이 표시되지 않으면 드롭다운 메뉴를 클릭하여 `Create a merge commit` 를 클릭한다. 257 | 258 | ![merge pull request](https://help.github.com/assets/images/help/pull_requests/pullrequest-mergebutton.png) 259 | 260 | 2. 스쿼시하여 커밋을 하나의 커밋으로 압축하려면 `Squash and merge`을 클릭한다. 261 | 262 | ![squash and merge](https://help.github.com/assets/images/help/pull_requests/select-squash-and-merge-from-drop-down-menu.png) 263 | 264 | 3. 커밋을 리베이스하고 병합하고 싶다면 `Rebase and merge` 를 클릭한다. 265 | 266 | ![Rebase and merge](https://help.github.com/assets/images/help/pull_requests/select-rebase-and-merge-from-drop-down-menu.png) 267 | 268 | > **Note** : 리베이스 및 병합은 항상 커밋자 정보를 업데이트하고 새로운 커밋을 생성한다. 269 | 270 | 4. 커밋 메세지 입력창이 나타나면 메세지를 입력한다. 271 | 272 | ![confirm merge](https://help.github.com/assets/images/help/pull_requests/merge_box/pullrequest-commitmessage.png) 273 | 274 | ### 풀 리퀘스트 닫기 275 | 276 | 풀 리퀘스트를 병합하지 않으려면 닫을 수 있다. 277 | 278 | > **Tips** : 만약 풀 리퀘스트의 베이스 브랜치를 잘못 선택하였다면, 풀 리퀘스트를 닫고 새로 생성하는 것이 아니라 베이스 분기를 변경할 수 있다. 참고 : [Changing the base branch of a pull request](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/changing-the-base-branch-of-a-pull-request) 279 | 280 | 풀 리퀘스트 하단의 `Close pull request` 를 클릭하여 풀 리퀘스트를 닫을 수 있다. 281 | 282 | ![closw pull request](https://help.github.com/assets/images/help/pull_requests/pullrequest-closebutton.png) 283 | 284 | ### 풀 리퀘스트 Revert 하기 285 | 286 | 풀 리퀘스트를 병합하고 나서 되돌리는 작업을 하고 싶다면 이 과정이 포함된 새로운 풀 리퀘스트가 생성된다. 287 | 288 | > **Note** : 다음과 같은 경우 [ Git을 사용하여 수동으로 커밋을 되돌릴 수 있다](https://git-scm.com/docs/git-revert.html). 289 | > 290 | > - 풀 리퀘스트를 되돌리면 병합 충돌이 발생하는 경우 291 | > - 풀 리퀘스트가 Github에서 병합되지 않고 Git 명령으로 병합된 경우 292 | 293 | 풀 리퀘스트의 맨 아래쪽의 `Revert` 를 클릭하면 된다. 294 | 295 | ![revert](https://help.github.com/assets/images/help/pull_requests/revert-pull-request-link.png) 296 | 297 | 298 | 299 | 300 | 301 | -------------------------------------------------------------------------------- /QnA.md: -------------------------------------------------------------------------------- 1 | # Question 2 | 안녕하세요? 3 | Github 탐구 스터디에 관심있는 꿈나무 개발자입니다. 스터디 소식을 보고 몇가지 궁금한 사항이 있어 질문합니다! 4 | 5 | ### 질문 1 : 주 1회 스터디 모임은 오프라인으로만 진행되나요? 6 | 온라인 스터디로 함께하고 싶은 참여자도 받으실 의향이 있는지 문의드립니다. 7 | 또는, 오프라인 스터디에 참여하지 않더라도 다른 스터디원들이 볼 수 있도록 자신이 공부한 내용을 문서로 정리해서 공유하고 같이 공유받는 방식도 괜찮은지 궁금합니다. 8 | 9 | ### 질문 2 : 커리큘럼은 어떻게 정해지나요? 10 | 정해진 커리큘럼에 따라 챕터를 담당한다면 커리큘럼은 스터디장이 정하는 것인지, 같이 정하는 것인지, 혹은 참고할만한 가이드라인이나 문서가 있는 것인지 궁금합니다. 11 | 12 | ### 질문 3 : 스터디에 불성실하게 임하는 스터디원에게 패널티가 부여되나요? 13 | 매주 할당된 과제를 하지 않았거나, 과제를 했으나 그 내용이 빈약하거나, 오프라인으로 진행될 시에 참석하지 않는다면 주어지는 패널티가 있는지, 혹은 이 부분은 앞으로 스터디원이 모이고 나면 함께 상의할 부분인 것인지 궁금합니다. 14 | 15 | --- 16 | * 답변 여부와 별개로 스터디를 주최하는 스장님과 참여하시는 분들의 열정을 응원합니다! 17 | * ~~파이팅 파이팅 파이티이티잉ㅇ!!!~~ 18 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Github Cookbook 🍽 2 | 개발자로서 아직 다뤄보지 못한 Github의 기능들을 배워보기 위한 스터디입니다. 3 | 4 | ## Goal 🌟 5 | 6 | - Github으로 협업하는 다양한 방법을 배웁니다. 7 | - Github의 잘 알지 못했던 새로운 것들을 배웁니다. 8 | - Github을 사용하면서 느꼈던 알 수 없는 갈증을 해소합니다. 9 | 10 | ## Requirements 📌 11 | 12 | - Github을 배우기 위함이므로, Git의 기본적인 사용에 익숙함을 전제로 합니다. 13 | - Github을 Git의 원격 저장소로 사용해본 경험이 있음을 전제로 합니다. 14 | - 스터디 문서 작성을 위해 markdown 문서 작성에 익숙함을 전제로 합니다. 15 | 16 | ## Rule 📋 17 | 18 | - 주 1회 스터디 모임을 합니다. 19 | - 정해진 커리큘럼에 따라 한 개의 챕터를 한 명이 담당하여 스터디를 준비합니다. 20 | - 자신의 정해진 챕터에 대한 주제를 바탕으로 세미나를 진행합니다. 21 | - 세미나 진행이 끝나면 다같이 자유롭게 토론합니다. 22 | - 세미나의 내용은 챕터를 담당한 인원이 자유롭게 구성합니다. 23 | - 자신이 맡은 챕터가 아니어도 그 주제에서 자신이 소개하고 싶은 내용이 있다면 준비를 해옵니다. 24 | 25 | ## Curriculum 🗂 26 | 27 | - Chapter에 정해진 Presenter가 그 주의 세미나를 준비합니다. 28 | 29 | > | Chapter | Subject | Presenter | 30 | > | ------- | ----------------------- | -------------- | 31 | > | 1 | [Git Workflow](Git-Github-Collaborating.md) | [soogoon](https://github.com/soogoon) | 32 | > | 2 | [Github Marketplace, Explore](Github-Marketplace-Explore.md) / [Repository Settings](Repository-Settings.md) | [ttub-nii](https://github.com/ttub-nii) | 33 | > | 3 | [Pull & Request](Pull-Request.md) | [soogoon](https://github.com/soogoon) | 34 | > | 4 | [Github Project](About-Git-Project.md) | [5anniversary](https://github.com/5anniversary) | 35 | > | 5 | [Github issue](Github-Issue.md) | [khyunjiee](https://github.com/khyunjiee) | 36 | > | 6 | [Github blog with Github page](Github-blog-posting.md) | [jihye0420](https://github.com/jihye0420) | 37 | 38 | ## Contributers 39 | 40 | - [soogoon](https://github.com/soogoon) 41 | - [ttub-nii](https://github.com/ttub-nii) 42 | - [5anniversary](https://github.com/5anniversary) 43 | - [jihye0420](https://github.com/jihye0420) 44 | - [dongminyoon](https://github.com/dongminyoon) 45 | - [khyunjiee](https://github.com/khyunjiee) 46 | - [ChoiEunji0114](https://github.com/ChoiEunji0114) 47 | -------------------------------------------------------------------------------- /Repository-Settings.md: -------------------------------------------------------------------------------- 1 | # 📌 Previous Contents 2 | * 👀[Marketplace & Explore 탭 살펴보기](Github-Marketplace-Explore.md) 3 | --- 4 | # [Repository 환경 제대로 알고 설정하기](#Repository-Setting-살펴보기) 5 | 6 | Repository 에 들어가보면 Code 부터 Pull requests, Actions, Projects, Wiki, Security, Insights, 그리고 **Settings** 까지 7 | 8 | 8가지의 메뉴 중에서 **Settings 에서 할 수 있는 것들**에 대해 얼마나 알고 있는지 스스로 자문해봅시다. 9 | 10 | 저는 주로 Repository 의 이름을 변경하거나, 위치를 이동하거나, 삭제할 때 이외에는 잘 사용하지 않았던 것 같습니다. 11 | 12 | 이번에는 우리가 주로 사용하는 **Options Settings 이외의 다른 탭 메뉴들**에 대해서도 살펴보려고 합니다. 13 | 14 |

Repository Setting

15 |

16 | 스크린샷 2020-03-27 오전 12 18 36 17 |

18 | 19 |

Setting menu

20 | 21 |

22 | 스크린샷 2020-03-27 오후 9 57 43 23 |

24 | 25 | # Repository Setting 살펴보기 26 | 27 | ## Options 28 | ### Template repository 29 | 2019년 6월 9일자로 새로 추가된 기능인 template repository는, 설정을 체크하면 모든 파일과 폴더가 포함된 새 repository 를 생성할 수 있습니다. 30 | 튜토리얼을 작성하거나 기업용 *boilerplate* 를 만들거나 프레임워크를 배포하고 싶을 때 유용하게 사용할 수 있습니다. 31 | 32 | > 사용 예시 1 : https://github.com/ttub-nii/test-template-repo 33 | 34 | > 사용 예시 2 : https://github.com/ttub-nii/Study-Node-Server 35 | 36 | **Fork 와 무엇이 다른가?** 37 | Fork 와 유사하지만 매우 중요한 다른 점이 있습니다. 38 | 39 | * fork 를 받은 repository 에는 상위 저장소의 전체 commit history 가 포함됩니다. 그러나 template 에서 작성된 repository 는 싱글 commit 로 시작합니다. 40 | 41 | * fork 로 commit 한 내용은 contributions 그래프에 나타나지 않습니다. 그러나 template 에서 생성된 repository 에 대한 commit 은 contributions 그래프에 나타납니다. 42 | 43 | * fork 는 기존 프로젝트에 코드를 기여하기 위한 임시적인 방법일 수 있지만 template 에서 repository 를 만들면 새 프로젝트를 빠르게 시작할 수 있습니다. 44 | 45 |

Fork commit 이 Merge 되기 전 / 후 비교

46 | 47 |

48 | 스크린샷 2020-04-01 오후 11 46 29    스크린샷 2020-04-02 오후 1 40 17 49 |

50 | 51 | ## 52 | ### Social preview 53 | 누군가가 Repository 에 링크를 걸 때 소셜 미디어 플랫폼에 표시되는 이미지를 설정할 수 있습니다. 54 | 이미지를 추가하지 않으면 저장소 및 소유자 아바타에 대한 기본 정보가 표시됩니다. 55 | 56 |

Social preview 적용 전 / 후 비교

57 | 58 |

59 |   60 |

61 | 62 | ## 63 | ### Features 64 | * Wikis 65 | 66 | * 자신의 Repository 에 대해 documents 를 작성해서 다른 이들이 프로젝트를 사용하거나 프로젝트에 기여할 수 있도록 합니다. 67 | 68 | * 선택을 해제하면 Wiki 탭을 비활성화할 수 있습니다. 또한 Wiki 를 collaborators 에게만 수정 권한을 부여할 수 있습니다. 69 | 70 | * Issues 71 | 72 | * 사용자의 피드백을 모으거나, sw 의 버그를 report 하거나, task 를 오거나이즈 하는 데에 사용할 수 있습니다. 73 | 74 | * Issues 탭을 비활성화할 수 있고, **Set up templates** 버튼을 눌러 새 Issue 를 작성할 때 양식을 커스텀할 수 있습니다. 75 | 76 | * template 의 타입을 **Bug report, Fearture request, Custom template** 중에 선택하여 생성합니다. 77 | 78 | * 이슈 제목을 자동으로 설정하거나, repository 에 읽기 권한이 있는 사용자에게 이슈를 할당하거나, title, labels, YAML frontmatter 형식의 커스텀 라벨을 지정할 수도 있습니다. 79 | 80 |

81 | 스크린샷 2020-03-28 오후 2 21 04 82 |

83 | 84 | * Sponsorships 85 | 86 | * 오픈 소스 프로젝트에 가치를 기여하고 해당 repository 에 대해 스폰서 십(경제적 지원)을 받을 것인지 설정하는 부분입니다. 87 | 88 | * **Set up sponsor button** 을 누르면 오픈소스 프로젝트의 가시성을 높이기 위한 스폰서 버튼 활성화 할 수 있습니다. 89 | 90 | > TIP 91 | >> Github Sponsor 계정으로 등록하고 은행, 세금 정보를 제출하고 GitHub 계정에서 2 단계 인증을 활성화하면 스폰서 개발자가 될 수 있습니다. 92 | 93 | * Projects 94 | 95 | 스크린샷 2020-03-31 오전 2 07 15 96 | 97 | * 작업을 조직화, 구성하거나 우선 순위를 매길 때 유용하게 사용할 수 있는 게시판입니다. 98 | 99 | * 특정 기능의 작업이나 포괄적인 로드맵이나, 출시 체크 리스트 등에 관한 프로젝트를 만들 수 있습니다. 100 | 101 | > **Projects Template 종류** 102 | >> * None 103 | >> * Basic kanban 104 | >> * Automated kanban 105 | >> * Automated kanban with reviews 106 | >> * Bug triage 107 | 108 | ## 109 | ### Data services 110 | denpendency 에서 취약성이 발견되었을 때 알림을 주는 기능입니다. 111 | 여기서 취약성은 프로젝트 또는 해당 코드를 사용하는 다른 프로젝트의 기밀성, 무결성, 가용성을 손상시키기 위해 악용될 수 있는 프로젝트 코드의 문제입니다. 112 | 113 | **Security Alerts 에는 다음과 같은 내용이 포함됩니다.** 114 | 115 | * 심각도 수준 116 | 117 | * 프로젝트의 영향을 받는 파일에 대한 링크 118 | 119 | * 취약점을 해결하는 자동 보안 업데이트가 포함된 Pull requests 링크 120 | 121 | ## 122 | ### Merge button 123 | Pull request 를 merge 할 때, commit / 스쿼시 / 리베이스 중에서 어떤 조합을 허용할 것인지 설정할 수 있습니다. 124 | 만약 protected 브랜치에서 linear history 를 활성화 한 경우에는 스쿼시나 리베이스를 허용해야 합니다. 125 | 다음과 같은 옵션 중에서 하나 이상의 옵션은 활성화 되어 있어야 합니다. 126 | 127 | * Allow merge commits 128 | 129 | * Allow squash merging 130 | 131 | * Allow rebase merging 132 | 133 | Pull request 가 merge 된 후 헤드 브랜치를 자동으로 삭제할 수 있습니다. 134 | 135 | * Automatically delete head branches 136 | 137 | ## 138 | ### GitHub Pages 139 | GitHub 저장소에서 직접 개인, organization 또는 프로젝트에 대한 웹 사이트를 호스팅 할 수 있습니다. 140 | GitHub의 저장소에서 HTML, CSS 및 JavaScript 파일을 직접 가져 와서 웹 사이트를 게시하는 정적 사이트 호스팅 서비스입니다. 141 | 142 | * Source 143 | 144 | * default source 를 사용하면 가장 최근에 빌드된 master branch 의 내용으로 사이트가 자동으로 게시됩니다. 145 | 146 | * 다른 브랜치나 폴더에서 프로젝트 사이트를 게시하도록 선택할 수도 있습니다. 147 | 148 | * Theme Chooser 149 | 150 | * GitHub 페이지 사이트에 테마를 추가하여 사이트의 모양과 느낌을 사용자 정의 할 수 있습니다. 151 | 152 | * 예시 : https://ttub-nii.github.io/Github-Cookbook/ 153 | 154 | ## 155 | ### Danger Zone 156 | 157 | * 비공개 & 공개 설정 158 | 159 | * repository 의 Owner 를 변경하거나, 위치를 이동 160 | 161 | * repository 를 아카이빙 목적, read-only 로 사용 162 | 163 | * repository 를 삭제 164 | * ~~그러나 삭제된 repository 되돌리기는 User settings > Repositories 에서 가능합니다.~~ 165 | 166 | ## 167 | ## Manage access 168 | team 이나 person 을 검색 & 초대할 수 있고 권한을 수정하거나 삭제할 수 있다. 169 | 170 | ## Branches 171 | ### Branch protection rules 172 | Pull requests 가 Merge 전에 일련의 확인을 통과하도록 요구할 수 있습니다. 173 | 예를 들어 상태 확인을 통과하지 못한 Pull requests 을 차단하거나 특정 수의 승인 검토가 있어야 병합할 수 있습니다. 174 | 175 | **Add rules** 버튼을 눌러 다음과 같은 규칙을 부여할 수 있습니다. 176 | 177 | > 참고 | [오지는 컴퓨터 공부 - Git에 대해 알아보자 5. GitHub 추가 기능들](https://cupjoo.tistory.com/11) 178 | 179 | * **Require pull request reviews before merging** 180 | 181 | * 지정된 횟수 만큼의 승인이 완료되어야 Merge가 가능합니다. 182 | 183 | * 이 조건을 선택할 경우, 요구 승인 수를 설정할 수 있으며 또 다른 추가 선택 사항들이 나타납니다. 184 | 185 | * **Require status checks to pass before merging** 186 | * CI 테스트를 통해 기존 브랜치와 충돌이 없을 시에만 Merge가 가능합니다. 187 | 188 | * A 브랜치가 최신인 상태를 기준으로 해당 검사를 실시하기에, B 브랜치에서 코드를 수정하던 중 C 브랜치에 의해 A 브랜치가 업데이트 됐을 시, 새로운 A 브랜치를 B 브랜치로 Merge 시켜야 합니다. 189 | 190 | * **Require signed commits** 191 | * GPG key가 있어야 Merge가 가능합니다. 192 | 193 | * **Require linear history** 194 | * to block all merge commits from a protected branch. 195 | 196 | * **Include administrators** 197 | * 관리자에게도 이 모든 제약 사항을 적용하도록 하는 옵션입니다. 198 | 199 | 강제로 푸시하는 것을 허용하거나, 브랜치를 삭제하는 것 역시 권한을 설정할 수 있습니다. 200 | 201 | * **Allow force pushes** 202 | 203 | * **Allow deletions** 204 | > 사용 예시 : https://github.com/binarysound/web-lab/issues/4 205 | 206 | ## Webhooks 207 | 앱이 다른 앱에 실시간 정보를 제공하는 방법입니다. 208 | GitHub 의 특정 이벤트를 구독하는 GitHub Apps 또는 OAuth Apps 와 같은 integrations 을 설정할 수 있습니다. 209 | 이벤트가 발생하면 Webhooks 의 URL에 HTTP 요청을 다른 애플리케이션에 주로 POST 형태의 페이로드를 보낼 것입니다. 210 | 간단하게 요약하자면, Webhook 기능을 사용해 특정 API를 호출하는 것이 가능합니다. 211 | 212 | > 참고 | [44bits - 깃허브 웹훅을 활용해 슬랙에 이벤트 전달하기](https://www.44bits.io/ko/post/notifying-github-event-by-using-github-webhook) | [SendGrid Team - What’s a Webhook?](https://sendgrid.com/blog/whats-webhook/) 213 | 214 | * 유일한 단점은 처음에 설정하기가 어렵다는 것인데 Webhook 은 API와는 반대 방향으로 작동합니다. 215 | 216 | * Webhook 은 API 스펙에 해당하기 때문에 Webhook 을 사용하기 위해서는 API를 설계해야 합니다. 217 | 218 | * 예를 들어 보통 API를 호출하면 어떤 정보를 되돌려줍니다만, Webhook 에 등록하면 어떤 이벤트가 발생할 때 거꾸로 깃허브에서 등록한 URL을 호출합니다. 219 | 220 | ## Notifications 221 | push 이벤트가 발생했을 때 설정한 이메일 주소로 알림을 받을 수 있습니다. 222 | 223 | * Approved header 224 | 225 | * GitHub가 보내는 각 이메일 알림에는 헤더 정보가 포함되어 있습니다. 226 | 227 | * 모든 이메일의 헤더 정보는 일관성이 있으므로 모든 GitHub 알림 또는 특정 유형의 GitHub 알림을 필터링하거나 전달할 수 있습니다. 228 | 229 | * 'Approved' 헤더 값을 추가하면 읽기 전용 메일을 자동으로 승인합니다. 230 | 231 | ## Integrations 232 | 설치된 Github Apps 를 확인할 수 있습니다. 233 | 234 | > 사용 예시 235 | 236 |

237 | 스크린샷 2020-04-01 오후 8 23 33 238 |

239 | 240 | ## Deploy keys 241 | repository 의 SSH 키로, repository 에 접근하는 클라이언트에게 읽기 전용 (원하는 경우 r / w) 액세스 권한을 부여합니다. 242 | 이름에서 알 수 있듯이, 주요 기능은 읽기 접근 권한이 필요한 배포 프로세스에서 사용됩니다. 243 | 따라서 Deploy key 를 설정하면 서버 쪽이 망가졌을 경우에 대비하여 repository 를 공격으로부터 안전하게 유지할 수 있습니다. 244 | > 사용 방법 : https://gist.github.com/zhujunsan/a0becf82ade50ed06115 245 | 246 | ## Secrets 247 | 암호화 되어 저장되는 환경 변수로 특정 선택한 작업에만 노출됩니다. 248 | Repository 에 공동 작업자 액세스 권한이 있는 사람은 누구나 이러한 비밀을 사용할 수 있습니다. 249 | 액세스 토큰과 같은 민감한 정보를 저장할 수 있고, fork 로 부터 Pull requests 한 워크 프로우에는 Secret 이 전달되지 않습니다. 250 | 251 | Github 공식 문서에서는 Secret 이름은 공백을 포함할 수 없고, JSON 이나 인코딩 된 Git Blob 과 같은 structured data 를 secret 값으로 저장하는 걸 지양하라고 합니다. 252 | > 출처 253 | >> https://help.github.com/en/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets 254 | 255 | ## Actions 256 | 257 | * **local 과 third party Action 모두 허용함** 258 | * Action 코드가 이 repository 에 있는지, organization 에 있는지, 제 3자가 소유한 repository 에 있는지 상관 없이 모든 Action 을 실행할 수 있습니다. 259 | 260 | * **local Action 만 허용함** 261 | * 해당 repository 나 organization 에 속하기만 하면 어떤 Action 이든 실행되는 것을 허용합니다. 262 | 263 | * **Action 사용 안함** 264 | * 해당 repository 에서 모든 Action 을 불허합니다. 265 | 266 | ## Security Alerts (organization 에 속한 repository) 267 | 보안 경고는 관리자가 권한을 부여한 사람과 팀만 볼 수 있습니다. 268 | 권한을 부여받으면 dependencies 중 하나에서 새로운 취약점이 발견되면 알림을 주고, 자동 업데이트한 보안 내용의 추가 세부 정보들을 볼 수 있습니다. 269 | 각 개인은 해당 탭에서 보안 알림을 받는 방법을 관리 할 수 있습니다. 270 | 271 | > **Choose the people or teams you would like to grant access to security alerts** 272 | >> 보안 경고에 접근할 수 있도록 하려는 개인이나 팀을 찾아 권한을 부여합니다. 273 | 274 | --- 275 | # Moderation 276 | ## Interaction limits 277 | 24시간 동안 repository 나 organization 의 특정 사용자가 278 | 1. comment 를 남기거나, 279 | 2. issues 를 열거나, 280 | 3. Pull requests 를 작성하는 것을 제한할 수 있습니다. 281 | 282 | 예를 들어, Github 공식 문서는 283 | ``` 284 | This may be used to force a "cool-down" period during heated discussions. 285 | ``` 286 | 너무 논쟁이 과열됐을 때 이 기능을 사용하여 진정 기간을 가질 수 있다고 설명합니다. 287 | 288 | * **Limit to existing users** 289 | * Users that have recently created their account will be unable to interact with the repository. 290 | 291 | * 24시간 이내에 계정을 만든 사용자 중에 contributions 가 없고 공동 작업자도 아닌 사용자의 활동을 제한합니다. 292 | 293 | * **Limit to prior contributors** 294 | * Users that have not previously committed to the repository’s master branch will be unable to interact with the repository. 295 | 296 | * 이전에 master 브랜치에 commit 하지 않았거나 공동 작업자가 아닌 사용자의 활동을 제한합니다. 297 | 298 | * **Limit to repository collaborators** 299 | * 공동 작업자가 아닌 사용자의 활동을 제한합니다. 300 | 301 | ## Reported content (organization 에 속한 repository) 302 | collaborators 나 contributors 는 욕설 또는 파괴적인 콘텐츠를 신고할 수 있습니다. 303 | **Accept** 한다면 repository 관리자에게 collaborators, contributors 가 콘텐츠를 신고할 수 있는 옵션이 보여집니다. 304 | 305 | --- 306 | ### 끝! 모두 수고 많으셨습니다 :) 307 | -------------------------------------------------------------------------------- /_config.yml: -------------------------------------------------------------------------------- 1 | theme: jekyll-theme-architect --------------------------------------------------------------------------------