Step-up Step-up

dev 브랜치 작업을 모두 완료했습니다. 이제 배포를 위해 master 브랜치로 Pull request를 보내고자 합니다. (이번 튜토리얼에서는 master 브랜치는 main 브랜치와 같은 역할을 합니다.) PR을 보내기 전, Upstream의 브랜치 위치를 반드시 확인하고 Pull Request를 보내야 합니다. 2. 브랜치를 확인했다면, Create pull request를 클릭합니다. 3. 버튼을 누르면 아래와 같이 화면이 나오게 되는데, 추가적으로 작성할 부분이 없다면 그대로 Create pull request를 진행합니다. 4.이제 Upstream 리포지토리 dev 브랜치에 PR된 이슈를 확인하실 수 있습니다. 붉은색으로 표시된 곳을 잘 봐주세요 5. 위 브랜치 위치 등을 확인했다면 이제 본격적..

Git flow Git flow는 2010년 Vincent Driessen의 블로그 글로부터 시작되었고, 이후 많은 개발자의 사랑을 받아온 Git 브랜칭 전략입니다. Git flow는 대규모 개발 프로젝트를 제작하여 하나의 소프트웨어의 릴리스 버전을 명확하게 나누고, 다양한 버전을 배포해야 하는 당시의 개발 환경과는 적합했지만, 빠르게 제작하고 배포하고 고객의 피드백을 받는 애자일한 개발 팀에 적용하기는 다소 복잡했습니다. 원문에도 아래와 같은 조언이 담겨있습니다. Web apps are typically continuously delivered, not rolled back, and you don't have to support multiple versions of the software running..

Git branch 브랜칭(branching)은 기존 개발 중인 메인 개발 코드를 그대로 복사하여 새로운 기능 개발을 메인 개발 코드를 건드리지 않고 할 수 있는 버전 관리 기법입니다. 처음에 GitHub Repository를 생성하면 나오는 main 브랜치에서만 작업을 하다가 새로운 기능 개발을 위해 feature 브랜치를 새로 생성하는 경우, 기존 main 브랜치에서의 작업은 유지하고 새로운 feature 브랜치에서 자유롭게 코드를 추가 및 삭제할 수 있습니다. 브랜치 생성하기 / 변경하기 (git switch) 이때, 새로운 브랜치로 Git이 바라보는 곳, HEAD를 변경하는 작업을 switch라고 부릅니다. 브랜치를 생성할 때는 생성(create)의 의미로 -c를 붙여줘야 하고, 기존에 있는 브랜..

GitHub Repository에 꼭 필요한 파일 README.md GitHub는 개발자의 SNS라고 불릴 정도로 다양한 종류의 오픈소스 프로젝트가 공유되어 있습니다. 오픈소스 프로젝트에 들어가면, 가장 먼저 확인할 수 있는 정보가 바로 이 README.md 파일입니다. 기본적인 마크다운 사용법을 잘 숙지하고 있으면 간단한 소개 페이지처럼 제작할 수 있습니다. README.md 파일을 적는 양식은 따로 존재하지 않지만, 대체로 어떻게 하면 해당 오픈소스를 활용할 수 있는지에 대한 상세한 정보가 작성되어 있습니다. Pre-Project GitHub Repository README.md 파일은 아래 정보를 꼭 포함해야 합니다. 프로젝트 이름 프로젝트 핵심 기능 소개 팀원 소개 .gitignore gitign..

백엔드의 개발 서버 역할을 해줄 api와, 프론트엔드의 개발 서버 역할을 해줄 my-app에 각각 접근하여 npm install을 합니다. cd api npm install cd my-app npm install //api terminal npm run dev //my-app terminal npm start 이 상태에서 Get all Books라고 쓰여 있는 버튼을 눌러봅시다. CORS 에러를 확인 에러창 어디갔지? 17:1 uncaught (in promise) syntaxerror: unexpected token '

webpack dev server proxy 먼저 webpack dev server에서 제공하는 proxy 기능을 사용하는 방법이 있습니다. webpack dev server의 proxy를 사용하게 되면, 브라우저 API를 요청할 때 백엔드 서버에 직접적으로 요청을 하지 않고, 현재 개발서버의 주소로 우회 요청을 하게 됩니다. 그러면 웹팩 개발 서버에서 해당 요청을 받아 그대로 백엔드 서버로 전달하고, 백엔드 서버에서 응답한 내용을 다시 브라우저 쪽으로 반환합니다. 웹팩 개발서버의 proxy 설정은 원래 웹팩 설정을 통해서 적용을 하지만, CRA를 통해 만든 리액트 프로젝트에서는 package.json 에서 "proxy" 값을 설정하여 쉽게 적용할 수 있도록 구성이 되어 있습니다. ... "browser..

CORS 정책이 필요한 이유 브라우저에서 기본적으로 API를 요청할 때에, 브라우저의 현재 주소와 API의 주소의 도메인이 일치해야만 데이터를 접근할 수 있게 되어 있습니다. 만약 다른 도메인에서 API를 요청해서 사용할 수 있게 해 주려면 CORS 설정이 필요하다는 것을 여러분 또한 이전 섹션에서 배워 기억하고 계실 것입니다. CORS 교차 출처 리소스 공유(Cross-Origin Resource Sharing, CORS)는 추가 HTTP 헤더를 사용하여, 한 출처에서 실행 중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 체제입니다. 출처 웹 콘텐츠의 출처(origin)는 접근할 때 사용하는 URL의 스킴(프로토콜), 호스트(도메인), 포트로 정의..

GitHub Actions는 Github가 공식적으로 제공하는 빌드, 테스트 및 배포 파이프라인을 자동화할 수 있는 CI/CD 플랫폼입니다. 레포지토리에서 Pull Request 나 push 같은 이벤트를 트리거로 GitHub 작업 워크플로우(Workflow)를 구성할 수 있습니다. 워크플로우는 하나 이상의 작업이 실행되는 자동화 프로세스로, 각 작업은 자체 가상 머신 또는 컨테이너 내부에서 실행됩니다. 워크플로우는 .yml (혹은 .yaml ) 파일에 의해 구성되며, 테스트, 배포 등 기능에 따라 여러 개의 워크플로우로도 만들 수 있습니다. 생성된 워크플로우는 .github/workflows 디렉토리 이하에 위치합니다. 비공개 레포지토리의 경우 Github Actions가 작동할 때의 용량과 시간이 제..