2023.06.16.금.TIL

heeh·2023년 6월 16일

TIL

목록 보기

23/82

과제

2-5까지 듣고 과제 시작…!

new project 생성
- Spring Web
- Thymeleaf
- Lombok
SQL 생성 소문자, 대문자 상관없음
Class가 속성(int, String)과 같은 자료형을 만들기 위해 커스텀 개념
왜 private final Map<Long, Post> postList = new HashMap<>();를 쓰는지?
- 글이 추가 될 때를 위해, 마지막 글(넘버링)에 +1을 하여 몇 번째 게시글 뒤에 들어가는지 하기 위해!
- Long(넘버링)는 Key값, Post(contents, username 등을 담은 Class) value값
new HashMap<>(); 의 개념?
- HashMap
  - HashMap은 제네릭 클래스로, 다양한 자료형의 키와 값 쌍을 저장
  - 하나의 키에는 하나의 값만 연결
  - HashMap 자체는 키(Key)에 대해서는 중복과 null을 허용하지만, 값(Value)에 대해서는 중복을 허용
  - 요소의 순서를 보장하지 않음
- new HashMap<>();
  - new HashMap<>();은 Java에서 HashMap 클래스의 인스턴스를 생성하는 코드
  - 무런 초기 용량(capacity)이나 초기 요소를 가지지 않은 상태에서 시작하는 빈 해시 맵을 생성
포스트, 조회, 수정, 삭제 - 강의 참고

postman

post

Type 선택 - 주소 입력 - Body - raw - JSON 선택 - 코드 작성 - Send

POST
http://localhost:9090/api/post

{
    "username" : "Jinhee",
    "contetns" : "Jinhee가 작성한 내용"
}

post Type 선택 - 주소 입력 - Send

get

get Type 선택 - 주소 입력 - Send

GET
http://localhost:9090/api/posts

{
        "id": 1,
        "username": "Jinhee",
        "contents": "Jinhee가 작성한 내용"
    }

put
- put Type 선택 - 주소 입력 - Send
  → http://localhost:9090/api/post/2
  → {id}에 2를 지정
  → body에 수정할 값을 넣어줌
- put 결과를 get - http://localhost:9090/api/posts - Send로 조회
```
PUT
http://localhost:9090/api/post/{id}

{
        "id": 2,
        "username": "Jinhee2",
        "contents": "Jinhee2가 작성한 내용"
    }
```

delete

deletet Type 선택 - 주소 입력 - Send
→ http://localhost:9090/api/post/2
→ {id}에 2를 지정
→ body에 넣을 값 없음

delete 결과를 get - http://localhost:9090/api/posts - Send로 조회

DELETE
http://localhost:9090/api/post/{id}

{
        "id": 1,
        "username": "Jinhee",
        "contents": "Jinhee가 작성한 내용"
    },
    {
        "id": 3,
        "username": "Jinhee",
        "contents": "Jinhee가 작성한 내용"
    },
    {
        "id": 4,
        "username": "Jinhee",
        "contents": "Jinhee가 작성한 내용"
    }

postman에서 순서가 바뀌는 오류

{
        "id": 1,
        "contents": "Jinhee가 작성한 내용",
        "author": "Jinhee",
        "password": "pass123",
        "title": "title"
    }

HashMap을 사용해서?

상세 조회
```
<힌트>
파라미터, URL
1, 2, 3이 있다면 2를 선택, map.getKey
```
- @PathVariable 으로 링크를 구성/지정해 줄 수 있음
- if문을 이용하여 id값이 맞으면, 해당되는 id값의 getTitle 등을 가져오기
- 타입과 같은(해당하는) 타입으로 return 해주기
  - @PathVariable Long id = Long은 id라고 선언해줬으니까 id로 반환
id, title, contents, author, password 추가
- 과제 API를 뒤늦게 보고…
password
- @RequestBody(sanner같은 역할?!)을 추가하고 password가 있는 클래스, 클래스 변수명을 선언해줌
- if문을 이용해서 (원래 있는 패스워드)와 @RequestBody를 이용한 클래스, 클래스 변수명에 있는 Password가 .equals를 이용하여 같은지 비교
- 타입을 String으로 바꿔주고 입력한 값이 맞으면 true 값을 주고 아니라면 false
더 만들어야 할 것
- Use Case 다이어그램 만들어야 함
- Response에서 날짜 찍히는 것…?
  → 작성 날짜 2-13 강의 듣기
  - createdAt
  - modifiedAt
  - id
  - title
  - content
  - author
