쌓고 쌓다

브랜치를 나눠서 커밋을 나눠서한 이후에추가적인 코드 작성후 main에 바로 Push하려고하니 문제가 발생했다... 문제 상황을 보자.. 아래는 원격 저장소(Remote)의 커밋 상황이다.커밋 "feat: 버킷리스트 상태 검색" 이후 2개의 커밋이 존재한다.  아래는 로컬 저장소(Local)의 커밋 상황이다.내가 추가적인 코드 작성 후 커밋을 2개 더 한 상황이다.커밋 "feat: 버킷리스트 상태 검색" 이후에 추가적인 코드 작성한 2개의 커밋이 존재한다.  원격 저장소와 로컬 저장소에 공통 커밋의 종점인"feat: 버킷리스트 상태 검색"을 Base라고 하겠다. 즉,원격 저장소에는 Base 이후에 2개의 커밋 A, B가 존재하는 상황이고로컬 저장소에는 Base 이후에 A, B의 커밋이 없이 추가적인 커밋 ..

1일 1커밋으로 깃허브에 잔디를 빼곡히 채우고 싶어서기능 구현이나 스타일 변경등의 커밋을 한번에 하지 않고미루고 종류별로 하루에 한개씩 커밋을 했다. 그런데 A 기능을 구현하고 그 클래스 또는 파일에서 B 기능을 위한 변경 사항이 있을때커밋 기록으로 A -> B를 남기기가 어려운 부분이 있다.그래서 A를 커밋하고 B를 위한 코드를 변경하고 커밋해야하는 부분이지만B를위한 코드의 변경 내용을 기억하거나 주석으로 남겨놓아 커밋을 미루기도 어려운 부분이다! 그래서 로컬에서 브랜치별로 기능을 구현하고 커밋을 해놓는다.그 커밋 내용을 1일 1커밋을 위해 하루에 하나씩 원격 저장소에 브랜치를 올리거나 main 브랜치에 합치면 된다...! 방법을 한번 보자~ 브랜치의 생성은 현재 로컬 저장소에 poster-achiev..

기존 수동 배포 과정이전의 프로젝트 아키텍처를 보자. 빌드와 배포 모두 수동으로 진행했었다.테스트 코드도 돌려보고 빌드하고 이미지로 만들어서 EC2에서 구동시키는 방법이였다. 이제 이 과정들을 자동화해보고자 한다. 목표Github Push -> 테스트 코드 실행 -> Docker 이미지 build, push -> EC2에서 pull -> 이미지 동작 구축깃허브 리포지토리에 Actions 탭이 있다. 현재 프로젝트는 Gradle로 빌드한다. Configure를 누르자. .github/workflows 경로에 Actions를 위한 스크립트를 작성해야한다. 필자는 다음과 같이 구축했다.name: CI/CDon: push: branches: [ "main" ] pull_request: branc..

API 서버를 만들어보면서 회원 인증 방법에 대해 JWT를 택했다. JWT는 AccessToken과 RefreshToken으로 회원을 구분한다. 처음에는 Refresh Token의 필요성에대해 전혀 이해가 가지 않았다.그냥 Access Token을 Refresh Token 처럼 만료 기한을 길게 잡고 쓰면 되는것이 아닌가?DB에서 Access Token을 저장하며 사용하면 탈취시 대응할 수 있지 않는가? 전혀 JWT의 장점을 이해하지 못한 상태에서 생각할 수 있는 수준 정도였던 것 같다. 클라이언트가 서버에 인증 과정을 거쳐 JWT인 Access Token과 Refresh Token을 발급 받는다. 먼저 Access Token에 대해 알아보자.Access TokenAccess Token은 만료 시간을 짧..

URI, URL 차이가 무엇인지 이번에 확실히 이해해보자. URI, URL, URN?URI는 Uniform Resource Identifier이다.말 그대로 "리소스를 구별 식별하는 통일된 방식"이다. 그러면 URL, URN은 무슨 말일까?URL는 Uniform Resource Locator으로 리소스에 위치를 지정하여 구별하는것URN는 Uniform Resource Name으로 리소스에 이름을 지정하여 구별하는것 그렇다~URL은 위치, URN은 이름으로 리소스를 구별하는 것이다. 그럼 URI는 "리소스를 구분하는 통일된 방식"이니깐 URL, URN을 포함하는 개념일 것이다. 포함하는 개념이 맞다.URI와 URL을 구분하지 않고 불러도 괜찮다.URI는 위치(Locate), 이름(Name) 또는 둘 다로 ..

서버와 DB는 통신시 다음 과정을 거친다. 커넥션 연결 : TCP/IP를 통해 연결 SQL 전달 : 커넥션을 통해 서버는 MySQL에 맞는 SQL을 전달한다. 결과 응답 : DB는 서버가 전달한 SQL을 수행하고 결과를 응답한다. 그런데 여기서 DB의 종류가 바뀌면 어떻게 될까? DB마다 커넥션을 연결하고 쿼리를 전달하고 응답이 다르다는 문제가 발생한다. 즉, 서버에서 개발한 DB 사용 코드도 변경해야하고 DB에 맞는 통신 방법을 공부해야한다. 이런 문제를 해결하기 위해 JDBC가 등장한 것이다. JDBC 표준 인터페이스 JDBC(Java Database Connectivity)는 자바에서 DB에 접속, 자료의 쿼리, 업데이트등을 돕는 자바 API이다. 다음 3가지 기능을 표준 인터페이스로 제공한다. j..

IP(Internet Protocol) 지정 IP 주소에 데이터 전달 패킷 단위로 데이터 전달 IP 프로토콜의 한계 비연결성 : 패킷 전송시, 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송 내가 어떤 친구가 있겠지하고 전송했지만 상대 PC가 꺼져있을 수 있다. 그런 경우에도 난 전송을 하는것을 뜻한다. 난 전송이 제대로 되었는지 모름... 비신뢰성 : 내가 패킷을 전송했는데 패킷이 사라지거나 순서가 제대로 도착하지 않을 수 있다. 이것을 해결 못함... 프로그램 구분 : 한 피씨에서 카톡, 게임 등등.. 여러 애플리케이션이 있는데 통신하는 애플리케이션이 구분할 수 없음.. 인터넷 프로토콜 4계층 애플리케이션 계층 - HTTP, FTP 전송 계층 - TCP, UDP 인터넷 계층 - IP 네트워..

Merge하고 작업하던 브랜치를 삭제했고 분명 브랜치는 존재하지 않는데. 기존에 작업했던 feature/approveParameter 브랜치가 남아있어 보인다. git remote update를 해도 자꾸 나타난다... 다음 명령어로 지워주자. git remote prune origin local에서 remote를 참조하는데 유효하지 않는것을 지워주는 작업이다. 존재하지 않는 브랜치가 제거되었다. git remote update는 remote에 존재하는 브랜치를 가져올뿐이지 삭제된것을 반영해주지는 않는다고한다.