2022-01-29

Daily/StudyNote/2022-01-29.md

@@ -0,0 +1,252 @@
+# GitHub - 알고리즘 스터디 활용
+
+이번에 동기들과 알고리즘 스터디를 진행하기로 했는데 어떻게 하면 GitHub을 통해서 알고리즘을 효율적으로 진행할 수 있을지 고민해봤다.
+
+## 이런저런 아이디어
+
+* organization 생성, 각자 `fork` 받아와서 `자신의 이름` 폴더에서 작업.
+
+### 브랜치
+
+* 각자 다른 폴더에서 작업하기 때문에 브랜치 생성은 생략해도 될 것 같다.
+
+  몇주차인지 이슈에서 확인할수도 있고, PR할때 squash로 제목을 주차로 묶어도 괜찮을듯.
+
+* `#이슈번호`를 포함시켜서 branch를 생성해서 사용하는 것도 좋은 것 같다.
+
+  > merge commit 기본 메시지가 `Merge pull request #[PR번호] from 리포지토리명/브랜치명`이라서 merge commit에서 관련 issue와 PR에 빠르게 접근할 수 있다.
+
+### Issue - 주차별 문제목록
+
+* 주차별로 공통 문제를 정해서 풀어가는 방식으로 하려면 issue를 통해 주차별로 문제목록을 올려두면 좋을 것 같다.
+
+* 다만 PR과 issue를 연동하려면 PR이 merge될경우 issue도 close되는 형식밖에 없어서 고민이다.
+
+  하지만 PR없이 커밋으로만 하려니 코드 리뷰하기에도 그렇게 좋지 않고 전체적인 코드 관리가 힘들어지는 것 같다.
+
+  그래도 커밋이나 merge커밋에 이슈번호를 넣으면 PR이랑 issue랑 간접적으로는 연결된다.
+
+* `[문제출처] [문제 이름](문제 url) / 난이도`
+
+  > 난이도를 표시하는게 좋을지 잘 모르겠다.
+
+* 주차별로 문제풀이 현황을 빠르게 확인할 수 있다.
+
+### Commit - 소스코드
+
+* 평소에 알고리즘 문제를 풀고 md파일에 정리해 둔다. 그래서 이걸 활용해보면 어떨까 싶었는데 커밋내역에서는 마크업되어서 나오지 않기 때문에 가독성이 안 좋았다.
+
+  > 알고보니 마크업해서 볼 수 있도록 버튼이 하나 있었다. 하지만 마크업상태에서는 comment를 남길 수가 없어서 소스코드만 올리는게 코드 리뷰하기에는 더 나은 것 같다.
+
+* 파일 자체는 소스코드만 올려두고 문제 접근 방식, 어려웠던 점 등은 PR에 포함시키는게 더 좋을 것 같다.
+
+* **커밋 컨벤션**<br>[문제 출처] 문제 이름 / 소요시간  (#이슈번호)<br>ex) `[프로그래머스] 문자열압축 / 30분 (#4)`
+
+  > 난이도까지 포함시키는게 좋을까?
+
+### PR - 문제풀면서 정리한 내용, 코드리뷰
+
+* GitHub에 Issue랑 PR template 기능이 있던데 사용하면 편할 것 같다.
+
+* 문제별로 생성하는게 좋을지, 주차별로 생성하는게 좋을지
+
+  > 생각해보니 문제별로 브랜치를 따로 만들지 않는 이상 PR이 머지되기 전까지는 새로운 문제를 풀 수가 없다.
+
+* merge strategy
+
+  * **merge commit**을 생성하는게 PR이랑 링크되서 코드리뷰를 바로 확인할 수 있어서 좋은 것 같다.<br>따로 merge commit 이름을 설정할수도 있지만 기본 메시지도 무방할 것 같다. `Merge pull request #[PR번호] from 리포지토리명/브랜치명`
+
+  * **squash**로 주차별로 커밋 내역을 묶어서 깔끔하게 유지할 수 있다. 하지만 커밋 로그에서 어떤 문제들을 풀어왔는지 기록을 바로 확인할 수 없다는 단점이 있다.
+
+    > 커밋이 하나만 있을 경우 PR을 생성하면 제목이 해당 커밋 메시지랑 동일하게 설정되어서 문제별로 PR을 작성할 경우 squash도 좋을 것 같다.
+    >
+    > 단, issue에서는 squash를 진행하기전 커밋 기록이 남아있어서 중복이 발생하면서 좀 지저분해질 수 있다.
+
+  주차별로 PR을 생성한다면 merge commit을 좋을 것 같고,
+
+  문제별로 PR을 생성한다면 squash가 좋을 것 같다.
+
+  > repository에서 허용할 strategy들을 고를 수 있다.
+
+* 코드리뷰
+
+  만약 코드리뷰를 선택적으로 받는다면 기본적으로 reviewer를 선택하지 않고<br>코드리뷰를 원하는 경우만 `code-review` 라벨을 붙이고 reviewer를 선택하는 방식으로 해도 좋을듯?
+
+### Discussions
+
+* GitHub에서 제공해주는 기능인데, 게시판 같은 기능이다.
+
+* 정보 공유나 질문 등을 올릴때 활용하면 좋을 것 같다.
+
+### Organizations
+
+* organization은 무한대로 만들 수 있다.
+
+* 알고리즘 문제풀이랑 개념정리를 2개의 repoistory로 나눠서 관리해도 좋을 것 같다.
+
+### 개념정리
+
+* 나무위키처럼 집단 지성을 이용해서 알고리즘 개념, 문제를 풀다보면 알게되는 유용한 문법 등의 정보들을 다 같이 정리하는 공간이 있어도 도움이 되겠다는 생각이 들었다.
+
+* wiki를 이용하거나 repository를 따로 만들어서 TIL처럼 md파일로 정리?
+
+* 돌아가면서 알고리즘 개념 md파일로 정리해서 올리기?
+
+  PR을 날리면 다들 복습하거나 추가로 알고있는 내용이 있다면 보충해주는 느낌으로
+
+<br>
+
+## 스터디 진행방식
+
+일단 사람당 한 문제씩 정해서 총 4문제를 다 같이 푸는건 좋은 것 같다.
+
+* **비대면** : 일정 기간 내에만 문제를 풀고 PR이 올라오는대로 코드 리뷰
+
+  편한 시간대에 자기 수준에 맞춰서 시간을 정해두고 풀 수 있어서 좋다. 하지만 그만큼 자칫 게을러질 수도 있을 것 같다.
+
+* **대면** : 코딩 테스트처럼 시간을 정해두고 모여서 푸는게 좋을 것 같긴 한데 사람마다 푸는 시간도 다르고 그래서 좀 고민이다.
+
+  아니면 문제만 미리 풀어서 github에 올려두고 모여서 코드 리뷰? <= 근데 이러면 굳이 모여서 할 필요가 있나?
+
+**스터디가 개인적으로 공부하는것에 비해서 가지는 장점을 곰곰히 생각해보고 이를 극대화 할 수 있는 방식을 생각해보자.**
+
+* 개인적으로 공부할 경우 지치기 쉬운데 스터디를 하게된다면 강제성이 있어서 하게되고 서로가 서로에게 동기부여가 된다.
+* 미처 생각하지 못했던 문제 해결 전략에 대해서 알 수 있다. (하지만 이건 프로그래머스의 경우 `다른 사람의 풀이`를 제공해주고, 따로 구글링을 통해서도 좋은 답안들을 찾아볼 수 있다.)
+* 코드 리뷰를 통해 좋은 코드에 대해 고민하고 피드백을 받는 경험을 할 수 있다.
+
+스터디를 함으로써 얻는게 무엇일지 곰곰히 생각해보니 **코드리뷰**가 스터디의 가장 큰 장점인 것 같다.
+
+### 코드 리뷰
+
+사실 남이 작성한 코드를 읽는 것이 쉬운 일은 아니라서 들이는 노력에 비해서 얻는게 없는 것 같아서 코드 리뷰에 대해서 살짝 회의감을 가지고 있었다.
+
+하지만 문득 추후에 협업을 하다보면 남의 코드를 읽게되는 일이 정말 많을 것이고, 미리 연습을 해둔다면 많은 도움이 될거라는 생각이 들었다. 그리고 혼자서 코드를 작성하다보면 이게 정말로 좋은 코드인지 알기 어려운데 코드 리뷰를 통해 피드백을 받아볼 수 있다. 따라서 코드 리뷰를 하다보면 자연스레 좋은 코드에 대한 경험치가 많이 쌓일 것 같다는 생각이 들었다.
+
+그렇다면 어떻게 코드 리뷰를 진행해야 할까
+
+인터넷을 좀 찾아보니 
+
+* 코드에 대해서 궁금한 점 질문
+* 잘한 내용에 대한 칭찬
+* 좋은 코드로 개선할 여지가 있는지
+
+등 코드를 보고 느낀점을 다양하게 얘기하는 식으로 진행하는 것 같다.
+
+그리고 코드 리뷰는 온라인에서 진행하는 것이 더 효율적일 것 같다. 그렇다면 만났을때는 어떤 활동을 하는게 좋을까.. 다른 알고리즘 스터디들을 보면 알고리즘 개념을 각자 공부하고 정리해와서 발표하는 시간을 가진 것 같다.
+
+<br>
+
+## 최종 아이디어
+
+맨 처음, 해당 repository를 `fork` 한 뒤 자신의 이름으로 폴더 만들어서 사용
+
+<br>
+
+### 1. 주차별 문제 목록 issue로 생성
+
+- 매주 각자 한 문제씩 골라오기
+
+- 해당 주차의 issue에 다음과 같은 형식으로 자신이 고른 문제 추가
+
+  `[문제출처] 난이도 [문제 이름](문제 url) - 문제 고른 사람`
+
+  ex) `[프로그래머스] Lv.2 [문자열 압축](https://programmers.co.kr/learn/courses/30/lessons/60057) - 치산`
+
+<br>
+
+### 2. 문제 단위로 Commit
+
+문제 해결 후 커밋
+
+```bash
+$ git add .
+$ git status
+$ git commit -m "#10 - [프로그래머스] Lv.2 문자열 압축 / 30분"
+$ git push origin main
+```
+
+- **커밋 컨벤션**
+
+  #이슈번호 - [문제 출처]문제이름 난이도 / 소요시간
+
+  ex) `#10 - [프로그래머스] Lv.2 문자열 압축 / 30분`
+
+  > 이슈번호를 넣음으로써 추후에 issue에서 해당 주차에 대한 커밋들을 모아서 확인할 수 있다.
+
+<br>
+
+#### 3. Pull Request
+
+커밋 후, fork 해 온 저장소로 이동해서 upstream 저장소에 PR 작성
+
+* **PR 컨벤션** (PR 만들때 나오는 template 참고)
+
+  **제목**: 
+
+  1. 문제별로 PR 생성하는 경우
+
+     커밋 메시지와 동일하게 작성. (커밋 내역이 하나일 경우 자동으로 커밋 메시지와 동일하게 설정된다.)
+
+  2. 주차별로 PR 생성하는 경우  (한 PR내에 여러 문제가 포함되는 경우)
+
+     `(#이슈번호) 알고리즘 문제풀이`처럼 제목에 이슈번호 포함시켜서 작성.
+
+  **내용**: 풀이 간단하게 설명, 문제풀면서 어려웠던 점, 소요시간 등 적어두기
+
+- reviewer 모두 지정
+
+<br>
+
+### 3. 코드 리뷰 후 Merge
+
+##### 코드리뷰
+
+- 최대한 가독성이 좋게 코드를 작성하려고 노력해보자
+- 코드 리뷰 내용은 자유롭게 작성하기
+  - 코드에 대해서 궁금한 점 질문
+  - 코드에 대한 칭찬
+  - 코드 개선 아이디어 건의 (성능, 클린코드 등)
+  - 등등 ..
+- 코드 리뷰가 끝난 뒤 필요에 따라 추가로 리팩토링하고 커밋 (커밋 형식은 자유)
+
+##### Merge
+
+1. 문제별로 PR을 생성한 경우 **squash merge**
+2. 주차별로 PR을 생성한 경우 (한 PR에 여러 문제가 포함된 경우) **merge commit** 생성
+
+<br>
+
+## 핵심 규칙
+
+너무 이런저런 규칙이 많아도 복잡할 것 같아서 코드 리뷰가 효과적으로 이루어지기 위해서 필요한 과정만 간추려봤다.
+
+* 주차별 문제 모음 issue로 생성
+* fork해서 `본인 이름의 폴더`에서 작업
+* 문제별로 커밋 작성. 커밋 메시지에 문제 이름, 이슈번호 포함해서 작성
+* upstream에 PR (제목에 몇주차인지 명시 / 본문에 문제 접근 방식, 어려웠던 점 등 자유롭게 기술)
+* 모든 사람들에게 코드 리뷰 받은 뒤 머지 (기본적으로 merge commit 생성)
+
+<br>
+
+> **참고자료**
+>
+> https://github.com/CodeTest-StudyGroup/Code-Test-Study
+>
+> https://github.com/ellynhan/challenge100-codingtest-study#readme
+>
+> https://github.com/kingyong9169/algorithm-tutoring
+>
+> https://prography-tech.github.io/2020/02/19/review-algorithm-study/
+>
+> https://prgms.tistory.com/9
+>
+> https://github.com/DKU-STUDY/Algorithm
+>
+> https://5anniversary.dev/20200614/Algorithm_Study
+
+<br>
+
+
+
+
+

