B612 1학기 알고리즘 스터디 레포입니다.
스터디 참여 방식, 그리고 깃허브 사용법에 대한 가이드입니다. 꼭 읽어주세요.
만약 가이드에서 수정 사항, 개선점, 혹은 추가할 내용이 있다면, 직접 추가해서 PR을 날려주세요. 유의미한 개선일 경우 공헌을 인정하여 유형의 보상을 드리겠습니다. 가이드 수정 시 PR 메시지:
Update: README.md
algorithmStudy
| nx006
| week1
| (문제 번호) (문제 이름)
| (정답코드).src
| (풀이).md
| 1000번 A+B
| main.cpp
| 1000.md
| week2
| 1003번 피보나치 함수
| main.py
| 1003.md
소스의 이름은 굳이 상관은 없지만, 나머지 폴더 구조, 이름 양식같은 것은 지켜주셔야 합니다.
- 리뷰 자료는 상세하게 쓰기
- 모든 리뷰 자료(.md, 노션 페이지)는 글만 읽어도 이해할 수 있게끔 작성(간결하되 친절하게)
- 기본적인 내용을 전부 다 적을 필요는 없음.
- 그러나 리뷰 자료만 보고서도 이 문제를 어떻게 풀었는지 알 수 있게 적어야 함 (나에게 직접 설명한다는 느낌)
- 노션 페이지와 레포지토리에 올라오는 내용을 일치시킬 것
- 소스 코드 역시 알아보기 쉽게끔 작성
- 변수명 등을 되도록 알아보기 쉽게끔 작성한다
- 기본적인 클린 코드 규칙 적용
- 수식이 길고 복잡하면 변수 단위로 나눈다
- 필요할 경우 적절히 주석을 활용한다
num과 같은 추상적인 의미의 변수를 최대한 피한다.- 필요할 경우 주석 사용
- 코딩 스타일은 본인의 방식을 따르나, 최대한 일관되게 적용
- cpp의 경우 clang-format 사용 권장, 다른 언어 역시 그에 맞는 코드 포매터 적용
- 매주 화요일 18:00 전까지 PR 완료해야 함
- 커뮤니케이션
- PR을 완료한 후 카톡으로 PR 완료했다고 말하기
- 제출자료
- 문제 번호와 이름으로 된 파일에,
소스 파일,.md,이미지 등 기타 자료들만 제출 - 나머지 구성 파일들(
.exe,sln,CMakeList,makefile등등은 제출 X)
- 남의 코드 파일은 수정하지 않는다.
- 해당 레포지토리를 fork 한 후에, 본인 id로 된 브랜치를 생성
- 매주 한 문제 이상을 소스코드와 풀이와 함께 같은 폴더에 담아서 본인 fork해간 레포에 push한 후, 화요일 18:00 전까지 이 레포의 본인 id 브랜치에 Pull Request 생성
- 카카오톡에 PR 날렸다고 말하기
- 노션에도 동일하게 자료 생성
- 이 레포를 본인 깃허브 계정으로 fork 한다.
- fork 한 레포를 클론한다.
git clone [레포 클론 주소]사용 git remote -v를 통해 먼저 연결된 원격 저장소를 확인한다.
- 보통 다음과 같이 되어 있을 것
origin https://github.com/nx006/algorithm-study.git (fetch)
origin https://github.com/nx006/algorithm-study.git (push)
git remote add upstream https://github.com/HongikB612/algorithm-study.git를 입력하여 원격 저장소에 원본 저장소를 추가한다- 그러면 다음과 같이 된다.
origin https://github.com/nx006/algorithm-study.git (fetch)
origin https://github.com/nx006/algorithm-study.git (push)
upstream https://github.com/HongikB612/algorithm-study.git (fetch)
upstream https://github.com/HongikB612/algorithm-study.git (push)
- 참고로 origin과 upstream은 변수명임. 여기에 원격 레포지토리 주소를 변수로써 저장한다는 뜻임
- 매번 새로 들어올 때마다,
git fetch upstream을 통해 원본 저장소와 내 포크한 레포를 동기화시켜주는 것이 좋다.
fetch는 이후에merge과정을 거쳐야 하는데, fetch+merge를 합친 명령어로pull이 있다.git pull upstream main해서 원본 저장소의 main 레포지토리를 pull한다.- 참고로 이 pull 과정을 안 했을시 이후에 merge conflict 등 다양한 문제가 발생할 수 있어서, 꼭 pull을 해주는게 좋다
git pull upstream submit도 해서 submit도 동기화시켜주자.- 제가 최대한 main과 submit은 화요일/목요일마다 머지는 시켜놓을텐데, 가끔 까먹고 안 되어 있을 수 있거든요? 그래서 잘 확인해주시면 됩니다.
- 작업을 열심히 마무리하고선,
git add [파일명]을 통해 변경사항이 들어있는 파일을 스테이징 아리아로 옮긴다.
git add .를 하면 모든 변경된 파일이 스테이징 아리아에 올라간다.- 대신 이때는 수동으로 필요없는 파일들은 지운다.
git add 1003.md를 하면 1003.md 파일만 스테이징 아리아에 올라간다.
git commit -m [커밋메시지]로 스테이징된 파일들을 로컬 레포지토리로 옮긴다
- 커밋 메시지 컨벤션은 후술할 내용 참조
git push origin으로 원격 레포지토리에 푸시한다.
- 참고로 이때 origin 뒤에 브랜치 이름을 붙인다면 해당 브랜치로 푸시된다
- 예를 들어
git push origin nx006라 하면 nx006라는 브랜치로 푸시됨 - upstream으로 푸시하지 않는다. (권한 막혀있음)
- 이후에 github.com으로 가서, 변경사항을 확인한 후
Create Pull Request를 눌러pull request를 생성해준다 - merge conflict가 나는지 확인한 후에, submit 브랜치에 PR을 생성한다
- 카카오톡/디스코드에 PR 올렸다고 말한다.
- 저 명령어들은 터미널에서 입력하면 됩니다. (iterm, git bash, cmd, powershell 등등)
- vscode, visual studio, clion, intellij, pycharm 등등 다양한 ide에서도 git을 사용할 수 있습니다. 이때는 ide에서 제공하는 기능을 사용하면 됩니다. 개인적으로 이 방법을 추천합니다.
- 혹은 위 ide나 에디터들에서도 terminal을 사용할 수 있습니다. 이때는 위 명령어들을 그대로 사용하면 됩니다.
- 다시 한 번 말하지만, 꼭
pull하는 거 잊지 마세요!
매주 화요일 22:00에 제(nx006)가 PR을 모두 체크한 뒤에, main으로 머지할 것입니다. 만약 수정사항이 있으면 PR을 거절하고, 다시 PR을 보내달라고 요청할 것입니다. 이때 목요일까지 다시 수정해서 올려주시면 됩니다.
다시 한 번 말하지만, PR 후에는 저한테 PR 보냈다고 말해주세요. 제가 확인을 못하면 머지를 못할 수도 있습니다.
커밋 메시지는 일관되게 작성해주세요. 여기서는 딱히 커밋 규칙에 대한 강제사항을 두지는 않겠으나, 다음 규칙을 적용하면 보기 편합니다.
- 단위 기능 별로 커밋한다.
- 너무 많은 커밋을 남기는 것은 좋지 않으나, 적당히 기능/수정 사항 별로 쪼개서 커밋을 남기는 게 좋다.
- 커밋 메시지는 일관되게 영어로 작성한다.
- 커밋 메시지 규칙은 하단을 참고해주세요.
- 제목과 본문을 빈 행으로 구분한다
- 제목을 50글자 내로 제한
- 제목 첫 글자는 대문자로 작성
- 제목 끝에 마침표 넣지 않기
- 제목은 명령문으로 사용하며 과거형을 사용하지 않는다
- 본문의 각 행은 72글자 내로 제한
- 어떻게 보다는 무엇과 왜를 설명한다
근데 3번부터는 사실 저도 안 지켜서, 너무 빡빡하게는 안 지켜도 됨. 오히려 너무 엄격한 커밋 양식은 그 효율성을 떨어뜨린다고 생각해서, 개인적으로는 커밋 규칙을 엄격하게 강요하는 걸 별로 안 좋아하긴 합니다. 그냥 본인이 생갔했을 때 일관되게 하시면 됩니다.
알골 스터디에서는 특별 규칙을 적용합니다.
- PR의 제목은
Submit (문제 번호) (문제 이름) on (주차)로 작성한다.
예시
Submit 1003 on 1st week
첫 번째 Commit 메시지에 Submit 규칙은 제거합니다. PR 제목으로 대체합니다. 다만 마지막 Commit 메시지의 경우 Submit 메시지를 남겨주면 좋습니다.
- Feat : 새로운 기능의 추가
- Fix: 버그 수정
- Docs: 문서 수정
- Style: 스타일 관련 기능(코드 포맷팅, 세미콜론 누락, 코드 자체의 변경이 없는 경우)
- Refactor: 코드 리펙토링
- Test: 테스트 코트, 리펙토링 테스트 코드 추가
- Chore: 빌드 업무 수정, 패키지 매니저 수정(ex .gitignore 수정 같은 경우)
- Submit: 과제 제출 (알골 스터디 깃허브에만 있는 명령어)
예시
Docs: Update Readme
Feat: Add Fibonacci function
Fix: Fibonacci function to working with long long type
Now fibonacci function uses long long type, and if overflows happens function throws error
Fix: Anagram_hash function returns invalid hash error
Now anagram_hash function returns valid hash, which is ordered by lexicographical order
Style: Apply clang-format to main.cpp, use llvm format
Refactor: Rename the cnt variable to testCount
Rename the variable with more descriptive name
Refactor: remove unused import
Submit 1000번 A+B on week1
참고로 커밋 메시지 규칙같은 건 팀마다 다릅니다. 어디서는 DOCS Update readme 이런 식으로 쓰기도 하고, : 이거를 붙이기도 하고, 안 붙이기도 합니다.
알골 스터디에서는 거기까지 제한을 두지 않되, 본인에게 맞추어서 일관되게 작성해주시면 됩니다.
upstream의 경우 submit 브랜치로만 PR합니다.
fork된 origin의 경우 자유롭게 브랜치를 만들어서 작업하면 됩니다.
출석 확인은 노션에서 확인하실 수 있습니다.
주의사항: PR이 거부되었을 경우 출석으로 인정되지 않습니다. 즉 PR 거부당하고서 다시 제출하지 않으면 결석입니다.
5번 결석 시 알고리즘 스터디에서 퇴출됩니다.
인정 결석의 경우 3번까지 가능합니다. 하지만 타당한 사유가 있을 경우 횟수는 유연하게 조정될 수 있습니다.
git을 사용하지 않고 노션에 작성하는 경우면 저한테 꼭 말해주세요. 제가 확인 못하면 출석으로 인정되지 않을 수 있습니다.
PR 재제출 확인은 매주 목요일 날 확인합니다. PR 재제출의 경우 꼭 저에게 말해주세요.
다시 한 번 말하지만, 말을 안 하면, 제가 운좋게 확인해서 머지를 하는 경우도 있지만, 제가 확인을 못 할 경우 책임은 각자에게 있습니다. 당연한거죠?
우수 포상: 스터디를 독려하기 위해, 추후 출석률, 제출물의 퀄리티 등을 고려해 우수 포상을 선정하여 줍니다. B612 회비에서 지원하겠습니다. (추후 변경 가능)