pepe

이전 포스팅에서는 기본 페이지를 만들었습니다. 이번 포스팅에서는 원하는 내용을 수정 후 push 하여 내용이 변경되는지 확인해보겠습니다. 코드를 수정할 수 있도록 github repository에서 코드를 clone 합니다. git clone https://github.com/GHGHGHKO/slate.git Cloning into 'slate'... remote: Enumerating objects: 83, done. remote: Counting objects: 100% (83/83), done. remote: Compressing objects: 100% (75/75), done. Receiving objects: 98% (82/83)used 67 (delta 4), pack-reused 0 Rec..

slate는 markdown 수정만으로 API 문서를 만들 수 있는 오픈소스입니다. https://awesomeopensource.com/projects/api-documentation 여기서 가장 별이 높은 오픈소스를 참고했습니다. 이 오픈소스에서는 Using Slate Natively Using Slate in Vagrant Using Slate in Docker How to Edit Slate Markdown files Publishing with Slate — Either to Github Pages, or your own server. Github Pages Custom Domain Names with Slate 위와 같은 배포 방식을 사용할 수 있게 되어있습니다. 이 블로그에서는 Github ..

나 혼자 개발하는 건이면 상관 없을 수 있겠지만 모두가 한 repository에서 작업을 한다면 남이 봐도 이해하기 쉬운 커밋 메시지를 적어야 한다. 커밋 메시지를 잘 써야하는 대표적인 이유는 1. 더 좋은 커밋 로그 가독성 2. 더 나은 협업과 리뷰 프로세스 3. 더 쉬운 코드 유지보수 커밋 메시지는 주로 영어를 활용한다. 하지만 한국인끼리 협업을 한다면 굳이 영어를 쓸 필요가 있을까 싶다. 커밋 메시지는 아래와 같은 구조가 되어야 한다. [적용 범위(선택 사항)]: [본문(선택 사항)] [꼬리말(선택 사항)] 커밋에는 라이브러리를 사용하는 사람들에게 의도를 전달하기 위해 다음과 같은 구조적 요소가 포함된다. 1. fix: 코드 베이스에서 버그를 패치하는 fix 타입의 커밋(유의적 버전에서의 PATCH..

배포가 정기적으로 이루어진 팀, 프로젝트를 지원한다. 평소에 GitHub를 사용할 때 어떻게 흘러가는지에 대해 알 수 있다. 1. Create a branch master : 제품으로 출시될 수 있는 브랜치 develop : 다음 출시 버전을 개발하는 브랜치 feature : 기능을 개발하는 브랜치 release : 이번 출시 버전을 준비하는 브랜치 hotfix : 출시 버전에서 발생한 버그를 수정 하는 브랜치 위와 같은 브런치들이 있다. 꼭 지켜야 하는 것은 아니지만 협업을 한다면 따르는 것이 좋을 것 같다. 프로젝트를 진행하다보면 요구사항들을 받을텐데 가능한 요구사항이 있고 불가능한 요구사항이 있을 것이다. 프로젝트에서 브랜치를 새로 생성하면 새 메모장 처럼 여러 코드를 테스트 할 수 있는 환경이 만..