[TIL] 깃허브 그라운드 룰을 만들다!

 

안녕하세요! NewCodes입니다!!

 

오늘도 알차게 보냈습니다!

함께 보시죠!

 

---

To do list

• [ ] 알고리즘 - 1, 2교시
  • [x] 백준 dp 2문제
  • [x] 백준 그리디 2문제 (1문제 풀이함)
  • [x] 프로그래머스 카카오 레벨2 1문제
  • [x] 백준 유니온 파인드 1문제
    • [ ] 강의 들어보기
  • [ ] 깃허브 레포 업그레이드 수도 코드
• [ ] CS - 3교시
  • [x] 스터디 깃허브 룰 만들기 90분은 걸린 듯..
  • [x] 스터디 변경된 공지사항 올리기
    • [x] 1시간 전 발표 임의 선정
    • [x] 5분 이상 지각 시 3000원 보증금 차감
    • [x] 깃허브 룰
  • [ ] CS 네트워크의 기초 책 읽기
  • [x] CS50 강의 듣기 2~3강
    • [ ] 약간 쉬움 주말에나 듣기
• [x] 프로젝트 - 4교시
  • [x] 김영한 스프링 강의 섹션2
• [ ] 방향 설정 - 저녁
  • [x] TIL 작성
  • [ ] 우테캠 물어보기 (어떤 기능 구현할지) 

 

오늘은 To do list를 다 끝내진 못했습니다 ㅠㅠ CS 스터디 깃허브 그라운드 룰 만드는 데 은근히 시간이 오래 걸리더라고요.. 그래도 80% 이상은 완료한 것 같습니다!!

 

 

---

1️⃣ 알고리즘

1 - 1) 동적 계획법 문풀 피드백

- int와 long 선택 잘하자..!
  - 우선 범위 좀 넘을 것 같으면 long으로 통일하자!
- dp에는 여러 방식이 있을 수 있다!
  - 이차원 배열을 통해 이전 값을 더욱 세밀하게 활용하는 방법도 있다!
  - 이전 값을 순차적으로 정적으로 활용하는 게 아니라, 경우의 수 나눠서 동적으로 활용하는 방법도 있음! (계단 오르기, 포도주 시식)
- answer += steps[n][i] % mod;
  - 이렇게 나누는 건 의미가 없다! 
  - 고친 코드: answer = (answer + steps[n][i]) % mod;

- 검토할 때 극단적인 경우, 값 고려하자!! 해당 문제에서 n이 1일 때, 런타임 에러 생길 수 있음.

 

 

1 - 2) 정규표현식

- 이스케이프(Escape): 메타 문자를 일반 문자로 인식하게 하는 역할을 합니다. \를 사용하여 이스케이프 합니다.
  - +, [, ], (, ) 등의 특수문자를 사용할 때는 앞에 \\를 붙여주어야 함.
  - Java에서는 \ 대신 \\를 적어야 합니다.

 

 

프로그래머스 정규표현식 강의(빈칸 채우기)

 : 우연히 정규표현식 좋은 학습 자료를 발견했습니다!! 다음 주에 쭉 풀어보려고 합니다!

 

 

---

2️⃣ CS

2-1) CS 스터디 깃허브 그라운드 룰

# Git Ground Rule
```
처음에는 원본 프로젝트에서 각자 clone 하고 branch만 나누어 작업하려 했습니다. 하지만, fork 해서 진행하는 게 더 나을 것 같다고 판단했습니다. 

스터디한 내용을 각자의 깃허브 레포에 담을 수 있으며, 스터디가 끝난 이후 각자 자유롭게 관리할 수 있다는 장점이 있습니다. 

그리고 브랜치를 각자의 username으로 관리하는 건 그렇게 좋은 방법은 아닌 것 같습니다.

- 공유할만한 내용(super-tips)은 깃이 아니라 카톡에 남겨주세요!
    - 리더(상혁)가 스터디 시작 전에 취합하겠습니다!
    - 이 방법이 더 원활하게 공유가 가능할 것 같아요!
```
## 📋 협업 작업 리스트
### contents / 발표 자료
  - 스터디 시작 60분 전, 각 스터디원은 각자의 레포에 push
  - 스터디 끝 이후, 24시간 이내로 발표자의 역할:
    - 팀원의 레포를 둘러보며 본인의 발표자료 첨삭하기
    - 첨삭한 발표자료를 자신의 레포에 push한 뒤, PR

### contents / 면접 질문
  - 스터디 시작 전, 각 스터디원은 각자의 레포에 push
  - 스터디 끝 이후, 24시간 이내로 발표자의 역할:
    - 팀원의 레포를 둘러보며 면접질문 취합하기 (중복 제외)
    - 취합한 면접질문을 자신의 레포에 push한 뒤, PR

### Study / restrospectives
  - 스터디 시작 60분 전, 각 스터디원은 각자의 레포에 push한 뒤 PR
  - '상혁-회고.md'와 같이 각자의 파일을 관리하는 것이기에 충돌 위험성 x