Git/README.md

@@ -28,6 +28,22 @@
 
 
 
+## --root
+
+맨 처음 커밋을 가리키는 것
+
+`git rebase -i --root`를 하면 맨 처음 커밋까지 rebase 적용
+
+## git checkout --orphan
+
+새로운 root commit 생성
+
+> **참고자료**
+>
+> https://stackoverflow.com/questions/22992543/how-do-i-git-rebase-the-first-commit/23000315
+
+
+
 ### git branch -M
 
 브랜치 이름변경
@@ -49,9 +65,9 @@ https://git-scm.com/docs/git-push#Documentation/git-push.txt--u
 
 개인프로젝트를 할때는 main, feature 브랜치 정도로 나눠두고 main 브랜치 기준으로 CI/CD를 구축해두고 feature 브랜치에서 브랜치를 만들어서 기능을 만들고 배포가 필요할때 main에 머지하는 정도로 관리하면 좋을 것 같다.
 
-그리고 이번에 팀플하면서 브랜치이름으로 `prefix/{#이슈변호}` 형식을 사용했는데 직관성이 떨어져서 이게 맞나 싶었다.
+그리고 이번에 팀플하면서 브랜치이름으로 `prefix/{#이슈변호}` 형식을 사용했는데 직관성이 떨어져서 이게 맞나 싶었다. 브랜치에 이슈번호를 명시해둠으로써 얻는 이점이 뭔지 알아볼 필요가 있을 것 같다.
 
-브랜치에 이슈번호를 명시해둠으로써 얻는 이점이 뭔지 알아볼 필요가 있을 것 같다.
+GitHub의 경우 merge commit의 기본메시지가 `Merge pull request #[PR번호] from 리포지토리명/브랜치명`이라서 브랜치에 이슈번호를 명시해두면 merge commit이 issue에 연결된다.