- API 명세서의 Request와 Response 개념 더 이해하기
  - DELETE Request : "password" :"password"
    → 비밀번호를 입력하면 DELETE가 되게 하기
  - DELETE Response : "success": true
    → Request 가 완료되면 나타나는 결과
- POST, PUT의 password 확인하기
  - PUT의 password 인증
다시해보기&리팩토링
- Use Case 다이어그램 만들어야 함
  - https://app.diagrams.net/
  - https://narup.tistory.com/70
    https://googry.tistory.com/2
    를 참고하고
  - drow.io 를 이용하여 다이어그램 만들어봄
- POST, PUT의 password 확인하기
  - PUT의 password 인증
    → delete의 if문을 참고하여 만듦

IJ에서 Commit한 내용 삭제하기(되돌리기)

참고
- https://fierycoding.tistory.com/40
- https://guiyomi.tistory.com/124
```
git reset HEAD~1  # 최근 1개의 커밋 삭제 + 변경된 파일은 unstaging 상태로 유지
git reset HEAD~n  # 최근 n개의 커밋 삭제 + 변경된 파일은 unstaging 상태로 유지
```
- git reset HEAD~1 : local - master 최근 커밋 목록이 1개 삭제됨
- git reset HEAD~n : local - master 최근 커밋 목록이 n개 삭제됨
git reset을 사용하면 local - master의 커밋은 삭제되지만 git hub에 공유, push된 원격(remote)에서 적용이 되지 않음
커밋 삭제가 이루어진 local - master를 공유하면 새로운 원격이 생기고 적용 완료
그렇다면 이미 공유된 레포지토리의 커밋, 원격(Remote)에 있는 커밋은 삭제가 불가능한가?

원격 저장소에 있는 커밋을 삭제하는 것은 일반적으로 권장되지 않습니다. 커밋은 Git에서 변경 기록을 나타내는 중요한 요소이며, 원격 저장소는 여러 사용자가 함께 작업하고 협력하는 공간입니다.

일반적으로 원격 저장소의 커밋은 변경되면 안 되며, 이를 유지해야 합니다. 원격 저장소에서 커밋을 삭제하거나 변경하면 해당 변경 내역을 공유하는 다른 사용자들과의 동기화에 문제가 발생할 수 있습니다.

따라서, 원격 저장소에 올라간 커밋을 삭제하는 대신, 더 나은 접근 방법은 잘못된 커밋을 되돌리거나 수정하는 것입니다. 이를 위해 Git의 다양한 기능을 사용할 수 있습니다. 예를 들면, git revert를 사용하여 커밋을 되돌릴 수 있습니다. 이를 통해 잘못된 커밋을 취소하고 새로운 커밋을 생성할 수 있습니다.

그러나, 원격 저장소에 올라간 커밋을 삭제하고 싶은 특수한 상황이 있다면, 해당 원격 저장소에 대한 쓰기 권한이 있는 경우 원격 브랜치를 강제로 업데이트할 수 있습니다. 이는 주의해야 할 작업이며, 협업하는 팀원들과 충분한 협의 후에 수행해야 합니다.

따라서, 원격 저장소의 커밋을 삭제하는 것은 권장되지 않으며, 실수를 수정하거나 새로운 커밋을 생성하는 방법을 고려하는 것이 좋습니다.
remote에 있는 커밋을 터미널에서 reset으로 삭제하는 방법
1. 터미널을 열고 원격 저장소가 연결된 로컬 저장소의 디렉토리로 이동합니다.
2. git log 명령을 사용하여 삭제할 커밋의 해시값(예: commit_hash)을 확인합니다. 이는 삭제할 커밋의 고유 식별자입니다.
3. git reset 명령을 사용하여 원격 저장소의 브랜치를 삭제할 커밋 이전으로 이동시킵니다. 다음은 예시 명령어입니다:
```
git reset --hard commit_hash
```
  여기서 commit_hash는 삭제할 커밋의 해시값으로 대체해야 합니다.
