오뚝이개발자

서로 다른 두 개의 브랜치에서 작업하다가 브랜치를 합칠 때 충돌이 생기는 것을 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:..

커밋 메시지를 통일된 양식으로 작성하면 추후 어떠한 부분이 변경되었는지 알기도 쉽고 협업을 할 때도 도움이 된다. 따라서 메시지를 작성하는 컨벤션을 정리해보려고 한다. 커밋 메시지는 크게 제목(Title), 본문(Body), 꼬리말(Footer)의 세 부분으로 구성된다. Type : Title Body Footer Type 커밋하는 메시지의 타입을 설명해준다. 예를 들어, 버그 수정인지 새로운 기능의 추가인지 등이다. feat : 새로운 기능, 코드 추가 add : 파일 추가 fix : 버그 수정 refactor : 코드 리팩토링 docs : 문서 수정 style : 코드 형식, 정렬, 주석 등의 변경(동작에 영향을 주지 않는 변경사항) test : 테스트 코드에 관련된 변경 사항 chore : 빌드 업..

분명 .gitignore에 추가를 했는데 계속 반영되지 않고 변경사항에 포함되는 경우가 있다. 이 경우 git의 cache에 데이터가 남아있어서인데 아래와 같이 cache를 지워주고 다시 add all 해주면 된다. git rm -r --cached . git add . git commit -m "fixed untracked files"