### Study / super-tips
  - 스터디 시작 60분 전, 리더가 취합해서 PR & Merge

---
## ⚙️ 프로젝트 초기 설정

### 1. Fork
- 의미: 원본 저장소를 자신의 GitHub 계정으로 복제합니다. 이를 통해 개인이 수정할 수 있는 공간을 생성합니다.
- 방법: [원본 저장소](https://github.com/BCS-study/basic-computer-science)에서 오른쪽 상단 fork 버튼 클릭

### 2. clone
- 의미: Fork한 저장소를 로컬 환경으로 복제합니다. 이를 통해 로컬에서 작업을 진행할 수 있습니다.
- 방법
   ```
   git clone [Fork한 저장소의 URL]
   ```

### 3. remote upstream
- 의미: 원본 저장소를 원격 저장소로 추가합니다. 이를 통해 원본 저장소의 변경사항을 가져와서 자신의 로컬 저장소에 반영할 수 있습니다.
- 명령어
  - (로컬 저장소 내에서) git remote add upstream [원본 저장소의 URL]
   ```bash
   git remote add upstream https://github.com/BCS-study/basic-computer-science
   ```

## 🕹️ 작업 흐름 (Workflow)
### 1. 원본 저장소로부터 변경사항 가져오기
- 의미: 스터디가 끝난 24시간 이후에 이전 주 차 학습 내용이 merge되면 원본 저장소로부터 변경사항을 가져옵니다. 
- 명령어
   ```
   git fetch upstream
   ```

### 2. 개인 레포에서 작업 내용 작성
- 의미: 개인의 로컬 환경에서 해당 주 차에 따라 발표 자료, 면접질문&답변, 회고를 작성합니다.
- 작업 내용: 발표 자료, 면접질문&답변 4세트, 이전 주 회고

### 3. 개인 저장소 관리 (add/commit/push)

### 4. Pull Request
- 의미: 개인의 원격 저장소에서 원본 저장소로 Pull Request를 생성합니다. 이를 통해 변경사항을 원본 저장소에 반영할 수 있습니다.

### 5. Merge
- 의미: Pull Request가 검토되고 승인되면 원본 저장소에 변경사항이 병합됩니다. 이제 모든 스터디원들이 최신의 작업 내용을 공유할 수 있습니다.

## 📩 Pull Request 및 코드 리뷰 규칙
- 원격 저장소에 기여하는 모든 행위는 PR을 통해야 합니다. 
- Pull Request는 3명의 코드 리뷰어의 승인이 필요합니다.
- 리뷰어는 변경 사항을 검토하고 피드백을 제공해야 합니다.

  - 피드백의 종류:
    - 오타가 있는가?
    - 의미가 모호한 부분이 있는가?
    - 문장, 문단의 흐름이 어색한 부분이 있는가?
    - 템플릿 형식이 지켜지지 않은 부분이 있는가?
    - 스터디에서 다룬 내용이 빠짐없이 기재되었는가?

## 📄 커밋 메시지 규칙
```📍 Commit convention : [대주제] 소주제 분류(발표자료 정리/면접질문&답변/ ...)```
- ex) git commit -m "[네트워크] HTTP 발표자료 정리"

위 그라운드 룰 작성하는 데 약 90분이 걸렸습니다. 생각보다 힘이 드는 작업이군요.. 덕분에 두리뭉실하게 알던 깃허브 협업 흐름에 대해서 더 자세히 알 수 있었습니다!!

 

다음에 실제로 깃허브 협업 프로젝트를 하게 된다면 이를 바탕으로 '브랜치 전략'을 좀 더 보완해서 매뉴얼을 작성해 보겠습니다!

 

 

---

3️⃣ 프로젝트

3-1) 김영한 스프링 입문 강의 섹터 2

스프링에서의 웹 개발 방식 3가지에 대해 학습했습니다. 

1. 정적 컨텐츠
2. MVC와 템플릿 엔진
3. API

정적 컨텐츠는 /static과 같은 폴더에 있는 HTML 정적 파일을 그대로 전달하는 방식입니다. 

 

MVC와 템플릿 엔진 방식은 Model, View, Controller를 통해 사용자 인터페이스를 설계하는 방식입니다. 컨트롤러가 클라이언트의 요청을 받아서 모델을 업데이트하고, 그 결과를 뷰에 반영하여 클라이언트에게 제공합니다. 이때 템플릿 엔진을 사용하여 동적인 컨텐츠를 HTML로 전달합니다.

 

API는 클라이언트에게 HTML 파일이 아니라 데이터 그 자체를 직접 전송하는 방식입니다. 주로 JSON 형식으로 전달합니다. 

 

강의 내용 정리: https://same-treatment-dcb.notion.site/Spring-901929b9ffb64b1dab12fd70396dba9d?pvs=4

Spring 입문 강의 | Notion

 

 

---

 

아직 TIL 작성하는 게 자연스럽진 않네요..! 오늘은 약 30분 정도 작성했습니다!

 

어떠한 방식으로 해야 효율적 일지 계속 고민해 봐야겠습니다. 이상입니다!!