├── .gitignore ├── LICENSE └── README.md /.gitignore: -------------------------------------------------------------------------------- 1 | # macOS 2 | *~ 3 | .DS_Store 4 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Copyright (c) 2020 stevejkang 2 | 3 | Permission is hereby granted, free of charge, to any person obtaining a copy 4 | of this software and associated documentation files (the "Software"), to deal 5 | in the Software without restriction, including without limitation the rights 6 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 7 | copies of the Software, and to permit persons to whom the Software is 8 | furnished to do so, subject to the following conditions: 9 | 10 | The above copyright notice and this permission notice shall be included in 11 | all copies or substantial portions of the Software. 12 | 13 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 14 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 15 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 16 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 17 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 18 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN 19 | THE SOFTWARE. 20 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | # git-guideline 4 | 5 | Personal git/github guideline about commit convention, git flow, issue/pull-request templates, etc. 6 | 7 | [![Last Commit](https://img.shields.io/github/last-commit/stevejkang/git-guideline.svg)](https://github.com/stevejkang/git-guideline/commits) 8 | [![Hits](https://hits.seeyoufarm.com/api/count/incr/badge.svg?url=https%3A%2F%2Fgithub.com%2Fstevejkang%2Fgit-guideline)](https://github.com/stevejkang/git-guideline) 9 | 10 | ## Table of Contents 11 | 1. [Commit Convention](#1-commit-convention) 12 | 2. [Git Flow & Branch](#2-git-flow--branch) 13 | 3. [Issue](#3-issue) 14 | 4. [Pull Request](#4-pull-request) 15 | 5. [Actions](#5-actions) 16 | 6. [Wiki](#6-wiki) 17 | 7. [Troubleshooting](#7-troubleshooting) 18 | 8. [Tips](#8-tips) 19 | 9. [이제 뭘하면 되나요?](#9-so-what-should-i-do) 20 | 21 | ## 1. Commit Convention 22 | > [상단으로 ⬆️](#git-guideline) 23 | 24 | ### 1.1. 커밋의 정의 25 | 26 | #### 1.1.1. 작성자 27 | 28 | 커밋은 작업자가 직접 작업한 내용에 대해 커밋을 합니다. 29 | 30 | #### 1.1.2. 단위 31 | 32 | 커밋은 작업 하나의 단위가 되어야 합니다. 행동 하나의 단위가 되어서는 안됩니다. 33 | 예를 들어, `Case A`는 가능하지만 `Case B`는 커밋의 단위로 권장하지 않습니다. 34 | 35 | - `Case A` 36 | - CLI로 Vue.js 프로젝트를 설치한 경우 37 | - 오타를 고친 경우 38 | - 여러 개의 Dependency를 설치하여 프로젝트 기반을 만든 경우 39 | - 하나 이상의 Dependency를 설치하고 프로젝트 어딘가에 정의, 적용한 경우 40 | - `Case B` 41 | - Dependency를 설치한 경우 42 | 43 | #### 1.1.3. 조건 44 | 45 | 커밋은 임시로 저장 해두기 위한 장치로 사용해서는 안됩니다. ([git stash](https://git-scm.com/docs/git-stash) 커맨드 사용을 권장합니다.) 즉, 모든 커밋은 개발 당시에 완결된 코드만이 올라가야 합니다. 46 | 47 | ### 1.2. 커밋 메세지 48 | 49 | > 상세한 커밋 메세지를 작성하도록 노력해야 합니다. 습관적으로 `-m` 옵션을 붙이고 single-line 커밋을 지양하도록 합니다. (당연하게도 `-m`이 multi-line 커밋을 작성할 수 없다는 의미는 아닙니다. 여기서는 좀 더 상세한 커밋 정보를 확인하기 위해 입력창으로 들어가 작성하는 것을 습관들이기 위함입니다.) 50 | 51 | #### 1.2.1. 언어 52 | 53 | 누구나 봤을 때 이해할 수 있도록 영어로 작성하는 것을 권장합니다. 54 | 55 | > 어디까지나 권장일 뿐, 강제 사항은 아니며, 사내에서 사용하는 경우나 필요에 따라서는 사용하기 편한 언어로 서술하는 게 전달이 명확한 경우도 있습니다. 56 | > 대신, 오픈소스를 개발하고자 한다면, 영어를 사용하는 것이 좋습니다. 57 | 58 | #### 1.2.2. 구성 59 | 60 | 아래는 이 레포지토리에서 제안하는 커밋 컨벤션입니다. 61 | 62 | > 아래에서 설명하는 컨벤션은 가장 기본적인 컨벤션입니다. 63 | > 상황에 따라 다양한 포맷을 사용할 수 있고, 이미 사용하고 있는 컨벤션이 있다면 [다음](#2-git-flow--branch)으로 넘어가주세요. 64 | 65 | - 기본 구성은 다음과 같습니다. 66 | 67 | > ``는 optional field를 의미합니다. 68 | 69 | ``` 70 | 71 | 72 | 73 | - 74 | 75 | ``` 76 | 77 | - 모든 줄은 문장으로 구성되며, 첫 문자는 대문자로, 첫 단어는 현재형 동사로, 마침표는 사용하지 않아야 합니다. 기타 기호 또는 특수문자(emoji 포함)는 필요한 경우를 제외하고는 사용을 권장하지 않습니다. 78 | - 예외사항 79 | - 메소드명 `getMessage()` 80 | - 파일명 `getMessage.js` 81 | - 예시 82 | - `Fix calculation in process.uptime()` 83 | 84 | - 세 줄 이상 작성해야 하고, 커밋의 두 번째 줄은 반드시 비워야 합니다. 세 번째 줄의 항목부터 상세 내용을 추가( `-` + 내용)할 수 있습니다. 85 | - 예외사항 86 | - 오타 수정 `Fix typo` 87 | - 예시 88 | ``` 89 | Prevent multiple connection errors 90 | 91 | Catch error caused by network error 92 | - Use try catch expression 93 | ``` 94 | 95 | - 이슈가 해결된 내용은 커밋 최하단에 `Fix #7`와 같은 용법으로 사용할 수 있습니다. 96 | > 또는 PR로 올라갈 커밋이 아니라면 간단히 메세지 뒤에 `(#7)`과 같이 reference 할 수 있습니다. 97 | 98 | - 커밋의 제목 또는 본문에 가장 먼저 나타나는 현재형 동사는 다음을 사용합니다. 99 | - **Fix** [기능수정] 100 | - `Fix A`: A 수정 101 | - `Fix A in B`: B의 A 수정 102 | - `Fix A which B/Fix A that B`: B인 A 수정 103 | - `Fix A to B/Fix A to be B`: B를 위해 A 수정 | B하기 위해 A 수정 104 | - `Fix A so that B`: A 수정해서 B (B 상태 강조) 105 | - `Fix A[issue|error|crash] where B`: B하는 A 수정 106 | - `Fix A when B`: B에 발생하는 A 수정 107 | - **Add** [추가(코드/테스트/문서)] 108 | - `Add A`: A 추가 109 | - `Add A for B`: B를 위한 A 추가 110 | - `Add A to B`: B에 A 추가 111 | - **Remove** [삭제(코드/문서)] 112 | > 보통 (unnecessary|useless|unneeded|unused|duplicated) + A 형태 113 | - `Remove A`: A 삭제 114 | - `Remove A from B`: B에서 A 삭제 115 | - **Use** [사용] 116 | - `Use A`: A 사용 117 | - `Use A for B`: B를 위한 A 사용 118 | - `Use A to B`: B에 A 사용 (to-부정사 B 허용) 119 | - `Use A in B`: B에 A 사용 | B 내부에서 A 사용 120 | - `Use A instead of B`: B 대신에 A 사용 121 | - **Apply** [적용] 122 | - `Apply A`: A 적용 123 | - `Apply A to B`: B에 A 적용 124 | - **Refactor** [리팩토링(행위/기능/메소드)] 125 | - `Refactor A`: A 리팩토링 126 | - **Simplify** [단순화(행위/기능/메소드)] 127 | - `Simplify A`: A 단순화 128 | - **Update** [업데이트/버전 업(문서/리소스)] 129 | - `Update A`: A 최신화 130 | - `Update A to B`: A를 B로 최신화 131 | - `Update A for B`: B를 위한 A 업데이트 132 | - **Change** [변경] 133 | - `Change A`: A 변경 134 | - `Change A into B`: A를 B로 변경 135 | - **Improve**/**Enhance** [향상/개선(테스트/커버리지/성능)] 136 | - `Improve A`: A 향상 137 | - **Make** [동작 변경] 138 | - `Make A B`: A를 B하게 하다 (to-부정사 B 허용) | A를 B로 만들다 139 | - **Implement** [Add 보다 큰 구현] 140 | - `Implement A`: A 구현 141 | - `Implement A to B`: B에 A 구현 142 | - **Correct** [(문법/타입 등을) 맞도록 수정] 143 | - `Correct A`: A를 맞게 하다 144 | - **Ensure**/**Make sure** [검증] 145 | - `Ensure A`: A를 확실하게 하다 146 | - **Prevent** [접근제한] 147 | - `Prevent A`: A를 막다 148 | - `Prevent A from B`: A를 B하지 못하게 막다 149 | - **Avoid** [(조건 등을) 피하다] 150 | - `Avoid A`: A를 피하다. 151 | - `Avoid A if B/Avoid A when B`: B일 때 A에 걸리지 않도록 하다 152 | - **Move** [이동(코드/문서)] 153 | - `Move A to B/Move A into B`: A를 B로 이동하다 154 | - **Rename** [이름 수정(코드/문서/메소드)] 155 | - `Rename A to B`: A를 B로 이름을 바꾸다 156 | - **Allow** [허용] 157 | - `Allow A to B`: A가 B할 수 있도록 허용 158 | - **Verify** [검증] 159 | - `Verify A`: A를 검증 160 | - **Set** [설정(변수/값)] 161 | - `Set A to B`: A를 B로 설정 162 | - **Pass** [파라메터] 163 | - `Pass A to B`: A를 B로 넘기다 164 | - **Disable** [비활성화] 165 | - `Disable A`: A를 비활성화 하다 166 | - **Organize** [정리] 167 | - `Organize A`: A 정리 168 | 169 | ## 2. Git Flow & Branch 170 | > [상단으로 ⬆️](#git-guideline) 171 | 172 | ### 2.1. 개요 173 | 174 | #### 2.1.1. 정의 175 | 176 | Git Flow는 버전 관리 시스템(Version Control System, VCS)의 한 종류인 git을 통해 효율적으로 프로젝트를 관리하고 배포하기 위한 전략이자 브랜칭 관리 전략(Branch Management Strategy) 입니다. 실제 프로덕트를 개발하고 지속적으로 배포하는 조직에서 권장되는 방법이지만, 실제로 개발 조직에 적용하는 방식은 각기 다를 수 있습니다. 177 | 178 | > 아래에서는 Best Practice를 담으려 노력하였으나, 조직과 프로젝트의 성격에 맞게 조정이 필요할 수 있습니다. 179 | 180 | 이 섹션에서 말하는 Branch는 Git Flow의 브랜칭 관리 전략을 따르는 브랜치에 대한 설명입니다. 따라서 기본적인 `git branch` 명령어에 대한 설명을 포함하지 않습니다. 즉, 기본적으로 branch를 만들고, 이동하며, 삭제하는 등의 기초지식이 요구됩니다. 181 | 182 | > Git Flow는 GitHub Flow와 다릅니다. 무엇이 더 좋은 지에 대한 논의는 [여기](https://stackoverflow.com/questions/18188492/what-are-the-pros-and-cons-of-git-flow-vs-github-flow)에서 확인할 수 있습니다. 가장 먼저 제안된 모델(classic version)은 Git Flow이지만, CI/CD가 존재한다면, 또는 다양한 시도가 필요한 애자일 조직에서는 GitHub Flow를 사용하는 것이 나은 방법인 경우도 있습니다. 183 | 184 | ### 2.2. 방법 185 | 186 | > Vincent Driessen이 제안한 Git Flow는 다음 [PDF](https://nvie.com/files/Git-branching-model.pdf)로 한 눈에 확인할 수 있습니다. 187 | 188 | #### 2.2.1. 브랜치 전략 189 | 190 | Git Flow에서는 용도/환경에 따라 브랜치를 구분합니다. 메인 브랜치는 master, develop 브랜치가 해당되며, 그 외에 보조 브랜치는 feature, release, hotfix, bugfix 브랜치 등이 해당됩니다. 191 | 192 | - **master** 193 | 프로젝트의 뿌리가 되는 브랜치로, 해당 브랜치의 HEAD는 production 환경에 배포되었거나, 곧 배포될 예정임(production-ready)을 의미합니다. 실제 서비스에서는 실 서버와 sync가 맞아야 합니다. 194 | master 브랜치에 반영 혹은 병합된다는 것은 새 버전이 배포됨을 의미합니다. 보통 실제 서버로 빌드 & 배포하는 스크립트가 작동합니다. 195 | 196 | - **develop** 197 | 다음 배포를 위해 개발되고 있는 코드가 위치하는 브랜치. 실제 서비스에서는 개발 서버 혹은 테스트 서버와 sync가 맞아야 합니다. 198 | develop 브랜치가 안정화되고, 배포 기능이 완성되면, master로 병합됩니다. 199 | 200 | 201 | 202 | 203 | 204 | 205 | 206 | 207 | 208 | 209 | 210 | 211 | 212 | 213 | 214 | 215 | 216 | 217 | 218 | 219 | 220 | 221 |
브랜치 상세
develop시작브랜치master
병합브랜치(방향/순서)master
네이밍 규칙develop
222 | 223 | - **feature** 224 | feature 브랜치는 개발하고자 하는 기능을 개발하는 주축이 되는 브랜치입니다. 만약 애자일 방법론을 채택한 조직이라면, 스프린트 기간 중 하나의 스토리 혹은 하나의 에픽이 이에 해당할 수 있습니다. 225 | 이 브랜치는 성공적으로 develop에 병합되거나 필요성이 없어진 경우 삭제하여 관리할 수 있습니다. 226 | 227 | > 네이밍 규칙에서 `feature-*`가 본래 권장되는 형식이나, SourceTree 등 GUI 환경에서 폴더구조로 표시된다는 이점 때문에 `feature/*`로 사용하기도 합니다. 228 | 229 | 230 | 231 | 232 | 233 | 234 | 235 | 236 | 237 | 238 | 239 | 240 | 241 | 242 | 243 | 244 | 245 | 246 | 247 | 248 | 249 | 250 |
브랜치 상세
feature시작브랜치develop
병합브랜치(방향/순서)develop / master
네이밍 규칙feature-* 또는 feature/*
251 | 252 | - **work** 253 | 개인별 작업을 위한 브랜치. 이는 Git Flow에 해당하는 내용은 아니지만, optional하게 사용할 수 있는 브랜치로, feature에서 분기되어 기능 개발에 사용되며, 작업자별 원활한 작업을 위해 만드는 것을 권장합니다. 254 | 255 | > 일부 조직에서는 fork의 형태로 repository를 분리하는 방법을 채택하기도 합니다. 256 | 257 | 258 | 259 | 260 | 261 | 262 | 263 | 264 | 265 | 266 | 267 | 268 | 269 | 270 | 271 | 272 | 273 | 274 | 275 | 276 | 277 | 278 |
브랜치 상세
work시작브랜치feature
병합브랜치(방향/순서)feature / develop / master
네이밍 규칙ex) steve-* 또는 steve/*
279 | 280 | 여기까지 정리해보면 전체적인 브랜치 분기의 depth를 가장 위의 계층부터 나타내면 아래와 같습니다. 281 | 282 | master -> develop -> feature/* -> work/* 283 | 284 | develop 브랜치에서는 여러 개의 feature 브랜치가 분기될 수 있으며, 하나의 feature 브랜치에는 여러개의 work 브랜치가 분기될 수 있습니다. 285 | 286 | 아래는 release, hotfix, bugfix 브랜치로, 각각의 상황에 따라 사용되는 보조 브랜치입니다. 287 | 288 | - **release** 289 | 최종 프로덕션으로 올릴 상태가 되었을 때, 이를 master로 반영하기 직전에 생성되는 브랜치. 보통의 경우, develop은 master보다 업데이트 주기가 짧기 때문에, develop에서 작업 중인 한 시점에서 release 브랜치를 생성하여, 최종적인 릴리즈 준비를 할 수 있습니다. 290 | 이렇게 진행할 경우, 처음 release가 분기되고 그 이후에 develop에 업데이트 되는 내용들은 다음 release 브랜치가 분기될 때 반영하게 되어, 현재 분기된 release 브랜치에 한해 정확한 범위 내에 업데이트를 진행할 수 있게 됩니다. 291 | 이 브랜치가 master로 반영될 때, 태그를 이용해 버저닝(versioning)을 진행하는 것을 권장하며, 반영 후에는 develop에도 동일한 내용을 병합합니다. 292 | 293 | 294 | 295 | 296 | 297 | 298 | 299 | 300 | 301 | 302 | 303 | 304 | 305 | 306 | 307 | 308 | 309 | 310 | 311 | 312 | 313 | 314 |
브랜치 상세
release시작브랜치develop
병합브랜치(방향/순서)master / develop
네이밍 규칙release-* 또는 release/*
315 | 316 | - **hotfix** 317 | 미리 계획되지 못한 배포를 위한 브랜치. 실제 프로덕션에 장애를 일으킬 정도의 크리티컬(critical)한 이슈가 발생되어 긴급히 수정해야 할 때 사용합니다. 318 | 이전 release 브랜치가 master에 반영된 시점(태그로 버저닝된 시점)에서 hotfix 브랜치를 분기하여 이를 master, develop 순으로 반영을 진행합니다. 319 | 320 | 321 | 322 | 323 | 324 | 325 | 326 | 327 | 328 | 329 | 330 | 331 | 332 | 333 | 334 | 335 | 336 | 337 | 338 | 339 | 340 | 341 |
브랜치 상세
hotfix시작브랜치master
병합브랜치(방향/순서)master / develop
네이밍 규칙hotfix-* 또는 hotfix/*
342 | 343 | - **bugfix** 344 | 기존에 리포팅된 이슈 혹은 버그를 해결하기 위해 생성되는 브랜치. 보통 fix 브랜치라고 불리기도 하며, 서비스에 중대한 영향을 끼치진 않지만, 기능으로 분류될 수 없고, 버그라 판단되는 경우, 이를 서비스에 반영하기 위해 생성합니다. 345 | 보통 develop에서 분기되어 이를 develop, master 순으로 병합되며, 표면적으로는 feature 브랜치와 동일합니다. 346 | 347 | 348 | 349 | 350 | 351 | 352 | 353 | 354 | 355 | 356 | 357 | 358 | 359 | 360 | 361 | 362 | 363 | 364 | 365 | 366 | 367 | 368 |
브랜치 상세
bugfix시작브랜치develop
병합브랜치(방향/순서)develop / master
네이밍 규칙bugfix-* 또는 bugfix/*
369 | 370 | ### 2.3. 적용 371 | 372 | #### 2.3.1. 일반적인 플로우 373 | 374 | 이 섹션에서 말하는 '일반적인' 플로우란 릴리즈 혹은 핫픽스와 같은 상황을 제외한 가장 보편적인 상황(common case)을 다룹니다. 조직에 따라 work(개인 작업) 브랜치 대신에 fork하여 사용할 수 있고, merge 전에 rebase를 택할 수도 있습니다. ([2.4.1. merge와 rebase 무엇이 정답일까?](#241-merge-전에-rebase를-해야-하는-이유) 참고) 375 | 376 | 그러니 이 레포지토리에서는 merge 전에 rebase를 하는 병합 플로우, 그리고 브랜치 관리 전략을 강력하게 권장합니다. 해당 방법은 rebase 후에 fast-forward merge를 사용하여 깔끔한 브랜치를 유지할 수 있습니다. 이 방법은 뒤에 나오는 [2.3.2. 릴리즈 플로우](#232-릴리즈-플로우)와 [2.3.3. 핫픽스 플로우](#233-핫픽스-플로우)에서도 동일하게 사용합니다. 377 | 378 | > WIP general flow 379 | 380 | #### 2.3.2. 릴리즈 플로우 381 | 382 | > WIP release flow 383 | 384 | #### 2.3.3. 핫픽스 플로우 385 | 386 | > WIP hotfix flow 387 | 388 | ### 2.4. 고민해볼 내용 389 | 390 | #### 2.4.1. merge 전에 rebase를 해야 하는 이유 391 | 392 | 393 | 394 | 395 | **merge** 396 | feature/order에서 분기한 steve/pg 브랜치가 있다고 가정합니다. 397 | > [feature/order] git commit -m "a" 398 | > [feature/order] git commit -m "b" 399 | > [feature/order] git checkout -b steve/pg 400 | > [steve/pg] git commit -m "x" 401 | > [steve/pg] git commit -m "y" 402 | 403 | (a) (b) 404 | feature/order * ----- * 405 | \ 406 | steve/pg ----- * ----- * 407 | (x) (y) 408 | 409 | 위 상태에서 작업 내용을 feature/order로 병합하려 할 때, 만약 다른 팀원이 feature/order 브랜치에 반영한 내용이 없고, 분기 이후로 진행된 커밋이 없다는 것이 origin으로부터 확인되면, fast-forward merge 혹은 non-fast-forward merge를 진행할 수 있습니다. 410 | 411 | - fast-forward merge를 하면 다음과 같습니다. 412 | > [steve/pg] git checkout feature/order 413 | > [feature/order] git merge --ff-only steve/pg 414 | 415 | > 이 경우에는 상위 브랜치에 변경사항이 없으므로 뒤에서 나올 rebase와 동일하게 사용할 수 있습니다. (아래에서 나올 예시와 다른 점은 상위 브랜치에서 하위 브랜치로 rebase 한다는 점입니다.) 416 | 417 | (a) (b) 418 | * ----- * 419 | \ steve/pg 420 | ----- * ----- * feature/order 421 | (x) (y) 422 | 423 | > 작업이 완료된 steve/pg 브랜치를 삭제하여 히스토리를 깔끔하게 유지할 수 있습니다. 424 | 425 | - non-fast-forward를 하면 다음과 같습니다. (m은 merge commit) 426 | > [steve/pg] git checkout feature/order 427 | > [feature/order] git merge --no-ff steve/pg 428 | 429 | (a) (b) (m) 430 | feature/order * ----- * * ----- 431 | \ / 432 | steve/pg ----- * ----- * ----- 433 | (x) (y) 434 | 435 | > 작업이 완료된 steve/pg 브랜치를 삭제하면 분기된 브랜치의 형태와 그 커밋은 유지되고 브랜치만 삭제됩니다. 436 | 437 | 하지만, feature/order에 변경사항이 있고 rebase 한 적도 없는 경우, 실질적인 머지 커밋으로만 병합이 가능합니다. 이 때는 non-fast-forward merge와 fast-forward merge 모두 동일하게 커밋이 남게 됩니다. 438 | 439 | > [steve/pg] git checkout feature/order 440 | > [feature/order] git merge steve/pg 441 | 442 | (a) (b) (m) 443 | feature/order * ----- * * ----- 444 | \ / 445 | steve/pg ----- * ----- * ----- 446 | (x) (y) 447 | 448 | > 작업이 완료된 steve/pg 브랜치를 삭제하면 분기된 브랜치의 형태와 그 커밋은 유지되고 브랜치만 삭제됩니다. 449 | 450 | **rebase** 451 | 리베이스는 병합(merge)한다는 개념과는 거리가 있지만, 브랜치의 base를 옮겨 다른 브랜치의 내용을 반영한다는 점에서는 비슷합니다. 452 | 453 | rebase 작업을 하면서 가장 주의해야 할 것은 rebase 후에 그 rebase를 적용받은 커밋들은 commit hash가 바뀌게 됩니다. 즉, 그렇게 바뀐 커밋이 이미 remote(github 등) branch에 올라갔던 커밋이라면 해당 내용을 (불가피하게) force-push(`--force`) 해야 할 것이고, 누군가와 동일한 브랜치에서 협업을 하고 있다면 푸시 후 `git reset --hard origin/` 등으로 다시 로컬에 반영이 필요할 것입니다. 454 | 455 | 결론적으로 개인 브랜치에서는 리베이스를 자유롭게 해도 무방하지만, 다양한 협업과 커밋이 짧은 주기로 이루어진다면 협업에 많은 주의가 필요합니다. 이를 위해 항상 up-stream 설정을 해두고 로컬과 리모트의 상태를 최신화할 필요가 있습니다. 습관적으로 `git push` 전에 `git fetch`와 해당 변경사항을 올바르게 `git pull`을 해주어야 합니다. 456 | 457 | rebase는 보통 하위 브랜치에서 상위 브랜치를 rebase한다고 표현하며, 현재 브랜치가 "하위 브랜치", 바라보는/병합 브랜치가 "상위 브랜치"가 됩니다. 상위 브랜치의 변경사항을 모두 반영하여, 그 상위 브랜치를 기반(base)으로 하여 현재 브랜치의 base 이후 모든 커밋을 최신화한다는 의미를 가지고 있습니다. 458 | 459 | 예를 들어, 기존의 상태가 다음과 같다면, 460 | 461 | (a) (b) 462 | feature/order * ----- * 463 | \ 464 | steve/pg ----- * ----- * 465 | (x) (y) 466 | 467 | steve/pg에서 feature/order 기준으로 rebase할 수 있습니다. 468 | 469 | > [steve/pg] git rebase feature/order 470 | > f/o가 feature/order, s/p가 steve/pg 브랜치. 471 | 472 | (a) (b) (x) (y) 473 | * ----- * ----- * ----- * 474 | (f/o) (s/p) 475 | 476 | 이때, steve/pg에서 커밋했던 (x), (y) 커밋이 영향을 받습니다. 이미 remote에 올라갔다면 force push로 업데이트해야 합니다. 477 | 478 | 만약 rebase에서 conflict가 난 경우, 각 파일에서 conflict를 해결하고 rebase를 진행하면 됩니다. rebase는 진행 방법이 현재 브랜치의 커밋을 하나하나 탐색하며, 적용하는 방법이므로, 한 번 rebase를 할 때 각 커밋별로 여러번 해결해야 하는 경우도 있습니다. 대신 이와 같이 conflict를 해결하는 것이 공동작업 업무에서도 문제없이 요구사항을 올바르게 반영할 수 있는 방법입니다. 479 | 480 | > [steve/pg] git rebase feature/order 481 | > [steve/pg] [CONFLICT 발생] 482 | > [steve/pg] git add [confilcted file] 483 | > [steve/pg] git rebase --continue 484 | 485 | ## 3. Issue 486 | > [상단으로 ⬆️](#git-guideline) 487 | 488 | 여기부터 [6. Wiki](#6-wiki)까지는 GitHub 위주의 내용이지만, [3. Issue](#3-issue)와 [4. Pull Request](#4-pull-request)는 다른 git hosting service(bitbucket, gitlab 등)에서도 사용되는 것으로 기본적인 개념은 동일합니다. 그러나 여기서는 github 환경을 위주로 설명합니다. 489 | 490 | Issue로 등록되는 경우에는 다양한 경우가 있습니다. jira의 ticket처럼 사용할 수도 있고, 버그 픽스를 요구하는 issue가 등록될 수도 있습니다. 특히 오픈소스라면 다양한 내용이 이슈로 등록될 수 있고, 사내 프로젝트에서도 용도가 다양할 수 있습니다. 이 섹션의 목표는 단순히 이슈 하나를 만들고, 발행하는 것이 아니라, github의 다양한 기능들을 이용하여 좀 더 생산성 높게 Issue를 다루는 방법을 안내합니다. 491 | 492 | ### 3.1. Issue Template 493 | ## 4. Pull Request 494 | > [상단으로 ⬆️](#git-guideline) 495 | 496 | ## 5. Actions 497 | > [상단으로 ⬆️](#git-guideline) 498 | 499 | ## 6. Wiki 500 | > [상단으로 ⬆️](#git-guideline) 501 | 502 | ## 7. Troubleshooting 503 | > [상단으로 ⬆️](#git-guideline) 504 | 505 | ## 8. Tips 506 | > [상단으로 ⬆️](#git-guideline) 507 | 508 | ## 9. So, What should I do? 509 | > [상단으로 ⬆️](#git-guideline) 510 | 511 | git(혹은 github)은 사용하는 사람, 혹은 조직에 따라 매우 유연하게 사용되어야 합니다. 조직이라면, 개발 조직내 인원 모두가 git과 gitflow에 대한 이해가 되어 있을 때, 제대로 작동할 수 있습니다. 512 | 513 | ## Reference 514 | 515 | - [좋은 git commit 메시지를 위한 영어 사전](https://blog.ull.im/engineering/2019/03/10/logs-on-git.html) 516 | - [GIT을 기반으로 한 프로젝트 개발프로세스](https://gist.github.com/ihoneymon/a28138ee5309c73e94f9) 517 | - [A successful Git branching model](https://nvie.com/posts/a-successful-git-branching-model/) 518 | - [Merge Branch - Backlog](https://backlog.com/git-tutorial/integrating-branches/git-merge/) 519 | - [Rebase Branch - Backlog](https://backlog.com/git-tutorial/integrating-branches/rebase-branch/) 520 | 521 | ## License 522 | 523 | MIT 524 | 525 | ## Author 526 | 527 | stevejkang 528 | --------------------------------------------------------------------------------