일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |
- kick start
- 프로그래머스
- linux
- OS
- 운영체제
- 브루트포스
- PYTHON
- 코딩 테스트
- 코딩테스트
- 파이썬
- 구글 킥스타트
- 순열
- 킥스타트
- 백준
- CSS
- AI
- BFS
- dp
- 리눅스
- 딥러닝
- 코딩
- 네트워크
- DFS
- 동적프로그래밍
- 동적 프로그래밍
- 알고리즘
- 그래프
- 프로그래밍
- google coding competition
- nlp
- Today
- Total
목록깃허브 (7)
오뚝이개발자
서로 다른 두 개의 브랜치에서 작업하다가 브랜치를 합칠 때 충돌이 생기는 것을 merge conflict(병합충돌)라고 한다. 보통 둘 이상의 사람이 협업을 할 때 발생하곤 하는데 서로 다른 브랜치에다 작업을 하다가 최종적으로 프로젝트의 큰 흐름을 담고 있는 master 브랜치로 합칠 때 이런 문제가 자주 발생한다. Git은 기본적으로 Version Control Service(VCS)이다. 때문에 merge conflict가 발생하면 pull을 할 수가 없다.(만약 이러한 상황을 무시하고 그냥 pull을 가능하게 만들어버리면 사용자의 로컬에 있는 파일들이 모두 리모트 저장소의 코드로 덮어씌워져 버리기 때문이다.) 물론, 이와 동일한 이유로 pull뿐만 아니라 commit도 되지 않는다. 이러한 merg..
Git을 처음 다운받으면 초기에 설정해주어야 하는 것이 있다. 무작정 git을 다운받았다고 해서 바로 git clone을 사용해 레포지토리를 클론할 수 있는 것이 아니다. git config 명령어를 사용하여 user name과 user email을 입력해주어야 한다. 깃허브에 가입 시에 적었던 본인의 email과 user name이 필요하다. 이 두가지 정보는 보안과 관련된 정보들이니 본인만 알고 있어야 한다.(깃헙에서 사용자를 indentify하는 일종의 authentication information이라고 생각하면 된다.) 아래와 같은 명령어를 커맨드 창에 입력하여 두 가지 정보를 입력할 수 있다. git config --global user.name=본인의 깃허브 name git config --..
케라스 창시자에게 배우는 책의 실습 코드를 작성하고 깃허브에 올려두었다. 바로 아래 책이다. 책의 내용이 아주 좋은 것 같다. 설명이 충분해서 예제 코드들을 이해하고 따라서 실습해보기에 무리가 없다. 나는 해당 책의 코드 실습과 더불어 모델의 정확도를 높이기 위한 다양한 시도들을 개인적으로 해보았다. 간단하게는 층이나 은닉 유닛의 갯수를 조절하는 것에서부터 복잡하게는 optimizer나 loss function을 바꾸고, early stopping과 같은 regularization 기법을 사용하는 것까지 말이다. 깃허브 레포지토리 링크를 여기에 올려두니 책을 공부하며 함께 참고하면 좋을 듯하다. 아래 레포지토리 링크로 깃허브에 접속하면 서로 다른 데이터셋을 사용한 실습 코드들을 볼 수 있다. https:..
README란? readme란 프로젝트에 대한 간단한 설명을 담고 있는 문서이다. 일반적으로 git에서 특정 레포지토리에 들어가면 가장 먼저 보이는 main page가 바로 readme이다. 이런 readme 파일은 일반적으로 markdown 문법으로 작성된다.(확장자는 md) 쉽게 말해 readme를 작성한다는 것은 구현한 프로젝트를 문서화하는 작업이다. 그렇다면 readme 파일은 도대체 왜 작성해야 할까? 나를 위해 - 시간이 지나면 자신이 작성한 코드도 다시 읽어보아야 이해가 간다. 이처럼 나중에 자신이 보았을 때에도 쉽게 이해할 수 있도록 readme를 작성해두면 도움이 된다. 함께 작업하는 동료를 위해 - 협업을 할 때 동료에게 내가 작성한 readme는 좋은 지침서가 될 수 있다. 다른 사용..
커밋 메시지를 통일된 양식으로 작성하면 추후 어떠한 부분이 변경되었는지 알기도 쉽고 협업을 할 때도 도움이 된다. 따라서 메시지를 작성하는 컨벤션을 정리해보려고 한다. 커밋 메시지는 크게 제목(Title), 본문(Body), 꼬리말(Footer)의 세 부분으로 구성된다. Type : Title Body Footer Type 커밋하는 메시지의 타입을 설명해준다. 예를 들어, 버그 수정인지 새로운 기능의 추가인지 등이다. feat : 새로운 기능, 코드 추가 add : 파일 추가 fix : 버그 수정 refactor : 코드 리팩토링 docs : 문서 수정 style : 코드 형식, 정렬, 주석 등의 변경(동작에 영향을 주지 않는 변경사항) test : 테스트 코드에 관련된 변경 사항 chore : 빌드 업..
git init -> git저장소 시작 git status -> 파일들의 상태 확인 git add filename -> file을 git 저장소에 추가 git add * -> 변경사항 전부 추가 git commit -m "commit message" -> commit(확정) git log -> 커밋 로그 확인 git checkout branch name -> 해당 브랜치로 이동 git branch -> 존재하는 branch 확인 및 현재 있는 branch 확인(*가 붙어있음) git branch test -> test라는 브랜치 생성 git merge branch name -> 해당 브랜치를 마스터에 병합시킴 git branch -d branch name -> 해당 브랜치 제거(-d 옵션으로 인해) gi..