###### tags: `2020 Boostcamp`
# Day01 - 학습정리

## 스스로 확인할 사항

- **코딩 테스트와 다르게 개선된 부분이 있는가 설명해본다.**
1. keyboard 배열에서 해당 문자 찾을 때 완전 탐색 -> Dictionary로 초기화 후 사전 탐색
* keyboard가 얼마나 크게 들어올 지는 모르지만 탐색시간을 O(n^2)에서 O(logN) 으로 줄임
2. 함수 분할
* 더 작은 단위로 함수를 쪼개어 가독성을 높힘
3. 변수명에 주의
* 한번에 알아들을 수 있는 변수명을 고심하고 사용함
4. 주석 추가
* 세세한 주석을 추가하여 다른 사람이 내 코드를 봤을 때 충분히 이해가 가도록 작성함
- **함수를 여러 개로 분리해서 만들면서 어떤 기준으로 함수를 분리했는가 설명한다.**
- 같은 논리 흐름을 가지는 최소 단위로 분리함
- 같은 로직이지만 방향성이 다르다면 분리함
- **git의 branch에 대해서 이해를 하고 있는가 본인이 이해한 데로 설명해본다.**
- 어떤 일을 독립적으로 작업하기 위한 개념으로 각각의 브랜치는 다른 브랜치의 영향을 받지 않기 때문에 여러 작업을 여러사람이 같이 할 수 있다는 것이 핵심이다. *Divide and Conquer* 의 진가를 보여주는 기능이 아닌가 싶은데, 작은 단위로 부터 그 크기를 키워나가며 큰 작업을 할 수 있고, 문제가 발생했을 때 원인을 찾기 쉽다는 장점이 있다.

## 다같이 확인할 사항

- **원본 저장소를 fork해서, PR을 보낼 때까지 흐름에 대해서 각자 이해한 내용과 차이점이 있는지 비교한다.**

1. 원본 저장소에서 내 저장소로 fork
* 다른 사람의 저장소에서 내가 어떤 부분을 수정하거나 추가 기능을 넣고 싶을 때
* 원본의 내용이 변하면 fetch나 rebase의 과정을 거쳐 내 저장소에 반영이 가능하다
2. 작업 후 PR
* pull request를 보내기 전까지는 내 저장소에만 변경 사항이 반영되어 있다
* pr을 보내면 원본 저장소의 관리자가 적절성을 따져 승인 여부를 결정하게 된다
* 승인이 되면 나의 작업물이 원본 저장소에 commit, merge 되어 반영된다

- **git add와 commit을 할때 git 내부에서는 어떤 동작이 일어나는 것인지 자료를 찾아서 학습하고 이를 비교해서 정리한다.**

* Object

Git을 구성하는 데이터파일. Working directory의 파일 정보를 object형식으로 변환하여 Object database에 저장

각각의 Object 파일은 Zlib을 이용하여 압축되며, 파일의 내용과 헤더를 40자의 SHA-1 헤시값으로 저장한다

* Index

object 파일 링크의 list를 가지고 있다

* git add

object 파일이 생성되고, blob, object 링크, 파일이름 을 담고 있는 index 파일이 변경된다

* git commit

git에 변경된 파일이 있음을 명시하는 동작이다. 따라서 commit을 하면, 그 전까지 add한 파일들이 해당 commit에 기록된다

먼저 index 파일을 변경하고, 변경된 파일 정보들을 가지고 있는 object를 생성한다. 그 후 commit의 전체 정보가 담긴 파일을 생성하고 마지막으로 commit을 가르키는 HEAD등 그와 관련된 파일들이 변경된다

- **여러 명이 협업을 하며 프로젝트를 개발할때는 다양한 branch전략을 세워서 한다.**
**실무에서 사용하는 워크플로우 (예 - gitflow, git workflow, gitlab workflow 등)에 대해서 찾아보고, 왜 그런 전략이 필요한지 고민한 후 비교한다.**

- gitflow - master와 develop 브랜치를 항상 유지하고 보조 브랜치를 일정기간 유지한다.
- master : 제품으로 출시될 수 있는 브랜치
- develop : 다음 출시 버전을 개발하는 브랜치
- feature : 기능을 개발하는 브랜치
- release : 이번 출시 버전을 준비하는 브랜치
- hotfix : 출시 버전에서 발생한 버그를 수정 하는 브랜치
- github flow - master 브랜치에 대한 role만 정확하다면 나머지 브랜치들에는 관여하지 않는다. PR 권장
- 릴리즈 라는 개념이 없다
- 브랜치 전략 단순
- CI가 필수적이며, 배포는 자동으로 진행할 수 있다
- gitlab flow - github flow의 진화버전, production 브랜치가 존재하여 커밋한 내용들을 일방적으로 디플로이 하는 형태
- master와 production 사이에 pre-production을 두어 개발 내용을 시간을 두고 반영한다.
- PR하여 merge 한다

코드 품질 향상, 코드 가독성 향상이 주 목적이라 생각된다. 또한 버그가 발생하였을 때 해당 버전의 코드로 디버깅해서 원인을 찾고 상황 재현, 수정, 검증, 재배포의 단계를 체계적이고 안정적으로 처리할 수 있어야 한다. 그러기 위해 branch 전략을 세우는 것은 필수적이다.