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 | 
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 .svg?cdnVersion=912)
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 | .svg?cdnVersion=912)
92 |
93 | 자신이 새로 구현한 기능에 대해 풀 리퀘스트를 생성한다. 풀 리퀘스트를 활용하면 다른 팀원에게 자신의 구현한 기능에 대한 코멘트를 받을 수 있다. 이 과정은 협업 과정에서 아주 중요한 역할을 할 수 있다. 다른 팀원을 명시하여 풀 리퀘스트를 생성하고 해당 기능에 대해 리뷰를 요청할 수 있다. 풀 리퀘스트에 대한 자세한 고찰은 나중에 다룰 것이다.
94 |
95 | 풀 리퀘스트는 Github, Bitbucket 등의 원격 저장소 서비스를 활용해야 한다.
96 |
97 | ### 풀 리퀘스트 병합(merge)
98 |
99 | 새로운 기능 브랜치가 이상이 없다면 풀 리퀘스트를 병합한다.
100 |
101 | - 이 때 만약 병합 충돌(merge conflict)이 생겨 자동 병합이 안된다면 해당 충돌을 반드시 해결해야 한다.
102 |
103 | 
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 | .svg?cdnVersion=913)
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 | .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 | .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 | 
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 | 
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 | 
28 | [Disabling Issues](https://help.github.com/en/github/managing-your-work-on-github/disabling-issues)
29 |
30 | * 이슈는 현재 존재하는 풀 리퀘스트의 코드로도 생성할 수 있다.
31 | 풀리퀘를 하고있는 파일을 View File을 한 후 코드를 선택해서 이슈를 생성할 수 있다.
32 |
33 | 
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 | 
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 | 
51 |
52 | 이슈를 만들 Repository에서 Issue탭의 New Issue를 클릭한다.
53 | 이슈는 제목과 이슈에 대한 설명을 적을 수 있다.
54 |
55 |
56 |
57 | 
58 |
59 | 생성된 이슈는 리스트 형태로 관리하기 힘들어 보인다.
60 | 이슈가 엄청 많다면? ~~특정 이슈를 찾기 힘들어질 것이다.~~
61 |
62 |
63 |
64 | ### Label 기능
65 |
66 | ✔️이러한 문제점을 개선하기 위해 우리는 **Label 기능을 사용**한다.
67 |
68 | **각 이슈에 대한 Labeling을 통해 이슈를 검색할 수 있고, 이슈별 주제를 구분할 수 있다.**
69 |
70 | 
71 |
72 | Labels 버튼에서 새로운 라벨을 만들 수 있고, 기본으로 있는 라벨을 사용할 수도 있다. (컬러 지정도 가능)
73 |
74 |
75 |
76 | 
77 |
78 | 라벨을 커스텀하여 생성할 수 있다.
79 |
80 |
81 |
82 | 
83 |
84 | 
85 |
86 | 이슈 상세페이지에서 이슈를 생성한 라벨로 지정할 수 있다.
87 |
88 | ==라벨을 나누는 기준?==
89 |
90 | 라벨은 이슈의 우선순위, 카테고리, 다른 유용한 정보들을 나누는 기준으로 만들어야한다.
91 | (작은 단위일수록 좋다. )
92 |
93 |
94 |
95 | ### Assignees 부여
96 |
97 | ✔️또한, 해당 이슈에 대해 Assignees(책임자)를 부여할 수 있다.
98 |
99 | 
100 |
101 | 
102 |
103 |
104 |
105 | 
106 |
107 | 라벨과 책임자를 부여한 후 이슈 리스트를 보면 깔끔하게 정리되어있는 것을 확인할 수 있다.
108 | 지정한 label과 assignee를 통해 Filters 란에서 필터링하여 이슈를 검색할 수 있다.
109 |
110 |
111 |
112 | 하지만, Label과 Assignee를 부여해도 각 기능별 서로 유사한 이슈들이 존재하며, 이와 관련된 이슈를 찾거나 해당 기능들이 얼마나 구현되어 있는지 파악하기 위해서는 일일히 추적해야한다.
113 |
114 |
115 |
116 | ### Milestone 설정
117 |
118 | ✔️이러한 문제점을 해결하는 기능이 **Milestone**이다.
119 |
120 | 마일스톤은 말 그대로 이정표 역할을 하며, **이슈들을 그룹화**한다.
121 |
122 | 
123 |
124 | 
125 |
126 | 이슈 탭의 Milestones에서 마일스톤을 생성할 수 있다.
127 |
128 |
129 |
130 | 
131 |
132 | 
133 |
134 | 이슈 상세페이지에서 마일스톤을 지정할 수 있다.
135 |
136 |
137 |
138 | 
139 |
140 | 
141 |
142 | 이슈는 이슈 상세페이지에서 close와 reopen을 할 수 있고, 마일스톤으로 최대 3개의 이슈까지 묶을 수 있다.
143 |
144 |
145 |
146 | 
147 |
148 | 하나의 이슈가 완료(close)된다면 마일스톤 진행상황이 업데이트된다.
149 |
150 | 또한 이슈 페이지에서 @이름을 통해 다른 사용자를 언급할 수 있고, #num을 통해 커밋, 이슈를 참조하여 소통을 원활하게 할 수 있다.
151 |
152 | 이를 통해 연관된 이슈의 추적과 진행상황을 한 눈에 파악할 수 있다.
153 |
154 |
155 |
156 | ✔️또 다르게, 풀 리퀘스트에서 이슈를 지정할 수 있다.
157 |
158 | 
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 | 
46 |
Repository Setting
48 |
49 | 
50 |
73 | 
74 |
82 | 
83 |
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 | 
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 | 
135 |
Profile 클릭 > Settings > Personal Settings > Profile > Trending settings
163 |
164 | 
165 |
192 | 
193 | 
194 |
195 |
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 |
17 |
Setting menu
20 | 21 |
22 | 
23 |
Fork commit 이 Merge 되기 전 / 후 비교
46 | 47 |
48 | 
49 |
Social preview 적용 전 / 후 비교
57 | 58 |
59 | 
60 |
81 | 
82 |
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 | 
238 |