목차
🦁멋쟁이사자처럼 백엔드 부트캠프 13기 🦁
TIL 회고 - [68]일차
🚀68일차에는 Git과 GitHub의 연동에 대해 학습했다. Git을 가볍게만 사용하고 GitHub에서 작성했던 기능들을 push하는 방식으로만 사용하고 있었는데 토큰발급의 필요성, 커밋을 진행했던 로컬 저장소와 원격 저장소의 연결, Organization 기능 등을 알 수 있게되었다.
학습 목표 : GitHub를 통해 향후 프로젝트 시의 pull Request, Branch로 작업 등에 익숙해져야함
학습 과정 : 회고를 통해 작성
Git 명령어
git cat-file
- git cat-file -p [해시코드값]
- ex. git cat-file -p aa15~~~ .gitignore
- 파일의 내용이 보여짐
- Git 저장소에서 객체를 검사할때 사용
- -p : pretty-print 형식으로 출력
이 명령은 주어진 객체의 타입을 자동으로 감지하고 적절한 형식으로
내용을 출력 (객체의 유형 : 커밋, 트리, 블롭 등)자동으로 감지
git log --oneline
- 한 줄로 로그를 요약해서 보여줌
git log 를 출력했을때 커밋을 2번 한 것을 확인 가능
- commit : 4c7f 와 e0a2 해시 값이 있고, 4c7f가 HEAD를 가짐
- HEAD가 아닌 e0a2 값을 다시 탐색해보면, d5a5, 3dd6, 440f 가 있고 그 중 d5a5는 blob구조이며
나머지는 트리구조이다.
- blob파일인 d5a5를 탐색해보면 그 안의 파일 내용이 바로 출력되는 것을 확인 가능
- tree는 트리구조로 펼쳐져있는 형태이고, blob은 파일의 형태
- 따라서 git cat-file -p 명령어를 통해 이처럼 트리 구조를 탐색해 볼 수 있다.
- reset 같은 명령어를 사용해서 이전의 커밋으로 돌아갈 수 있는데
- 이전의 커밋으로 돌아가게되면 HEAD가 가리키고 있는 4c7f 가 아닌 e0a2 로 가리켜지게될 것이다.
- HEAD가 가리키는 부분이 현재 위치한 커밋이라는 의미이므로 (parent가 이전커밋을 가짐)
- HEAD는 이전의 커밋으로 돌아갔으므로 그 시점 기준 최신커밋인 e0a2를 가리키게되는 구조로 동작한다.
git reset --hard e0a2
- git reset 명령어로 e0a2 커밋으로 되돌아갈 수 있다.
git reset
- 현재 브랜치에서 특정 커밋으로 되돌리는 명령어
- 되돌리는 방법에 따라 --soft, --mixed, --hard 옵션이 존재
- -mixed 옵션 : 기본값으로
1) HEAD 변경 → 현재 브랜치의 HEAD가 한 커밋 뒤로 이동 (HEAD~1)
2) Staging Area(=Index) 초기화 → 해당 커밋에서 반영된 변경 사항이 스테이징 영역에서 제거
3) 작업 디렉터리(Working Directory)는 그대로 유지 → 파일의 변경 내용은 유지되며, Unstaged 상태가 됨
이와 같은 흐름을 가짐 - HEAD~1 : 현재 커밋에서 하나 이전 커밋을 가리키는 것
| --soft | O (이전 커밋으로 이동) | O (스테이징 유지) | O (작업 디렉터리 유지) |
| --mixed | O (이전 커밋으로 이동) | X (스테이징 초기화) | O (작업 디렉터리 유지) |
| --hard | O (이전 커밋으로 이동) | X (스테이징 초기화) | X (작업 디렉터리도 되돌림) |
- 최근 커밋을 취소하고 다시 수정하려면 : git reset --soft HEAD~1
- 최근 커밋을 취소하고 다시 커밋하려면 : git reset --mixed HEAD~1
- 최근 커밋을 완전히 삭제하고 되돌리려면 (주의!) : git reset --hard HEAD~1
▶️실습 - git reset
- reset.txt에
line1 → commit 1
line2 (라인 추가 ) → commit 2
line3 (라인 추가) → commit 3 - 커밋 3개를 만들어준 후 git log --oneline 의 결과
- git reset —soft [가고싶은커밋의해시값]
ex. git reset —soft 530205a
➡️두번째 커밋값으로 돌아가므로 FORK 프로그램에서 확인해보면 line1, line2만 저장되어있는 것을 확인할 수 있다. - git reset —soft c4c8b25
➡️세번째 커밋값으로 돌아간 후
➡️vi reset.txt 편집기로 line3 - 수정 문구를 추가 후 git add . 다시 커밋을 올림
➡️-m “update: reset Third Commit” : 세번째 커밋 업데이트 내용으로 변경해준다.
- 다시 확인해보면 이런 방식으로 커밋들이 쌓여있을 것이고
- git reset —mixed HEAD~1 ➡️ 바로 이전 커밋으로 되돌릴 수 있다.
git reflog
- reflog를 사용하면 사라진 것들도 포함하여 모든 로그 기록들을 볼 수 있다.
git diff
- 커밋 간 변경사항 출력
- git diff [해시값1] [해시값2]
echo
- 파일 내용 작성 및 파일 생성
- ex.
echo email:pickipi@pickipi.com >> resources/application.properties
➡️>> : 2개이면 이어붙여 쓰기
➡️> : 1개이면 덮어쓰거나 새로생성
: 기존 파일이 있으면 내용을 지우고 새로 작성
: 없는 파일이면 새로 생성
git restore
- git reset 은 커밋을 되돌리는 명령이었다면
- git restore는 파일의 변경 내용을 되돌리는 명령
git show
- Git에서 특정 객체(커밋, 태그 등)의 상세정보를 보여줌
- 최신커밋에 대하여 메타데이터와 패치정보를 출력할 수 있고
해시값을 넣어주면 최신커밋이 아닌 특정 커밋에 대한 상세정보도 조회할 수 있다.
브랜치 Branch
- 코드의 다른 버전을 분리하여 독립적으로 관리할 수 있게해주는 “포인터”
- 개발자는 브랜치를 통해 여러 기능을 “동시에 개발”하고 다양한 실험 수행 가능
- 브랜치를 사용하여 “메인 코드베이스 (main/ master)”가 안정적인 상태를 유지하면서
동시에 새로운 기능을 개발하고 테스트할 수 있다. - 각 기능이 완료되고 충분히 테스트 되었으면 메인 코드베이스 (=메인브랜치)로 “병합(merge)”가능
- Git Flow : feature, develop, release, hotfix(긴급한 수정), main 등 여러 종류의 브랜치를 사용하는 “복잡한 전략”
- GitHub Flow : main 브랜치와 여러 feature 브랜치를 사용하므로 상대적으로 간단
- 모든 변경사항은 feature브랜치에서 작업되고 코드 리뷰 및 테스트를 거친 후 main 브랜치로 병합되어 배포됨
Branch 생성
- checkout 을 쓰기도 하지만 현재는 checkout 대신 switch를 사용
- git switch -c [브랜치명] : 브랜치 생성과 동시에 이 브랜치로 변경해주는 역할
- git branch : 현재있는 브랜치들을 확인할 수 있는 명령
- git branch [브랜치명] : 기본적으로 브랜치를 생성해주는 명령
- git switch abc : abc 브랜치로 변경
- abc 브랜치에서 add와 commit까지 한 후 확인해보면 abc에서는 abc.txt 가 존재하고
- main 브랜치에서는 abc.txt 가 존재하지 않는 것을 확인할 수 있다.
HEAD
- cat .git/HEAD 파일을 확인함으로써 HEAD가 어느 브랜치에 위치해있는지 알 수 있다.
- 브랜치를 변경 후 다시 확인해보면 바뀐 브랜치로 HEAD가 가리키고 있음을 확인할 수 있다.
- main과 동일한 커밋을 가지는 blog_create, blog_update 브랜치이기때문에
현재 브랜치가 blog_update 이면 HEAD는 현재 브랜치인 blog_update를 가리키고,
main, blog_create, blog_update 브랜치들은 이전 커밋인 parent 해시를 가리키고 있는 형태인 것이다. - (이전 커밋의 해시 = parent)
Branch 명령어
- git branch -a : 로컬 / 원격 브랜치 모두 나열
- git branch -r : 원격 브랜치만 나열
- git branch -d [브랜치명] : 브랜치 삭제
소문자 d 는 안전삭제 (브랜치가 이미 다른 브랜치에 병합된 경우에만 삭제를 허용) - git branch -D [브랜치명] : 브랜치 삭제
대문자 D는 강제삭제 (브랜치가 병합되어있더라도 관계없이 브랜치를 삭제) - git branch -m [기존 브랜치명] [새 브랜치명] : 브랜치 이름의 변경
- blog_update, blog_create, abc 에 각각 개별 커밋을 진행한 후의 FORK에 줄기가 여러개 생긴것을 확인할 수 있다.
Merge 병합하기
- main으로 브랜치 변경 후 merge blog_update 로 blog_update브랜치와 병합을 진행하면
- 이처럼 blog_update브랜치의 내용이 main과 병합된 것을 확인할 수 있다.
- 병합하고나면 main브랜치에서 src 디렉토리를 확인해봤을때
blog_update 브랜치에서 작업했던 파일 BlogUpdate.java가 들어와있는 것을 확인 가능
merge 시 충돌해결
- hello.txt 동일한 파일에 써진 내용이 Bradley 브랜치에서는 line2, Bradley line이고
- main 브랜치에서는 line1, main line 일때
- main브랜치로 이동하여 git merge Bradley를 하고자할때 merge 오류가 발생할 것이다.
- code hello.txt
➡️파일에 들어가보면 이처럼 두 내용 모두 포함되어있는 것을 확인할 수 있다.
line2
Bradley line
- Bradley의 필요부분만 남기고 모두 지워준 후
- hello.txt를 추가하고 커밋을 해보면 코드내용이 수정된 것을 확인할 수 있다.
원격저장소(GitHub)와 로컬 저장소 연결
- 명령어를 통해 깃허브에서 만들어놓은 저장소와 연결한다.
- -v 옵션으로 fetch와 push가 잘 되어있는지 확인한다.
- fetch는 데이터를 잘 가져올 URL
- push는 데이터를 잘 올릴 URL
- origin은 별칭 (=이 저장소의 별칭)
- git push -u origin main
➡️origin의 main 브랜치에 푸시할 것
u 옵션 : -set-upstream의 축약형으로 현재 브랜치를 원격 저장소(origin)의
특정 브랜치(main)와 연결(추적, upstream 설정)하는 역할
한 번만 설정하면 이후에는 git push 또는 git pull만 입력해도 자동으로 원격 브랜치와 동기화
⚠️연동 인증 오류 해결
- origin을 지워주고 다시 생성할때
- git remote add origin https://닉네임:토큰@github.com/repository ➡️경로 형식으로 넣어준다.
- git remote -v로 확인해보면 제대로 연결이되었다.
- git push -u origin main➡️원격저장소에 push
- git pull ➡️ 업데이트할 사항이 있는지 체크
- 로컬에서 진행했었던 커밋 내용 (15개)가 원격 저장소에 추가되어 적용된 것을 확인할 수 있다.
Pull Request
- 한 브랜치의 변경사항을 다른 브랜치로 병합하기 위해 리뷰와 토론을 요청하는 기능
🚀회고 결과 :
GitHub와 연동하기 위한 명령어와 Git 자체적으로 reset, restore로 커밋을 관리하는 방법들을 회고를 통해서 더 자세히 알 수 있었다. reset, restore의 차이점과 --mixed, --soft, --hard 같은 옵션에 대해서도 차이점을 분석할 수 있었다.
향후 계획 :
- GitHub : Organization 기능에 대하여 알아보기
'Recording > 멋쟁이사자처럼 BE 13기' 카테고리의 다른 글
| [멋쟁이사자처럼 부트캠프 TIL 회고] BE 13기_70일차_"Docker + Linux (2)" (0) | 2025.03.20 |
|---|---|
| [멋쟁이사자처럼 부트캠프 TIL 회고] BE 13기_69일차_"Docker + Linux" (0) | 2025.03.19 |
| [멋쟁이사자처럼 부트캠프 TIL 회고] BE 13기_67일차_"JUnit" (0) | 2025.03.17 |
| [멋쟁이사자처럼 부트캠프 TIL 회고] BE 13기_66일차_"모임 관리 프로젝트" (0) | 2025.03.14 |
| [멋쟁이사자처럼 부트캠프 TIL 회고] BE 13기_63일차_"Swagger" (0) | 2025.03.11 |
🦁멋쟁이사자처럼 백엔드 부트캠프 13기 🦁
TIL 회고 - [68]일차
🚀68일차에는 Git과 GitHub의 연동에 대해 학습했다. Git을 가볍게만 사용하고 GitHub에서 작성했던 기능들을 push하는 방식으로만 사용하고 있었는데 토큰발급의 필요성, 커밋을 진행했던 로컬 저장소와 원격 저장소의 연결, Organization 기능 등을 알 수 있게되었다.
학습 목표 : GitHub를 통해 향후 프로젝트 시의 pull Request, Branch로 작업 등에 익숙해져야함
학습 과정 : 회고를 통해 작성
Git 명령어
git cat-file
- git cat-file -p [해시코드값]
- ex. git cat-file -p aa15~~~ .gitignore
- 파일의 내용이 보여짐
- Git 저장소에서 객체를 검사할때 사용
- -p : pretty-print 형식으로 출력
이 명령은 주어진 객체의 타입을 자동으로 감지하고 적절한 형식으로
내용을 출력 (객체의 유형 : 커밋, 트리, 블롭 등)자동으로 감지
git log --oneline
- 한 줄로 로그를 요약해서 보여줌
git log 를 출력했을때 커밋을 2번 한 것을 확인 가능
- commit : 4c7f 와 e0a2 해시 값이 있고, 4c7f가 HEAD를 가짐
- HEAD가 아닌 e0a2 값을 다시 탐색해보면, d5a5, 3dd6, 440f 가 있고 그 중 d5a5는 blob구조이며
나머지는 트리구조이다.
- blob파일인 d5a5를 탐색해보면 그 안의 파일 내용이 바로 출력되는 것을 확인 가능
- tree는 트리구조로 펼쳐져있는 형태이고, blob은 파일의 형태
- 따라서 git cat-file -p 명령어를 통해 이처럼 트리 구조를 탐색해 볼 수 있다.
- reset 같은 명령어를 사용해서 이전의 커밋으로 돌아갈 수 있는데
- 이전의 커밋으로 돌아가게되면 HEAD가 가리키고 있는 4c7f 가 아닌 e0a2 로 가리켜지게될 것이다.
- HEAD가 가리키는 부분이 현재 위치한 커밋이라는 의미이므로 (parent가 이전커밋을 가짐)
- HEAD는 이전의 커밋으로 돌아갔으므로 그 시점 기준 최신커밋인 e0a2를 가리키게되는 구조로 동작한다.
git reset --hard e0a2
- git reset 명령어로 e0a2 커밋으로 되돌아갈 수 있다.
git reset
- 현재 브랜치에서 특정 커밋으로 되돌리는 명령어
- 되돌리는 방법에 따라 --soft, --mixed, --hard 옵션이 존재
- -mixed 옵션 : 기본값으로
1) HEAD 변경 → 현재 브랜치의 HEAD가 한 커밋 뒤로 이동 (HEAD~1)
2) Staging Area(=Index) 초기화 → 해당 커밋에서 반영된 변경 사항이 스테이징 영역에서 제거
3) 작업 디렉터리(Working Directory)는 그대로 유지 → 파일의 변경 내용은 유지되며, Unstaged 상태가 됨
이와 같은 흐름을 가짐 - HEAD~1 : 현재 커밋에서 하나 이전 커밋을 가리키는 것
| --soft | O (이전 커밋으로 이동) | O (스테이징 유지) | O (작업 디렉터리 유지) |
| --mixed | O (이전 커밋으로 이동) | X (스테이징 초기화) | O (작업 디렉터리 유지) |
| --hard | O (이전 커밋으로 이동) | X (스테이징 초기화) | X (작업 디렉터리도 되돌림) |
- 최근 커밋을 취소하고 다시 수정하려면 : git reset --soft HEAD~1
- 최근 커밋을 취소하고 다시 커밋하려면 : git reset --mixed HEAD~1
- 최근 커밋을 완전히 삭제하고 되돌리려면 (주의!) : git reset --hard HEAD~1
▶️실습 - git reset
- reset.txt에
line1 → commit 1
line2 (라인 추가 ) → commit 2
line3 (라인 추가) → commit 3 - 커밋 3개를 만들어준 후 git log --oneline 의 결과
- git reset —soft [가고싶은커밋의해시값]
ex. git reset —soft 530205a
➡️두번째 커밋값으로 돌아가므로 FORK 프로그램에서 확인해보면 line1, line2만 저장되어있는 것을 확인할 수 있다. - git reset —soft c4c8b25
➡️세번째 커밋값으로 돌아간 후
➡️vi reset.txt 편집기로 line3 - 수정 문구를 추가 후 git add . 다시 커밋을 올림
➡️-m “update: reset Third Commit” : 세번째 커밋 업데이트 내용으로 변경해준다.
- 다시 확인해보면 이런 방식으로 커밋들이 쌓여있을 것이고
- git reset —mixed HEAD~1 ➡️ 바로 이전 커밋으로 되돌릴 수 있다.
git reflog
- reflog를 사용하면 사라진 것들도 포함하여 모든 로그 기록들을 볼 수 있다.
git diff
- 커밋 간 변경사항 출력
- git diff [해시값1] [해시값2]
echo
- 파일 내용 작성 및 파일 생성
- ex.
echo email:pickipi@pickipi.com >> resources/application.properties
➡️>> : 2개이면 이어붙여 쓰기
➡️> : 1개이면 덮어쓰거나 새로생성
: 기존 파일이 있으면 내용을 지우고 새로 작성
: 없는 파일이면 새로 생성
git restore
- git reset 은 커밋을 되돌리는 명령이었다면
- git restore는 파일의 변경 내용을 되돌리는 명령
git show
- Git에서 특정 객체(커밋, 태그 등)의 상세정보를 보여줌
- 최신커밋에 대하여 메타데이터와 패치정보를 출력할 수 있고
해시값을 넣어주면 최신커밋이 아닌 특정 커밋에 대한 상세정보도 조회할 수 있다.
브랜치 Branch
- 코드의 다른 버전을 분리하여 독립적으로 관리할 수 있게해주는 “포인터”
- 개발자는 브랜치를 통해 여러 기능을 “동시에 개발”하고 다양한 실험 수행 가능
- 브랜치를 사용하여 “메인 코드베이스 (main/ master)”가 안정적인 상태를 유지하면서
동시에 새로운 기능을 개발하고 테스트할 수 있다. - 각 기능이 완료되고 충분히 테스트 되었으면 메인 코드베이스 (=메인브랜치)로 “병합(merge)”가능
- Git Flow : feature, develop, release, hotfix(긴급한 수정), main 등 여러 종류의 브랜치를 사용하는 “복잡한 전략”
- GitHub Flow : main 브랜치와 여러 feature 브랜치를 사용하므로 상대적으로 간단
- 모든 변경사항은 feature브랜치에서 작업되고 코드 리뷰 및 테스트를 거친 후 main 브랜치로 병합되어 배포됨
Branch 생성
- checkout 을 쓰기도 하지만 현재는 checkout 대신 switch를 사용
- git switch -c [브랜치명] : 브랜치 생성과 동시에 이 브랜치로 변경해주는 역할
- git branch : 현재있는 브랜치들을 확인할 수 있는 명령
- git branch [브랜치명] : 기본적으로 브랜치를 생성해주는 명령
- git switch abc : abc 브랜치로 변경
- abc 브랜치에서 add와 commit까지 한 후 확인해보면 abc에서는 abc.txt 가 존재하고
- main 브랜치에서는 abc.txt 가 존재하지 않는 것을 확인할 수 있다.
HEAD
- cat .git/HEAD 파일을 확인함으로써 HEAD가 어느 브랜치에 위치해있는지 알 수 있다.
- 브랜치를 변경 후 다시 확인해보면 바뀐 브랜치로 HEAD가 가리키고 있음을 확인할 수 있다.
- main과 동일한 커밋을 가지는 blog_create, blog_update 브랜치이기때문에
현재 브랜치가 blog_update 이면 HEAD는 현재 브랜치인 blog_update를 가리키고,
main, blog_create, blog_update 브랜치들은 이전 커밋인 parent 해시를 가리키고 있는 형태인 것이다. - (이전 커밋의 해시 = parent)
Branch 명령어
- git branch -a : 로컬 / 원격 브랜치 모두 나열
- git branch -r : 원격 브랜치만 나열
- git branch -d [브랜치명] : 브랜치 삭제
소문자 d 는 안전삭제 (브랜치가 이미 다른 브랜치에 병합된 경우에만 삭제를 허용) - git branch -D [브랜치명] : 브랜치 삭제
대문자 D는 강제삭제 (브랜치가 병합되어있더라도 관계없이 브랜치를 삭제) - git branch -m [기존 브랜치명] [새 브랜치명] : 브랜치 이름의 변경
- blog_update, blog_create, abc 에 각각 개별 커밋을 진행한 후의 FORK에 줄기가 여러개 생긴것을 확인할 수 있다.
Merge 병합하기
- main으로 브랜치 변경 후 merge blog_update 로 blog_update브랜치와 병합을 진행하면
- 이처럼 blog_update브랜치의 내용이 main과 병합된 것을 확인할 수 있다.
- 병합하고나면 main브랜치에서 src 디렉토리를 확인해봤을때
blog_update 브랜치에서 작업했던 파일 BlogUpdate.java가 들어와있는 것을 확인 가능
merge 시 충돌해결
- hello.txt 동일한 파일에 써진 내용이 Bradley 브랜치에서는 line2, Bradley line이고
- main 브랜치에서는 line1, main line 일때
- main브랜치로 이동하여 git merge Bradley를 하고자할때 merge 오류가 발생할 것이다.
- code hello.txt
➡️파일에 들어가보면 이처럼 두 내용 모두 포함되어있는 것을 확인할 수 있다.
line2
Bradley line
- Bradley의 필요부분만 남기고 모두 지워준 후
- hello.txt를 추가하고 커밋을 해보면 코드내용이 수정된 것을 확인할 수 있다.
원격저장소(GitHub)와 로컬 저장소 연결
- 명령어를 통해 깃허브에서 만들어놓은 저장소와 연결한다.
- -v 옵션으로 fetch와 push가 잘 되어있는지 확인한다.
- fetch는 데이터를 잘 가져올 URL
- push는 데이터를 잘 올릴 URL
- origin은 별칭 (=이 저장소의 별칭)
- git push -u origin main
➡️origin의 main 브랜치에 푸시할 것
u 옵션 : -set-upstream의 축약형으로 현재 브랜치를 원격 저장소(origin)의
특정 브랜치(main)와 연결(추적, upstream 설정)하는 역할
한 번만 설정하면 이후에는 git push 또는 git pull만 입력해도 자동으로 원격 브랜치와 동기화
⚠️연동 인증 오류 해결
- origin을 지워주고 다시 생성할때
- git remote add origin https://닉네임:토큰@github.com/repository ➡️경로 형식으로 넣어준다.
- git remote -v로 확인해보면 제대로 연결이되었다.
- git push -u origin main➡️원격저장소에 push
- git pull ➡️ 업데이트할 사항이 있는지 체크
- 로컬에서 진행했었던 커밋 내용 (15개)가 원격 저장소에 추가되어 적용된 것을 확인할 수 있다.
Pull Request
- 한 브랜치의 변경사항을 다른 브랜치로 병합하기 위해 리뷰와 토론을 요청하는 기능
🚀회고 결과 :
GitHub와 연동하기 위한 명령어와 Git 자체적으로 reset, restore로 커밋을 관리하는 방법들을 회고를 통해서 더 자세히 알 수 있었다. reset, restore의 차이점과 --mixed, --soft, --hard 같은 옵션에 대해서도 차이점을 분석할 수 있었다.
향후 계획 :
- GitHub : Organization 기능에 대하여 알아보기
'Recording > 멋쟁이사자처럼 BE 13기' 카테고리의 다른 글
| [멋쟁이사자처럼 부트캠프 TIL 회고] BE 13기_70일차_"Docker + Linux (2)" (0) | 2025.03.20 |
|---|---|
| [멋쟁이사자처럼 부트캠프 TIL 회고] BE 13기_69일차_"Docker + Linux" (0) | 2025.03.19 |
| [멋쟁이사자처럼 부트캠프 TIL 회고] BE 13기_67일차_"JUnit" (0) | 2025.03.17 |
| [멋쟁이사자처럼 부트캠프 TIL 회고] BE 13기_66일차_"모임 관리 프로젝트" (0) | 2025.03.14 |
| [멋쟁이사자처럼 부트캠프 TIL 회고] BE 13기_63일차_"Swagger" (0) | 2025.03.11 |
