왜 굳이 DTO를 만들어서 보내야 할까?

처음에는 "그냥 엔티티 그대로 반환하면 되지 않을까?"라고 생각할 수 있다. 하지만 실제로는 다음과 같은 이유 때문에 DTO를 만들어 사용하는 것이 좋다.

1. 보안 문제 방지

엔티티에는 사용자 비밀번호, 내부 데이터 등 민감한 정보가 들어 있을 수 있는데, 이 때 엔티티를 그대로 응답으로 내보내면 정보들이 함께 노출될 수 있다.

2. 프론트엔드에 맞는 데이터 형태 제공

• 프론트에서는 꼭 모든 필드가 필요하지 않다. DTO를 통해 필요한 필드만 추려서 보낼 수 있다.
• 응답 형식을 프론트와 협의한 대로 정확히 맞춰줄 수 있다.

3. 유지보수 유리

엔티티 구조가 변경되어도 DTO를 통해 응답 구조를 따로 관리할 수 있다.

엔티티를 DTO로 바꾸는 3가지 방법

List 형태의 엔티티를 DTO로 변환하는 과정이다.

1. 생성자 사용

List<AttachmentDTO> attachmentDTOs = attachments.stream()
    .map(a -> new AttachmentDTO(
        a.getName(),
        a.getChangedName(),
        a.getSize(),
        a.getExtension()
    )).toList();

장점

• 간단하고 빠르게 작성할 수 있다.

단점

• 파라미터 순서를 지켜야 하고, 필드가 많아질수록 가독성이 떨어지고 실수할 수 있다.
• 어떤 값이 어떤 필드에 들어가는지 직관적으로 보이지 않는다.

2. 빌더 패턴 사용

@Builder
public class AttachmentDTO {

    private Long attachmentId;
    private String name;
    private String changedName;
    private LocalDateTime createdAt;
    private Long size;
    private String extension;

먼저, 해당 DTO 클래스에 @Builder 어노테이션을 추가해야 한다.

List<AttachmentDTO> attachmentDTOs = attachments.stream()
    .map(a -> AttachmentDTO.builder()
        .name(a.getName())
        .changedName(a.getChangedName())
        .size(a.getSize())
        .extension(a.getExtension())
        .build()
    ).toList();

장점

• 명확하게 어떤 값이 어떤 필드에 들어가는지 확인할 수 있어 가독성이 좋다.
• 선택적으로 필드를 설정할 수 있어서 유연하다.

단점

• 코드가 약간 길어진다.

3. 정적 팩토리 메소드 사용

public static AttachmentDTO convertDTO(Attachment attachment) {
    return new AttachmentDTO(
        attachment.getName(),
        attachment.getChangedName(),
        attachment.getSize(),
        attachment.getExtension()
    );
}

DTO 클래스 내부에 정적 메소드로 작성하여 사용한다. 엔티티에서 DTO로 변환하는 메소드라는 뜻으로 다음과 같이 convertDTO라는 이름으로 작성했다.

// 사용
List<AttachmentDTO> attachmentDTOs = attachments.stream()
    .map(AttachmentDTO::convertDTO)
    .toList();

장점

• AttachmentDTO.convertDTO()처럼 객체를 생성하지 않고 클래스 이름으로 직접 호출할 수 있어서 직관적이다.

• 변환 로직을 DTO 클래스 내부에 두어 관련 책임을 부여할 수 있다.

• 명확한 이름을 붙여서 어떤 역할인지 표현할 수 있다.