4. 변경된 내용을 원격 저장소에 강제로 푸시합니다. 다음은 예시 명령어입니다:
```
git push --force origin branch_name
```
  여기서 branch_name은 원격 저장소에서 삭제한 커밋이 포함된 브랜치의 이름으로 대체해야 합니다. --force 옵션을 사용하여 강제로 푸시합니다.
git push --force origin branch_name 에서 origin branch_name의 의미

git push --force origin branch_name 명령은 로컬 저장소의 branch_name 브랜치의 변경 사항을 origin 원격 저장소에 푸시하는 명령입니다. --force 옵션은 변경 사항을 강제로 푸시함을 의미합니다.
git push --force origin branch_name
- git push --force origin jh2
  → local에 있는 jh2를 origin(Remote)에 넣어 봤다
- 브랜치의 변경 사항이 origin(Remote)에 들어가는게 아니고 계정 인증이 뜨면서 jh2 브랜치가 복사 생성됨
origin 폴더에 branch_name 브랜치를 넣어준다는 거니까
origin 폴더에 master 에 branch_name 브랜치를 넣는다는 명령을 한다면?
- **git push --force origin master branch_name**
- **git push --force origin master jh2**
- local - master에 있는 내용이로 바뀌었다…?!
- jh2(커밋3)를 넣었는데 왜 로컬에 있는 master(커밋2)로 바뀐건지
결론
1. 로컬에 있는 마스터를 오리진에 있는 마스터로 넣어봄 - 안됨(터미널 멈춤)
  → git push --force origin master
2. 로컬에 있는 jh2를 오리진에 넣어봄 - 계정연동, jh2 브랜치 복사생성
  → git push --force origin jh2
3. 로컬에 있는 jh2를 오리진의 마스터에 넣어봄 - 로컬에 있는 마스터 내용으로 변경됨
  → git push --force origin master jh2
  
  의문점?
  로컬에 있는 마스터와 jh2의 커밋 내용이 다릅니다
  3번은 로컬의 jh2를 넣었는데 왜 로컬의 마스터 내용이 나올까요...
- git push --force origin master jh2
  로컬에 있는 master를 원격저장소 jh2브랜치에 푸시
- git push --force origin jh2 master
  로컬에 있는 jh2를 원격저장소 master에 푸시
- git push "원격저장소이름" "local브랜치이름" "원격저장소브랜치이름"
- 내가 생각했던 순서는? git push "원격저장소이름" "local브랜치이름" "원격저장소브랜치이름"
- 해설..?
  - 1 올바른 구문은 다음과 같습니다:
```
git push <원격저장소이름> <로컬브랜치이름>:<원격저장소브랜치이름>
```
    여기서 <원격저장소이름>은 원격 저장소의 이름(별칭)을 나타내며, <로컬브랜치이름>은 로컬 브랜치의 이름, <원격저장소브랜치이름>은 원격 저장소에 푸시하려는 브랜치의 이름입니다. 예를 들어, 만약 로컬 브랜치 main을 origin 원격 저장소의 main 브랜치로 푸시하려면 다음과 같이 명령을 사용할 수 있습니다:
```
git push origin main:main
```
    위 명령은 로컬 main 브랜치를 origin 원격 저장소의 main 브랜치로 푸시합니다. 즉, 로컬의 main 브랜치의 변경 사항이 origin 원격 저장소의 main 브랜치로 병합됩니다. 원격 저장소의 이름과 브랜치의 순서를 올바르게 지정하여 git push 명령을 사용하시기 바랍니다.
  - 2 로컬 브랜치 main을 origin 원격 저장소의 Like 브랜치로 푸시하려면 다음 명령을 사용하면 됩니다:
```
git push origin main:Like
```
터미널러 명령어를 주는 경우는 거의 없고 Git 메뉴에 대체적으로 있다고 합니다
ex) git push force 버튼이 있음

생성자, 메서드

타입(String…)이 붙어 있으면 메서드
타입이 없으면 생성자

heeh

공부하자개발하자으쌰으쌰

이전 포스트

2023.06.15.목.TIL

다음 포스트

2023.06.16.금.TIL

TIL

과제

IJ에서 Commit한 내용 삭제하기(되돌리기)

생성자, 메서드

2023.06.15.목.TIL

2023.06.19.월.TIL

0개의 댓글