일단 시작.

프로젝트를 진행하면서 PR 리뷰 받기를 기다리다가 다른 작업이 늦어지게 된 것이 여러 번.. git의 rebase기능을 이용하여 일의 효율을 높일 수 없을까 생각하여 공부를 하며 정리했다.

Spring Boot Test는 application을 실행시켜보는 작업이라서 DB 연동이 필요하다. 우리는 MySQL 기반으로 코드를 작성했기 때문에 Github Action이 실행되는 Runner에서도 MySQL을 설치해보았다. 아마 H2를 설치해서 확인해도 dialect 부분만 바꿔서 작성하면 괜찮을 것 같지만. 익숙한 MySQL을 설치하기로 했다. GitHub Marketplace에서 MySQL을 어떻게 설치하면 되는지 잘 나와있다. Start MySQL - GitHub Marketplace Start a MySQL database github.com steps: - uses: samin/mysql-action@v1 with: host port: 3800 # Optional, default val..

1. dev 브랜치에 푸시하거나 PR보낼때마다 CI check on: push: branches: [ "dev" ] pull_request: branches: [ "dev" ] 2. PR에 테스트 결과 코멘트로 알려 줄 때 필요한 허가. permissions: checks: write pull-requests: write 3. 레포지토리 체크아웃 레포지토리의 코드를 runner 컴퓨터에서 돌려볼 수 있도록 pull로 땡겨가는 코드. - name: 레포지토리 체크아웃 uses: actions/checkout@v3 4. 현재 내가 사용하는 Spring Boot는 3.x버전은 Java 17부터 지원하기 때문에 JDK 17 설치 - name: JDK 17 설치 uses: actions/setup-java@v3 ..

Microsoft Developer Korea - Github Actions 영상을 참고하고 기록. 영상에서는 Node.js 프로젝트를 예시로 함. 목표 : Github Actions 워크플로우를 내 입맛에 맞게 작성할 수 있다. OS 종류와 Node 버전이 다양해요. → 빌드 매트릭스 이용하기 빌드할 때마다 테스트를 실행해서 불편해요. → 템플릿 변경해서 빌드 테스트 분리하기 다른 Job에서 빌드 아티팩트 접근이 안돼요. → Built-in 스토리지 이용하기 1. OS 종류와 Node 버전이 다양해요. 여러 타겟으로 동시에 빌드한다! → 매트릭스 빌드 여기에서의 매트릭스는 행렬! 예를 들어, Windows, Linux 버전에서 Node 12버전과 Node 14버전을 돌려야 할 때, Windows Lin..

Github Action Github Action은 CI/CD를 위한 툴! 그렇다면 CI/CD가 뭔지 알아야 한다. 1. CI/CD 요즘같이 빠르게 변화하는 시대는 “어떻게 하면 시장과 고객의 요구에 빠르게 반응해서 제품 출시, 업데이트를 할 것인가!!”가 포인트. CI/CD는 어플리케이션 개발 단계부터 배포 때까지 이 모든 단계들을 자동화를 통해서 조금 더 효율적으로 빠르게 사용자에게 빈번이 배포할 수 있도록 만드는 것을 말한다! 1) CI(Continuous Integration) : 지속적인 통합 버그 수정이나 새로 만드는 기능들이 매일 Repository에 주기적으로 Build되고 Test가 되어서 머지되는 것! 포인트는 두 가지이다. 1. 코드 변경사항을 주기적으로 빈번하게 머지해야 한다. 두 ..

짧은 프로젝트라고 가정하고 Develop 브랜치까지 파지 않고 Main 브랜치와 각각의 기능별 브랜치를 판다고 가정. (Develop 브랜치를 파면 나중에 Develop 브랜치에도 규칙을 적용시켜 주면 된다.) 레포지토리 파는 사람이 할 일 1. 깃에서 레포지토리를 판다. README도 추가해 놓는다. README추가는 옵션! 근데 만들어놓는게 난 더 편했다. 내가 bash에서 명령어를 직접 입력하는데 README를 추가해놓지 않으면 깃허브에서 주는 명령어로 하는데 그거로 하다보면 오히려 헷갈린다.. 2. Settings - Branches - Add branch protection rule main 브랜치의 rule을 정하려면 Branch name pattern에 main을 적고 Protect matc..