  • 빌더를 사용하는 방식도 @Builder를 통해 정적 메소드를 주입한 것이다. 즉, AttachmentDTO.builder()도 정적 팩토리 메소드처럼 클래스 이름으로 객체를 생성하는 방식이다.

• 로직이 바뀌더라도 메소드 내부만 수정하면 돼서 유지보수에 좋다.

단점

• 변환 메소드를 작성해야 하므로 약간의 반복 작업이 필요하다.
• 클래스명.메소드() 형태로 전역으로 호출할 수 있기 때문에, 남용하면 설계가 복잡해질 수 있다.

+ OneToMany 연관 관계에서의 사용

Post <-> List(Attachment) 연관 관계이고, Post → PostDetailDTO 변환

public static PostDetailDTO convertDTO(Post post, List<AttachmentDTO> attachmentDTOs) {
    return new PostDetailDTO(
        post.getPostId(),
        post.getTitle(),
        post.getContent(),
        post.getCreatedAt(),
        attachmentDTOs
    );
}

• 복합적인 DTO를 만들 때는 여러 값을 함께 받아서 변환하는 메소드를 만들어 사용한다.

정리

API 응답을 깔끔하고 안정적으로 만들기 위해서는 DTO 설계와 변환 방식에 신경 써야 한다. 단순히 동작만 되면 끝이 아니라, 나중에 유지보수나 확장할 때 얼마나 편할지를 생각하고 코드를 짜보자.

정적 팩토리 메소드는 처음에는 익숙하지 않을 수 있지만, 점점 큰 프로젝트일수록 의도를 명확히 전달할 수 있고 변환 로직 변경이 필요할 때도 해당 메서드만 수정하면 되어 코드의 가독성과 유지보수성을 높일 수 있다.

이 글에서는 왜 그런 현상이 생기는지, 그리고 어떻게 해결할 수 있는지 정리했다.

왜 날짜가 배열처럼 보일까?

Spring Boot에서는 기본적으로 Jackson 라이브러리를 통해 객체를 JSON으로 직렬화한다.
하지만 LocalDateTime은 Jackson 기본 설정에 의해 이렇게 [year, month, day, hour, minute, second, nano] 배열 형태나 숫자 형태의 timestamp로 처리된다.

[2025, 5, 2, 3, 47, 19, 939277000]

혹은

20255234719939277000

이런 현상은 Spring Boot가 사용하는 JSON 직렬화 도구인 Jackson의 기본 설정 때문이다. Jackson은 Java 8의 LocalDateTime을 자동으로 지원하지 않으며, JSR-310(java.time)을 제대로 처리하기 위해서는 별도 모듈을 등록하거나 설정을 명시적으로 바꿔야 한다.

원인 정리

Spring Boot는 Jackson을 통해 객체를 JSON으로 직렬화한다. 그러나 Java 8의 LocalDateTime은 Jackson 2.x 기준으로 기본 지원 대상이 아니며, 아래와 같은 문제가 발생한다:

• Jackson이 JSR-310 타입(LocalDateTime, LocalDate, ZonedDateTime)을 배열 형태로 직렬화
• ObjectMapper가 WRITE_DATES_AS_TIMESTAMPS 설정을 true로 유지할 경우 timestamp처럼 처리

해결 방법

1. application.yml 설정 추가

spring:
  jackson:
    date-format: yyyy-MM-dd HH:mm:ss
    serialization:
      write-dates-as-timestamps: false

• date-format: 우리가 원하는 문자열 형식 지정
• write-dates-as-timestamps: false: timestamp 형태 사용 금지

이 설정을 통해 Jackson은 날짜/시간을 배열이나 timestamp가 아닌, 우리가 원하는 문자열 포맷으로 직렬화한다. 단, 이 방법은 java.util.Date, java.sql.Timestamp 등 구형 날짜 클래스에는 적용되지만, LocalDateTime에는 일부 제한이 있다.

2. 필드에 @JsonFormat 어노테이션으로 명시

엔티티나 DTO 클래스의 필드에 직접 적용하고 싶을 때 어노테이션을 붙이는 것이 확실하다.

@JsonFormat(pattern = "yyyy.MM.dd HH:mm:ss")
private LocalDateTime createdAt;

Jackson이 이 어노테이션을 통해 해당 필드만 원하는 포맷으로 직렬화한다. 포맷을 변경하거나 필드별로 다르게 적용하고 싶은 경우 유용하다.

응답 결과 확인

이제 응답에서 아래처럼 문자열 포맷으로 잘 나오는 걸 확인할 수 있다.

"createdAt": "2025.05.02 03:47:19"

마무리

• LocalDateTime은 기본적으로 배열이나 timestamp처럼 내려온다.
• 프론트엔드와 연동 시 날짜 포맷은 프로젝트 초기에 미리 설정해두면 좋을 것 같다.
• 전역 설정(application.yml) 또는 개별 설정(@JsonFormat) 중 선택 가능

왜 파일명을 변경해서 저장해야 할까?

업로드된 파일을 서버에 저장할 때 원래 파일명을 그대로 저장하면, 같은 이름의 파일이 업로드될 경우 기존 파일이 덮어 써지는 문제가 발생한다. 이를 방지하기 위해 UUID를 활용하여 고유한 파일명을 생성해 저장해주어야 한다.

String changedName = UUID.randomUUID().toString() + "." + extension;

파일 저장 전 처리해야 할 작업들

1. 파일 확장자 추출하기

파일 확장자는 파일명에서 마지막 . 이후의 문자열로 얻을 수 있다.

String extension = originalName.substring(originalName.lastIndexOf(".") + 1);

lastIndexOf(".")를 사용하면 파일명 중 마지막 점(.)의 위치를 기준으로 확장자를 정확히 추출할 수 있다.

2. 파일 저장 경로 만들기

파일은 디스크에 저장할 때 폴더 + 파일명으로 경로가 완성되어야 한다.
이 경로를 코드에 하드코딩하기보다는 application.yml에 저장하고 @Value로 주입받는 게 유지보수에 유리하다.

application.yml

file:
  upload-dir: C:/uploads/myfile/files

코드에서 주입받기

@Value("${file.upload-dir}")
private String uploadUrl;

하드코딩(String path = "C:/...")보다 설정 파일을 사용하는 것이 환경 변경에 유리하고, 코드 수정 없이 배포 가능하다.

3. 파일 디렉토리 생성

업로드 디렉토리가 존재하지 않으면 직접 만들어주어야 한다.

File directory = new File(uploadUrl);
if (!directory.exists()) {
    directory.mkdirs();
}

실제 파일 저장

업로드된 파일을 서버 디스크에 저장하려면 transferTo() 메서드를 꼭 호출해줘야 한다. 이걸 하지 않으면 DB에 경로만 저장되고 실제 파일은 존재하지 않는 상황이 생긴다.

File saveFile = new File(uploadUrl + File.separator + changedName);
file.transferTo(saveFile); // 서버 디스크에 저장

디렉토리가 존재하지 않는다면 mkdirs()로 먼저 만들어줘야 한다.

파일 저장 서비스 전체 로직

@Transactional
public Object createPostWithFile(PostRequestDTO postRequestDTO, List<MultipartFile> files) {
    Post post = new Post(postRequestDTO.getTitle(), postRequestDTO.getContent());

    if (!files.isEmpty()) {
        File directory = new File(uploadUrl);
        if (!directory.exists()) {
            directory.mkdirs();
        }

        for (MultipartFile file : files) {
            validateFile(file);

            String originalName = file.getOriginalFilename();
            String extension = originalName.substring(originalName.lastIndexOf(".") + 1);
            String changedName = UUID.randomUUID().toString() + "." + extension;
            String path = uploadUrl + File.separator + changedName;

            try {
                file.transferTo(new File(path));
            } catch (IOException e) {
                throw new RuntimeException("파일 저장 실패", e);
            }

            Attachment newAttachment = Attachment.builder()
                    .name(originalName)
                    .changedName(changedName)
                    .path(path)
                    .size(file.getSize())
                    .extension(extension)
                    .build();

            post.addAttachment(newAttachment);
        }
    }

    postRepository.save(post);
    return "저장 완료";
}

파일 유효성 검사

업로드 가능한 파일에 대해 몇 가지 기준을 두고 필터링해야 한다. 아래 3가지는 기본적으로 검사해주는 게 좋다.

유효성 검사 항목

• 파일명 검사: 비어있거나 null인 경우 거부
• 파일 크기 제한: 예: 100MB 이하
• 확장자 제한: .jpg, .png, .pdf 등 허용된 확장자만 업로드 가능

private void validateFile(MultipartFile file) {
    if (file.getOriginalFilename() == null) {
        throw new IllegalArgumentException("유효하지 않은 파일명입니다.");
    }

    if (file.getSize() > MAX_FILE_SIZE) {
        throw new IllegalArgumentException("파일 크기는 100MB를 초과할 수 없습니다.");
    }

    String extension = file.getOriginalFilename()
                           .substring(file.getOriginalFilename().lastIndexOf(".") + 1)
                           .toLowerCase();

    if (!ALLOWED_EXTENSIONS.contains(extension)) {
        throw new IllegalArgumentException("허용되지 않은 파일 확장자입니다. 허용 확장자: " + ALLOWED_EXTENSIONS);
    }
}

예외 처리

잘못된 요청에 대해서는 IllegalArgumentException 등 구체적인 예외를 던져, 클라이언트가 문제를 쉽게 파악할 수 있도록 한다. IllegalArgumentException:인자가 잘못되었을 때 발생하는 예외

정리

정리한 파일 업로드 로직은 다음과 같은 요구사항을 충족한다:

• 중복 파일명 문제 방지 (UUID)
• 유연한 경로 관리 (설정 파일)
• 안전한 저장 (유효성 검사 및 예외 처리)
• 실제 디스크 저장 보장

Post와 Attachment 연관관계 설정

1. 관계 구조

• 게시글 하나(Post)에 첨부파일 여러 개(Attachment)가 달릴 수 있으니까 1:N 관계로 매핑했다.
• Post 쪽에서는 다음처럼 설정:

@OneToMany(mappedBy = "post", cascade = CascadeType.ALL, orphanRemoval = true)
private List<Attachment> attachments = new ArrayList<>();

• mappedBy = "post": Attachment 안의 Post post 필드 기준으로 연관관계 매핑
• cascade = CascadeType.ALL: 게시글 저장 시 첨부파일도 함께 저장
• orphanRemoval = true: 게시글에서 첨부파일을 제거하면 DB에서도 자동 삭제
• new ArrayList<>(): 리스트는 NullPointException 방지를 위해 항상 초기화

연관관계 편의 메서드

양방향 연관관계일 경우, 양쪽에 모두 값을 설정해줘야 정확한 관계가 만들어진다. 이걸 깜빡하면 매핑이 꼬일 수도 있다. 그래서 아래처럼 편의 메서드를 만들어 사용하는 게 안정적이다.

public void addAttachment(Attachment attachment) {
    attachments.add(attachment);
    attachment.setPost(this);
}

• Post가 첨부파일을 관리하는 게 더 자연스러워 보였다.
• 실수할 가능성도 줄어든다. 연관관계를 Post 쪽에서 확실히 책임지도록 만들어줌.

@PrePersist로 자동 날짜 저장

매번 createdAt 필드에 현재 시간을 넣는 게 귀찮아서, JPA 라이프사이클 콜백을 이용했다.

@PrePersist
public void prePersist() {
    this.createdAt = LocalDateTime.now();
}

이제는 저장 전에 자동으로 날짜가 들어가니까 깔끔하다.

파일 업로드 처리 흐름

FileList 개념

프론트에서 <input type="file" multiple>을 사용하면 여러 개 파일을 선택할 수 있는데, 이때 나오는 건 배열이 아니라 FileList 객체다. 배열처럼 생겼지만 진짜 배열은 아니다.

e.target.files[0].name           // 파일 이름
e.target.files[0].size           // 파일 크기 (byte 단위)
e.target.files[0].type           // MIME 타입
e.target.files.length            // 파일 개수

FormData로 전송

일반 JSON은 텍스트만 전송할 수 있어서, 파일 전송은 multipart/form-data 형식을 사용해야 한다. 이럴 때 FormData 객체를 사용하면 편하다.

const formData = new FormData();
formData.append("title", newPost.title);
formData.append("content", newPost.content);

for (let i = 0; i < selectedFile.length; i++) {
    formData.append("files", selectedFile[i]);
}

서버 쪽에서는 @RequestParam이나 List<MultipartFile>로 받을 수 있다.

@PostMapping("/file")
public ResponseEntity<?> upload(
        @RequestParam String title,
        @RequestParam String content,
        @RequestParam List<MultipartFile> files
) {
    // 저장 로직
}

Axios로 전송

await axios.post('http://localhost:8080/file', formData, {
    headers: {
        "Content-Type": "multipart/form-data",
    },
});

Content-Type은 생략해도 브라우저가 자동으로 설정해주긴 하지만, 명시적으로 넣는 게 확실하다.

정리

이번에 연관관계 매핑 + 파일 업로드까지 흐름을 정리하면서 느낀 점:

• JPA에서 연관관계 설정은 생각보다 실수가 많을 수 있어서, 처음부터 편의 메서드로 안정성 높이는 게 중요하다.
• cascade, orphanRemoval 덕분에 저장/삭제가 훨씬 간단해진다.
• FormData와 multipart/form-data 구조는 한 번 익혀두면, 이미지 업로드, 파일 첨부 등에서 자주 쓴다.

시간 들여 구현하고 나니까 훨씬 구조가 깔끔해진 느낌. 다음엔 파일 다운로드나 미리보기 기능도 붙여볼 예정이다.

설치 과정

MySQL :: Download MySQL Installer

MySQL 8 버전을 설치했다. 다운로드를 누르면 가입과 로그인 버튼 2개가 나오는데, 밑에 그냥 다운로드하기를 누르면 가입 없이 바로 다운로드 받을 수 있다.

설치하고 실행하고나면 다음과 같이 설치 화면이 나온다. 서버와 Workbench를 설치해줘야 하기 때문에 Custom을 선택한다.

MySQL Servers와 Workbench를 화살표(⇨)를 눌러 오른쪽으로 옮겨준다.

(Samples and Examples는 예제 코드이므로 상관없음)

Execute를 눌러서 설치를 시작한다.

next >

계정 비밀번호 설정

까먹을 수 있으니 간단하게 설정했다.

next >

이후 계속 next >

서버와 연결

root 와 비밀번호를 입력해서 위에 성공이 떠야한다.

경로 설정

설치하면 C:\Program Files\MySQL\MySQL Server 8.0\bin 위치에 MySQL 실행 파일이 있는 것을 확인할 수 있다. Windows PowerShell 창을 열어 명령어를 입력한다. 성공: 지정한 값을 저장했습니다. 라고 나오면 컴퓨터에 경로를 잘 설정한 것이다.

SETX PATH "C:\Program Files\MySQL\MySQL Server 8.0\bin:%PATH%"

사용자 계정 등록

내부에서만 사용하고 싶으면 주소에 localhost(내 PC), 외부에서도 접속해서 사용 가능하게 하려면 ‘%’를 쓴다.

CREATE USER '계정명'@'주소' identified by '비밀번호';

• SHOW databases - 현재 존재하는 데이터베이스를 확인할 수 있다.
• USE mysql - 기본으로 제공되는 mysql을 사용할 수 있다.
• SELECT * FROM user - mysql 데이터베이스에서 user를 확인해 계정이 잘 추가된 것을 확인한다

데이터베이스 생성

CREATE DATABASE 이름;

명령어를 실행하고 왼쪽 Schemas 창에 마우스 왼쪽을 클릭해서 refresh all로 새로고침을 해서 데이터베이스가 잘 생성되었는지 확인한다.

권한 부여

해당 계정에 데이터베이스에 관한 모든 권한을 부여한다는 명령어이다.

GRANT ALL PRIVILEGES ON 데이터베이스 이름.* TO '계정명'@'%';

권한 확인

그러고 계정이 가지고 있는 권한을 확인할 수 있다.

SHOW GRANTS FOR '계정명'@'%';

계정 연결

계정을 생성했으면 연결을 해야 원하는 계정에 접속할 수 있다. MySQL Workbench 홈(집 모양)에 들어가서 저기 + 를 누른다.

설정 정보 입력 후 Test Connection

• *connection name *: 헷갈리지 않게 데이터베이스 이름으로 설정(상관 없음)
• username : 계정 이름
• default Schema : 기본으로 사용할 데이터베이스 이름

계정 비밀번호 입력

연결 완료

현재 mtvs 계정에 ‘menudb’라는 데이터베이스(스키마)를 생성했고, menudb에서 mtvs 계정에 모든 권한을 부여한 상태를 만든 것이다. 이제 mtvs 계정에 접속해서 DB를 마음대로 다룰 수 있다!

상속은 우리가 알고 있는 것처럼 자식이 부모의 것을 그대로 물려받는다는 의미가 자바에서 그대로 적용된다. A 클래스가 B 클래스를 상속받았다고 한다면, 이 때 상속한 B 클래스를 부모 클래스, 상속 받은 A 클래스를 자식 클래스로 역할을 나눌 수 있다.

상속은 extends 키워드를 사용하여 다음과 같이 표현한다.

public class A extends B{
 ...
}

그러면 B 클래스는 A 클래스(부모)가 가지고 있는 멤버들을 모두 자기 것처럼 사용할 수 있게 된다. 단, 부모가 제외한 것 빼고 사용할 수 있다. (접근 제한자 private, 생성자)

그리고 자바는 단일 상속만을 지원하고 있어 클래스 하나만 부모클래스로 상속받을 수 있다. 다중 상속이 되지 않는다.

상속 관계를 가질 수 있는 조건은?

Is-A 관계여야 한다. ‘~는 ~이다’가 되어야 한다.

제품 클래스와 컴퓨터 클래스가 있다고 하자. ‘컴퓨터는 제품이다’ 맞는 말이며 Is-A 관계이다. 따라서 컴퓨터는 제품 클래스를 상속받을 수 있다. 반대로 ‘제품은 컴퓨터이다’는 말이 되지 않는다. Is-A 관계가 성립하지 않기 때문에 상속 관계가 될 수 없다.

오버라이딩(Overriding)

상속은 부모의 것을 물려받는다는 개념 보다는 부모 클래스의 확장(extends) 개념을 가진다. 물려받은 것을 자기 것처럼 사용하는 것 뿐만 아니라 자식 클래스의 고유 멤버나 메소드를 작성할 수 있다.

특히 부모가 가진 메소드를 커스터마이징할 수도 있는데, 이를 부모 메소드를 자식 클래스에서 재정의한다고 표현하고 오버라이딩 했다고 한다.

부모가 가지는 메소드 선언부를 그대로 사용하면서, 자식 클래스에서 정의한 메소드대로 동작하도록 구현 몸체 부분을 새롭게 다시 작성, 다시 정의하는 기술이다.(메소드 재정의)

이렇게 메소드 재정의를 하면 메소드를 호출할 시 자식클래스에서 재정의한 메소드가 우선적으로 동작하게 된다.

// override 코드

override 코드

상속을 하는 이유

새로운 클래스를 작성할 때 기존에 작성한 클래스를 재사용하기 위함이다. 코드가 반복적으로 사용될 경우 재사용하면 생산성을 크게 향상시킬 수 있다. 또 공통적으로 사용되는 코드가 부모 클래스에 존재하면 수정 사항이 생길 시 부모 클래스만 수정해도 전체적으로 적용된다.

또한, 다형성을 적용하기 위함이다. 다형성은 간단히 말하면 하나의 객체가 여러 가지 타입을 가질 수 있게 한 것이다. 상속을 하면 자식 클래스의 타입은 자기 자신과 부모 2가지 타입을 가지게 된다.

깃은 소스 버전 관리 시스템으로, 소스 코드를 수정하고 변경한 내용들을 자동으로 계속 기록되는 것이다.

예를 들면, 원래 잘 작동하는 소스 코드가 있는데, 거기에다가 다른 기능을 구현하고 싶어 이리저리 코드를 작성했다고 하자. 그러고 실행해보니 오류가 발생하거나, 원하는 대로 기능이 작동하지 않는다면 어떻게 할까? 이 때 작성했던 코드를 수정하거나 작성하기 이전의 잘 작성되었던 코드로 돌아가야 하는데, 어떻게 되돌릴 것이냐 복구할 것인가 하는 문제가 발생한다. 물론 코드를 작성하기 전 백업을 해두는 방법도 있다. 그러나 많은 코드들을 항상 백업해놓고 관리하기는 어렵기 때문에 Git을 통해 기록들을 계속 저장해두는 것이다.

깃 설치하기 Git - Downloading Package

깃허브(Github) & 사용하는 이유

위와 같이 깃은 소스 이력들을 계속 저장하고 관리하는 거라면,

깃허브는 이러한 깃들을 온라인 상에서 자유롭게 쓸 수 있도록 모아놓은 저장소이다.

동시에 여러 사람이 / 같은 버전의 소스를 / 서로 다르게 변경하게 된다면, 서로 버전을 알 수 없는 코드가 생기고 코드가 엉키기 쉽기 때문에 코드를 변경하고 관리하기가 어렵게 된다. 따라서 각 사람들의 깃 버전을 관리해야할 필요가 있고, 그러기 위해서는 서로 코드를 잘 알고 있는 상태가 되어야 한다. 그래서 깃허브를 통해 여러 사람들과 코드를 공유하고 각각 소스 코드의 버전을 관리하도록 하는 것이다. 여러 사람과 협업해야할 때 필수적으로 사용되고 있다.

GitHub(깃허브) 사용법

깃허브에 소스 코드를 올리려면 다음과 같은 과정을 거쳐야 한다.

소스 코드(project) —> staging area —> local repository —> remote repository

간단히 말하면 프로젝트를 업로드 하기 위해 3가지 과정을 거쳐야 한다는 것이다.

프로젝트 폴더에서 open git bash here로 bash 창을 열고 명령어 를 입력을 할 준비를 한다.

1. Git 저장소 생성(init)

프로젝트 폴더에 로컬 저장소(.git)를 생성한다.

git init

명령어를 입력하면 다음과 같이 프로젝트 디렉토리에 .git 저장소가 생성된다. ‘.git 폴더’가 있는지 확인하고 업로드를 시작한다.

2. 임시 저장소에 추가(add)

git add 파일명

업로드하고 싶은 파일을 임시 저장소(staging area)에 추가한다.

3. 로컬 저장소에 저장(commit)

git commit -m "commit 메세지"

임시 저장소에 있던 깃을 로컬 저장소(.git)로 저장한다. 저장할 때 변경 사항과 같은 설명들을 메세지로 남길 수 있다.

4. 로컬 저장소와 원격 저장소(깃허브 repository) 연결(remote)

git remote add origin github repository

repository url은 repository에 code 밑에 나와있다.

5. 원격 저장소에 저장, 업로드(push)

git push -u origin master(main)

이러면 원격 저장소 깃허브에 코드를 성공적으로 업로드할 수 있다!

토큰 발급

원격 저장소에 업로드를 할 때 토큰을 입력하라고 나온다. 이때 당황하지 않고 토큰을 발급 받으면 된다. 설정에서 맨 아래 Developer Settings 에서 다음과 같이 Generate new token을 통해 발급 받을 수 있다.

settings > developer Settings > Personal access tokens > Tokens(classic) > Generate new token