> * 첫 번째 방법 - sync fork * 두 번째 방법 - bash를 이용하여 포크 주소를 이용하여 fetch해오는 방법 첫 번째 방법 sync fork -> 내 원격 master브랜치로 복사 완료 -> 내 로컬에서 pull 로 원격 master 데이터 가져오기 -> 내 로컬 브랜치를 내 로컬 master와 merge하기. 1. sync fork 클릭! sync fork 하는 것은 내가 포크해온 레포지토리와 내 레포지토리의 master 브랜치에 싱크가 맞춰지는 것. 2. 포크 레포지토리와 연결된 프로젝트가 있는 폴더로 가서 git bash 열기. 3. git checkout master branch를 master로 checkout. ( 옆에 master 뜨는지 확인. ) ※ 브랜치를 옮길 때는 ch..

풀 리퀘스트로 코드 리뷰하는 방법 이제까지 풀리퀘스트로 각자의 코드를 모으기만 했었는데, 풀 리퀘스트의 장점인 코드 리뷰를 스터디에서 적용시켜 보기로 했다. 스터디원들에게 코드 리뷰하는 방법을 알려주기 위해 공부한 과정을 기록한다. 1. 자신이 포크해온 원래 레포지토리로 들어가서 pull request 탭으로 들어간다. 2. 코드 리뷰할 풀 리퀘스트로 들어가서 Conversation 탭에 있는 설명을 읽어보고 어떻게 문제를 풀었고, 코드를 썼는지 파악한다. 남이 자신의 코드를 파악하기 좋게 풀 리퀘스트를 할 때 설명을 잘 해야 한다! 3. Files changed 탭에 들어가서 코드리뷰할 파일을 선택한다. 4. 리뷰를 남겨보자. 1) 한 줄에 대한 리뷰를 남기고 싶을 때 줄 옆에 +가 뜬다! 누르면 리뷰..

> 1. git reset과 revert 연습의 필요성 2. git reset --soft 3. git reset --mixed ( git reset ) 4. git reset --hard 5. git revert 1. git reset과 revert 연습의 필요성 이번 프로젝트 당시 팀원이 본인 브랜치를 마스터 브랜치에 머지를 했는데, 충돌 해결을 그 전 버전으로 해버리셔서 내가 한 작업이 일부 날아가는 일이 있었다. 그 때는 제출 시간을 약간 넘긴 뒤라 조금 정신이 없어서 일단 history를 보며 다시 수정을 하게 되었다. 지금 생각하면 마스터 브랜치의 커밋을 hard로 되돌려 작업 디렉터리를 돌린 다음에 다시 팀원의 브랜치를 머지했으면 됐을 간단한 일이었는데 그 순간에는 이게 훨씬 어려운 일인거 ..

오늘은 업무에서나 개인적으로나 많이 쓸 수 있는 pull request를 연습해 보았다. 1. 기여하려는 repo에 가서 fork해온다. fork해 오면 내 계정의 소유로 repo가 복제가 된다. 남의 원격 저장소에서 내 원격 저장소로 되는 것! repo 이름을 설정해 준뒤, 해 준다. 내 repo에 가보면 fork해온 repo를 확인할 수 있다. 2. 포크한 repo를 클론해오기(원격 -> 로컬) 작업하려는 폴더에서 git bash here을 누른 다음, git clone 를 명령어로 입력하면 원격 repo가 내 로컬로 clone이 된다. 일단은 바탕화면에다가 해보자! 3. 브랜치 생성 후 생성한 브랜치로 chekout하기 repo가 있는 폴더로 이동 후 다시 bash에서 ..